세립도 액세스 제어를 사용하여 검색

Open Distro for Elasticsearch 광범위한 액세스 제어 기능이 내장되어 있습니다.물론 액세스 제어는 민감한 정보에 대한 접근을 막을 수 있지만, Open Distro for Elasticsearch for search에 의존하는 응용 프로그램을 구축하는 데 도움을 줄 수 있습니다.우리 한층 더 토론해 봅시다.

애플리케이션이 표준 HTTP 노드를 사용하여 엔드 유저에게 데이터를 제공한다고 가정합니다.따라서 웹 사용자가 웹 페이지를 불러오면 클라이언트 Javascript는 응용 프로그램 단점에 HTTP 요청을 보내서 특정한 유형의 데이터를 가져오고 데이터는 클라이언트 Javascript로 되돌아오며 브라우저는 사용자에게 화면에 데이터를 보여줍니다.서버 코드는 클라이언트 Javascript에서 쉽게 사용할 수 있도록 HTTP 루트와 매개 변수를 비교적 작게 처리하고 있습니다.매우 전형적인 물건.
프로그램이 충분히 복잡해졌을 때, 코드가 통상적으로 중복되는 것을 발견할 수 있습니다.거의 같은 방법으로 HTTP 요청을 정탐하고 처리하며 Elasticsearch에 문의하고 결과를 되돌려줍니다. 그러나 약간의 차이가 있습니다.이것은 쓰기가 지루할 뿐만 아니라, 더욱 크고 유지하기 어려운 코드 라이브러리를 대표한다.그렇다면 액세스 제어는 어떻게 이 모든 것에 적응합니까?
요청된 유형에 따라 Elasticsearch 사용자의 오픈 버전을 변경하면 되돌아오는 데이터를 변경할 수 있습니다.이 경우 프로젝트를 대표하는 문서가 있습니다. 이 문서는 대중을 위한 필드 - 가격, 색깔, 재료, 설명뿐만 아니라 원가, 공급업체, 성능 등 개인 필드도 포함할 수 있습니다.직원은 특수 로그인 후 모든 정보를 봐야 할 수 있으며, 고객은 공공 정보만 봐야 합니다.물론 모든 유형에 대해 매우 비슷한 서버 코드를 작성하여 조회 DSL의 _source 과 논리의 재구현 부하를 변경할 수 있습니다.또는 오픈 버전으로 이 작업을 완성하고 현장의 가용성을 집중적으로 제어할 수 있습니다.
이 예를 들어 Kibana 개발 도구 (<yourhost>:<yourport>/app/dev_tools#/console 의 검색에서 실행하면 색인에 항목 ecommerce-items 을 추가합니다.

PUT ecommerce-items/_doc/brown-mug
{
    "title": "Brown Mug",
    "description": "This mug features a large handle and a marbled, brown ceramic design.",
    "price" : 5.99,
    "private" : {
        "cost" : 1,
        "supplier" : "Mug World"
     }
}

무슨 일이 발생하든지 간에 우리는 우리의 고객이 private 대상에서 어떤 것도 볼 수 있기를 원하지 않는다.우리는 이 점을 실현하기 위해 오픈 버전의 내장된 액세스 제어 기능을 사용할 것이다.

사용자 역할 만들기(&R)

우선 Kibana에서 사용자를 만들어야 합니다.응용 프로그램은 이 사용자를 사용하여 공공 정보를 제공하기 때문에 public-item-user 라고 명명합니다.먼저 측면 메뉴에서 보안 항목으로 이동한 다음 보조 메뉴에서 내부 사용자를 클릭합니다.이제 내부 사용자 만들기 버튼을 클릭합니다.이것은 너를 데리고 갈 것이다 <yourhost>:<yourport>/app/opendistro_security#/users/create.
인증하려면 자격 증명 제목public-item-user에 사용자 이름과 암호를 두 번 입력합니다.그런 다음 만들기 버튼을 클릭합니다.현재 우리는 이미 사용자를 만들었지만, 그것은 개방 발행판에서 아무것도 할 수 없다.그것을 유용하게 하기 위해서, 우리는 반드시 캐릭터를 만들고 분배해야 한다.
측면 메뉴에서 안전으로 돌아가고 보조 메뉴에서 역할로 돌아가고 역할 만들기 단추를 누르십시오.너는 있어야 한다<yourhost>:<yourport>/app/opendistro_security#/roles/create.이름 제목에서 이름 텍스트 상자에 public-item-viewer 를 입력합니다.그런 다음 제목 색인 권한 아래에서 색인 필드에 ecommerce-items 를 추가한 다음 색인 권한 필드에 indices:data/read/search 을 추가합니다.마지막으로 필드 레벨 보안 제목에서 제외 필드로 이동하여 입력 private.이 모든 작업을 완료한 후 아래쪽으로 이동하여 만들기 버튼을 클릭합니다.
계속하기 전에 왜 **indices:data/read/search가 이런 상황에 대한 정확한 허가인지 연구하는 데 시간을 들읍시다.이 역할을 가진 사용자가 문서를 검색할 수 있지만 작업할 수는 없습니다.색인 사용 권한 상자를 스크롤할 경우 유형 crud 및 search 이 * 사용 권한 그룹임을 알 수 있습니다 *권한 그룹은 일반적으로 사용되는 권한을 속기로 묶습니다.실제로 여기에서 사용할 수 있지만, 필요한 권한을 훨씬 초과할 수도 있습니다. 따라서 우리는 매우 구체적인 권한을 사용할 것입니다. 이 권한은 할 수 있는 일이 매우 적습니다. (잠시 후에 상세하게 설명할 것입니다.)
사용자 public-item-user 와 역할 public-item-viewer 이 있지만 연결되지 않습니다.오픈 버전에서 이것은 맵이라고 부른다.사용자에게 역할을 매핑하려면 보안으로 돌아가서 역할을 선택하고 사용자 public-item-viewer 를 찾은 다음 검색 상자를 사용해야 할 수도 있습니다.그것은 반드시 너를 데리고 가야 한다<yourhost>:<yourport>/app/opendistro_security#/roles/view/public-item-viewer.이제 맵 사용자 탭으로 이동합니다. 목록이 비어 있으므로 맵 사용자를 클릭합니다.URL<yourhost>:<yourport>/app/opendistro_security#/roles/edit/public-item-viewer/mapuser에 위치합니다.제목 Internal users(내부 사용자)에서 Internal users(내부 사용자) 필드로 이동하여 public-item-user 를 선택합니다.그런 다음 지도를 클릭합니다.
현재 사용자(public-item-user는 역할public-item-viewer이 제공하는 모든 권한을 가지고 있습니다.개인이나 익명의 창에서 키바나로 가보자.이 기교는 당신이 두 사용자에게 동시에 로그인할 수 있도록 할 것입니다.개발 도구 <yourhost>:<yourport>/app/dev_tools#/console 로 이동하여 다음 질의를 입력합니다.

GET /ecommerce-items/_search
{
  "query": {
    "match" : {
      "title": "brown"
    }
  }
}

결과가 표시됩니다.

{
    ...,
    "hits" : [
        {
        "_index" : "ecommerce-items",
        "_type" : "_doc",
        "_id" : "brown-mug",
        "_score" : 0.13353139,
        "_source" : {
            "title" : "Brown Mug",
                "description" : "This mug features a large handle and a marbled, brown ceramic design.",
                "price" : 5.99
            }
        }
    ]
}

private 객체가 사라졌습니다.우리의 사용자와 역할은 이미 이 데이터를 필터해 냈다.
여기서 주의해야 할 것은 이 두 캐릭터를 이 특정 색인에만 접근할 수 있도록 설정하는 것이다.이것은 일부 오류나 우연한 이벤트로 인해 사용자에게 증거를 발표하거나 응용 프로그램 오류로 다른 인덱스를 전달할 수 있다면 덮어쓰게 된다는 것을 의미합니다.조회할 때 접근 제어를 거부하기 때문에 발행판 관리의 다른 인덱스를 개방해도 누설될 위험이 없습니다.당신은 그것을 최소 특권 원칙의 실현으로 간주할 수 있습니다.
응용 프로그램의 직원 부분에 대한 라우팅을 설정하려면 private-item-viewer 이라는 역할을 만듭니다. 이 역할은 모든 정보를 볼 수 있는 권한을 가지고 있습니다.위의 절차를 반복하지만 필드 레벨 보안 섹션에서 제외 private 단계를 건너뜁니다.그리고 private-item-user라는 사용자를 만듭니다. 역할은 private-item-viewer입니다.백엔드에서 백엔드까지의 모든 직원 요청은 이 사용자가 요청을 보내서 객체의 모든 필드private에 접근할 수 있도록 합니다.

애플리케이션, 사용자/역할 및 검색 개요

응용 프로그램의 경우, 서로 다른 정보를 가진 다른 경로를 제공하기 위해 최소한의 추상만 필요합니다.개인 정보를 조회해야 하는 직원에게 신분 검증을 거친 루트는 모든 조회 준비, 요청, 서열화, 반서열화, 표현 코드를 공공 루트로 다시 사용할 수 있다.나중에 데이터가 변경되고 문서의 다른 부분을 포함하거나 제외하기를 원할 때 코드를 수정할 필요가 없습니다. 역할만 변경하면 프로그램이 지정한 필드에만 서비스를 제공합니다.

총결산

Open Distro for Elasticsearch의 액세스 제어 기능을 사용하면 프로그램에 필요한 코드 양을 줄일 수 있습니다. 이 프로그램은 상황에 따라 같은 인덱스의 다른 데이터에 서비스를 제공합니다.상기 모델은 데이터 가시성의 책임을 응용 프로그램에서 검색 엔진으로 옮긴다.이러한 방식을 통해 응용 프로그램은 더욱 간단하고 데이터 단계에서 집중적이고 코드가 없는 제어를 얻을 수 있습니다.
이런 모델도 많은 다른 상황까지 보급할 수 있다.두 그룹에 민감한 문서가 있고 두 그룹 모두 전체 문서를 볼 수 없다고 가정하십시오.또한 보안이나 규정 준수 때문에 전체 문서를 확인해야 하는 다른 그룹도 있습니다.동일한 사용자, 역할, 권한 모드를 사용하여 같은 조회에서 서로 다른 데이터 가시성을 제공합니다.그러나 이것은 또 다른 시대의 이야기이다. 방문Open Distro for Elasticsearch Blog은 더 많은 정보를 알고 최신을 유지한다.