Amazon Verified Permissionsを利用した 責務の分割のメリット・デメリット 株式会社カミナシ　セキュリティエンジニア　西川　彰 2023/08/26

自己紹介 ● 西川　彰 ● 鹿児島県霧島市在住 ● 株式会社カミナシ　セキュリティエンジニア ● 一般社団法人鹿児島県サイバーセキュリティ協議会　代表理事 ● 鹿児島工業高等専門学校　情報工学科　非常勤講師 ● CISSP ● AWS Certified Security-Specialty

Amazon Verified Permissions（AVP）とは

Amazon Verified Permission(AVP) とは

AVPとは アプリケーション向けの認可機能を提供しているサービス 対応している権限モデル ● ロールベースアクセス制御（RBAC） ● 属性ベースアクセス制御（ABAC） ポリシー言語 ● Cedarを採用 認可を外部化させることでアプリケーション開発を20%加速させた（らしい） AWS re:Inforce 2023 - Fine-grained authorization for apps with Amazon Verified Permissions(IAM 308)

これがあると何が嬉しいの？？ →アプリケーションコードを変更せずに →リアルタイムに →誰が何にアクセスを許可するしないを制御できる！ 認可の責務をAVPに移譲できてアプリケーションはそれを意識しないでよくなる！ ゼロトラストの話でいうと、、、 ● MFAを設定しているか ● 許可されているIPアドレスからのリクエストか ● アクセスしてきている時間が業務時間内か などをリアルタイムに判断することができて、特に機密性が高い情報にアクセスするときだけこういっ た条件をつけるとかもできる

AVPの流れ OK/NG ① ② ③ ④ or ⑥ ④ ⑤ Forbidden or Response

Cedar言語とは

permit( principal in User::"alice", // 誰が action in [Action::"update", Action::"delete"], // 何を resource == Photo::"flower.jpg") // 何に when { context.mfa_authenticated == true && context.request_client_ip == "222.222.222.222" }; Cedar言語とは プリンシパルやリソースに関す ることをpermitに書く アプリケーションがリクエスト を受けた時点で初めてわかるも のなどをwhenに書く チュートリアルもあるので、まずは触ってみることをおすすめします Cedar Language Playground：https://www.cedarpolicy.com/en/tutorial/policy-structure

{ "url": "https://example.com/path/to?name=alice } contextで使用するデータは正規化して送信する { "url": { "transport": "https", "host": "example.com", "path": "/path/to" "queryParams": { "name": "alice", } } アプリケーションはポリシーが作成 しやすいように正規化して送信する permit (principal, action, resource) when { context.url.path == "/path/to" context.url.queryParams.name == "alice" };

あまり複雑なことはできない（しないほうがよい） OK？/NG？ ① ②

正規表現は実装しないの？ ● リソースの過剰消費を防ぐ ○ 攻撃者に意図的に評価の時間を掛けさせられないように ● 「誰でも書ける」が阻害される ○ CedarはSQLよりも簡単であるとうたっている ○ 正規表現の場合、ぱっと見どういう内容かエンジニア以外の人がわかりづらい ● 誤りに気付きにくい ○ エラーになってもポリシーが無視されるだけなので気付きづらい ○ 想定通りに動いているのかわかりづらい 以上のような理由で意図的に外されている 参考：https://cedarland.blog/design/why-no-regex/content.html　 （Why doesn’t Cedar have regexes and string operators? - Cedarland Blog）

ワイルドカードは条件でのみ利用できる permit ( principal == User::"3gi488f2-123c-820a-5678-e7fden84b398", action, resource ) when { resource.id like "image*.jp*" }; 書けるもののパフォーマンスが低下することがあると言及されている 合わせて「admin」に許可したつもりが「badminton-club」も許可されてしまったりする ので注意が必要（実際にあったらしい）

permit( principal in User::"alice", action in [Action::"update", Action::"delete"], resource == File::"hoge/image.jpg" ) エンティティには一意で普遍で再利用不可能なものを使用する これは推奨されていない aliceさんがこのシステムを利用しなくなった時のことを考える。 このルールが削除されなかった場合に、以前のaliceさんがアクセスできていたものに、 新しく利用を開始した別のaliceさんがアクセスできてしまう可能性がある

) when { !( principal.sports == "soccer") // sportsという要素がないとtrueになってしまう }; ) when { principal has sports && !(principal.sports == "soccer") }; 要素を持っているかどうか確認する

OIDCプロバイダーを利用した場合

OIDCプロバイダーを利用する利点 permit( principal in User::"ap-northeast-1_12345|12345678-ref8d9-4033-a750-4c8622d62fb6", action in [Action::"update", Action::"delete"], resource == Photo::"flower.jpg") when { principal.cognito.username == "nishikawa" && principal has custom && principal.custom has sports && principal.custom.sports == “soccer” }; Cognitoが持っている情報を条件 に利用できたり、OIDCで持って いる情報をCustom claimを使っ て比較できる

AVPをアプリに組み込んでみる

こんな感じで認可の検証ロジックをコードから消すことができる（スッキリ） function huga(request): if (!isAdmin(request.user)) { return Exception('Access Denied'); } if (request.ip_addr == '会社のIPアドレス') { return Exception('Access Denied'); } : : function huga(request): if (!client.is_authorized(...)) { return Exception('Access Denied') } コードがシンプルになり、ビジネスロジックでは認可に関して気にしなくてよくなる！

本当に気にしなくてよいの？ 本当に？

AVPとビジネスロジックが切り分けられない場合 function show(request, id): if (!client.is_authorized(request)) { return Exception('Access Denied') } : select = "" if (is_jinji(request)) { // こういう条件を加えてしまっている場合 select = ",name" } sql = "SELECT profile" + select + " FROM human_resources" いわゆるRESTfulAPIのアンチパターン を書いてしまうと厳しい

AVPとビジネスロジックが切り分けられない場合 function show(request, id): if (!client.is_authorized(request)) { return Exception('Access Denied') } : : select = "" if (!is_business(request)) { // エンタープライズプランなら機密情報へのアクセス可能 select = ",secret" } sql = "SELECT profile" + select + " FROM human_resources" permit (principal, action, resource) when { principal has custom && principal.custom has plan && principal.custom.plan in [“business”, “enterprise”, “personal”] };　　　　　　　　　　　　 後から追加した条件によって本来enterpriseしかアクセス できないデータにpersonalプランの人もアクセスできてし まう

責務の分割とは

責務分割のパターン アプリケーション開発者 アクセス管理者 コンプライアンスマネージャー＆監査者 アプリケーション開発者 アクセス管理者＆ポリシー管理者 ① ② ポリシーはポリシー管理者が書く アプリケーション開発者がポリシーも書く

アプリケーション開発者がポリシーも書く場合のメリット・デメリット メリット ● 構成としてはシンプルで推奨されている形 ● アプリケーションとポリシーと同期が取りやすい デメリット ● メンテナンスが多重で発生する可能性がある ● アプリケーションのコンテキストを把握している必要があるので詳細を監査できるのか不明

ポリシー管理者がポリシーも書く場合のメリット・デメリット メリット ● アプリケーション開発者が一切認可のことを気にしなくてよくなる デメリット ● 監査として「第三者」という観点が抜ける ○ そもそもAVPで監査が成り立つのかは不明 ○ アクセス管理者と共同で作業するなどの運用ルールである程度は担保できるかも ● ビジネスロジックに認可が絡むと事故が起きる可能性がある

開発するサービスのパターン サービスA サービスB サービスA サービスB サービスC

シングルサービスにおける責務分割パターンのメリット・デメリット アプリケーション開発者がポリシーを書く場合 メリット ● 構成としてはシンプルで推奨されている形 ● アプリケーションとポリシーと同期が取りや すい デメリット ● メンテナンスが多重で発生する可能性がある ● アプリケーションのコンテキストを把握して いる必要があるので詳細を監査できるのか不 明 ポリシー管理者がポリシーを書く場合 メリット ● アプリケーション開発者が一切認可のこと を気にしなくてよくなる デメリット ● アプリケーションのコンテキストをポリ シー管理者が把握する必要がある ○ そのためにアクセス管理者と共同で動 く必要がある ● ビジネスロジックに認可が絡むと事故が起 きる可能性がある アプリケーション開発者がポリシーも書く場合 ポリシー管理者がポリシーを書く場合

マルチサービスにおける責務分割パターンのメリット・デメリット アプリケーション開発者がポリシーを書く場合 サービスAの開発者がポリシーを触ることによっ てサービスBに影響が出てしまう可能性があるな どマルチサービスの場合はそもそも向いていない ポリシー管理者がポリシーを書く場合 メリット ● アプリケーションとポリシー作成者が分か れているため責任を分割させやすい ● マルチサービスの場合、この構成以外考え づらい（メリット？） デメリット ● 監査として「第三者」という観点が抜ける ○ アクセス管理者と共同で作業するなど の運用ルールである程度は担保できる かも アプリケーション開発者がポリシーも書く場合 ポリシー管理者がポリシーを書く場合

まとめ

🔹今すでに運用しているサービスに対してポリシーを当てていくのは大変かも 🔹Cognitoと連携してもIDTokenを投げないとあまり恩恵を受けられない！ 　AccessToken投げて恩恵をうけたい！ 🔹一方的にセキュアになるというよりは、逆に使うことによって脆弱性を生み出す、もしくは運用が大 変になる可能性は大いにありそう とにもかくにも設計が大事！ 所感

ご清聴ありがとうございました

参考 Amazon Verified Permissions Documentation https://docs.aws.amazon.com/verifiedpermissions/ Amazon Verified Permissions workshop https://catalog.workshops.aws/verified-permissions-in-action/en-US/10-intro/getting-started Cedarのチュートリアル https://www.cedarpolicy.com/en/tutorial Cedarポリシー評価のテスト https://github.com/Pigius/cedar-authorization-service/tree/main