AWSアソシエイト試験に向けて3(IAM周り）

IAMの認証方式

大きく分けて4つに分類される。

アクセスキーID/シークレットアクセスキー

EC2インスタンス接続などのREST/Query形式でのアクセスやAWS CLI、API利用時の認証に用いる。

X.509 Certificate(公開鍵証明)

SOAP形式(リクエスト及びレスポンスをXMLで行う)でのAPIリクエストで用いる。

AWSマネジメントコンソールへのログインパスワード

AWSアカウントごとに設定されるパスワード、デフォルトでは未設定

MFA(多要素認証)

Google Authenticatorなどを使った認証。
ルートアカウントなどセキュリティリスクが高い場合に用いてセキュリティを強化する。

ユーザーのアクティビティの記録

AWSにおけるユーザーのアクティビティの記録はIAMが担う。
ツールは以下のように様々ある。

IAMAccessAnalyzer

外部エンティティと共有されているS3バケットやIAMロールなどを分析し、セキュリティ上のリスクであるリソースとデータへの意図しないアクセスを特定する。

Access AdvisorのService Last Accessed Data

IAMエンティティ(エンティティは実体の意。例えばこの場合はIAMユーザー、グループ、ロールを指す)が、最後にAWSサービスにアクセスした日付と時刻を表示する機能。

Credential Report

利用日時などが記録されたIAM認証情報のレポートファイル

AWS Config

IAMのユーザー、グループ、ロール、ポリシーの変更履歴、構成変更を管理・確認することができる機能

AWS CloudTrail

AWSインフラストラクチャ全体でアカウントアクティビティをログに記録し、継続的に監視し、保持することができる機能。
APIに関するログはこちらから。

IAM権限におけるベストプラクティス

IAMは権限に関わる機能になるので原則ベストプラクティスに沿った運用をするのが望ましい。

• ルートアカウントは必要な場合を除いて通常は使用しない
• 運用時には個々のIAMユーザーを作成し、管理する
• IAMユーザーへのポリシーの付与はIAMグループを通して行うようにする
• IAMユーザーやグループへのポリシーの付与は最小権限に収まるようにする(必要以上に権限を与えない)
• 新しくポリシーを作るのではなく、まずはAWS管理ポリシーを使用するようにする
• インラインポリシーではなく、カスタマー管理ポリシーを使用する
• アクセスレベルを使用して、IAMアクセス許可を確認する
• ユーザーのために強度の高いパスワードポリシーを設定する
• MFAの有効化
• EC2インスタンスで実行するアプリケーションにはIAMロールを使用する
• 第三者に一時的に認証を付与する場合はIAMロールを使用してアクセス許可を移譲する
• アクセスキーの共有はしない
• 認証情報を定期的にローテーションする
• 不要な認証情報は削除する
• AWSアカウントのアクティビティを監視する

IAMポリシーについて

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

基本的には上記のように表記される。
下から順に読んでいくとわかりやすい。
Conditionが条件。この場合は176.32.92.49/32のIPアドレスのアクセスについてと意訳できる。
ResourceはAWSリソースを指定する。この場合はS3のマイバケット。
ActionはAWSのサービス。この場合はS3のListBucketsとGetアクション全般。
最後にEffectが認可方式(ホワイトリストorブラックリスト)。この場合はホワイトリスト方式(以下のアクションやリソースを許可する)。
つまり

176.32.92.49/32のIPアドレスからのアクセスはS3のMyBucket及びS3のListBuckets、Getアクション全般について認可をする。

という意味になる。
こういうことをユーザーやその集団であるグループに都度付与したり、あるいはどのユーザーやグループにどんなポリシーが付与されているのかという関係性を表したのがIAMになる。

IAMユーザー

IAMにおけるユーザーは権限(ポリシー)の強度によって管理される。
例えば

• ルートユーザー
• 管理者権限(Administer Accessポリシー持ち)
• パワーユーザー

という例を見てみる。
ルートユーザーはその名の通りすべてのサービスとリソースへの権限を持っているユーザーになる。
当然、普段遣いはその特性上推奨されないので以下のように管理者権限を持つユーザーを作り役割の大半を代行させるようにする。
管理者権限はAdminister Accessというポリシーを付与されたユーザーであり、IAMの操作権限等(新規ユーザーの作成など)ルートユーザーの権限の多くを代行できる権限を持つユーザー。
ただし、ルートユーザーのみ持つ権限に関しては代行できない。
パワーユーザーはIAM以外のすべてのAWSサービスにフルアクセス権限を有するユーザー。
管理者権限との違いはIAMの操作権限を持たないこと。
このように同じユーザーでも持つ権限を変えることができる。
当然、ある特定のサービス及びリソースのみアクセスできるようなユーザーを作ることもできる。
ちなみにIAMユーザーはデフォルトでは全ての権限を持っていない状態で作成される。

IAMグループ

先程の例はユーザー単位で権限を付与していたが、ユーザーをグループにしてそのグループに属する人たちに一括でポリシーを付与することもできる。
その集団をIAMグループという。
利点としてはグループに権限を付与するので、あとから人員(ユーザー)の追加があっても都度ポリシーを付与する必要がないということ。

IAM設計

実際に設計してみる。
設計において大切なことはAWSを利用するユーザーの役割及びそのアクセス権限を自社の組織構造と合わせて設計すること。
以下その観点の例。

• IAMユーザーかIAMグループか
• AWS利用者が誰なのか
• 利用者の役割とその利用範囲はどこまでなのか

例えばこの3点ならまずポリシーの付与をユーザー単位かグループ単位かにするのをその規模感で決定し、その後利用者は何人いてそれらがどの役割(管理者、PG、運用……etc)を持ち、それ故にどこまでアクセス権限を与えるか……というフローで考える。
結局、権限は必要以上に与えないずに例えばグループであるならば同じ役割や利用範囲でグループ別にし、それぞれに権限を与えることでそれを実現するといったことが肝要になってくるということになる。

アクセス管理

マネジメントコンソールからIAMへ飛び、ダッシュボードへ行く。
アクセス管理の欄から各IAMの設定ができる。

グループ～ポリシーまではいいとして、IDプロパイダは何に使うかというと、IAMユーザーを作成する代わりに、既存の外部IDに対してAWSリソースへのアクセス認可を与えるというものである。
SSO(Single-SignOn)を使うときに用いられる。
要はソーシャルログインを使ってAWSアカウントのリソースに対してアクセスしたい……なんて時に設定するところ。
アカウント設定からはAWSアカウントに設定されているパスワードポリシーの確認、及び変更と一時的な認証に用いるSTS(Security Tokens Service)のエンドポイントの設定を確認できる。

アクセスレポート

アクセスに対するモニタリング。
組織アクティビティとSCPはAWS Organizationの部分で触れる

Access Analyzers

リソースに対して不正なアクセスがないかモニタリングをしている。

認証情報レポート

アカウントのすべてのユーザーと、ユーザーのさまざまな認証情報のステータスをリストしてくれている。

ポリシーの作成

実際にポリシーを作ってみる。
ポリシーには3つ種類があり

• ユーザー管理ポリシー(ユーザーが作ったポリシー)
• AWS管理ポリシー(プリセット)
• インラインポリシー(IAMアイデンティティ自体に紐ついて定義されているポリシー)

の3つがある。
IAMアイデンティティはIAMユーザー、グループ、ロールを指す。
参考: 管理ポリシーとインラインポリシー
なるべくAWS管理ポリシーを使うというのがベストプラクティスであった。
そして権限は最小限に留めるべきというのもベストプラクティスであったので、具体的にポリシーを作成する際には

どのサービスに対しての権限を考えるのか → どれくらいの権限を与えるのか

というフローが大切になる。
例えばアプリ開発に関わる部分及びログ管理の権限を持ったユーザーを作りたいとする。
このときユーザーありきで考えてしまうと

上記2つの権限を持ったユーザーを作ればいいじゃない → 開発・ログ管理の権限をまとめたポリシーを作成！

という罠にハマってしまう。
繰り返しになるが権限は最小限度でなければいけない。
つまりこの場合開発とログ管理でポリシーを別々に作り、適用時にその2つを権限を持つべきユーザーへ適用するのが正解となる。

さて先程のJsonを見てみる。

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

こういったことを定義していこうというのがポリシーの作成だが直接JSONを書かなくてもビジュアルエディタで下記のフローをサービス毎に都度行うことでも設定できる。

サービスの設定

どのサービスに対してのポリシーなのか選択する。

アクション

指定したサービスに対してどのアクションを許可するか選択できる。
例えばEC2インスタンスにおいてタグ付けはできるが、削除はできないといったレベルで細かく設定することもできる。

ただし、上記の通り例えばEC2の場合は約400ものアクションがあるためちゃんと扱えるにはそのサービスのアクションについての理解が問われることとなる。

リソース

指定したサービスに関わるリソースへのアクセス認可を設定できる。

こんな感じでずらっと出てくるが、基本的にはすべてのリソースでということになる。
この部分は例えば複数のグループがある場合などはそれぞれ役割や利用範囲が異なるはずなので、それに対してリソースへのアクセスを適宜制限したほうが良い……というケースもあるが、特に必要がある場合はリソースへのアクセスに制限をかけるという認識で問題はないようだ。

リクエスト条件

ユーザーに対するアクセス認可への条件。
MFA認証なしではそもそもサービスへアクセスできないとかそういうレベルの設定をする。

ポリシーの確認

作ったポリシーを確認してみる。
テキストボックスから検索してもいいし、フィルターにかければユーザー管理かAWS管理かでフィルタリングできる。

こんな感じで表示される。
ポリシー名をクリックすると詳細が見れる。
例えばJsonでみたければ以下のように表示することもできる。

ユーザー作成とグループ追加

あとはユーザー作成をしてそれをグループに入れれば完了となる。
グループ作成は画面の指示に従うだけなので割愛、ポリシーの適用もここでできる。

IAMロール

システム設計においてAWSサービス間で連携する必要性があるとする。
その場合連携箇所を割り出して、必要な連携が取れるようにリソースに対して権限設定をしないといけない。
そういうときに用いるのがIAMロールとなる。
おさらいであるがIAMロールは今回のようにリソースに対する権限付与の他に、第三者に一時的に権限を付与する(役割(Roll)を与える)という目的などでも使用される。
ポリシーを作ったあと、ロールの作成からロールを適用するユースケース(サービス)を指定し、ロールに内包するポリシーを選択して作成することができる。
今回はEC2インスタンスがS3に対してバッチ処理ができるようにという想定なので、EC2インスタンスに対してS3への権限を付与するということを下記のように行っている。

あとは以前やったようにSSHでインスタンスにアクセスしてコマンドを打って接続ができているか確認すればOK。
ここまででS3の設定(CloudTrailで証跡を作る等)をしていればaws s3 lsでログの有無を取得できる。

IAMロールでの権限付与

繰り返しになるがIAMロールでは第三者に対して一時的に権限を付与することができる。
ユースケースとしては監査人に対して監査の際にアクセスできるように権限を与えるということが考えられる。
手順例としては下記の通り

• 実行アカウントで権限移譲用のIAMロールを作成
• 移譲されるアカウントでIAMポリシーに先程のロールを適用し作成する
• 作成したIAMポリシー移譲されるアカウントのIAMユーザーに適用する
• 上記のIAMユーザーで実行アカウントへアクセスする。

ロールの作成へ飛んで、今度は別のAWSアカウントを選択して対象となるアカウントIDを入力してあとは画面の指示に従えば、そのアカウントIDに対して適用できるロールが完成する。
あとはロールの一覧から作ったロールを選択して詳細画面へ行き

• ロール名
• ロールARN(ロールを一意に識別するもの)
• アカウントID(ロールを作ったアカウントのID)

をメモしておく。
あとはロールを適用する側のアカウントでポリシーを作ってもらう。
この時、今回は権限移譲になるのでAWS管理ポリシーからAdministerAccessポリシーをインポートしておく。
あとはビジュアルエディタではなくjsonから直接

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "sts:assumeRole",
            "Resource": "ロールARN"
        }
    ]
}

としてやれば完成。
sts:assumeRoleは一時的なSTS認証を取得するアクション、つまりSTS認証ができるようにする。
あとは作ったポリシーを該当ユーザーへ付与(既存のポリシーから付与できる)し、作成したユーザーでサインインすればOK。
IAMユーザーは作成した際に、コンソールへのログイン権限を持つならリンクが出るのでそこからできる。
あとはサインイン先のヘッダーにアカウント名があると思うのでそこのプルダウンからロールの切り替えができる。

あとはロールの切り替えから先程メモした

• 実行アカウントのID(権限を本来持っているアカウントのID)
• 移譲用ロールのロール名

を入力すると実行アカウントのコンソールへアクセスできるという寸法。
こうすることで監査人に対して監査の時だけ当該アカウントのコンソールへアクセスできるようにすることができた。

Access Analyzerの作成

リソースに対してのユーザーのアクセスに対するアクティビティの分析を行う場所。
要は不正なアクセスがないかどうかをモニタリングしてくれる。
アーカイブルールを作るとそのルールに基づいたアクティビティをアーカイブに保存しておいてくれる。
例えば先程のアカウント移譲の際にアカウントIDを指定することがあったが、そのアカウントID以外のアカウントIDからのアクセスをアーカイブ化しておけばいつどこで不正にコンソールへのアクセスがなされたか証拠が残る……ということもできる。

AWS Organization

IAMのアクセス管理を大規模組織で簡素化するためのサービス。
これまではアカウント内のIAMユーザーやグループに対して色々やってきたが、AWS OrganizationはAWSアカウント自体が対象となる。
主にできることとしては

• AWSアカウントをグループ化してポリシーを一括で適用できる
• コンソール/SDK/CLIでアカウントの新規作成を行い、作成内容をログ管理できる
• 複数のAWSアカウントの請求を一括化できる

ということが挙げられる。

フローとしては以下の通り

マスターアカウントの決定

グループ化するAWSアカウントのうちマスターになるアカウントを決定し、メンバーになるアカウントを招待する

組織単位(OU)に分配

マスターアカウントがルートユーザーアカウントとなり、招待したメンバーアカウントをグループにあたる組織(OU)へ適宜分配する。

機能セットの選択

以下2つから選択

• Consolidated Billing Only
• All Feature

要は支払い一括請求のみ使うか、すべての機能を使うかという選択。
ただし、All Featureにする場合は当然AWSアカウントすべてを統制することになるのでその分人的・運用コストがかかる。

SCP

OUにおけるポリシーのようなものがSCP。
つまりOU内メンバーに関する権限境界の設定となる。
ただし、あくまで境界の設定なので別途IAMで権限は付与しないといけない。
例えば

SCP側

• EC2
• RDS
• ECS

IAM

• EC2
• ECS

といった場合、権限があるのはEC2とECSのみになる。
SCPはOU内のメンバーに対して権限を与えるならどこまで与えていいかを示しているようなものだろうか

ポリシーの設定

AWS Organizationsのポリシー(SCP)には以下の4つがある。

• AIサービスのオプトアウトポリシー
• バックアップポリシー
• サービスコントロールポリシー
• タグポリシー

うちサービスコントロールポリシーが先程の例における権限領域の設定、タグポリシーがOU内でのタグ付けのルールを統一するためのポリシーとなる。