암호화, 사용자 등을 통해 무료로 Elasticsearch 클러스터의 보안을 유지하는 팁

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을 사용하시기에 아주 좋은 때죠!