現場エンジニアのIAM設計時に考えていること

Transcript

1. 現場エンジニアのIAM設計時に考えていること 01 02 03 04 05 IAMとは 最小権限の適用 実際の問題点 最小権限の手助け ◦◦による最小権限 自己紹介：鈴木 嘉泰 (22) - Infrastructure Specialist - Kyndryl | LinkedIn 事業会社でオンプレからAWSへのシステム移行、基幹業務システムのAWSインフラ設計・構築 → Kyndrylで金融系システムのAWS設計・構築。最近、個人的に物理MFAデバイスを買いました。 Level 100 Introductory Level 200 Intermediate Level 300 Advanced Level 400 Expert 苦悩を交えて。
2. AWS Identity and Access Management （IAM）とは 2 AWSに対して何か要求を行う場合は、AWSサービスエンドポイント宛てにHTTPリクエストを送信する。 しかしそれだけだと 、AWS のアカウントを作成せずに AWS のサービスが利用できたり、勝手に他人のリ ソースを操作できてしまうため、AWSにリクエストを送信する際に リクエストの署名を付与する仕組み、 署名を検証する仕組みとしてAWS Identity and Access Management （IAM）が存在する。 AWS CLI AWS Console AWS SDK AWS Cloud サービス エンドポイント https://ec2.amazonaws.co m/?Action=ListInstance&... IAM 検証 署名 ほぼすべてのリクエストは署名が必要となるため、 IAMは避けては通れないサービス。
3. IAMとは – IAMの構成要素 3 備考 同一目的・種別および組織に属するIAMユーザーをまとめるのに利用す る。 グループに対してIAMポリシーを設定し、操作可能なサービスや対 象を制限する。 IAMポリシー IAMユーザー、グループ、ロールのAWSリソースに対しての操作権限を JSON形式で定義したもの。 ユーザー、グループ、ロールにアタッチして使用される IAMグループ IAMロール 特定のAWSサービスが別のサービスと連携する場合にIAMロールと呼ば れる役割を付与する。また、特定のIAMユーザーに特定の役割を委任 する場合に利用する。 AWSを操作するユーザーをIAMユーザーと呼ぶ。 AWSの操作を行うにあたり、AWS管理コンソールもしくはCLI実行時に IAMユーザーが必要となる。 IAMユーザー IAMポリシー設定の対象となる 最大10ポリシーをアタッチ可能 マネージメントコンソールでも作 成することができる。 リソースに対して付与するため認 証の仕組みは持たない。 最大10ポリシーをアタッチ可能 最大10グループに割り当て可能 最大10ポリシーをアタッチ可能 構成要素 説明 • アクセス制御の実態としてはIAMポリシーとなるため、IAMポリシーをどう定義するがポイント。 • IAMポリシーに似たもので、SCPやリソースベースポリシーもあるが、基本的な構文は同様であり、どこ に割り当てるかで、効能が異なるという認識で問題ない。
4. 【参考】IAMポリシーのJSON 4 { "Version": "2012-10-17", "Statement": [ { "Principal": { "AWS": "arn:aws:iam::123456789012:root“ }, "Resource": [ “ec2:*" ], "Action": [ “ec2:Start*" ], "Effect": “Deny" } ] } 誰が 何に対しての どんな操作を 許可/拒否する
5. IAMとは – IAMの制限箇所 5 • IAMポリシーを記載する箇所としては、IAMのアイデンティティベースポリシーになります。実際にユー ザー（アイデンティティ）に対してアタッチするIAMポリシー（JSON）を記載することになります。 • SCPやリソースベースポリシーといったアイデンティティポリシーと似たアクセス制御方式もあり、 判定フローに応じてポリシーの最終評価していきます。 SCP アイデンティティ ベースポリシー リソース ベースポリシー AND OR ポリシー名 論理評価 設定サービス Organizations Control Tower IAM Policy S3 SNS … 制御範囲 AWSアカウント IAMユーザー、IAMロール 設定したリソース
6. 【参考】権限判定の判定フロー(評価論理) 暗黙的なDeny 該当するPolicyの検査 Denyが明示されている Denyと評価 (明示的なDeny) SCPが定義された Organizationsの 管理アカウントである SCPに Allowが明示されている Denyと評価 (暗黙的なDeny) リソースポリシーを 持つリソースである リソースポリシーに Allowが明示されている Principalの指定に依存 IDベースポリシーが 定義されている Denyと評価 (暗黙的なDeny) Denyと評価 (暗黙的なDeny) Permissions Boundaryが 定義されている IDベースポリシーに Allowが明示されている ロールセッションまたは IAM federated userセッションである Permissions Boundaryに Allowが明示されている Allowと評価 Allowと評価 セッションポリシーが 定義されている セッションポリシーに Allowが明示されている Denyと評価 (暗黙的なDeny) ロールセッションである 明示的なDenyの評価 SCPの評価 リソースポリシーの評価 IDベースポリシーの評価 Permissions Boundaryの 評価 セッションポリシーの評価 6 IAM 評価論理ファンがいるらしい
7. 最小権限の適用 - IAMポリシーの種類 7 • 最小権限とするベストプラクティスに則ると、#1 カスタマー管理ポリシーでResource x Action単位での細 かいアクセス制御を記述することになる。 • すべてのフェーズで#1 カスタマー管理ポリシー の利用を徹底すると、管理負荷や構築作業の効率を下げ ることとなるため、実際には難しい。 • また、AWS管理ポリシー #2~4では、アタッチ上限10個があるため、結局#1になる気がしてます。 # 記載方法 説明 評価 イメージ 1 カスタマー管理ポリシー (許可リスト型) 業務必要なアクションを列 挙したポリシーを作成する 最も最小となる権限。プログラム や定型作業に使用する場合など 設計や検証の負荷が最も大きい 2 AWS管理ポリシー ＋カスタマー管理ポリ シー(拒否リスト) AWS管理ポリシーに、 禁止したい操作の拒否設 定を付加したもの ガードレールの発想。一般ユー ザーに権限を払い出す場合など。 禁止操作の洗い出しが必要 3 AWS管理ポリシー AWS管理ポリシーをその まま使用する FullAccess/ReadOnlyなど既 存のポリシーを利用する、管理の 手間がない方法 4 職務機能の AWS管理ポリシー AWS管理ポリシーの集合 として定義された職務機 能の管理ポリシーを利用 操作に必要な権限が取りまとめら れ、管理負荷は最小。ただし権 限の範囲が必要以上になりがち カスタマー管理ポリシー 許可する Action AWS管理ポリシー 禁止する Action AWS管理ポリシー 職務機能の管理ポリシー 権限 範囲 狭 広 管理 負荷 高 低
8. 最小権限の適用 - IAMポリシーの記載方針 8 • 金融系システムでよくある要件として「最小権限とすること」を実現する上で • IAMユーザー • 事前に役割・ユースケースを確定させて予め権限を付与しておき、触らせてはいけないものについて拒否を入れる。 • 個々の権限設定は地道にExcel管理する。 • IAM管理者を立ててIAMユーザーへのIAMポリシーの割り振り管理する。 • IAMロール • 構築/運用フェーズともに、システムに必要な最小限の操作のみを設定する。 • だたし、開発者が最小権限で作成しているか分からず統制が取れない。 IAMロール IAM管理者 IAMユーザー 構成要素 管理者 開発者 運用負荷 役割・ユースケースが事前に確定していれば負荷は少ない。 →IAM権限管理シートに洗い出す。 開発者がAWSの権限を熟知しており、最初から最小権限で 設定をしているのであれば負荷は少ないが、Get*等の広い権 限や不要な権限を付与された場合、最小権限ではなくなる。 問題点
9. 【参考】IAM権限管理シート 9 組織と業務 権限割り当てグループ IAMポリシー名 AWS上のロール名 実際のポリシードキュメ ントは別シートで管理し てもよい。 AWS上のグループ名 IAMポリシー割り当て 詳細は「【AWS Black Belt Online Seminar】 AWSサービスの権限管理」参照 https://d0.awsstatic.com/webinars/jp/pdf/solution-casestudy/20160621_AWS-BlackBelt-Authority-public.pdf
10. 実際の問題点 - IAMロールとリソースポリシーの最小権限 10 【問題点】 IAMロールの作成者はシステム開発者となるため、統制が届かず最終的に最小権限とならない問題。 【対策①】：IAM管理者による完全な統制 IAMロールをIAM管理者が作成し、作成したIAMロールを開発者に渡す。 （負担が大きく、IAM管理者がすべてのシステムについて動作を熟知している必要がある。） 【対策②】 ：開発者による自律的な統制 IAMを開発者に作成してもらい、あとからIAM管理者/開発者が棚卸を行う。（後述のAWSサービスを利用） IAM管理者 開発者 申請 作成 IAMロール 負担大 統制◎ 対 策 ① IAM管理者 開発者 作成・棚卸 IAMロール 負担小 統制△ 対 策 ② 棚卸 負担増
11. 最小権限の手助け – IAM Access Analyzer 11 IAM Access Analyzerとは… CloudTrailに記録されたアクセス履歴を分析し、過去に利用されたことのあるIAMポリシーを出力するサービス。 対応しないサービスがあったり、リソースは生成してくれないため、実用には不十分な機能となっている。 { "Version": "2012-10-17", "Statement": [ { "Principal": { "AWS": "arn:aws:iam::123456789012:root“ }, "Resource": [ “s3:file" ], "Action": [ “s3:List*" ], "Effect": “Allow" } ] } Actionのみ生成可能
12. 実際の問題点 - IAMロールとリソースポリシーの最小権限 12 開発者による 自律的な統制 IAM管理者 IAM管理者 による完全な統制 統制方針 管理主体 開発者 メリット 最小権限を達成できる可能性が高 い。 IAM管理者が不要なため、小規模 なプロジェクトに向いている。 開発者が自身で作成・利用するた め、工数はかからない。 デメリット 構築するシステムについて熟知して いる必要がある。 申請のレビューや作成・付与の工数 がかかる。 最小権限を達成できない可能性が ある。 小規模な構築では、開発者による自律的な統制を取ることでも問題は発生しないが、大規模になるとすべての開発者が最小権限を遵守し ているか統制が取れず、最小権限を満たさない可能性が高い。IAM Access Analyzerの更なる進化すれば大規模でも問題な可能性が 出てくる。 大規模案件で、なるべくIAM管理者による統制を行いたいが、IAM管理者のスキルレベルの要求・負荷が高く、うまく回らないこともあると思 います。なるべく負荷を下げるために私が推しているのが、次ページの「◦◦による最小権限」。
13. IaCによる最小権限 13 • お客様のポリシーとして最小権限を要求する場合、IAMの最小権限を守るためにかなりの工数を割く覚悟 が必要。 • IAM管理者の負荷を下げるために、IAMポリシーの発行申請～IAMポリシーの付与までのプロセスを考える と、申請・承認は人が関与するプロセスと、作成・付与はシステムにより自動化できるプロセスがある。 申請 承認 作成 付与 コンプラ厳しい お客様ほどIaCは必須 概要 開発者が必要なポリシーを IAM管理者に申請する。 申請されたポリシーに過剰がな いか確認する。 ポリシーを申請通り作成する。 ポリシーをアタッチする。 自動化可能性 ✘ ✘ ✓ ✓ IaC Github + Terraform 作業者 開発者 IAM管理者 IAM管理者 IAM管理者 feature/iam-role push main pull request main approve plan apply ※トランクベース開発