IAM

IAMポリシー

JSON形式で記述されたアクセス権限の設定のこと。
- Effectは制御方法で、"Allow", "Deny"のみ。
- Actionは対象の操作
- Resourceは対象のAWSリソース
- Conditionはアクセス制御が有効となる条件
IAMユーザ、IAMグループ、IAMロールに設定可能
実例

{
  "Effect": "Allow",
  "Action": [
    "s3:ListBuckets",
    "s3:Get*",
  ],
  "Resource": [
    "arn:aws:s3:::mybucket",
  ],
  "Condition": {
    "IpAddress": {
      "aws:SourceIP": ["176.32.92.49/32"]
    }
  }
}

アカウント種類

通常、以下のようなアカウント階層で運用する。
- ルートアカウント ... すべてのサービスとリソースの使用権原を有する。日常的には使わない。
- 管理者権限(IAMユーザー) ... AdministratorAccessが許可されたIAMユーザー。IAMの操作も可能。
- パワーユーザー(IAMユーザー) ... PowerUserAccessのIAMユーザー。IAM以外のすべてのAWSサービスにアクセス権限を持つ。IAMは操作できない。
ルートアカウントのみの権限
- ルートアカウントのメアド、パスワード変更
- IAMユーザーの課金情報へのアクセス権のactivate/deactivate
- DNS関連
  - 他AWSアカウントへのRoute53のドメイン登録の移行
  - 逆引きDNS申請
- AWSサポート等のキャンセル
- AWSアカウントの停止
- 一括請求（コンソリデーティッドビリング）の設定
- 脆弱性診断フォームの提出

IAMエンティティの種類

IAMユーザー
IAMグループ
- 組織単位でIAMポリシーを設定可能となる。
IAMロール
- AWSリソースに対してアクセス権限をロールとして付与できる。
- また、アカウントの外部アクセスにも付与できる。(別のAWSアカウントなど)
IAMポリシーのタイプ
- ユーザーベースのポリシー
  - 管理ポリシー、インラインポリシーをIAMエンティティ(IAMユーザー、グループ、ロール)にアタッチする。
  - ユーザーベースのポリシーでは、アクセス許可はIAMエンティティに付与される。
- リソースベースのポリシー
  - バケットポリシーなどのJSON形式で定義されたインラインポリシーをリソースにアタッチする方式。
  - リソース自体が固有のポリシーを持っているケースはこれ。
  - S3バケットポリシーやIAMロールの信頼ポリシーなど。
  - 他には、SNSのTopicポリシーやVPCエンドポイントポリシーなどあるようだ。
  - 詳細は下記。
    https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html
- アクセス許可の境界
  - ユーザーベースのポリシーがIAMエンティティに付与できる許可の上限を設定する機能
  - アクセス許可を付与することはできない。

ユーザーベースの様々なポリシー種類

管理ポリシー
- AWS管理ポリシーは、AWSがすでに準備しているポリシーである。
- カスタマー管理ポリシーは、AWSアカウントが作成・管理する管理ポリシーであり、同じポリシーを複数のIAMエンティティにアタッチできる。
- ポリシーの変更時は、アタッチ済みのすべてのエンティティに変更が反映され、バーしょん管理も可能。
インラインポリシー
- １つのプリンシパルエンティティに埋め込まれた固有のポリシー。
- ポリシー単体では存在できず、いずれか１つのエンティティにアタッチされる。
- 意図しないアクセス権の変更が行われたくない場合に使用するが、基本的には、管理ポリシーの使用が推奨。
IAMロールの信頼ポリシー
- 一時的な権限移譲操作に特化したポリシー。
- 具体例としては、監査人に一時的に監査ログへのアクセス権を付与したい場合など。
- 以下に具体的な例がある。
  - https://dev.classmethod.jp/articles/iam-role-externalid/
- この例では以下のような手順で使用される。
  - 私のAWSアカウントで外部(Example Corp.)向けのIAMロールを作成し、IAMロールのARNをExample Corp.に伝える。
  - このIAMロールは、信頼されたエンティティに、Example Corp.のAWSアカウントを指定しておく。これにより、Example Corp.以外がAssumeRoleすることはできない。
  - Example Corop.は、このARNを使用してAssumeRoleし、私のAWSアカウントのリソースにアクセスが可能となる。
- ちなみにこの例では、外部IDというものをConditionに使い、ARNが漏洩した場合に、第３者に、Example Corp.のSaaSを介して、不正アクセスされないようにするため、という理由を説明している。
- IAMユーザを一時的に作成し、削除するという使い方でも一時的な権限移譲はできるが、 IAMユーザ作成は基本永続的な対応に使用されるため、信頼ポリシーを使うことが推奨される。
- SaaSによっては、IAMロールではなくアクセスキーしか対応してない場合のあり得る。

IAMの認証方式

アクセスキーIDとシークレットアクセスキー
- EC2インスタンス接続などのREST、AWS CLI、APIを使用した認証で使用。
X.509 Certificate
- SOAP形式のAPIリクエスト向けの認証方式。
- SOAPはRESTより歴史が古く、より厳格な標準化の元管理され、XMLでのメッセージングを行う。
AWSマネジメントコンソールへのログインパスワード
- デフォルトは未設定
MFA(多要素認証)
- 推奨されているピンコード等での認証方式

アクティビティの記録方法

IAMアクセスアナライザー
- 外部アカウント(エンティティ)と共有しているS3やIAMロールを分析し、意図しないアクセスをリスクとして特定
Access AdvisorのService Last Accessed Data
- IAMエンティティが最後にAWSサービスにアクセスした日付と時刻を表示する機能
Credential Report
- IAM認証情報の詳細なレポートを取得できる。
AWS Config
- IAMのユーザ、グループ、ロール、ポリシーの変更履歴を管理、確認できる機能
AWS CloudTrail
- AWSインフラ全体のアカウントアクティビティをログに記録して監視できる機能。
その他のロギング機能としては以下も使用可能
- Amazon CloudFront
  - ユーザーリクエストを記録できる。
- Amazon S3
  - アクセスリクエストを記録できる。
- Amazon CouldWatch
  - リソースとアプリケーションを監視し、定義したメトリクスに基づいてアラームを設定可能。

IAM権限のベストプラクティス

ルートアカウントのアクセスキーをロックし、ルートアカウントを使用しない。
個々のIAMユーザーを作成して、IAMユーザーで管理を行う。
IAMユーザーへのアクセス許可には、IAMグループを介して行う。
アクセス許可は最小権限のみを設定する。
カスタマー管理ポリシーよりも、AWS管理ポリシーを使用できないか検討する。
インラインポリシーよりも、カスタマー管理ポリシーを使用できないか検討する。
アクセスレベルを使用してIAMアクセス許可を確認する
- ReadOnlyやFullAccessなど、適切なものをという意味。
強度の高いパスワードポリシーを設定する。
MFAを有効化する。
EC2インスタンスで実行するアプリケーションにはIAMロールを使用する。
- EC2インスタンスにアクセスキーなどを配置せず、IAMロールを使って制御しろという意味と思われる。
- アクセスキーが必要なのは、AWSの外部からアクセスする場合のみである。
第三者に一時的に認証を付与する場合はIAMロールを使用する。
- IAMロールの信頼ポリシーを参照。
アクセスキーを共有しない。
認証情報は定期的にローテーションする。
不要な認証情報を削除する。
AWSアカウントのアクティビティを監視する。
- アクティビティ記録方法を参照。
公式は以下の通り。
- https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/best-practices.html

IAM機能の説明

Policy Simulator
- IAMやOrganizationで、複数のポリシーを設定した場合に、うまく権限付与されているかを確認するツール。
- OrganizationsにおけるSCPなどの他のポリシーに対しても使える。
  - Organizationsは複数のAWSアカウントを管理するサービス。
  - SCPはそのポリシーで、AWSアカウントのアクセスを制御する。 (IAMポリシーは、IAMエンティティのアクセスしか制御できないのでそこｔが異なる。)
Web Identity Federation Playground
- ID Federationを使って、SSOやオンプレのAD(Active Directory)と連携する場合がある。
- その際のIdP(IDプロバイダ)での認証情報や一時的なtokenを取得するためのツール
IdP(IDプロバイダ)
- Federation Accessを実現するもの。
- ADというオンプレの認証の仕組みとIAMを連携し、統合管理できるようにする機能。
- AWS外のユーザーIDを管理し、アクセス許可などを制御できる。
STS(Security Token Service)
- 一時的な認証情報を付与する機能.
- アカウント設定から、リージョン毎のエンドポイントでの有効・無効を設定できる。
アクセスレポート
- アクセスアナライザー
  - 認証情報の分析、不正なアクセスなどを分析できる。
- 認証情報レポート
- 組織アクティビティ
  - Organizationsを使用している場合に使う。
  - Organizationsにおけるアクティビティを見ることが可能。
- SCP
  - Organizationsを使用している場合に使う。
  - AWSアカウントのアクセス権をコントロールするポリシー。

ポリシーの作成例

開発グループ用
- リソースで絞り込んで、アクションを選択する。VPC関連のアクションはなぜかEC2リソースの中にあるので、注意する。
- EC2, ELB, AutoScaling, RDS, S3のサービスについて、すべてのアクション、すべてのリソースを許可してポリシーを作成。
  - AutoScalingなど、リソースを指定できないものもあり、その場合は勝手にすべてのリソースとなる。
運用グループ用
- CouldWatch, CouldTrail, Configについて作成

ロールの作成の種類

ロールの種類として以下がある。
- AWSサービス用
- 別のAWSアカウント用
- ウェブID ... WebIDプロバイダを使ってFederationによって外部認証をする機能があり、それを使うCognito、STSなどの場合に使用。
- SAML 2.0 Federation ... ADなどで使われる方式。ADと統合してIAMを使っていく場合に使用。

IAMロールの権限移譲

アカウントAでアカウントBへの権限移譲用IAMロールを設定
アカウントBで、権限移譲用IAMロールをポリシーとして設定
- ポリシーの作成でJSONモードで作業
- 管理ポリシーのインポートによりAdministratorAccessを流用する。
- 以下のように編集。
```
{
  "Version": "2012-10-17",
  "Statment": [
    {
      "Effect": "Allow",
      "Action": "sts:AssumeRole",
      "Resource": "アカウントAで作成したIAMロールのARN",
    }
  ]
}
```
ポリシーを、アカウントBのIAMユーザーに設定
IAMユーザーを利用してIAMロールをスイッチすることで、アカウントAにアクセスする。

Permissions boundary

IAMユーザーに対して権限境界を設定し、付与可能な権限範囲を制限できる。
例えば、IAMポリシーとPermissions boundaryの双方でアクセス権限がある場合、権限が有効となる。
形式は普通のIAMポリシーと変わらない。

Access Analyzer

analyzerをまず作成する必要がある。
アーカイブルールなどで、特定の条件にマッチしたらアーカイブすることができる。

AWS Organizations

複数のAWSアカウントを管理するもの。
- IAMは一つのAWSアカウント内でユーザーなどを管理するものである。
マスターアカウントとメンバーアカウントの階層となる。
以下が実現できる
- 複数アカウントの一元管理
  - 部署単位でOUにまとめて、そこに複数のメンバーアカウントをいれる。
  - OU単位でポリシーを管理
- 新規アカウント作成の自動化
- 複数アカウントの請求の一括化
  - Consolidated Billing Only
    請求のみを一括する。ボリュームディスカウントを得られるためコストメリットがある。
  - All Feature
    アカウント統制も含めてやりたい場合はこちら。
SCP
- SCPというポリシーを利用して、OU内に権限境界を設定できる。
- フォーマットはIAMポリシーと同じ。Sid, Effect, Action, Resouceなどを指定してアクセス権限を設定できる。
- 動作はPermissions boundaryと似ており、境界を与えるだけ。
- 設定しないデフォルトでは、制限のない状態となる。

AWS Organizationsの作成

Organizationsを作成すると、そのアカウントがmasterアカウントとなる。
組織IDが発行される。
メールアドレスの確認メールにより有効化される。
AWSアカウントを追加する。
- 新規作成と既存アカウントの招待の２パターンがある。
- 同様に確認メールとAcceptにより有効化される。
OUで階層構造化することができる。

AWS Organizationsで使用できるポリシー

SCP
- 説明済み
タグポリシー
- 組織内タグ付けのルールを標準化できる。(大文字小文字など)
バックアップポリシー
- バックアップルールを標準化できる。
AIサービスのオプトアウトポリシー
- AIサービスにAWSアカウント情報が使われないように制限するポリシー。
- rekognitionやlexなどサービス毎にOptOut(使用されないようにする)、OptInを設定可能。

IAM参考

[AWS]管理ポリシーとインラインポリシーの違いが分からなかったので改めてIAMポリシーのお勉強をする
- https://qiita.com/Batchi/items/a2dde3d2df27568cc078
セッションポリシーというものもあるらしい。
- https://docs.aws.amazon.com/ja_jp/transfer/latest/userguide/session-policy.html
IAMポリシーとSCPの違い
- https://aws.amazon.com/jp/premiumsupport/knowledge-center/iam-policy-service-control-policy/

Previous導入 NextVPC

Last updated 2 years ago