#amazon-cloudsearch
OpenSearch Service で動くマルチテナントな商品検索の認証認可設計(前編)
## はじめに こんにちは、BASE Department で PHPer をしている @meihei です。 BASE の商品検索では、Amazon OpenSearch Service を使っています。マルチテナントのプールモデルで、非常に多くのショップの商品を同じインデックスに入れています。そのため、基本的には自分のショップ以外の情報を検索できないようにする必要があります。 この記事では、商品検索の OpenSearch 化で実装した認証認可について、2回に分けて紹介します。今回はインフラが中心で、アプリケーションでの仕組みは後編でお話しします。 ## 背景 BASE の商品検索は、CloudSearch から OpenSearch Service へ移行しました。この移行に合わせて、アクセス制御も整備しています。 商品検索を使うアプリケーションは複数あり、必要な権限はそれぞれ異なります。例えば、ショップページではそのショップの公開中の商品だけを検索しますが、ショップ管理画面ではログイン中のショップの非公開の商品も検索します。インデックスを更新するバッチもあります。 ### アクセス制御の全体像 BASE の商品検索では、次の4つの層でアクセスを制御しています。下の3層は OpenSearch Service で、一番上の層はアプリケーションで制御します。下から順に、制御の単位が細かくなります。 層 | 制御の単位 | 制御する内容 ---|---|--- アプリケーション | ショップ | どのショップの商品を検索するか きめ細かなアクセスコントロール | OpenSearch のロールごとのインデックス、ドキュメント | ユーザーを認証し、OpenSearch のロールに応じて何を許可するか ドメインアクセスポリシー | IAM ロール | どの IAM ロールのリクエストを許可するか ネットワーク | 接続元 | リクエストがドメインに到達できるか docs.aws.amazon.com 今回は OpenSearch Service で制御する3層を説明します。 ## ネットワークとドメインアクセスポリシーで接続元を絞る 商品検索のドメインは VPC 内に置き、外部からのアクセスをブロックしています。 ドメインアクセスポリシーでは、最小権限の考え方に沿って、商品検索を使うアプリケーションと運用に必要な IAM ロールだけを許可しています。許可されていない IAM ロールのリクエストは、きめ細かなアクセスコントロールに届く前に拒否されます。 ## きめ細かなアクセスコントロールで認証認可する 内部ユーザーデータベースは使わず、IAM ロールで認証しています。マスターユーザーにも IAM ロールを指定しています。 ### アプリケーションを認証する AWS のブログでは、テナントごとに OpenSearch のロールを用意し、テナント ID で絞るドキュメントレベルのセキュリティ(DLS)でテナントを分離する方法を紹介しています。 aws.amazon.com BASE はテナントにあたるショップの数が非常に多いので、ショップごとに OpenSearch のロールとマッピングを用意する方法は現実的ではありません。そこで、ロールはアプリケーション単位で割り当てています。アプリケーションは ECS で動いているので、きめ細かなアクセスコントロールは ECS タスクロールに紐付けています。 ECS タスクロールを OpenSearch のロールにマッピングするときは、ロールマッピングの `backend_roles` に IAM ロールの ARN を指定します。例えばショップページの ECS タスクロールは、次のように指定します(ARN は例です)。 { "backend_roles": [ "arn:aws:iam::123456789012:role/shop-front-task-role" ] } これで、どのアプリケーションからのリクエストかによって、OpenSearch のロールが決まります。 ### ロールで権限を絞る 用途ごとに、次のロールを用意しています。 ロール | 権限 | 使うアプリケーション ---|---|--- `items_reader_public` | 公開情報の商品検索(読み込み)のみ | ショップページ `items_reader_full` | 全情報の商品検索(読み込み)のみ | ショップ管理画面、社内管理画面 `items_writer` | 商品情報の書き込みと読み込み(ドメイン自体の設定にはさわれない) | DB の内容をインデックスへ反映するバッチ `item_search_index_manager` | インデックスの操作のみ | 開発者がレビューを経て実行するワンショットのバッチ `items_reader_public` には、次のように DLS を設定しています(インデックス名は例です)。 { "index_permissions": [ { "index_patterns": ["items*"], "allowed_actions": ["read"], "dls": "{\"term\": {\"is_visible\": true}}" } ] } `is_visible` が `true` のドキュメントだけが検索対象になるので、ショップページからは公開中の商品だけを検索できます。 ロールの分け方は、管轄の境界にも沿っています。ドメインやロールの定義は SRE が管轄する Terraform のリポジトリに、インデックスのマッピングやエイリアスはアプリケーションエンジニアが管轄するアプリケーションのリポジトリにあります。 アプリケーションのバッチにはインデックスの操作だけができる `item_search_index_manager` を割り当て、ロールやロールマッピングを変更できる権限はアプリケーションには渡していません。 なお、これらのロールでは、どのショップの商品を検索するかまでは絞っていません。ここはアプリケーション上で制御していて、後編でお話しします。 ショップページの検索を例に、ここまでの流れを図にすると次のようになります。 ## おわりに 今回は、商品検索の認証認可のうち、インフラを中心に紹介しました。 VPC で外部からのアクセスをブロックし、ドメインアクセスポリシーで許可する IAM ロールを限定し、きめ細かなアクセスコントロールで ECS タスクロールごとに権限を絞っています。 後編ではアプリケーションでの仕組みを紹介します。自分のショップ以外の情報を検索できないようにする制御をアプリケーション上で行い、CODEOWNERS と PHPStan で守っている話をします。 こうした商品検索の基盤づくりに興味のある方は、ぜひ採用情報もご覧ください! binc.jp
devblog.thebase.in
November 11, 2026 at 10:11 PM
"Lesser Known AWS Features — Day 42: AWS Lambda Queue Consumption Mode for Apache Kafka" by Nikunj Purohit

#aws-lambda #apache-kafka #amazon-ec2 #amazon-cloudsearch #cloudformation-resources
Lesser Known AWS Features — Day 42: AWS Lambda Queue Consumption Mode for Apache Kafka
While exploring the latest AWS updates, I came across a really interesting improvement for Kafka + Lambda.
community.aws
November 3, 2026 at 2:00 PM