こんにちは、ひろかずです。
AWSが開催する、初のセキュリティ特化型カンファレンスre:Inforce2019に行ってきたので、一筆書きます。
ひろかずは、英語のヒアリングが非常に苦手なのですが、パッションだけで参加してきました。
初めて使う様々なツールを駆使しての執筆になりますので、いろいろご容赦ください。
tl;dr的な何か
- 組織の成長に合わせて詳細な権限を設定するためのスケーラブルなメカニズムが必要
- 属性ベースのアクセス制御(ABAC)を紹介と、組織に合わせてスケールする権限ルールを作成して権限管理を簡略化する方法を紹介
- プロジェクト内のAWSリソースへのアクセスを開発者に許可するために、管理者がポリシーを作成し、タグを管理する方法を紹介
権限の確認
組織における一般的なパーミッション
ゴール
- ビジネスの革新
- 迅速な行動の俊敏性
- ビルダーに自由をもたらす
確保すること
- 危険アクションの軽減
- 責任あるセキュリティ体制
- 設定で何が起きているかを知るために、警備体制の状況を確認する必要もある
- コスト効果のあるソリューション
特定の誰かは何にアクセスできるか
- Workforce Userは、IAM Roleのこと(アプリケーションも意味する)
- AWSのリソースは、インスタンスやs3バケット、Cloudwatch EventsやSecret Managerなど
- それらはAWSアカウント間でさえある
- それらがその2つを繋ぐもの
権限の2つの部分
あなたの職務 : 仕様
- 特定のリソースに対してどのアクションをどのエンティティーが実行できるか、およびどの条件で実行できるかを定義する
AWSの職務 : 実行
- 各要求に対して、サービスまたはアプリケーションは、アクセスを許可または拒否するように定義した許可を評価する
ロールベースのアクセスコントロール(RBAC)
- ポリシーに毎日取り組む中央のセキュリティチームとって、管理対象はますます重要になっていき、毎回アップデートしている
メリット
- 役割の集合を割り当てることにより、ユーザーに特定の権限を付与する
- 固有のアクセス許可の組み合わせごとに異なる役割を作成する
- 新しいリソースごとにアクセス権を追加して許可を更新する
- 特定の役割のアクセス許可を監査してアクセスを決定する
AWSにおけるABACの紹介
- もっといい方法はないかと考えた。どうやって規模を拡大すればいい？
- 属性は非常に協力で、特にAWSを使って実際に権限管理をスケールする方法でもある
- Attribute-Based Access Control
- 属性を使用して、従来の組織に合わせて拡張された一般的な権限ルールを作成
属性について少し
- 属性は、
キーまたはキーと値のペア - 属性は、プロバイダによって事前に定義されているか、カスタムしたものである
- keyはユーザー情報や、開発/本番、チームやプロジェクト名
- 属性は会社の従業員全員に小さなタグがついていて、これらは全て属性である
- 例としては、以下
- AWSでは、それらのタグをIdPへの属性にすることができる
- これによりIdPを社会的な選択肢にすることができる
- また、ユーザーの識別に使う属性を渡して、アクセス制御に使える
ABACのメリット
- 権限は技術革新とともに拡大し、開発者はそれを構築できる
- 権限は属性に基づいて自動的に適用されるため、チームの行動が速くなる
- 新しいユーザーまたはリソースごとに権限を更新しなくても、詳細な権限を設定できる
- 監査属性を使用してアクセスを決定できる
- 全てが属性に基づいており、属性が一致する限りアクセスができる
- パーミッションの更新を必要とせずに、詳細なパーミッションを設定できる
属性ベースパーミッションの例
- 開発者にプロジェクトリソースへの読み取りおよび書き込みアクセスを許可する
- 開発者はプロジェクトを新しいリソースに割り当てる必要がある
- チームに共通するリソースへの読み取りアクセスを開発者に許可する
- 自分が所有するリソースのみを管理する
組織へのABACの適用
ステップ(1〜3を定義して、忘れる)
- アクセスコントロール属性を設定して、IDを作成する
- 新しいリソースに属性を要求する
- 属性に基づいて許可を設定する
- 新しいリソースを作成する
- 権限が自動的に適用される
デモ
Secret Managerのシークレットへのアクセスを題材にデモ
1. 開発者ロールを作成する
プロジェクトpicklesの開発者ロール
project=pickles, costcenter=1234
プロジェクトbubblesの開発者ロール
project=bubbles, costcenter=2048
2. 新しいリソースに属性を要求する
- AWS Secrets Managerで作成された新しいシークレットにprojectタグとcostcenterタグを要求する権限を追加
- 開発者がstage、createdby、applicationをタグ付けできるようにする権限を追加
- 以下ポリシーでは、projectとcostcenterタグの値を必須項目とする
- ポリシーに記載されているキーでプロジェクトは許可するが、その他は許可しない
3. 属性に基づいて許可を設定する
- 開発者ロールに許可を追加して、同じプロジェクトタグでシークレットを管理する
- 開発者がアプリケーションタグとステージタグを追加または更新できるようにする
- このポリシーでは、Conditionに記載されているprojectタグを持つユーザーだけがリソースを管理できる
- このポリシーでは、これらのタグを持つリソースにのみタグを付けられる
- projectタグに設定できるキーは、ポリシーに記載されているものだけ設定できる
- このポリシーでは、自分のプロジェクトのタグのみ変更ができる
4. 新しいリソースを作成する
- Picklesロールを使って新しいシークレットを作成
- Picklesロールを使って、プロジェクトPicklesのシークレットの管理を試みる
- タグの編集ができる
- Picklesロールを使って、プロジェクトbubblesのシークレットの管理を試みる
- タグの編集ができない
- bubblesロールを使って、プロジェクトbubblesのシークレットの管理を試みる
- タグの編集ができる
ABACのベストプラクティス
- アクセス制御に使用する属性のサブセットを予約する
- 承認されたエンティティのみが属性を設定または変更できる
- 作成中にすべてにタグを付けて、権限がすぐに適用されるようにする
- 属性を使用して、リソースを管理する権限を付与する
- 定期的に監査を行い、リソースに適切なタグが付けられていることを確認する
追加リソース
AWS re:Invent 2018: [REPEAT 1] Become an IAM Policy Master in 60 Minutes or Less (SEC316-R1)
- iamポリシーテクニックのレビューとそれらを使用する方法のデモンストレーション;ここには、ABACのさまざまな例が含まれています
Actions, Resources, and Condition Keys for AWS Services
- AWS全体でサポートされているサービス、アクション、リソースレベルの権限、および条件の中心的な場所について記載
(※ひろかず注)AWS Security Blog | Simplify granting access to your AWS resources by using tags on AWS IAM users and roles も参考になります
感想的な何か
- RBACの限界に達しつつある組織では、PoCを通してチャレンジする価値がある方法論だと思います
- タグの付け方など、文化・風習と上手くマッチさせれば、もう1段先の景色が見えてきそうです
- 会場が寒さでお腹が冷えなければ、もっと楽しめたセッションだったと思います。。。
現場からは以上です。
お疲れ様でした。