はじめに
こんにちは。今回はSCS試験対策でのIAMについてBluckBeltで学習した内容のメモ書きとして記録しようと思います。
よろしくお願いします(｡･ω･)ﾉﾞ
AWS IAMとは
- AWSのリソースをセキュアに操作するためのサービスであり、認証認可の仕組みを提供してくれる。
- 多要素認証（MFA）でセキュリティの強化もしてくれる
- 一時的な認証トークンを用いた権限の委任
- ADなどによるAWSリソースへの一時的なアクセスの許可
- 無料
ルートユーザーとは
個人学習とかでAWSコンソールにログインする際に一番最初に作成しなければならないAWSアカウントで、クレジット情報やすべてのリソースに対して完全なアクセス権があるため極力使用しないことがベストプラクティスに挙げられます。
なので、ルートユーザーのアクセスキーはロック・削除する必要がありルートユーザーの認証情報をほかの人に開示したりプログラムに埋め込んだりすると悪用される場合があるのでやらないこと！
-
アクセスキーとは
- アクセスキーとはIAMやEC2などのAWSの各サービスに対してプログラムにおけるアクセスを認証するために作成される認証キーになる。
- アクセスキーIDとシークレットアクセスキーで構成されます。
- 複数でリソースへのアクセス権を共有したい場合でもアクセスキーの共有はしない
- AWSへのアクセスを必要とするアプリケーションの場合はIAMロールを使用し一時的セキュリティ認証情報の取得
- 間違ってもGitHubやAMIの中などに情報を置かないこと
-
ルートユーザーで行う必要があるタスクの例
- ルートユーザーのメアドとパスワードの変更
- 支払いオプションの変更・確認
- AWSサポートプランの変更
- AWSアカウントの解約 etc...
IAMユーザー
AWSで作成しルートユーザーの代わりに使用するユーザーで作成する際には強力なパスワードポリシーを設定することが推奨されている。ちなみにルートユーザーにはパスワードポリシーは適用されない。
-
個別のIAMユーザーを作成するメリット
- 認証情報を個別にローテーションすることが可能
- アクセス許可をいつでも変更・無効化することができる
- CloudTraiからログアクションを追跡できる
-
MFA（多要素認証）
- パスワードやアクセスキーによる認証に追加してセキュリティを強化する仕組み
- ルートユーザーや強い権限をも有するIAMユーザー（特権ユーザー）にはMFAを有効化することでセキュリティを強化する。
IAMポリシー
IAMアイデンティティやAWSリソースに関連付けることによってアクセス許可を定義することができ通常JSONなどで記述される。
主なポリシーのタイプや説明がこちら
IAMグループ
IAMユーザーの集合体でIAMグループを使用することで同じ役割を持つIAMユーザーをグループ化しまとめることができます。ただしグループにグループやロールを所属させることは出来ない。IAMユーザーは複数のグループに最大10個に所属することができ、グループに関連付けされたポリシーは所属するユーザーに適応される。
IAMロール
AWSサービスやアプリケーションに対してAWSリソースの操作権限を付与することができる仕組み。ユーザー・アプリケーションに対して一時的に”引き受ける”ことで関連付けられたアクセス許可を受けることができる。IAMユーザーとグループには紐づけできない
-
一時的なセキュリティ認証情報
- 有効期限付きのアクセスキーID/シークレットアクセスキー/セキュリティトークンで構成される。
- 有効期限を一時的に付与するので認証情報が不要になった時にローテーションしたり明示的に取り消す必要がないので安全。（ユーザー側に認証情報が保存されない）
- ユーザーリクエストによってSTSが動的に作成される。
-
AWS Security Token Service（STS）について
- 一時的なセキュリティ認証情報を生成するサービスで、期限付きのキーやトークンを発行。
- 発行した認証情報の期限の変更は不可であり必要がある場合は特定の時点より前に発行したロールの認証情報のすべてのアクセス許可を取り消し可能。
- STSエンドポイントは全てのリージョンで使用できる。
◆一時的なセキュリティ認証情報を取得するためのAPI
| STSで利用できるAPI | 概要 |
|---|---|
| AssumeRole | ・既存のIAMユーザーの認証情報を用いてIAM Roleのtenporary security credentialsを取得するためにアクション ・AssumeRoleを行うのはIAMユーザーだけではなく重ね掛けすることができる。 |
| AssumeRoleWithWebIdentity | AmazonやFacebook、Googleによる承認情報を使用してロールを引き受け、tenporary security credentialsを取得するためのアクション |
| AssumeRoleWithSAML | Idpによる認証とSAMLのアサーションをAWSにポストすることでロールを引き受けtenporary security credentialsを取得するためのアクション |
| GetSessionToken | 自身で利用するIAMユーザーのtenporary security credentialsを取得するためのアクション |
| GetFederationToken | 認証を受けたFederatedユーザーのtenporary security credentialsを取得するためのアクション |
・PassRoleとAssumeRoleの使い分けについてはこちら
ロールを使用したアクセス許可の委任の例
別のAWSアカウントのユーザーが認証情報を共有せずに自分のAWSアカウントのリソースにアクセスを制御可能にすることが可能
◆ユースケース
- IAMロールによるクロスアカウントアクセス
- クロスアカウントアクセスにより権限管理を効率化
- SAML2.0ベースのIDフェデレーション
- SAML2.0ベースのマネコンへのSSO
- Cognitoを用いたモバイルアプリのWeb IDフェデレーション
◆ロールを使用したアクセス許可の委任
アカウント間でセキュリティ認証情報を共有しないこと
- IAMロール利用の利点
- EC2上のアクセスキーの管理が容易
- 認証情報はSTSで生成
- 自動的に認証情報のローテーションが行われる
- EC2上のアプリケーションに最低権限を与えることに適している
- IAMユーザーの認証情報を外部に漏えいしてしまうリスクを低減させる
AWSアカウントのアクティビティの監視 例：）CloudTrail
AWSのリソースにどのような操作が加えられたか記録に残す機能であり、全リージョンでの有効化が推奨であり、適切なユーザーが与えられた権限で環境を操作しているかの確認と記録に使用。
- 記録される情報には以下のようなものが含まれる
- APIを呼び出した身元（Who）
- APIを呼び出した時間（When）
- API呼び出した元のSource IP（Where）
- 呼び出されたAPI（What）
- APIの対象となるAWSリソース（What）
- 管理コンソールへのログインの変更・失敗
アクセスレベルを使用してIAM権限を確認する
AWSアカウントのセキュリティを向上させるにはIAMポリシーを定期的に確認しモニタリングしてあげることでセキュリティの向上を図ることができる。
・「アクセスアドバイザー」を活用し、ポリシーにおいて必要なアクションにのみの最低限の権限が付与されていることの確認
・ポリシーの使用状況を確認し、適用されているユーザーやグループ、ロールの確認
・アクセス権限タグで最小権限か確認
◆アクセスレベルとは？
-
Lisut
- オブジェクトが存在するかどうかを判断するためにサービス内のリソースを一覧表示するアクセス許可（例：S3アクションのListBucket等）
-
Read
- サービス内のリソースのコンテンツと属性を読み取るアクセス許可。編集に対するアクセス許可はなくあくまで読み取り専用。（例：S3アクションのGetObject等）
-
Write
- サービス内のリソースを作成・削除または変更に対するアクセス許可。Writeアクションでタグに対しての変更も許可できるがタグのみへの変更に対してはTaggingアクセスレベルでの許可もできる。（例：S3アクションのCreateBucket・DeleteBucket等）
-
Permissions management
- サービスのリソースに対するアクセス許可を付与または変更するアクセス許可。たとえば、IAM や AWS Organizations のほとんどのアクション。AWSアカウントのセキュリティを強化するには、Permissions managementアクセスレベル分類を含むポリシーを制限したり定期的にモニタリングしたりする。
- Permissions managementについて詳しくはこちら
不要な認証情報の削除
- パスワード屋アクセスキーおローテーションなどを認証情報ライフサイクルの要件の結果を調査
- コンソールを使用しないIAMユーザーにはパスワードを設定しない
- 最近使用していないパスワード、アクセスキーは削除の対象
- 社員の入社、退職、異動や役割の変更など人とのライフサイクル対しても連動させる
- 認証情報レポートはCSVファイルとしてダウンロードすることができる。
◆認証情報レポートとは
4時間ごとに1回作成することができ、「ユーザーの作成日時」「最後にパスワード変更された日時」「MFAを利用しているか」「アクセスキーをローテーションした日時」「証明書はActiveか」等がわかる
認証情報を定期的にローテーションする
IAMユーザーのパスワードやアクセスキー/シークレットアクセスキーは定期的にローテーションすることが推奨されており認証情報の利用状況はIAMの認証情報レポートで確認することができる。
- IAMユーザーのパスワードローテーション
- IAMのパスワードポリシーでユーザーがパスワード変更できるように設定
- パスワードに有効期限を設けることで定期的にパスワードのローテーションをできるようにする
- アクセスキーのローテーション
- アクセスキーの作成で新しい認証情報の作成（最大２つ）
- 新しい認証情報でテストを行い古いアクセスキーはInactiveにする
おわりに
今回はIAMについてまとめました。9月にSCS試験を受ける予定なのでそれに向けて良い学習になりもう少しIAMについて詳しくなるためこの本でもう少し学習を続けていこうと思います！
見ていただきありがとうございました！次回はまたまとめたいと思ったのがでてきたらまとめていこうと思います！
(｡･ω･)ﾉﾞバイバイ