Identity and Access Management(IAM)
講演 https://www.youtube.com/watch?v=K7F5yTThynw
AWSリソースにアクセスする仕組み
- AWSリソースにアクセスするものをプリンシパルという
- ユーザー
- ロール
- アプリケーション
- 認証
- Authentication
- AWS STS
- MFA Token
- 認可
- リソースベースのポリシー
- ユーザーベースのポリシー
IDと認証情報の管理のベストプラクティス
AWSアカウントのルートユーザーアクセスキーをロックする
- IAMで設定するアクセスポリシーではルートユーザーのアクセス制限ができない。
○ルートユーザーの認証が必要なAWSタスク
-メールアドレスやパスワードの変更など
○ベストプラクティス
- ルートユーザーのアクセスキーは削除する
- すでに持っている場合には削除する
- ルートユーザーの認証情報を他社に開示しない。
個々のIAMユーザーを作成する
IAMユーザーを利用する。
○IAMユーザーを識別する方法
-
ユーザーのフレンドリ名
-
ユーザーのARN(Amazon Resource Name)
-
ユーザーの一意の識別子
-
○認証情報
- コンソールパスワード
- アクセスキー
○ベストプラクティス
個々のIAMユーザーを作成する。
メリット
認証情報を個別に変更できる
アクセス許可をいつでも変更、無効化できる
CloudTrailからアクセスログを取得できる
ユーザーの強力なパスワードポリシーを設定
AWSアカウントのルートユーザーには適用されないので注意。
アクセスキーを共有しない
- AWSへのアクセスを必要とするアプリの場合は、IAMロールを使用して一時的セキュリティ認証情報を取得する
- 情報の置き場を注意 盗まれると悪用される。(ビットコインのマイニングに悪用された例もあるらしい。)
- GitHubリポジトリ
- AMIの中への埋め込み
- 設計書への記載
特権ユーザーに対してMFAを有効化する
- MFA条件を指定したポリシーを関連付けできる対象
- IAMユーザーまたはIAMグループ
- S3バケット、SQS、SNSなど
- IAMロールの信頼ポリシー
-AWSアカウントのルートユーザーや強い権限を持つIAMユーザーにはMFAを有効化し通常利用しない。
-MFAデバイスも管理する。盗難されたら代替の認証要素を使って認証し、新しいMFAデバイスを有効化しパスワードも変更する。
アクセス権限のベストプラクティス
AWS管理ポリシーを使用したアクセス許可の使用開始
-
ポリシー
- アクセス許可を定義することができるオブジェクト
- JSONポリシードキュメントでアクセス条件を記述
- ポリシードキュメントは1つ以上のStatementブロックで構成
-
AWSがサポートするポリシータイプ
-
https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/access_policies.html
-
アイデンティティペースのポリシー
- 管理ポリシー ・・・再利用可能、複数エンティティに関連付け可能。バージョニング(過去5世代まで。)ロールバック可能
- AWS管理ポリシー
- カスタマー管理ポリシー
- インラインポリシー
- 管理ポリシー ・・・再利用可能、複数エンティティに関連付け可能。バージョニング(過去5世代まで。)ロールバック可能
-
リソースベースのポリシー
- 単一のIAMユーザー、グループ、IAMロールに直接埋め込む
- ユーザーを削除すると消えてしまう。(古い機能だから非推奨)
- IAMエンティティとポリシーとの厳密な1対1の関係を維持する必要がある場合にのみインラインポリシーを適用(これ使うことないだろ。)
-
AWS管理ポリシー
- AWSにより事前定義された管理ポリシー
- AWSが作成するため編集不可
- すべてのAWSアカウントで利用可能
○ベストプラクティス
AWS管理ポリシーを使用したアクセス許可の使用開始。カスタマー管理ポリシーは作るの大変だから、まずはAWS管理ポリシーを使う。
インラインポリシーではなくカスタマー管理ポリシーを使用する
インラインポリシーは再利用不可など使いにくいから。
追加セキュリティに対するポリシー条件を使用する
ポリシー条件:ポリシードキュメントの要素。
ポリシードキュメントの主な要素。
https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/reference_policies_elements_resource.html
- Version・・・含めないと古いバージョンとして扱われる。・
- Statement
- Effect
以下のPARCが特に重要。
-
Principal(誰に対して)
- AWSリソースへのアクセスが許可/拒否されるIAMエンティティを指定
- リソースベースポリシーで使用。
- AWSアカウント、IAMユーザー、IAMロール、フェデれーティッドユーザー、引き受けたロールユーザーをARN形式で記述
- 注意 IAMグループの指定は不可。
- IAMロールの信頼ポリシーのPricipal要素に指定したIAMユーザーとIAMロールを削除すると信頼関係は壊れる。
- (特に解説なかったから今の時点でこれはわからん。)
-
Action(どんなアクションを)
- 許可/拒否される特定のアクションを指定する
- Statement要素にはAction/NotAction要素が必須
- NotActionはxx以外を表す。
- "Effect": "Allow" のステートメントで NotAction 要素を使用して、AWS サービス内で、NotAction で指定したアクションを除くすべてのアクションへのアクセスを許可できます。https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/reference_policies_elements_notaction.html
-
Resource(どのリソースに対して)
- ステートメントで取り扱う一連のオブジェクトを指定する
- Statement要素にはResource/NotResource要素が必須
-
Condition(どんな条件下で)
- ポリシーが有効になるタイミングの条件を指定する
- Condition要素の記述は必須ではない。https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/reference_policies_elements_condition.html
- 要素のAND条件とOR条件を設定できる
-
アクセス可否の決定ロジック
- 暗黙的なDeny < 明示的なAllow < 明示的なDeny
- すべてのアクセスはデフォルトで拒否
- アクセス権限にAllow条件があるとアクセス許可
- ただし、アクセス権限に1つでも明示的な"Deny"条件があった場合、アクセス拒否
○ベスプラ 追加セキュリティに対するポリシー条件を使用する
追加のセキュリティ要件に対しては適切に条件を設定して絞ると安全。
例. MFA必須、ソースIPアドレス範囲など。条件を絞る。
最小権限を付与する
アイデンティティベースのポリシー
管理ポリシーとインラインポリシーOR条件で有効になる
→これは納得。
アクセス管理の境界
アイデンティティベースのポリシーとAND条件で有効になる。
→これはよくわからない。
SCP
- IAMではなくAWS Organizationsの機能。
- 複数AWSアカウントをグループ(OU)化して管理可能。組織階層の配下ですべて許可になる。
- アクセス管理の境界と同様に、AND条件で有効になる。
SCPはアクセス管理の境界と違って、ルートユーザーの権限設定も可能。
リソースベースのポリシー
- 同一アカウントの場合、リソースベースポリシーとアイデンティティベースポリシーのOR条件で利用可能
- クロスアカウントの場合、リソースベースポリシーとアイデンティティベースポリシーのAND条件で利用可能
そりゃそうだね。他人のアカウントにアクセスするには他人に許可されないといけないから。
IAMユーザーへのアクセス許可を割り当てるためにグループを使用する。
- IAMグループは、IAMユーザーの集合
- IAMユーザーは複数のIAMグループに所属できる。
- IAMグループやに関連付けられたIAMポリシーは所属するIAMユーザーに継承される
所感・知ったこと・疑問
- STSは認証のサービスなんですね。
- ARNは(Amazon Resource Name)
- IAMロールの信頼ポリシーって何?
- パーミッションバウンダリーって何?必要性が不明。→https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/access_policies_boundaries.html
- IAMグループ使わないと権限管理が面倒なんですね。組織異動があったら、ユーザーのグループを移動させればよいなど。