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設計の実現」

ベストプラクティス

  1. アカウント設定などの必要な場合を除いて、ルートユーザを使用しない。

  2. ルートユーザなどの特権ユーザに対してMFAを有効化する

  3. 利用者ごとにIAMユーザを作成する

  4. 組織利用の場合は、役割ごとのIAMグループを作成してグループで管理するのを基本とする

  5. 最小限の権限設定と不要な認証情報は削除を心がける

    なるべくつける人が使う範囲だけの権限とする

  6. ユーザのために強度の高いパスワードポリシーを設定する

  7. EC2インスタンスで作動するアプリケーションなどのプログラムから利用する場合はなるべくロールを使用する

  8. モバイルやアプリケーションも含め、一時利用にはSTSなどで最小限の利用許可を与える

  9. AWSアカウントのアクティビティを常に監視する

    Logとしてしっかり見ていく

ユーザ?グループ?

少数利用がずっと継続する場合を除いて、拡大していく可能性があるのであれば少数利用も含めて最初からIAMグループで設定する方が良い

グループの設計方法

組織別または個人単位にAWS利用者とその役割別の利用範囲を整理して、グループ設計を実施する

AWS利用者の洗い出し => 利用グループへと集約
AWS利用者の特定   同じ役割や利用範囲の一つをグループとしてまとめる
利用者の役割と利用範囲を整理   グループ別の名称と最小利用範囲を確定する