【試験対策】AWSソリューションアーキテクト IAMの概要
AWS Identity and Access Management (IAM) の概要
責任共有モデル
セキュリティに対してAWSとユーザとで責任分解して対応する責任共有モデルとなっている
- IAMによるアカウント管理:ここをIAMで対応
- セキュリティグループの設定:ここをIAMで対応
- アプリケーションのロールベースのアクセス設定
- ネットワーク/インスタンスオペレーションシステム(バッチ)などの設定
- OS/ホストべースのファイアーウォール設置
IAMとは
AWS Identity and Access Management(IAM)は安全にAWS操作を実施するための認証・認可の仕組み
- AWS利用者認証の実施
- アクセスポリシーの設定
- ユーザ個人またはグループ毎に設定
IAMの認証方式
項目 | 内容 |
---|---|
アクセスキーID/シークレットアクセスキー | EC2インスタンス接続などREST/Query形式API利用時の認証に使用する |
X.509 Creificate | SOAP形式のAPIリクエスト用の認証方式 |
AWSマネジメントコンソールへのログインパスワード | AWSアカウントごとに設定 デフォルトは未設定(ログイン不可) |
MFA(多要素認証) | 物理デバイスなどを利用したピンコードによる認証方式。ルートアカウントなどにMFAを付与してセキュリティを強化する |
ユーザのアクティビティの記録
項目 | 内容 |
---|---|
Access Advisor のService Last Accessed Data | IAMエンティティ(ユーザ、グループ、ロール)が最後にAWSサービスにアクセスした日付と時刻を表示する機能 |
Credential Report | 利用日時などが記録されたIAM認証情報にかかるレポートファイル |
AWS Config | IAMのユーザ、グループ、ロール、ポリシーに関しての変更履歴の確認、構成管理をすることができる機能 |
AWS CloudTrail | AWSインフラストラクチャ全体でアカウントアクティビティをログに記録し、継続的に監視し、保持することができる機能 |
アクセス権限の一時付与
一時的なアクセス権限の付与を行う
-
AWS Security TokenService(STS)
動的にIAMユーザを作り、一時的に利用するトークンを発行するサービス
-
Temporary Security Credentials
AWSに対して一時的な認証情報を作成する仕組み
ルートユーザ
最初に作されるユーザ、通常の管理には利用しないアカウント
- AWSアカウント作成時に作られるIDアカウント
- 全てのAWSサービスとリソースを使用可能な権限を有するユーザ
- 日常的なタスクはルートユーザを使用しないことが強く推奨される
※パワーユーザ(IAMユーザやグループの管理以外の全てのAWSサービスについてフルアクセス権限を有するユーザ)とは別物
ルートユーザのみの実施権限
- AWSルートアカウントのメールアドレスやpasswordの変更
- IAMユーザの課金情報へのアクセスに関するactivate(許可)/deactivate(許可しない)
- 他のAWSアカウントのRute53のドメイン登録の移行
- CloudFrontのキーペアの作成
- AWSサービス(サポート等)のキャンセル
- AWSアカウントの停止
- コンソリディテッドビリングの設定(複数アカウントをまとめた請求書の設定)
- 脆弱性診断フォームの提出
- 逆引きDNS申請
IAMユーザ
項目 | 説明 |
---|---|
設定上限 | 1アカウントで5000ユーザまで作成可能 |
設計内容 | ユーザ名 パス(オプション) ユーザにオプションとして設定できる情報であり、パスを基にユーザの検索が可能となる。組織階層やプロジェクトなどを設定できる。 (例:/aws/sa/) 所属グループ 10のグループまで設定可能 パーミッション AWSサービスのアクセス権限 |
IAMグループ
項目 | 説明 |
---|---|
設定上限 | 1アカウントで300ユーザまで作成可能 |
設計内容 | グループ名 パス(オプション) 組織階層などを設定できる。 (例:/aws/) パーミッション AWSサービスのアクセス権限 IAMユーザに付与したパーミッションと同時に評価 |
IAMポリシー
JSON形式の文書で作成された、ユーザやグループに付与するアクセス権限
- ユーザベース
- リソースベース:コンポーネント間の連携に使用する(例:S3,SNS,SQS)
ポリシーの種類 | 内容 |
---|---|
管理ポリシー ※管理者が作成したもの |
【AWS管理ポリシー】 AWSが作成及び管理する管理ポリシー 【カスタム管理ポリシー】 AWSアカウントで作成・管理する管理ポリシー 同じポリシーを複数のIAMエンティティにアタッチできる |
インラインポリシー | 自身で作成及び管理するポリシー 1つのプリンシバルエンティティ(ユーザ、グループ、またはロール)に埋め込まれたポリシーで、プリンシバルエンティティにアタッチ可能 |
JSONの記載項目 | 内容 | 例 |
---|---|---|
Effect | 状態 | “Allow”=>許可 “Deny”=>拒否 |
Action | 対象のAWSサービス | “s3:Get” |
Resource | 対象のAWSリソース ARNで記述 |
“arn:aws:s3:::mybucket” |
Condition | アクセス制御が有効になる条件 | IPアドレスなど |
IAMロール
リソースに対して権限を付ける
IAM設計
【重要】:AWSを利用するユーザの役割やアクセス権限を自社の組織構造と合わせて設計すること
「AWS利用組織」+「セキュリティポリシー」=>「自社に最適なIAM設計の実現」
ベストプラクティス
-
アカウント設定などの必要な場合を除いて、ルートユーザを使用しない。
-
ルートユーザなどの特権ユーザに対してMFAを有効化する
-
利用者ごとにIAMユーザを作成する
-
組織利用の場合は、役割ごとのIAMグループを作成してグループで管理するのを基本とする
-
最小限の権限設定と不要な認証情報は削除を心がける
なるべくつける人が使う範囲だけの権限とする
-
ユーザのために強度の高いパスワードポリシーを設定する
-
EC2インスタンスで作動するアプリケーションなどのプログラムから利用する場合はなるべくロールを使用する
-
モバイルやアプリケーションも含め、一時利用にはSTSなどで最小限の利用許可を与える
-
AWSアカウントのアクティビティを常に監視する
Logとしてしっかり見ていく
ユーザ?グループ?
少数利用がずっと継続する場合を除いて、拡大していく可能性があるのであれば少数利用も含めて最初からIAMグループで設定する方が良い
グループの設計方法
組織別または個人単位にAWS利用者とその役割別の利用範囲を整理して、グループ設計を実施する
AWS利用者の洗い出し | => | 利用グループへと集約 |
---|---|---|
AWS利用者の特定 | 同じ役割や利用範囲の一つをグループとしてまとめる | |
利用者の役割と利用範囲を整理 | グループ別の名称と最小利用範囲を確定する |
Subscribe via RSS