Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Amazon Verified Permissionsを利用した 責務の分割のメリット・デメリット / Advantages and Disadvantages of Separation of Responsibilities Using Amazon Verified Permissions

Amazon Verified Permissionsを利用した 責務の分割のメリット・デメリット / Advantages and Disadvantages of Separation of Responsibilities Using Amazon Verified Permissions

2023/08/26 Security-JAWS【第30回】[Security-JAWS DAYS] ~Day1~

Amazon Verified Permissionsを利用した責務の分割のメリット・デメリット
https://s-jaws.doorkeeper.jp/events/155024

西川 彰
Software Engineer, Security Engineering

kaminashi, Inc.

August 25, 2023
Tweet

More Decks by kaminashi, Inc.

Other Decks in Technology

Transcript

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

    View Slide

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

    View Slide

  3. Amazon Verified Permissions(AVP)とは

    View Slide

  4. Amazon Verified Permission(AVP) とは

    View Slide

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

    View Slide

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

    View Slide

  7. AVPの流れ
    OK/NG

    ② ③
    ④ or ⑥


    Forbidden or Response

    View Slide

  8. Cedar言語とは

    View Slide

  9. 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

    View Slide

  10. {
    "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"
    };

    View Slide

  11. あまり複雑なことはできない(しないほうがよい)
    OK?/NG?


    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  17. 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を使っ
    て比較できる

    View Slide

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

    View Slide

  19. こんな感じで認可の検証ロジックをコードから消すことができる(スッキリ)
    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')
    }
    コードがシンプルになり、ビジネスロジックでは認可に関して気にしなくてよくなる!

    View Slide

  20. 本当に気にしなくてよいの?
    本当に?

    View Slide

  21. 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のアンチパターン
    を書いてしまうと厳しい

    View Slide

  22. 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プランの人もアクセスできてし
    まう

    View Slide

  23. 責務の分割とは

    View Slide

  24. 責務分割のパターン
    アプリケーション開発者 アクセス管理者 コンプライアンスマネージャー&監査者
    アプリケーション開発者 アクセス管理者&ポリシー管理者

    ② ポリシーはポリシー管理者が書く
    アプリケーション開発者がポリシーも書く

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    ポリシー管理者がポリシーを書く場合
    メリット
    ● アプリケーション開発者が一切認可のこと
    を気にしなくてよくなる
    デメリット
    ● アプリケーションのコンテキストをポリ
    シー管理者が把握する必要がある
    ○ そのためにアクセス管理者と共同で動
    く必要がある
    ● ビジネスロジックに認可が絡むと事故が起
    きる可能性がある
    アプリケーション開発者がポリシーも書く場合 ポリシー管理者がポリシーを書く場合

    View Slide

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

    View Slide

  30. まとめ

    View Slide

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

    View Slide

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

    View Slide

  33. 参考
    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

    View Slide