설치된 Elasticsearch가 극도로 악용될 수 있다는 사실에도 불구하고 이에 대한 정보가 심각하게 부족한 것 같습니다.
이 기능을 사용할 때 제가 가장 우려하는 점은 비전문가로서 가능한 취약점이 무엇인지, 어떻게 해결하는지 전혀 모른다는 것입니다.
보안 환경 내에서 다음을 수행할 수 있도록 Elasticsearch를 잠그는 방법을 누군가 나에게 설명해 줄 수 있습니까?
사용자당 여러 인덱스. 미리 이를 생성할 수 있다고 가정하면, 사용자는 권한이 부여된 경우 쿼리할 수 있는 경우를 제외하고는 다른 사용자의 인덱스에 대한 작업을 수행할 수 없어야 합니다. (각 사용자의 URL에 어떤 형태의 비밀 키가 있을 수 있나요?)
사용자는 자신의 인덱스에서 원하는 대로 개체를 추가하고 삭제할 수 있지만 인덱스를 삭제할 수는 없습니다.
사용자의 메모리 크기에 대한 일부 제한 형태로, 문제가 발생하더라도 서비스에 과부하가 걸리지 않도록 합니다.
이 중 일부는 애플리케이션 수준에서 수행되어야 한다고 생각하며 여러분이 저를 위해 이것을 작성해 줄 것이라고 기대할 수는 없습니다. 그러나 기본 구성은 너무 개방적이며 여기에 사용자 정의 API 레이어를 제공하더라도 누군가가 쉽게 작성할 수 있습니다. 이를 우회하고 서버와 직접 통신합니다.
답변1
제 생각에는 귀하가 요청한 방식으로 ES를 보호하는 유일한 방법은 다른 애플리케이션 계층 뒤에 ES를 잠그고 해당 계층이 https/ssl 전송, 인증 및 권한 부여 제어를 처리하도록 하는 것입니다.
ES 측면에서는 jetty ES 보안 플러그인이 개발되었습니다. 성공 여부는 알 수 없습니다. 플러그인이 처음 출시될 예정이었을 때 ES를 배포했을 때 살펴보시기 바랍니다.
답변2
이 모든 "비즈니스 로직"을 포함하는 중간 HTTP 프록시를 생성하고 로컬 호스트에서만 ElasticSearch 액세스를 허용해야 할 것 같습니다. 이렇게 하면 ES에 대한 직접 액세스가 차단되고 원하는 정책을 결정하고 시행할 수 있습니다(아아! ;)
"이 사용자 정의 API 레이어를 제공하더라도 누군가 쉽게 우회할 수 있습니다.": ES가 로컬 호스트의 연결만 허용하는 경우에는 불가능합니다.
메모리 사용량 제한이 가능하다고 생각하지 않습니다. 프록시 계층 내에서 쿼리를 사전 승인할 수 있을까요?
답변3
ES 앞에서 실행되는 Nginx를 사용하여 비슷한 작업을 수행했습니다. URL의 키워드를 기반으로 Nginx에서 "인증"을 설정할 수 있습니다. 이 문서에 정의된 사용 사례를 참조하세요.http://www.elasticsearch.org/blog/playing-http-tricks-nginx/
답변4
Elasticsearch를 openvpn 터널에 바인딩했습니다.
/etc/elasticsearch/elasticsearch.yml에서:
network.host: 172.16.xxx.xxx
여기서 172.16.xxx.xxx는 openvpn이 할당한 IP 주소입니다.