1年以上かけて OpenSearch の認証を Okta に移行するまで

■イベント
OpenSearch User Meetup Tokyo #2
https://www.meetup.com/opensearch-project-tokyo/events/316849624/

■登壇概要
タイトル：1年以上かけて OpenSearch の認証を Okta に移行するまで
登壇者：技術本部 Sansan Engineering Unit Infrastructure グループ 渡邉 友

■ 技術本部 採用情報
https://media.sansan-engineering.com

Transcript

1. 1年以上かけて OpenSearch の認証を Okta に移⾏するまで Sansan株式会社 技術本部 Sansan Engineering Unit Infrastructure グループ エンジニア 渡邉 友
2. 渡邉 友（Tomo Watanabe） 技術本部 Sansan Engineering Unit Infrastructure Group • • • • Sansanプロダクトのインフラ担当（AWS / Terraform / Ansible / etc.） ログ基盤としての OpenSearch をチームのメイン担当として運用 前職はSIerで6年、基幹システム（ERP）のインフラ基盤とEAI基盤開発 妻1・子供2・趣味は柔術🥋（白帯）
3. ⽬次 1. ログ基盤としての OpenSearch 2. 「認証をOktaにする」だけ？ 3. Okta認証に移⾏するまで 4. 興味のある OpenSearch の機能 5. まとめ
4. 1. ログ基盤としての OpenSearch
5. 1-1 : ログ基盤の全体像 - Sansan プロダクトのログは OpenSearch ドメインに集約している > 主な⽤途はアドホックなログ検索と、エラー通知や運⽤ダッシュボード確認 Linuxサーバー syslog / auditd / PostgreSQL Fluentd S3（⻑期保管バケット） アプリ開発者 OpenSearch Service Windowsサーバー IIS / event log / application log Fluentd OpenSearch Dashboards インフラメンバー カスタマーサポート AWSサービス CloudTrail / SQS / RDS / etc. AWS Lambda ログ通知アプリ（内製）
6. 1-2 : 規模と構成 - データノード10台、専⽤マスターノード3台、22種類のログを集約 > 3AZ 構成、総ストレージサイズは約20TB > 保持期間はログの種類ごとに 7⽇〜180⽇ 総ドキュメント ドキュメント流⼊/⽇ アクティブシャード 130億 3.5億 1,100
7. 1-3 : ログ基盤のユースケース - インフラだけでなく、アプリ開発者も、カスタマーサポートも利⽤する > Dashboardsの利⽤者は76名、うちインフラは8名 > ログ検索の⽅法や求める要件もそれぞれ - インフラ > 障害の切り分け、性能劣化の調査、⽇々の監視対応 - アプリ開発者 > リリース後の動作確認、不具合の再現調査 - カスタマーサポート > 利⽤者問い合わせの原因調査
8. 2. 「認証をOktaにする」だけ？
9. 2-1 : やりたかったこと - Dashboardsの認証を、ADからOktaに変更したかった > 全社の認証基盤に寄せることで、ADの保守運⽤から解放される > ユーザーの追加‧削除が、Oktaグループへの所属だけで完結する AD認証（旧構成） ユーザー管理：PythonスクリプトでAD操作 ブラウザ リバースプロキシ ‧Basic認証（LDAP） OpenSearch Dashboards Okta認証（新構成） ユーザー管理：Oktaグループのコード管理 ブラウザ リバースプロキシ OpenSearch Dashboards ‧SAML認証 okta
10. 2-2 : 「だけ」では済まなかった - Okta認証にする前に、対応が必要なことが複数あった > SAML 認証を使うには、Fine-grained access control（FGAC）の有効化が必要 > FGAC を有効化すると、接続元すべてに認証が必要になる > そもそもFGAC は Elasticsearch 6.7 以降または OpenSearch が前提（当時は6.0） - 前提条件を順にクリアするため、Okta認証への移⾏を2段階に分割した 第 1 段階：OpenSearch 移⾏ 第 2 段階：Okta 移⾏ 3段階のバージョンアップ / クライアント側の改修 クライアント側の署名対応 / FGAC‧SAML の有効化 2024.05 2024.09 2026.02 2026.07
11. 3. Okta認証に移⾏するまで
12. 3-1 : OpenSearch 移⾏ - Elasticsearch 6.0 から OpenSearch 2.13 まで、3 Step に分けて VersionUp した > 送信側‧データ‧利⽤者への対応がそれぞれ必要だった > どの作業をどの段階で⾏うか、順序の設計が必要だった Elasticsearch 6.0 Elasticsearch 6.8 OpenSearch 1.3 ※ 現在は 3.X OpenSearch 2.13 Step1 Step2 Step3 ‧ログコレクタのバージョン更新 ‧通知アプリの改修 ‧既存Indexのreindex ‧ドメインバージョンアップ ‧Dashboardsアクセス⽅法の周知 ‧送信側のTypeless対応 ‧ドメインバージョンアップ ‧ドメインバージョンアップ ‧翌⽉まで待機 （OpenSearchによるIndex作成待ち）
13. 3-2 : （閑話）誰も興味がなさそうな苦労話 - 通知アプリ（内製）が、Dashboards へのリンクを⽂字列結合で組み⽴てていた！！ > URL 形式がバージョンごとに変わり、3 Step のうち2回作り直した > `#` の位置が動く程度のこともあれば、パラメータの構造ごと変わることも ① ES 6.0 {BaseUrl}/app/kibana#/discover? _g=(time:(from:'{from}Z',mode:absolute,to:'{to}Z')) &_a=(columns:!(_source),index:{IndexId},interval:auto, query:(language:lucene,query:'{query}'),sort:!('@timestamp',desc)) ② OpenSearch 1.3 {BaseUrl}/app/discover#/? _g=(time:(from:'{fromUtc}',mode:absolute,to:'{toUtc}')) &_a=(columns:!(_source),index:{IndexId},interval:auto, query:(language:lucene,query:'{query}'),sort:!('@timestamp',desc)) ③ OpenSearch 2.13 {BaseUrl}/app/data-explorer/discover/#? _g=(time:(from:'{fromUtc}',mode:absolute,to:'{toUtc}')) &_a=(discover:(columns:!(_source),sort:!('@timestamp',desc)), metadata:(indexPattern:{IndexId},view:discover)) &_q=(query:(language:lucene,query:'{query}'))
14. 3-3 : アクセス元を洗い出す - FGAC を有効化するために、読み/書き両⽅のアクセス元を特定する必要があった > 書き込み側は、ログから送信元を逆引きし、コードも全⾛査して網羅した > 読み取り側は、コードに加えて把握している範囲で列挙するしかなかった 書き込み 読み取り ‧Lambda × 4 ‧Lambda × 2（結局リリースまで気づけず。。。） ‧EC2 × 約80 ‧通知アプリ × 1 ‧⼈ × 76
15. 3-4 : 洗い出したものに何をしたか - ⼈を除くすべてのアクセスを、SigV4 署名に対応させた > FGAC では ID / パスワードも使えるが、IAM だけで完結させた > 対応内容は共通だが、AMI の再作成から Terraform まで配布⼿段は様々 書き込み 読み取り ‧Lambda × 4 ‧Lambda × 2 → クライアントライブラリを差し替え → 同左 → Lambda実⾏ロールで署名 ‧EC2 × 約80 ‧通知アプリ × 1 → ログコレクタの設定変更 → OpenSearchへの接続⽅式を差し替え → EC2のIAMロールで署名 → ECSタスクロールで署名 ‧⼈ × 76
16. 3-5 : FGAC と SAML 有効化の段取り - FGAC を有効にしてもログの流⼊が途切れないよう、段取りを設計 Day 1 Day 2 ‧SigV4 署名対応の配布（前述） ‧スナップショット取得 → Ansible / AMI 再作成 / Terraform / ECSデプロイ ‧テスト → FGAC無効状態でログ転送が途切れないことを確認 ‧カスタムエンドポイント設定 → Okta に登録した URL と⼀致させる ‧FGAC + SAML 有効化 → 移⾏期間オプションは Off → SigV4 署名対応済みのため、ログ転送は途切れない ‧ロールマッピング編集（後述） ‧テスト
17. EC2 や Lambda に紐づく約20の IAM 3-6 : OpenSearch の認可を設定する - FGAC 有効化により、IAM ロールや Okta グループで権限を分けられるように > 権限の内容ごとに、4つのロールへマッピングした > FGAC 有効化時に default_role が⾃動で作られ、署名付きなら読み書きが通る > マッピング設定後、default_role は削除した Okta Admin Admin IAM IAM IAM IAM IAM IAM IAM IAM IAM IAM IAM IAM IAM IAM IAM IAM IAM IAM IAM 書き込み 参照 Okta User ReadOnly IAM IAM IAM Dashboards 操作 Okta Admin Okta User セキュリティ管理 Okta Admin Admin IAM 書き込み
18. 3-7 : 無事に移⾏は完了？ - 認証の Okta 化は果たしたが、⼤⼩さまざまなホットフィックス対応が続いた なくなった 、動か 読み取り側の Lambda が2本 IAM ポリシー 側の書き込み 権限が⾜りな かった 通知アプリが 401 を 返すようになった すぐログイ 「 利⽤者から クレームが なる」と ンし直しに できていなかった 従 追 が グ ン ピ ッ マ ロール名の変更に 認可の範囲が必要以上に広いケ ースもあった が弾かれた 新サーバーからのログ書き込み
19. 3-8 : Okta 移⾏プロジェクトから得た学び FGAC を使うために、ドメインとログコレクタのバージョンアップが必要だった ↓ まとめて上げようとすると、それだけで⼯数がかかる EOL にとらわれず、⼩刻みに上げておく システムの追加や変更に、ロールマッピングが追い付かなかった ↓ OpenSearch の認可設定も、Terraformで管理して変更を追えるようにする opensearch-project のプロバイダを⽤いれば、ISM ポリシーや監査設定まで扱える OpenSearch に接続しているものの特定に時間がかかり、漏れも発⽣した ↓ コードも含め、通信や監査の記録から網羅的に把握する必要がある フローログは接続元 IP、監査ログなら実⾏者まで把握できる
20. 4. 興味のある OpenSearch の機能
21. アクセス元はネットワーク、利⽤者は IAM で絞る 4-1 : OpenSearch UI - AWS がホストする UI を⽤いることで、前段のリバースプロキシを廃⽌できる > ALB、カスタムエンドポイントと証明書、Route 53 のレコードも不要になる 現在の Dashboards アクセス OpenSearch UI ブラウザ ブラウザ ALB OpenSearch UI リバースプロキシ OpenSearch Dashboards
22. 4-2 : MCP - AI エージェントから OpenSearch を検索できるようにしたい > 組み込みの MCP サーバー経由で、⾃然⽂での検索や Index 横断検索が可能に > OpenSearch への理解度や、検索の習熟度による差を埋められる > ただし LLM 利⽤には、ログに出す情報と権限設計の整備が別途必要 今の検索 MCP 経由の検索 インデックスを選ぶ クエリを書く 結果 インデックス毎に検索し、結果の突合は⼈がやる ⾃然⽂で聞く Index A Index B 結果 Index C
23. 4-3 : ログ分析最適化エンジン - ログ基盤としての利⽤に振り切っているので、恩恵を受けやすい > 列指向ストレージとフルテキスト検索を組み合わせた、ログ向けの新しいエンジン > 特にストレージ使⽤容量最⼤70%削減は、肥⼤化するログ基盤には⼤きなメリット - 出典：https://aws.amazon.com/jp/about-aws/whats-new/2026/07/amazon-opensearch-service-optimized-log-analytics/ > ただし既存ドメインのエンジン切替はできず、新規ドメインへ移⾏することに‧‧‧
24. 5. まとめ
25. 5-1 : まとめ - 「認証を変えるだけ」でも、ログ基盤全体への対応が必要だった > ドメインの更新だけでなく、接続元の洗い出しや周辺アプリの改修まで含めて考える - FGAC と SAML で、セキュリティも利便性も向上した > ただし接続元の洗い出しや署名対応など対応範囲は広く、移⾏には1年以上かかった - ドメインバージョンを上げ続けることが、次の改善につながる > 使いたい新機能をすぐ取り⼊れられる状態を保ち、ログ基盤の利便性を⾼めていきたい
26. Sansan 技術本部 採⽤情報 https://media.sansan-engineering.com/