암호 화 , 사용 자 등 을 통해 무료 로 Elasticsearch 클러스터 의 보안 을 유지 하 는 팁 | Elastic Blog 
 2019 년 6 월 4 일 엔지니어링 
 Elastic Stack 6 . 8 과 7 . 1 의 릴리즈 로 , 수많 은 Elasticsearch 보안 기능 이 기본 배포 에 무료 로 포함 되 어 누구 나 좀 더 광범위 하 게 이용 할 수 있 게 되 었 습니다 . 이 소식 을 나누 게 되 어 정말 기대 가 되 지만 이제 새로운 도전 과제 중 하나 는 Elastic Stack 의 보안 을 유지 하 는 방법 에 대한 모든 설명서 와 지침 을 업데이트 하 는 것 입니다 . 보안 을 유지 하 기 위해 Stack 앞 에 있 는 프록시 서버 에 만 의존 하 던 시절 은 갔 습니다 ! 
 저 는 보안 에 중점 을 둔 대부분 의 인기 있 는 예전 블로그 포스팅 을 살펴보 았 습니다 . 그리고 이제 지침 을 업데이트 하 고 , 일부 근거 없 는 믿음 을 떨쳐 버리 고 , 새로운 아이디어 몇 가지 를 지적 하 고 , 사용 자 가 그 어느 때 보다 도 Stack 의 보안 을 더 잘 유지 할 수 있 도록 하 려고 합니다 . 
 예전 글 과 는 전혀 링크 시키 지 않 을 예정 입니다 . 일부 예전 글 에서 는 지난 몇 년 간 Elastic Stack 이 변화 해 온 방식 으로 인해 이제 는 위험 하 다고 여겨 지 는 조언 을 하 고 있 기 때문 입니다 . ( 예전 블로그 에서 제공 하 는 보안 관련 조언 은 조심 하 시 는 게 좋 습니다 . 모든 것 이 상당히 빨리 변하 니까요 . ) 이 페이지 에서 그러 한 모든 링크 를 전해 드리 긴 하 겠 지만 , 그러 한 글 의 캐시 된 버전 을 제공 하 는 다른 사이트 를 보 시 면 , 그 사이트 에 이 페이지 로 의 링크 를 전달 해 주 시 기 바랍니다 . 
 TLS 암호 화 
 TLS 암호 화 는 이제 기본 배포 내 에서 무료 Elasticsearch 및 Kibana 보안 의 일부 가 됩니다 . TLS 의 목적 은 네트워크 통신 을 암호 화 하 는 것 입니다 . 우리 는 클러스터 의 노드 간 통신 과 클라이언트 와 클러스터 간 통신 그리고 Kibana 로부터 사용 자 로 의 연결 을 암호 화 합니다 . 
 우리 는 또한 TLS 인증서 를 사용 해 노드 가 클러스터 연결 을 위해 허락 을 받 아야 하 도록 하 고 있 습니다 . TLS 가 없 다면 , 누구 나 노드 를 클러스터 에 추가 할 수 있 습니다 . 여러 가지 비 도덕 적 인 목적 으로 공격자 들 이 이 를 악용 할 수 도 있 지만 , 훨씬 더 일반 적 인 사례 는 노드 가 뜻 하 지 않 게 잘못 된 클러스터 를 연결 할 때 입니다 . 적절 한 인증서 가 없 으면 노드 가 클러스터 를 연결 할 수 없 기 때문 에 TLS 는 이러 한 문제 를 피하 는 데 도움 이 될 수 있 습니다 . 
 6 . 8 과 7 . 1 전 에 는 , 베이직 라이선스 를 사용 하 면서 Elastic Stack 을 위해 TLS 가 필요 한 경우 , 일종 의 프록시 에 의존 해야 했 을 것 입니다 . 이 를 위해서 는 상당 한 양 의 설정 작업 이 추가 됩니다 . 노드 와 클라이언트 간 에 프록시 를 설정 해야 할 필요 가 없 더라도 , TLS 구성 은 그 자체 가 이미 상당히 어렵 습니다 . 프록시 를 추가 함 으로써 , 어려운 문제 를 현저히 더 어렵 게 만들 게 됩니다 . 이제 우리 는 Elastic Stack 에서 직접 TLS 지원 을 활용 할 수 있 습니다 . 
 우리 는 TLS 구성 방법 에 대한 설명서 를 꽤 많이 갖추 고 있 습니다 . TLS 를 가지 고 작업 을 해 보 신 적 이 있 다면 , 인증서 설정 이 결코 쉽 지 않 다는 것 을 아실 것 입니다 . 그러나 우리 는 좀 더 쉽 게 처리 할 수 있 도록 클러스터 차원 의 인증서 와 인증 기관 생성 을 도와 주 는 기본 도구 를 갖추 고 있 습니다 . 모든 Elastic Stack 구성 요소 에서 TLS 를 가장 잘 구성 하 는 방법 에 대한 세부 사항 을 다루 는 블로그 포스팅 이 앞 으로 이 공간 에 게재 될 예정 이 니 , 눈여겨 봐 주 시 기 바랍니다 . 오늘 시작 하 기 위한 가장 쉬운 방법 두 가지 는 어떤 것 일까요 ? 이 Elasticsearch 보안 시작 하 기 블로그 포스팅 을 확인 해 보 시 거나 공식 Kubernetes Operator 를 살펴보 시 는 것 입니다 . 
 버전 6 . 8 과 7 . 1 에서 는 모두 에게 기본 인증 이 제공 됩니다 . 인증 의 목적 은 클라이언트 가 Elastic Stack 에게 자신 의 신원 을 밝힐 수 있 도록 하 는 것 입니다 . 인증 은 시스템 에 로그인 하 기 위해 사용 하 는 사용 자 이름 과 비밀 번호 로 알려져 있 는 경우 가 많 습니다 . 데이터 로 가득 찬 클러스터 를 온 세상 에 개방 된 채 로 두 는 것 은 일반 적 으로 좋 지 않 은 생각 입니다 . 비밀 번호 를 사용 하 지 않 고 누구 나 접속 할 수 있 는 인터넷 에 클러스터 가 직접 연결 되 어 있 는 경우 에 는 특히 위험 합니다 . 
 과거 에 는 , 클라이언트 와 클러스터 간 에 기본 인증 이 활성 화 되 어 있 는 Nginx 서버 를 사용 하 도록 조언 했 습니다 . 이 구성 을 제대로 하 는 것 은 놀랄 만큼 어렵 습니다 . 모든 노드 가 외부 요청 에 대한 서비스 를 제공 할 수 있 기 때문 에 , 노드 에서 방화벽 을 차단 하 는 것 을 잊어버리 는 경우 , 누구 라도 인증 없이 클러스터 에 접속 할 수 있 을 것 입니다 . 
 우리 는 이제 무료 로 기본 영역 및 파일 영역 을 사용 해 인증 을 허용 합니다 . 파일 영역 은 모든 노드 에서 파일 에 사용 자 정보 를 저장 합니다 . 모든 노드 에서 파일 이 동기 화 되 어 있 도록 유지 해야 합니다 . 기본 영역 은 보다 간소 화 된 환경 이 며 , 다음 과 같이 누구 나 예상 하 는 작업 을 수행 합니다 . 모든 노드 가 액세스 하 는 클러스터 의 인덱스 에 사용 자 데이터 가 저장 됩니다 . REST API 를 통해 사용 자 이름 과 비밀 번호 를 추가 한 다음 , 그 계정 으로 로그인 할 수 있 습니다 . 더 자세 한 내용 은 Elasticsearch 보안 시작 하 기 블로그 를 참조 하 세요 . 
 LDAP , Active Directory , SAML 또는 그 밖 에 좀 더 복잡 한 인증 이 필요 한 경우 , 이 중 일부 와 기타 상용 기능 이 탑재 된 Cloud ( SaaS ) 서비스 를 제공 합니다 . 또는 저희 에게 연락 하 셔서 온 - 프레 미스 형 솔루션 이 가능 한지 상의 하 세요 . 저희 가 제공 하 는 다른 인증 옵션 을 보 시 려면 , 인증 설명서 를 확인 해 보 시 기 바랍니다 . 
 승인 과 인증 은 서로 관련 되 어 있 는 경향 이 있 습니다 . Elastic Stack 도 마찬가지 입니다 . 클러스터 와 인덱스 , 그리고 문서 와 필드 수준 까지 승인 규칙 을 정의 할 수 있 는 아주 유연 한 시스템 을 갖추 고 있 으며 , 또한 승인 엔진 이 라고 하 는 것 을 통해 사용 자 가 자체 적 인 승인 플러그인 을 구축 할 수 도 있 습니다 . 
 지금 까지 , 이 공간 에서 제공 해 드린 조언 은 상당히 대략 적 인 것 이 었 습니다 . 과거 에 는 몇 가지 방식 으로 Nginx 같 은 프록시 를 이용 해 다소 복잡 한 필터링 규칙 을 작성 한 다음 , 필터링 된 별칭 을 활용 하 여 거의 승인 처럼 보이 는 작업 을 하 도록 제안 해 왔 습니다 . 우리 는 모든 분 들 이 승인 을 위해 이러 한 방법 을 사용 하 지 않 으실 것 을 강력히 권장 합니다 . 그런 것 은 보안 기능 이 아니 며 , 아마도 사용 자 가 원 하 는 일 을 해 주 지 않 을 것 이 며 , 유지 관리 에 엄청나 게 취약 합니다 . 시간 이 지나 면서 Elasticsearch API 의 수 가 현저 하 게 증가 했 기 때문 에 이러 한 솔루션 은 더 이상 사용 자 가 정말 원 하 는 것 을 해 주 지 못합니다 . 쿼리 인덱스 와 거기 에 포함 된 데이터 에 액세스 하 는 방법 은 많이 있 습니다 . 모든 요청 하나 하나 를 모두 차단 하 거나 제한 했 는지 확인 하 는 방법 은 없 습니다 . 두 번 째 이유 는 첫 번 째 이유 와 연관 되 어 있 는데 , 보호 해야 할 엔드 포인트 가 너무나 많 고 , 언제나 새로운 엔드 포인트 를 추가 하 고 있 기 때문 입니다 . 그러 한 필터 를 계속 해서 업데이트 하 려면 엄청나 게 방대 한 작업 이 될 것 입니다 . 
 다행히 도 , 더 이상 이것 에 대해 걱정 할 필요 가 없 습니다 . 6 . 8 과 7 . 1 에서 는 상당 한 수 의 승인 기능 을 사용 할 수 있 습니다 . 여기 이 블로그 에서 설명 하 기 에 는 너무 많 은 내용 이 지만 Elastic Stack 보안 설명서 에서 기존 의 모든 권한 을 아주 잘 설명 해 놓 고 있 습니다 . 앞 으로 시간 을 갖 고 향후 블로그 포스팅 에서 우리 의 사용 권한 모델 을 이용 해 구축 될 수 있 는 솔루션 몇 가지 에 대해 설명 해 드리 려고 합니다 . 
 승인 처럼 , 개별 문서 와 필드 에 적용 될 수 있 는 좀 더 고급 한 승인 기능 을 갖추 고 있 습니다 . 자체 인증 및 승인 플러그인 을 구축 할 수 있 고 , 클러스터 에서 보안 이벤트 를 로 깅 할 수 도 있 습니다 . 이것 을 저희 Cloud 서비스 의 일환 으로 사용 할 수 도 있 고 , 또는 저희 에게 연락 하 셔서 온 - 프레 미스 형 옵션 에 대해 상의 하 실 수 도 있 습니다 . 
 VPN 및 / 또는 방화벽 으로 스택 보호 
 과거 의 조언 상당수 가 Elastic Stack 을 병화 벽 이나 VPN 으로 보호 하 도록 제안 해 왔 습니다 . 이러 한 조언 의 목적 은 대부분 TLS 와 인증 이 없 으면 프록시 만 사용 해서 클러스터 를 보호 하 는 것 이 어려울 수 있 으며 , 따라서 모두 에 대한 액세스 를 차단 하 는 것 이 모든 움직이 는 부분 을 적절 하 게 구성 하 려고 노력 하 는 것 보다 더 쉽 기 때문 이 었 습니다 . 
 TLS 와 인증 이 활성 화 된 상태 에서 도 여전히 그렇게 하 고 싶 으시 면 , 그것 도 좋 은 생각 일 수 있 습니다 . 보안 은 여러 계층 이 있 을 때 가장 좋 습니다 . 지금 이것 의 좋 은 부분 하나 는 VPN 과 방화벽 이 그냥 계층 이 아니 라는 점 입니다 . 
 제한 된 스크립트 
 오래 전 에 Elasticsearch 에서 스크립팅 을 제한 하 는 것 에 대한 블로그 포스팅 을 한 적 이 있 습니다 . Painless 스크립팅 언어 의 개발 로 , 나쁜 의도 를 가지 고 있 는 스크립트 조차 도 클러스터 를 종료 시키 기 가 훨씬 더 어렵 습니다 . 하지만 불 가능 한 것 은 아닙니다 . 이 주제 에 대한 저희 의 현재 입장 을 다루 는 스크립팅 보안 설명서 에서 모범 사례 몇 가지 를 소개 하 고 있 습니다 . 그러나 다시 말씀 드리 지만 , 언제나 환경 을 검토 하 고 , 그 환경 에 가장 합리 적 인 단계 를 밟 아야 합니다 . 보안 은 여러 계층 이 있 을 때 가장 좋 습니다 . 따라서 단 하나 의 최고 옵션 은 없 습니다 . 
 보안 의 이유 로 클러스터 와 노드 를 격리 하 는 것 이 언급 된 경우 가 많이 있 었 습니다 . 이것 은 컨테이너 에서부터 방화벽 과 IP 필터링 에 이르 기 까지 모든 것 이 될 수 있 습니다 . 
 이것 은 여전히 아주 좋 은 조언 이 며 , 할 수 있 는 한 모든 것 을 격리 하 는 것 은 훌륭 한 보안 팁 입니다 . 지난 몇 년 동안 , 우리 는 그 어느 때 보다 도 이 를 더 쉽 게 만들 기 위해 많 은 작업 을 했 습니다 . Docker Hub 에 게시 된 저희 의 공식 컨테이너 이미지 를 사용 하 실 수 있 습니다 . Elasticsearch Service 를 활용 하 실 수 있 으며 , 힘든 작업 은 저희 가 모두 처리 해 드리 겠 습니다 . 그리고 구동 하 실 수 있 는 공식 Kubernetes Operator 가 이제 막 발표 되 었 습니다 . 
 인덱스 백업 ( 쉽 게 변경 될 수 있 으므로 특히 . kibana ) 
 데이터 백업 은 여전히 언제 나 와 같이 중요 합니다 . 보안 이 어떤 식 으로 든 백업 의 중요 성 을 바꾸 지 는 않 지만 , 백업 이 라는 이 오래 된 작업 을 위한 좀 더 새로운 방식 을 가르쳐 드리 겠 습니다 . 
 가장 큰 장점 은 Kibana Space 를 사용 해 누가 특정 대시보드 를 수정 할 수 있 는지 제한 할 수 있 다는 것 입니다 . 이것 또한 6 . 8 과 7 . 1 의 일환 으로 무료 로 릴리즈 되 었 습니다 . 과거 에 는 , Kibana 에 액세스 할 수 있 다면 , 아마도 원 하 는 모든 것 을 변경 할 수 있 었 을 것 입니다 . 누군가 가 대시보드 를 엉망 으로 만드 는 것 도 드문 일 이 아니 었 고 , 어떤 경우 에 는 실수 로 모든 것 을 삭제 해버릴 수 도 있 었 습니다 . 조언 은 실수 로부터 신속 하 게 복구 할 수 있 도록 . kibana 인덱스 를 주기 적 으로 백업 하 라는 것 이 었 습니다 . 인덱스 를 복구 하 는 것 은 대시보드 전체 를 다시 구축 하 는 것 보다 훨씬 더 빠릅니다 . . kibana 를 백업 하 는 것 은 여전히 중요 하 지만 , Space 와 승인 덕분 에 주기 적 으로 복구 할 필요 는 없 어야 합니다 . 
 보안 의 또 다른 큰 장점 은 누 가 스냅샷 을 찍 고 , 인덱스 를 생성 하 고 , 데이터 를 수정 할 수 있 는지 를 제어 할 수 있 다는 것 입니다 . 보안 이 없 다면 , 읽 기 만 가능 해야 하 는 사용 자 가 데이터 에 치명 적 인 변경 을 가할 수 도 있 을 것 입니다 . 보안 이 활성 화 되 면 , 우리 는 몇 가지 단계 를 밟 아서 바라 건대 중요 한 데이터 에 우연히 변경 이 생기 지 않 도록 방지 할 수 있 습니다 . 
 그럼 이제 할 일 은 ? 
 이 포스팅 의 목적 은 Elastic Stack 배포 의 보안 을 유지 하 는 방법 에 대한 이전 의 조언 일부 를 다시 점검 하 는 것 이 었 습니다 . 보안 의 세계 에서 , 변하 지 않 는 것 은 변한다는 것 뿐 입니다 . 이 블로그 의 조언 조차 도 언젠가 낡 은 것 이 되 고 틀린 조언 이 될 것 입니다 . Elastic Stack 의 보안 은 가능 한 옵션 의 수 가 많 아 벅찬 것 이 될 수 있 습니다 . ( 이것 은 버그 가 아니 라 기능 입니다 . ) 반드시 포럼 에 질문 을 하 시 거나 , 저희 블로그 와 설명서 를 읽 어 보 세요 . 
 간단 한 버튼 한 개 로 Elastic Stack 의 보안 을 유지 하 는 쪽 을 선호 하 시 면 , 몇 가지 옵션 이 있 습니다 . 저희 Elasticsearch Service 는 모든 클러스터 에 대한 TLS 구성 이 되 어 있 고 , 인증 과 승인 이 활성 화 되 어 있 으며 , 저희 엔터 프라이즈 보안 기능 이 기본 으로 활성 화 되 어 있 습니다 . 클라우드 가 편치 않 으시 다면 , Elastic Cloud Enterprise ( ECE ) 로 자체 데이터 센터 에서 Elasticsearch Service 의 수많 은 동일 한 기능 을 사용 하 실 수 있 습니다 . 또한 사용 자 를 위한 TLS 활성 화 와 인증 구성 등 복잡 한 작업 일부 가 기본 으로 처리 되 는 Kubernetes Operator 도 갖추 고 있 습니다 . 물론 , 자체 Stack 을 실행 하 는 엔터 프라이즈 고객 이 시 라면 , 발생 할 수 있 는 모든 문제 해결 을 도와 드리 는 환상 적 인 지원 팀 을 이용 하 실 수 있 습니다 . 
 앞 으로 저희 가 갖추 게 되 는 모든 것 을 눈여겨 봐 주 시 기 바랍니다 . 수많 은 방법 안내 가 계획 되 어 있 으며 앞 으로 여러 가지 새로운 보안 기능 도 보 시 게 될 것 입니다 . Elastic Stack 을 사용 하 시 기 에 아주 좋 은 때 죠 !