JAWS DAYS 2021 Hands-on Well-ArchitectedなIAMポリシーに挑戦する〜最小権限の原則を実装ってどゆこと？〜

JAWS DAYS 2021 Hands-on
Well-ArchitectedなIAMポリシーに挑戦する
Presented by JAWS-UG 初心者支部
～最小権限の原則を実装ってどゆこと？～
担当：おーたけ（JAWS-UG 初心者支部卒業生）
https://jaws-ug.doorkeeper.jp/events/118447

Well-ArchitectedなIAMポリシーに挑戦する～最小権限の原則を実装ってどゆこと？～
自己紹介
名前：おーたけ
職歴：とある電機メーカー
業務歴：社製ft ServerとかHAクラスタリングSWとか開発
⇒ なんやかんやあってAWSJとのアライアンス業務
JAWS-UG歴：初心者支部の勉強会に３回くらい参加
⇒ ご縁があって（？） Security-JAWS のコアメンバ
好きなAWSサービス：Amazon S3
詳しくは個人サポーターページにて
⇒ https://jawsdays2021.jaws-ug.jp/individual-supporter/
SORACOM UG Tokyo
https://www.facebook.com/soracomug/
Security-JAWS
https://s-jaws.doorkeeper.jp/
コミュニティ放送部
https://community-bc.connpass.com/
個人活動

ハンズオンの流れ
① 仕込み
↓ ・ CloudFormationでEC2インスタンスをデプロイする
↓
② 学習
↓ ・『最小権限の原則』を理解する
↓
③ 実習その１
↓ ・AWS CLI を活用する
↓
④ 実習その２
↓ ・AWS CloudTrail を活用する
↓
⑤ まとめ
結果が反映されるまで
１５～２０分くらいかかる
※おーたけ調べ

それでは『① 仕込み』から。

① 仕込み
CloudFormationでEC2インスタンスをデプロイ
０） AWS Management Console にログイン
【確認ポイント】
・Administrator権限のIAMユーザー
・リージョンは『東京』を選択

① 仕込み
０） Amazon EC2 のキーペアを確認
・任意のキーペアがあること
⇒ 無い場合はキーペアを作ろう
右上のボタン →
今回は名前を『jd2021-wa-iam-policy』で作成
※名前は任意でOK

① 仕込み
１）ユーザーガイドのテンプレートを拝借
https://docs.aws.amazon.com/ja_jp/AWSCloudFormation/latest/UserGuide
/sample-templates-services-ap-northeast-1.html#w2aac35c38c13c13
Launch Stack
別タブで開きましょう

① 仕込み
３）スタックの作成

① 仕込み
・EC2のキーペアを指定

① 仕込み

突然ですがハンズオン成功祈願のお時間です。
（前編）

① 仕込み
ハンズオン成功祈願（前編）～AWSCloudShell で 3連続アッパー！！～
何も考えず下記コマンドを３回連続で実行
$ aws accessanalyzer list-analyzers
このアイコンをクリック！
AWS CloudShellを起動
（初回実行は起動完了まで少々待つ）
別に他のコマンドでも
ＯＫなんですけどね。

スタック作成に戻ろう。
※成功祈願（前編）は完了

① 仕込み
スタックの作成が完了するまでしばし待つ

突然ですがハンズオン成功祈願のお時間です。
（後編）

① 仕込み
ハンズオン成功祈願（後編）～AWSCloudShell で 3連続アッパー！！～
何も考えず下記コマンドを３回連続で実行
このアイコンをクリック！
AWS CloudShellを起動
（初回実行は起動完了まで少々待つ）
別に他のコマンドでも
ＯＫなんですけどね。
再掲

EC2インスタンスを停止しよう。
※成功祈願（後編）は完了

① 仕込み
４）デプロイしたEC2インスタンスを停止
EC2インスタンスを停止
（手順は割愛）

以上で『① 仕込み』は完了

② 学習
『最小権限の原則』を理解する
https://aws.amazon.com/jp/architecture/well-architected/

② 学習
https://wa.aws.amazon.com/index.ja.html
クリックすると、、、

② 学習
ベストプラクティス
最小権限のアクセスを付与する:
特定の条件下で特定の AWS リソースに対する特定のアクションを行えるよ
うにして、ID に必要なアクセスのみを付与します。グループと ID 属性を利用
して、個々のユーザーのアクセス許可を定義するのではなく、規模に応じて
アクセス許可を動的に設定します。たとえば、開発者のグループに、扱うプ
ロジェクトのリソースのみを管理することを許可できます。これにより、開発
者がグループから削除されると、アクセスポリシーに変更を加えることなく、
そのグループがどこでアクセスコントロールに使用されたかを問わず、開発
者のアクセスが取り消されます。

② 学習
最小権限のアクセスを付与する:
特定の条件下で特定の AWS リソースに対する特定のアクションを行えるようにして、ID に必要なアクセスのみを付与します。グループ
と ID 属性を利用して、個々のユーザーのアクセス許可を定義するのではなく、規模に応じてアクセス許可を動的に設定します。たとえ
ば、開発者のグループに、扱うプロジェクトのリソースのみを管理することを許可できます。これにより、開発者がグループから削除さ
れると、アクセスポリシーに変更を加えることなく、そのグループがどこでアクセスコントロールに使用されたかを問わず、開発者のアク
セスが取り消されます。
改善計画
・最小権限ポリシーを実装する: IAM グループおよびロールに最小権限のアクセスポリシーを割り当てて、定義したユーザーのロール
または機能を反映します。
・必要でないアクセス許可を削除する: 不要なアクセス許可を削除して、最小権限を実装します。
・アクセス許可の境界を考慮する: アクセス許可の境界は、アイデンティティベースのポリシーが IAM エンティティに付与できるアクセス
許可の上限を設定する管理ポリシーを使用するための高度な機能です。エンティティのアクセス許可の境界では、アイデンティティベー
スのポリシーとそのアクセス許可の境界の両方で許可されているアクションのみを実行できます。
・アクセス許可のリソースタグを検討する: タグを使用して、タグ付けをサポートする AWS リソースへのアクセスを制御できます。また、
IAM ユーザーとロールにタグ付けして、ユーザーがアクセスできる内容を制御することもできます。
ベストプラクティスの具体的な解釈（考え方）
ベストプラクティスを実現するための具体的な対応策

② 学習
『最小権限の原則』を実装する
下記の３点を定義する必要あり
１）アクセス権限が必要となる条件 ⇒ 役割（ロール）
２）実行する具体的なアクション ⇒ API
３）操作対象のAWSリソース ⇒ ARN（AWS Resource Name）
あの
権限
その
権限
この
権限
『この人に与える権限は何？』
特定ユーザーに様々な権限が集まる
ま
ぜ
る
な
危
険
『この人が担う役割は何？』 ⇒ 『その役割に必要な権限は何？』
あの
権限
その
権限
この
権限
『役割』
状況で切り替え
あの
役割
その
役割
この
役割
ロールごとに必要な権限を割り当てる
まずはココの定義から
ば
ら
し
て
安
心

考え方は理解できましたか？
（で、具体的にどうやるの？）

『③ 実習その１』
最小権限の実装にトライ！
※習うより慣れろ！

③ 実習その１
まずは役割（ロール）を定義
役割：EC2インスタンスの運用
１） AWS Management Console にて、EC2やVPCなどサービスの状態や設定値を確認（目視）
API：閲覧に関係するもの全般
ARN：特に制限なし

③ 実習その１
AWS IAM にてロールを作成

③ 実習その１
AWS管理ポリシー
『ReadOnlyAccess』

③ 実習その１
特になし
今回は『EC2-Management』
心を込めてポチッ。

③ 実習その１
スイッチロールしてみよう
クリック！

③ 実習その１
スイッチロールしてみよう
ロール名が表示
権限不足にて
起動に失敗する

③ 実習その１
役割：EC2インスタンスの運用 ⇒ EC2-Management
API：閲覧に関係するもの全般 ⇒ ReadOnlyAccess
IAM Policyの中身
{
"Version": "2012-10-17",
"Statement": [
{
"Action": [
（略）
"ec2:Describe*",
"ec2:Get*",
"ec2:SearchTransitGatewayRoutes",
"ec2messages:Get*",
（略）
],
"Effect": "Allow",
"Resource": "*"
}
]
}
EC2の閲覧系全般
すべてのAWSリソース

③ 実習その１
２） EC2インスタンスの起動と停止（手動実行）
API：閲覧に関係するもの全般＋ EC2インスタンスの起動と停止
⇒ ReadOnlyAccess ＋カスタムポリシー
New
要追加

③ 実習その１
カスタムポリシーを作成する
EC2インスタンスの起動と停止に
必要なアクションのみを指定する
最小権限の実装を阻む壁
（ぶっちゃけ面倒）

【朗報】
AWS CloudShell ＋ AWS CLI
↑
この組み合わせが超便利

③ 実習その１
AWS CLI を活用する
画面操作の洗い出し
・EC2インスタンスの起動
・EC2インスタンスの停止
↓
AWS CLI で再現
・aws ec2 start-instances
・aws ec2 stop-instances
↓
IAMポリシーに反映
・EC2 : StartInstances
・EC2 : StopInstances
命名規則は比較的シンプル
（眺めて傾向をつかもう）
https://awscli.amazonaws.com/v2/documentation/api/latest/index.html
インスタンスの起動と停止
・start-instances
・stop-instances 似てるので類推可能

③ 実習その１
AWS CLI を活用する
$ aws start-instances --instance-ids <インスタンスID>
$ echo $?
$ aws stop-instances --instance-ids <インスタンスID>
$ echo $?
EC2インスタンスの起動
EC2インスタンスの停止
スイッチロールする前の状態に戻る
まずはAdministrator権限のIAMユーザーに戻る
⇒ AWS CloudShellから AWS CLI を実行してみよう

③ 実習その１
カスタムポリシーを作成する（再挑戦）
２つだけ許可

③ 実習その１
カスタムポリシーを作成する（再挑戦）
対象のAWSリソースを
絞るときはARNを指定
特になし
今回は『EC2-Management-Policy』

③ 実習その１
カスタムポリシーをロールにアタッチする
フィルタを使って見つけ出す

③ 実習その１
スイッチロールしてみよう（再挑戦）
ロール名が表示
EC2インスタンスの
起動に成功する

都度AWS CLIで再現するの面倒じゃね？
（CloudFormationが絡むと心が折れそう）

『④ 実習その２』
もっと楽なやり方がいい！
※必要は発明の母

④ 実習その２
AWS CloudTrail を活用する
画面操作＝APIの実行
（画面の操作履歴＝APIの実行履歴）
↓
『どんなAPIを実行されたのか？』は
イベント履歴から判明するのでは！？

④ 実習その２
■ AWS CLI を活用
画面操作の洗い出し
↓
AWS CLI で再現
↓
■ AWS CloudTrail を活用
画面操作の洗い出し＆実行
↓
AWS CloudTrail から発掘
↓

④ 実習その２
お題：CloudFormationでEC2インスタンスをデプロイするのに必要な権限は何？
Launch Stack
スタック作成時に使用されたAPIの実行履歴は
AWS CloudTrail のイベント履歴に記録されている
⇒ でも、どうやって発掘するの！？

【再び朗報】
ハンズオン成功祈願しましたよね？
↓
実はあれここ掘れワンワン的イベントです。
※便宜上『マーカーイベント』と呼びます

④ 実習その２
何も考えず３回連続で実行したコマンド
イベント名＝ListAnalyzers
マーカーイベント
発掘したいイベント（API）はこの隙間に眠っている！

④ 実習その２

④ 実習その２
マーカーイベント
ユーザー名とイベントソースを眺めて
関連しそうなイベント（API）を発掘する

④ 実習その２
イベントソースより AWS CloudShell のものと判断
→ スタック作成とは無関係なので無視でOKなハズ（仮説）
イベントソースよりEC2のものと判断
→ IAMポリシーのビジュアルエディタで発見できず
→ 一旦無視していいんじゃね？（仮説）
仮説が正しいかどうかは
実際に試して確認すること！

④ 実習その２
２） EC2インスタンスの起動と停止（手動実行）
３） CloudFormation でEC2インスタンスのデプロイ
API：閲覧に関係するもの全般＋ EC2インスタンスの起動と停止＋スタック作成※
⇒ ReadOnlyAccess ＋カスタムポリシー＋カスタムポリシー
New
※サンプルのテンプレート『EC2SecurityGroupSample』を利用
さらに追加

あとは君の目で確かめてくれ！
（俺たちの戦いはこれからだ！）
作成したものはちゃんと削除すること！

IAMポリシー解答編～たぶんこんな感じ～
イベントソースイベント名
ec2.amazonaws.com
AuthorizeSecurityGroupIngress
CreateSecurityGroup
CreateTags
RunInstances
cloudformation.amazonaws.com
DescribeStackEvents
DescribeStacks
ListStacks
CreateStack
EC2-Management-Policy_CreateSecurityGroupSample
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"ec2:AuthorizeSecurityGroupIngress",
"cloudformation:ListStacks",
"cloudformation:DescribeStackEvents",
"cloudformation:CreateStack",
"ec2:CreateSecurityGroup",
"ec2:CreateTags",
"ec2:RunInstances",
"cloudformation:DescribeStacks"
],
"Resource": "*"
}
]
} ※AWS IAMのビジュアルエディタで作成した結果
IAMロール（EC2-Management）にアタッチ

IAMポリシー解答編～たぶんこんな感じ～
同じCloudFormationテンプレートを使ってスタックを作成してみる
スイッチロールは忘れずに！
【注意】同じスタック名は使えないので別な名前を指定
作成できるかな？

ハンズオンの後片付け
作成したものは削除しよう
・CloudFormationのスタックを削除
→ 作成したEC2インスタンスやSecurityGroupが削除されます
・IAMロールやIAMポリシーを削除

おまけ～TIPSのような何か～
AWS管理ポリシー ReadOnlyAccess は安全？
IAM Policyの中身
{
"Version": "2012-10-17",
"Statement": [
{
"Action": [
（略）
"ec2:Describe*",
"ec2:Get*",
"ec2:SearchTransitGatewayRoutes",
"ec2messages:Get*",
（略）
],
"Effect": "Allow",
"Resource": "*"
}
]
}
閲覧系全般
すべてのAWSリソース
必要が無いデータにもアクセス可能！
⇒ 情報漏洩のリスクと考えることができる
AWS Well-Architected フレームワーク
SEC 8：保管時のデータをどのように保護していますか?
人をデータから遠ざけるメカニズムを使用する:
通常の運用状況で、すべてのユーザーが機密データおよびシス
テムに直接アクセスできないようにします。たとえば、クエリを実
行するデータストアに直接アクセスする代わりにダッシュボードを
提供します。CI/CD パイプラインを使用しない場合は、通常無効
になっている特権アクセスメカニズムを適切に提供するために必
要な制御とプロセスを決定します。

厳密には最小権限のIAMポリシーとは『最も絞り込んだ権限』
例）許可：特定のEC2インスタンスの起動/停止のみ
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"ec2:StartInstances",
"ec2:StopInstances"
],
"Resource": "*"
}
]
}
【改善ポイント】 AWSリソースはARNで明示すべし
ピンポイントな操作は
AWS CLI が捗るやつ！
【注意】
CloudWatch での監視やパフォーマンス分析など
AWS ManagementConsole を利用した方が捗る
ケースもあるので、使い方はよく吟味しよう。
ワイルドカードは要注意！

AWS CloudTrail はとにかく面倒実は奥が深い
・イベント履歴に記録されないAPIがある
・ユーザーガイドなどに一切の説明のないAPIがある
記録され方はAPIコールの状況により様々
（次回作のネタかな？）

過去資料ですが、関連しそうなので。
JAWS DAYS 2017
【Deep Diveセッション】IAM 権限をこえて～第二部 policyたち～
JAWS DAYS 2019
【AWSセキュリティ入門】徒然なるままに責任共有モデルの下から上までそこはかとなく解説
JAWS DAYS 2020
要件定義完了までに一度はやっておきたいAWS Well-Architected Frameworkを使ったレビューのコツ
～やってみてわかった十二の気付き～
JAWS-UG 朝会#13
Permission Boundary をやっと理解できたので誰か聞いてくれ(仮)
資料
資料
資料動画
資料
情報が古かったり、ミスがそのままの場合もあるのでご注意を！

JAWS DAYS 2021 Hands-on Well-ArchitectedなIAMポリシーに挑戦する〜最小権限の原則を実装ってどゆこと？〜

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie JAWS DAYS 2021 Hands-on Well-ArchitectedなIAMポリシーに挑戦する〜最小権限の原則を実装ってどゆこと？〜

Ähnlich wie JAWS DAYS 2021 Hands-on Well-ArchitectedなIAMポリシーに挑戦する〜最小権限の原則を実装ってどゆこと？〜 (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (9)