Amazon Web Services ブログ

Amazon Elasticsearch Service へのアクセスコントロールの設定

Dr. Jon Handler (@_searchgeek) は、検索技術を専門とする AWS ソリューションアーキテクトです。

Amazon Elasticsearch Service (Amazon ES) ドメインを保護することで、権限のないユーザーがデータにアクセスしたり変更したりすることを防ぐことができます。ほとんどのお客様は、IP アドレスベースまたは ID ベースのアクセスポリシーのセキュリティを望んでいますが、利便性からオープンアクセスを選択しています。オープンアクセスのドメインは、インターネット上の任意の当事者から Amazon ES ドメインへのデータの作成、表示、変更、および削除の要求を受け入れるため、このオプションはほとんどのお客様にとって適切なものではありません。

以前のブログ記事「Amazon Elasticsearch Service ドメインのアクセスをコントロールする方法」では、アクセスコントロールについて詳細に説明しました。このブログ記事では、ドメインの IAM ポリシーを開始する簡単な方法をいくつか紹介します。AWS Identity and Access Management (IAM) ポリシーを設定するにはいくつかの作業が必要ですが、この「予防的対策」により後で大量の作業が発生するのを防ぐことができます。

Amazon Elasticsearch Service における主要なアクセスコントロールの概念

Amazon ES が作成するドメインには、Elasticsearch クラスタ内のノードと複数の AWS サービスのリソースが含まれます。Amazon ESがドメインを作成すると、ドメインはサービス制御された VPC でインスタンスを起動します。これらのインスタンスの前面には Elastic Load Balancing (ELB) があり、ロードバランサーのエンドポイントはRoute 53 を通じて発行されます。ドメインへのリクエストは、ドメインの EC2 インスタンスにルーティングする ELB ロードバランサをパススルーします。リクエストがどこに行くかに関わらず、インスタンスは IAM にコンタクトしてリクエストが承認されているかどうかを判断します。承認されていないリクエストはブロックされ、破棄されます。

IAM ポリシーがどのように適用され、解決されるかを理解するための鍵は、次の点にあります。

  • ポリシーの場所: IAM ポリシーは、ドメインまたは個々のユーザーまたはロールに付加できます。ポリシーがドメインに付加されている場合は、リソースベースのポリシーと呼ばれます。ユーザーまたはロールに関連付けられている場合は、ユーザーベースのポリシーと呼ばれます。
  • ポリシーの解決: IAM は、リクエストが承認されているかどうかを判断するために、リクエストに適用されるすべてのユーザーベースおよびリソースベースのポリシーを収集します。詳細については、ブログ記事「Amazon Elasticsearch Service ドメインのアクセスコントロールを設定する方法」を参照してください。

リソースベースのポリシー、ユーザーベースのポリシー、またはそれらの組み合わせを作成するかどうかにかかわらず、IAM は特定のリクエストに対してすべてのポリシーを尊重します。

Amazon ES コンソールのウィザードを使用してドメインを作成すると、Amazon Elasticsearch Service はさまざまな種類のアクセスに対していくつかのテンプレート IAM ポリシーを提供します。

  • [1 つ以上の  AWS アカウントまたは IAM ユーザーにアクセスを許可、または拒否する] を選択した場合: ドメインにアクセスする必要がある IAM ユーザーまたはロールを指定します。ドメインへのすべてのリクエストは、AWS 署名バージョン 4 署名で署名する必要があります。リクエストがドメインに到達すると、署名検証とアクセスコントロールのためにリクエストが IAM に転送されます。
  • [Allow access to the domain from specific IP(s) (特定の IP からのアドメインへのアクセスを許可する)] を選択した場合: IP または CIDR ブロックを指定します。その IP アドレス範囲からの匿名 (署名なし) リクエストは許可されます。
  • [Deny access to the domain (ドメインへのアクセスを拒否する)] を選択した場合: 署名付きまたは署名なしにかかわらず、リクエストは許可されません。
  • [Deny access to the domain (ドメインへのアクセスを拒否する)] を選択した場合: 署名付きまたは署名なしにかかわらず、リクエストは許可されません。このテンプレートを選択すると、Amazon ES からポップアップ警告が表示されます。

シンプルな IP アドレスベースのセットアップ
Amazon Elasticsearch Service を使い始めたばかりのときは、データをすばやく読み込んだり、いくつかのクエリを実行したり (コマンドラインから、または Kibana を使用して)、コマンドラインからより詳細な検査と監視を行いたいものです。オープンアクセスポリシーは、ネイティブの Elasticsearch クライアント、curl、ウェブブラウザなどのツールがクラスタとやりとりすることを可能にするため、最も早く始める方法となります。

その性質上、オープンアクセスは安全ではありません。オープンアクセスポリシーはお勧めできません。IP アドレスベースのアクセスコントロールを使用すると、ドメインを保護することができます。不正な訪問者やポートスキャナは、次のようなメッセージで拒否されます。

{“Message”: “User: anonymous is not authorized to perform: es:ESHttpGet on resource:<domain ARN>”}

開発を EC2 インスタンスから行う場合は、VPC を設定してパブリック IP アドレスまたは Elastic IP アドレス (EIP) を割り当てることができます。

この簡単なセットアップで、[Allow access to the domain from specific IPs] オプションを選択すると、次のようなポリシーを生成できます。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "",
      "Effect": "Allow",
      "Principal": {
        "AWS": "*"
      },
      "Action": "es:*",
      "Condition": {
        "IpAddress": {
          "aws:SourceIp": [
            "111.222.333.444/0"
          ]
        }
      },
      "Resource": "arn:aws:es:us-west-2:123456789012:domain/mydomain/*"
    }

 

IPアドレス、アカウント ID、ドメイン名(赤で表示) を必ず自分の値に置き換えてください。

この設定は、開発およびテストのために必要な基本アクティビティをサポートします。curl のようなツールを使ってコマンドをクラスタに直接送ることができます。その EC2 インスタンスで Kibana を実行できます。IP アドレスベースのアクセスポリシーはフルアクセスを許可します。署名されていても匿名であっても、異なる IP アドレスからのドメインへのその他のすべてのリクエストは、IAM によって拒否されます。

Kinesis Firehose、Amazon CloudWatch ログ、または AWS IoT で使用するためのセットアップ
Amazon Elasticsearch Service を開始するには、別の AWS サービスからデータを送信するのが簡単です。Kinesis Firehose ストリームを作成するか、CloudWatch ログデータを Amazon ES にストリーミングするには、これらのサービスがドメインに書き込むことを許可するロールを作成する必要があります。IAM のポリシー解決により、他のサービスからのアクセスが許可され、ドメインにデータを書き込むことができるようになります。IP アドレスベースのポリシーによって、コマンドと Kibana のための EC2 インスタンスへのアクセスが許可されます。他のすべてのリクエストへのアクセスは拒否されます。

AWS IoT の安全なアクセスを設定する方法については、IP アドレスベースのポリシーを使用する方法について説明しているブログ記事「Analyze Device-Generated Data with AWS IoT and Amazon Elasticsearch Service (AWS IoT および Amazon Elasticsearch Service によるデバイス生成データの分析)」を参照してください。

IP アドレスがわからない場合のセットアップ
多くの場合、リクエスト元の静的 IP アドレスはわかりません。データセンター内のノードのセット、モバイルアプリケーションのサポート、または自動スケーリングされた一連のウェブサーバーまたは Logstash インスタンスからのリクエストの送信で、Kibana を実行することができます。

このような場合、VPC の既知の IPアドレスでリバースプロキシを使用して、Kibana から Amazon Elasticsearch Service サービスドメインにリクエストを転送し、ユーザーベースの認証で署名バージョン 4 の署名を使用してアプリケーションサーバーからリクエストを送信できます。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::123456789012:role/webserver "
      },
      "Action": ["es:ESHttpGet"],
      "Resource": "arn:aws:es:us-west-2:123456789012:domain/mydomain/*"
    },
    {
      "Sid": "",
      "Effect": "Allow",
      "Principal": {
        "AWS": "*"
      },
      "Action": "es:*",
      "Condition": {
        "IpAddress": {
          "aws:SourceIp": [
            "111.222.333.444/0",   <-- プロキシの IP アドレス
            "112.223.334.445/0"    <-- インスタンスの IP アドレス
          ]
        }
      },
      "Resource": "arn:aws:es:us-west-2:123456789012:domain/mydomain/*"
    }

  ]
}

 

プロキシサーバーの IP アドレスを IP アドレスベースのポリシーに置き換えて、プロキシからのロクエストを許可します。ポリシーに別の IP アドレスを追加して、コマンドラインと Kibana のためのアクセスを開くこともできます。

前述のポリシー例では、ウェブサーバーのロールに許可されているアクションを HTTP GET 呼び出しに制限しています。作成する IAM ポリシーでは、さまざまなコマンドと HTTP メソッドを許可しているため、さまざまなアクターのアクセスコントロールを設定できます。詳細については、ブログ記事「Amazon Elasticsearch Service ドメインのアクセスをコントロールする方法」を参照してください。

プロキシを使用してリクエストの署名を簡素化する
プロキシを作成すると、プロキシの IP アドレスをアイデンティティのソースとして使用して、ドメインへのアクセスをコントロールできます。プロキシから許可されたリクエストのみを発信することによって、アクセスをコントロールします。署名バージョン 4 のリクエスト署名を使用して、リクエストの背後にあるアイデンティティ情報を提供することもできます。Amazon ES は IAM を使用してこれらのリクエストを認証し、許可または拒否します。

リクエストの署名を実装するには、コードを記述する必要があります。これは、コマンドラインまたは Kibana のアクセスのための開発の追加ハードルになります。リクエストを受け取り、署名バージョン 4で署名し、AWS に転送する小さなアプリケーションを提供するオープンソースプロジェクトがあります。

そのような署名プロキシがここにあります: https://github.com/abutaha/aws-es-proxy。この小さなアプリケーションはポート 9200 でリッスンし、署名されたリクエストを Amazon Elasticsearch Service に転送します。

注意: この署名プロキシは、AWS ではなくサードパーティによって開発されたものです。これは開発やテストには適していますが、本番稼働用ワークロードには適していません。AWS は外部コンテンツの機能または適合性について責任を負いません。この署名プロキシを使用すると、1 つ以上の AWS アカウントまたは IAM ユーザーにアクセスを許可、または拒否する テンプレートを使用して、ドメインのポリシーを次のように設定できます。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::123456789012:user/susan"
      },
      "Action": "es:*",
      "Resource": "arn:aws:es:us-west-2:123456789012:domain/mydomain/*"
    }
  ]
}

 

ユーザー ARN と赤のドメイン ARN を生成されたポリシーからのものに置き換えます。プロキシを実行し、127.0.0.1:9200 でリッスンします。次に、curl を使用して Elasticsearch API 呼び出しを http://127.0.0.1:9200/ に送信すると、それらが使用するドメインに転送されます。開発マシン上で Kibana をローカルで実行する場合は、kibana.yml のhttp://127.0.0.1:9200/ を参照してください。

CloudTrail を使用してアクセスポリシーの変更を監視する
Amazon CloudTrail は、さまざまなサービスと対話するときに AWS に送信されるリクエストのログを提供します。Amazon Elasticsearch Service は、ドメインの作成、ドメイン設定の更新、タグの追加など、すべての管理アクションに対して CloudTrail イベントを送信します。CreateElasticsearchDomain および UpdateElasticsearchDomainConfig API 呼び出しの CloudTrail イベントを監視して、組織内のユーザーがドメインを作成または変更するときにアクセスポリシーを検証することをお勧めします。これらのログを使用して、すべてのアクセスポリシーを確認し、前述のプラクティスに準拠していることを確認できます。

まとめ
これで、テストと開発の際にニーズに合ったアクセスポリシーを簡単に設定できることを示すことができたと考えています。ご質問、コメント、ご提案があれば、コメントに投稿してください。