アプリケーションレイヤ認可の動向とアーキテクチャ / Authorization in Applications with OPA

CNCJ: Cloud Native Security Japan LT祭り
Cloud Native Security Japan, Dec 4, 6:30 – 9:00 PM (GMT+9)
https://community.cncf.io/events/details/cncf-cloud-native-security-japan-presents-cncj-cloud-native-security-japan-ltji-ri/

Transcript

1. アプリケーションレイヤ認可の動向と アーキテクチャ CNCJ: Cloud Native Security Japan LT祭り 2024年12月4日 株式会社野村総合研究所 安宅 優季
2. 1 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. 自己紹介 ◼名前 ⚫ 安宅 優季 ◼業務 ⚫ 今年で社会人4年目 ⚫ 2021/4~2023/10 NRI aslead 事業 DevOps 支援部隊 ⚫ 2023/10~ NRI OpenStandia 事業 IAM チーム ⚫ 認証基盤導入の技術支援 ⚫ 2024年は「認可」をキーワードに調査活動 ◼趣味 ⚫ ゲーム (Switch, PS5, ソシャゲ, カードゲーム...) ⚫ よさげな OSS を自宅のサーバで動かして使ってみる
3. 2 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. OpenStandia 事業とは？ オープンソースソフトウェア (OSS) に対するエンタープライズ向けのサポート＆サービス • オープンソース年間サポートサービス • オープンソース導入サービス • プロフェッショナルサービス (OSSよろず相談 (技術相談)) https://openstandia.jp/services/
4. 3 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. OpenStandia 事業 IAM チームとは？ ID 事業に注力し、セキュリティに関する課題解決をサポート • Keycloak x midPoint を中心としたサービス展開 • セキュリティ分野の最新動向調査&発信
5. 4 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. Qiita Advent Calendar 実施中！ https://qiita.com/advent-calendar/2024/nri-openstandia
6. 5 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. 本日の内容 •Open Policy Agent (OPA) とは？ •認証・認可の振り返り •認可領域における OPA 活用 •認可アーキテクチャ •OPA 認可基盤構築の発展編
7. 6 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. Open Policy Agent (OPA) とは？ • Go 言語製の汎用ポリシーエンジン OSS • あらゆるサービスからポリシーおよびポリシー判定処理を切り離すこと を目的とする。 • 「データ JSON x ポリシー記述言語 Rego」で表現されたルールで判 定を行う。 • 2021年2月に Cloud Native Computing Foundation (CNCF) Graduated と認定。
8. 7 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. Open Policy Agent (OPA) とは？ あらゆるサービスの判定処理を HTTP通信による処理として外部化 任意のスキーマ定義が可能 = 特定のサービスに非依存 Git などでコードとして管理する。 ポリシー管理者は Rego のみ習熟すれば、 様々なサービスのポリシーを記述・管理できるようになる。
9. 8 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. OPA のユースケース ID管理サービス ポリシー管理者 クライアント、アプリケーション 開発者 認証/認可サービス ポリシー管理 保護・制御 依存関係チェック CI/CD・リソース管理 ソースコード管理サービス 設定違反チェック k8s リソース管理 ポリシー生成支援 リンター、デモ環境 ポリシー記述言語 Rego で記載する コンテナ セキュリティチェック API保護 ポリシー更新管理 HTTP リクエストに含まれる接続元リソース情報 (IDなど) を利用し、 ポリシーエンジンへ問い合わせ処理を挟むことで認可処理を行う API リクエスト or OPA 判定モジュールを利用して実装する データアクセス保護 Webアクセス保護 ストリーミング制御 AI生成 検証 認可 ポリシーエンジン ソースコード管理ツール エディタ対応 ポリシーライフサイクル アプリ表示制御 IaC ファイルを入力とし、違反や 想定外の設定が無いか検証を行う ジョブ制御 検証&認可...？ 検証
10. 9 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. Rego 活用可能な OSS 例 ID管理サービス ポリシー管理者 クライアント、アプリケーション 開発者 認証/認可サービス ポリシー管理 保護・制御 CI/CD・リソース管理 ソースコード管理サービス ポリシー生成支援 ポリシー記述言語 Rego で記載する HTTP リクエストに含まれる接続元リソース情報 (IDなど) を利用し、 ポリシーエンジンへ問い合わせ処理を挟むことで認可処理を行う API リクエスト or OPA 判定モジュールを利用して実装する 検証 認可 ポリシーエンジン ソースコード管理ツール ポリシーライフサイクル IaC ファイルを入力とし、違反や 想定外の設定が無いか検証を行う OPToggle Gatekeeper Conftest opcr OPAL Regal
11. 10 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. 認証・認可の振り返り 認可とは 「あなたは何に対して何ができる？」 許可/非許可に関する権限管理・ 制御をすること。 トークンとして権限情報が渡される (OAuth2.0) 認証とは 「あなたは誰？」 処理操作主体が本物であるかを 確認すること。
12. 11 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. 認証・認可の振り返り 認可とは 「あなたは何に対して何ができる？」 許可/非許可に関する権限管理・ 制御をすること。 トークンとして権限情報が渡される (OAuth2.0) 認証とは 「あなたは誰？」 処理操作主体が本物であるかを 確認すること。 認証依存 ↓ 機械ユーザは逐一 作らないといけない…？ トークン依存 ↓ トークンが有効な間に ステータス更新 されても自動反映できない…
13. 12 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. 認可領域における OPA 活用 PEP PDP PAP ポリシー判定 を担う ポリシー管理を担う ポリシー判定結果を元に制御する
14. 13 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. 認可領域における OPA 活用 API GW IdP アプリ PEP アプリ PDP PAP 認可判定を外部化のうえ、ユーザ属性やトランザクション データに基づきリアルタイムでよりきめ細やかに認可 (AuthZEN により標準化中) ユーザが保有する権限に応じた トークンを発行し認可 (OAuth2.0 により標準化済)
15. 14 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. 認可アーキテクチャ 中央集中型 分散型 アプリ + PEP PDP PEP Pod アプリ アプリ PAP アプリ + PEP + PDP Pod アプリ + PEP + PDP アプリ + PDP PAP メリット ✓ 判定結果の一貫性を保証しやすい デメリット  ルールの肥大化、通信集中によるパフォーマンス低下の恐れがある メリット ✓ 通信が近傍で行われるためセキュア&迅速な判定 ✓ PDP が単一障害点とならない デメリット  各ポッドへポリシー更新を確実に行うことを保証する必要がある
16. 15 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. OPA 認可基盤構築の発展編 •判定の仕組みとセキュリティ •カスタム OPA サーバの開発 •ポリシー・データの更新 •Rego 開発補助
17. 16 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. 判定の仕組みとセキュリティ OPA サーバ Regoファイル package A JSONデータファイル Regoファイル package B JSONデータファイル
18. 17 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. 判定の仕組みとセキュリティ OPA サーバ Regoファイル package A JSONデータファイル Regoファイル package B JSONデータファイル package A import rego.v1 meta = "test policy" default allow = false default allow_read = false allow if { input.user == "Smith" } allow if { input.role == "admin" } allow_read if { user_is_owner action_is_read } user_is_owner if { data.user_attributes[input.user].title == "owner" } action_is_read if { input.action == "read" } { "user_attributes": { "Smith": { "tenure": 20, "title": "owner" }, "Sam": { "tenure": 15, "title": "employee" } } }
19. 18 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. 判定の仕組みとセキュリティ OPA サーバ Regoファイル package A JSONデータファイル Regoファイル package B JSONデータファイル アプリ・PEPからの リクエスト 例) Package A を使う。 allow の結果を返してもらう。 ※ アプリ・PEP は JSON データの構造を意識しない
20. 19 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. 判定の仕組みとセキュリティ OPA サーバ Regoファイル package A JSONデータファイル Regoファイル package B JSONデータファイル OPA サーバからの レスポンス 例) allow の判定結果
21. 20 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. 判定の仕組みとセキュリティ OPA サーバ Regoファイル package A JSONデータファイル Regoファイル package B JSONデータファイル OPA サーバからの レスポンス 例) allow の判定結果 もし、リクエスト時に応答対象 (allow 等) を指定しなかったら… • default に設定した判定情報・結果 • ≠によって適合とされた判定結果 • メタデータ が返ってしまう。
22. 21 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. 判定の仕組みとセキュリティ • PEP でパッケージ名を指定しアプリ側に秘匿する工夫 • PEP での適切なアクセス制御 • mTLS やクライアント認証を利用した OPA サーバへのアクセス制御 等々を検討しておくこと。 自身 (クライアント) を証明する 認証トークン または 証明書 アプリ・クライアント PEP OPA サーバ パッケージ名等を適切に選択 してリクエストを送信 TLS (mTLS) 設定 クライアント認証 アクセス制御 境界型セキュリティ TLS (mTLS) 設定
23. 22 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. カスタム OPA サーバの開発 • 判定直前/判定直後に OPA サーバ内で特殊な処理を行いたい。 • 指定するクエリや Rego は OPA サーバ側で管理したい。 → OPA モジュールを使う！※処理追加による負荷増加は予め見積もっておく。 package main import ( … "github.com/open-policy-agent/opa/rego" ) … func main() { http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) { … ctx := context.Background() rt := rego.New( rego.Query(`data`), rego.Load([]string{"./rego-sample/sample.rego"}, nil), ) query, err := rt.PrepareForEval(ctx) if err != nil {
24. 23 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. ポリシー・データの更新 OPA サーバ Regoファイル JSONデータファイル PAP
25. 24 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. ポリシー・データの更新 OPA サーバ Git サーバ ポリシー (Rego), データ (JSON) の管理 OPA サーバへデプロイ (CD) OPA サーバ起動時の ルールで判定実施 ✓ 単純な構成  ルール更新ごとにデプロイを行う 負担・リアルタイム性の低下
26. 25 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. ポリシー・データの更新 OPA サーバ services: - name: acmecorp url: https://example.com/service/v1 credentials: bearer: token: “xxx" bundles: authz: service: acmecorp resource: somedir/bundle.tar.gz persist: true polling: min_delay_seconds: 10 max_delay_seconds: 20 signing: keyid: my_global_key scope: read ポリシー公開サーバ Git サーバ ✓ OPA サーバのデプロイなしで更新  リアルタイム性はまだ低い ポリシー (Rego), データ (JSON) の管理 ポリシー公開サーバへデプロイ (CD) ※ ポリシーとデータを bundle として固めておく
27. 26 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. ポリシー・データの更新 OPA サーバ OPAL SERVER Git サーバ ✓ リアルタイム性を実現  アーキテクチャは複雑化 ポリシー (Rego) の管理 外部サービス (DB等) データの管理 OPAL CLIENT ※サイドカー 指定リポジトリの更新 をチェック 更新通知 Git リポジトリと 外部データソースから ポリシー・データを フェッチ
28. 27 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. Rego 開発補助 標準化が大変...Rego が難しい... → テストで検知することで解決するかも...? ローカル開発時 CI時 OPA Playground by Styra ポリシー判定のデモ用実行環境を提供。 ※学習用 ローカルで判定情報を確認できる。 OPA バイナリを取得するだけで実行可能。 OPA インタラクティブ モード (デバッグモード) opa run ./rego repl.input:./input.json Regal Rego リンター Regal バイナリを取得するだけで実行可能。 ユニットテスト用の Rego ファイルを作成 しておく必要あり。 OPA バイナリを取得するだけで実行可能。 OPA ポリシー ユニットテスト opa test ./rego -v
29. 28 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. Rego 開発補助
30. 29 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. まとめ •OPA を活用した認可アーキテクチャが現れ始めている •従来の OAuth 認可とは異なるレイヤでの認可実装が ターゲット •機能のリッチ化に伴いアーキテクチャは複雑になるので 要注意