【AWS SAA対策 Udemy】IAM
AWS Identity and Access Management (IAM) では、AWS のサービスやリソースへのアクセスを安全に管理できます。IAM を使用すると、AWS のユーザーとグループを作成および管理し、アクセス権を使用して AWS リソースへのアクセスを許可および拒否できます。
IAMの概要
IAM = AWS Identity and Access Management
AWSにおけるユーザー管理の仕組み
認証/認可の仕組み
個人やグループにAWSサービスを利用できる権限を管理できる
ECやS3にアクセスできる事を管理する
IAMのおける主要なトピック
IAMユーザー
ルートアカウント
すべてのAWS Webサービスを利用できるので、日常タスクは操作しない
ルートアカウントしかできない事(一部抜粋)
ルートアカウントのメールアドレスやパスワードの変更
AWSサービスのキャンセル
AWSアカウントの停止
管理者権限ユーユーザー
管理者権限を付与されたIAMユーザーの事を指す
IAMの操作権限まであり
ルートアカウントしかできない権限はされない
パワーユーザー
IAM以外の全てのAWSサービスにフルアクセス権限を有するIAMユーザー
IAMの操作権限はなし
IAMグループ
組織単位で使う場合はIAMグループを作って、そこにユーザーを追加していく
ポリシー
IAM ポリシーはどのリソースへのアクセスを許可するのか?を管理する。
Conditionがアクセス制御が有効となる条件になっている。
IAMロール
AWSリソースに対してアクセス権限をロールとして付与できる
EC2インスタンスにS3へアクセスするなど
IAMの認証方式
アクセスキーID/シークレットアクセスキー
AWS マネジメントコンソールへのログインパスワード
MAF(多要素認証)
IAMのベストプラクティス
AWSアカウントのルートユーザーのアクセスキーをロックして、通常はルートアカウントを使わない
個々のIAMユーザーを作成して、IAMユーザーで管理者権限の管理行う
IAMユーザーへのアクセス許可の割り当てにはIAMグループを利用する
IAMユーザーやIAMグループには最小の権限のみを設定する
新しくポリシーを作るのではなく、AWS管理ポリシーを使用する。
インラインポリシーではなくてカスタマー管理ポリシーを使用する
アクセスレベルを使用して、IAMアクセス許可を確認する
ユーザーの為に強度の高いパスワードポリシーを設定する
MFAを有効化する
Amazon EC2 インスタンスで実行するアプリケーションにIAMロールを適用する
第三者に一時的に認証を付与する場合はIAMロールを使用してアクセス許可を異常する
アクセスキーは共有しない
認証情報を定期的にローテンションする
はい...
不要な認証情報を削除する
AWS アカウントのアクティビティを監視する
インラインポリシーとは?
インラインポリシーは⾃⾝で作成および管理するポリシーであり、プリンシパルエンティティにアタッチすることができます。インラインポリシーは、ポリシーとそれが適用されているプリンシパルエンティティとの厳密な 1 対 1 の関係を維持する必要がある場合に便利です。たとえば、ポリシー内のアクセス権限が意図したプリンシパルエンティティ以外のエンティティに間違って割り当てられないようにする必要がある場合などです。インラインポリシーを使用すると、ポリシーのアクセス許可が間違ったプリンシパルエンティティにアタッチされることはありません。
IAMの設計
AWSを利用するユーザーの役割やアクセス権限を自社の組織構造と合わせて設計する事が重要
AWSの利用組織×自社のセキュリティポリシーでIAMを設計していく
IAM ユーザー or IAM グループ
少数利用を含めてグループを作成する
こっちの方が運用が楽になる
AWS利用者との役割の洗い出しを考える
インフラエンジニア = 管理者権限をもったユーザー
アプリケーションユーザー =IAM以外のAWSの操作権限を持ったユーザー
グループ別の名称と最小権限の設定
IAMグループへのポリシー適用
ここからハンズオンパート
適用手順
code:md
(1)自社組織に必要な権限を設計する
(2)自分で独自のポリシーを作成する
(3)グループを作成しポリシーを適用する
(4)ユーザーを作成してポリシーを適用する
ケースパターン
IT管理者
ルートユーザーも保持して、権限設定など管理する
フルアクセスの管理者権限 = 管理ポリシー、Adminstor
運用管理者(インフラ)
運用管理全般を担っているスタッフで様々なモニタリングと障害対応など直接アプリに触れる事もある
運用サービス全般と開発環境へのアクセスを付与
アプリ管理者(アプリケーションエンジニア)
主だったAWSサービスを利用してサービス開発を行っている
担当しているアプリの開発範囲でのみアクセス権限を付与する
まずはアプリ開発者用のポリシーを作成して適用させる。
めちゃくちゃアクセスレベルを細かく設定できる..すごい..!
https://gyazo.com/1fc45e1245c880d15bd470cfe69851db
なぜかはわからないが、EC2のアクセス権限の中にVPCの権限は入っている..
https://gyazo.com/549ac5181f6cabc6afa1b3a8e18419fb
リクエスト条件で送信元IPのチェックも設定できる。これは便利だ...!
アプリケーションエンジニアが利用するサービス、アクセスレベル、リソースをどんどん追加していく。
https://gyazo.com/862158e82409de9d702f08679382c9e7
これでテスト用のApplicationというポリシーが作成できた
https://gyazo.com/f23c18cd85b8c3689d05ba30693a4e37
次に運用チーム用のOparationというポリシーを作成する
https://gyazo.com/f0ada62e7b1affa4c869dfb7226c2554
カスタマー管理でフィルタリングができる
https://gyazo.com/0e8bd98484e05b0588fab73eb3d6a1f9
グループを作成して先程作ったポリシーをアタッチする。更にユーザーを作成してグループに追加する事で、ポリシーが適用されたユーザーが出来上がる。
IAMロールへのポリシー適用
code:md
ロールを設計する
ロール向けのポリシーを作成する
ロールを作成してポリシーを適用する
システム設計からAWSサービス間のアクセス権限の設定を行っていく
まずはEC２インスタンスを建てる。今回セキュリティグループはバッチサーバはSSHのみという事でタイプはSSHだけに絞る。
https://gyazo.com/11ff6e0161b6b7e28384a21520e87c49
https://gyazo.com/ee53955a28404dbbe4dacfd7a308312f
AWSサービス以外にもロールを適用できる
https://gyazo.com/5958be1e52a62d155bd1ea16ba73d8d2
https://gyazo.com/b1d6ac9be5d39e004c2a850177c46c91
次にターミナルから接続してS3にアクセスする
code:md
ssh -i ~/.ssh/udemy_sample.pem ec2-user@パブリック IPv4 アドレス
実行結果
code:sh
木 23 :~ endu# ssh -i ~/.ssh/udemy_sample.pem ec2-user@ec2-*** The authenticity of host 'ec2-***'
(~)
__| __|_ )
_| ( / Amazon Linux 2 AMI
___|\___|___|
11 package(s) needed for security, out of 35 available
Run "sudo yum update" to apply all updates.
内部ではs3コマンドでサービスの稼働が確認できる
code:md
2020-11-03 02:44:59 udemy-admin-20201103
IAMロールの権限移譲
IAMロールは監査人などに一時アクセスする歳に権限異常を行う
事前に別アカウントを作って、ロールの作成でアカウントIDを指定する
ARNとはAmazon Resorce Nameになっている
アクセスアナライザーの設定
https://gyazo.com/e69b4e4fc0bf9d58795af21728d739bc
アーカイブルールを設定できる
更に管理者を追加したりする事もできる。
https://gyazo.com/17fb86425016d4f5207d6d1ef2fb0368
Access AdvisorのLast Accessed DataにIAMエンティティ(ユーザー、グループ、ロール) が最後にAWSサービスにアクセスした⽇付と時刻が表⽰されます。AWS Identity and Access Management (IAM) アクセスアドバイザーでは、AWS コマンドラインインターフェイス (AWS CLI) または SDK で IAM アクセスアドバイザー API を使用することで、すべてのアカウントで IAM アクセス権限の分析を自動化できます。IAM アクセスアドバイザーは、サービスアクセス監査、不要なアクセス権限の削除、IAM エンティティ (ユーザー、ロール、グループなど) が AWS サービスに最終アクセスしたタイムスタンプ取得のための適切なアクセス権限の設定を支援します。
AWS Organaizationsの概要
AWS Organaizationsでは複数のAWSアカウントを利用している場合に、統合管理を実施する事ができる。
IAMのアクセス管理を大きな組織でも楽に実施できる
複数アカウントの一元管理
新規アカウント作成の自動化
一括請求
アカウントの構成は1つだけ、マスターアカウントにして、それ以外をメンバーアカウントにして管理する。
マスターアカウントからメンバーアカウントを招待する。
組織単位(OU)という単位で管理できる。また機能セットとして支払い一括代行と全体管理の2つがある。
SCP
サービスコントロールポリシー (SCP) は、組織のアクセス許可の管理に使用できる組織ポリシーの一種です。SCP では、組織のすべてのアカウントで使用可能な最大アクセス許可を一元的に制御できます。SCP は、アカウントが組織のアクセスコントロールガイドラインに従っていることを確認するのに役立ちます。SCP は、すべての機能が有効になっている 組織でのみ使用できます。組織が一括請求機能のみを有効にしている場合、SCP は使用できません。SCP を有効にする方法については、「ポリシータイプの有効化と無効化」を参照してください。
AWS Organaizations
AWSを使っているAWSアカウントを管理する
IAM
AWSアカウントないのIAMユーザーを管理する
IAMユーザーが具体的に何をするのかが、ふんわりしている
そもそも管理者ユーザーとルートユーザーが違う
IMAユーザー
管理者権限を持ったIAMユーザー
パワーユーザー
AWS Organaizationsの設定
ハンズオンする為には別アカウントを事前に用意しておく必要がある
https://gyazo.com/bc93378798e65dea1af58b04e6798fea
SCPが組織全体に適用させるポリシーで、さらにそこから個人の権限は付与したかったらIAMで適用させる。
code:md
1組織を作成する
2管理者ルートにマスターアカウントを設定する
3既存のAWSアカウントをメンバーアカウントとし組織内に追加(別のAWSアカウントが必要)
4組織単位(OU)を作成する
5OUにSCPを付与する
勉強してわかった事
IAMの基本的な概要
ルートアカウントとIAMユーザーの違い
ポリシーの適用方法
AWS Organaizationsについて