jaws-ug cli専門支部 #16...
TRANSCRIPT
CDPにIAM関連のデザインパターンが無いので提案してみる
JAWS-UG CLI #16 LT
2015/03/30
Nobuhiro Nakayama
me.json
{
"name“ : "Nobuhiro Nakayama",
"favorite aws services“ : [
"Storage Gateway",
"Directory Service",
"IAM"
],
"certifications“ : [
"AWS Certified Solutions Architect-Associate",
"AWS Certified SysOps Administrator-Associate",
"Microsoft Certified Solutions Expert : Server Infrastructure",
"Microsoft Certified Solutions Expert : SharePoint“
“IPA : Network Specialist”
“IPA : Information Security Specialist”
]
}
2015/3/30 2
目次
• CDP（クラウドデザインパターン）
• 「サービス・リソースを保護するパターン」のご提案
2015/3/30 3
#17でManaged Policy入門の講師をします
• 波田野さん以外が講師をするのは初・・・ ((((；ﾟДﾟ))))
• Qiitaでハンズオン資料を作成中
• そのとき、「CDPに参考になりそうなデザインパターンあるかも！」と思って調べてみた。
2015/3/30 4
2015/3/30 5
出典 http://aws.clouddesignpattern.org/images/a/ac/Cdp-overview-org.png
無かった・・・
2015/3/30 6
提案だ！
2015/3/30 7
とりあえず、提案してみる
1. Black List
2. White List
3. Resource Protection
4. Single Responsibility IAM Group
2015/3/30 8
Black List
• 概要
• 広い範囲のアクションを許可する権限と併せて、特定のアクションを禁止する権限を設定
• アクセス可否の決定ロジック
明示的なDeny ＞ 明示的なAllow ＞ デフォルトDeny
2015/3/30 9
Black List 設定例（１）
{
"Version": "2012-10-17",
"Statement": [
{
"Action": "ec2:*",
"Effect": "Allow",
"Resource": "*"
}
]
}
2015/3/30 10
明示的に広範囲のActionをAllowを設定し、
Black List 設定例（２）
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": [
"ec2:TerminateInstances"
],
"Condition": {
"StringEquals": {
"ec2:Region": "ap-northeast-1"
}
},
"Resource": [
"*"
]
}
]
}
2015/3/30 11
AllowしたActionの一部をDenyする。
White List
• 概要
• 特定のアクションを許可する権限を設定
2015/3/30 12
White List 設定例（１）
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:RebootInstances",
"ec2:StartInstances",
"ec2:StopInstances"
],
"Resource": [
"*"
]
}
]
}
2015/3/30 13
明示的に狭い範囲のActionをAllowする。
Resource Protection
• 概要
• 重要なリソースの削除や変更を禁止する権限を設定
• EC2やRDSインスタンス、EBSボリューム
• EIP（一度リリースすると、同じEIPを確保するのはほぼ不可能）
• Hosted Zone（権威サーバのホスト名が変わる）
• S3バケット、ファイル（監査ログの改ざん、請求明細の消失、など）
• ResourceやConditionを利用
• Black Listの亜種
• Blue-Green Deploymentとかやってるとこには向かないかも？
• メリット・このパターンのねらい
• 誤操作や悪意をもった操作に対してリソースを保護
2015/3/30 14
Resource Protection 設定例（１）
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": “Allow",
"Action": [
“rds:*"
],
"Resource": [
“*"
]
}
]
}
2015/3/30 15
明示的に広範囲のActionをAllowし、
Resource Protection 設定例（２）
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": [
"rds:DeleteDBInstance"
],
"Resource": [
"arn:aws:rds:ap-northeast-1:************:db:myinstance"
]
}
]
}
2015/3/30 16
特定のリソース／条件に対するActionをDenyする。
Single Responsibility IAM Group
• 概要
• 役割や機能単位でグループとポリシーを定義
• SRP(Single Responsibility Principle)のようなもの
• “A class should have only one reason to change.”
• グループにアタッチできるManaged Policyの上限は2つだが、単一の役割であれば十分なはず
• Managed Policyを利用することで、変更管理がしやすくなる（バージョン管理、ロールバック、など）
• ユーザは、担当する役割のグループに所属
• グループを分割しすぎると、グループに所属するユーザの管理が煩雑になるので注意が必要
• IAMユーザをIAMグループから削除し忘れる、など
• メリット・このパターンのねらい
• Managed Policyの新機能を生かしやすい（アタッチできる上限にひっかかりにくい）
• 複数バージョンの保持が可能
• ロールバックが簡単（Default Versionの変更）
• （うまく設計できれば）グループと役割が1:1になるで、わかりやすい。
• （たぶん）ポリシーが長くなりにくい
2015/3/30 17
Single Responsibility IAM Group
管理者（全ての権限）
監査（CloudTraliのログ
を閲覧）
監視（CloudWatchの読
み取り権限）
運用（EC2インスタンスの起動・停止・再起
動）
User01 ○
User02 ○
User03 ○
User04 ○ ○
2015/3/30 18
各役割毎にグループとポリシーを定義
まとめ
• IAMを含んだデザインパターンが欲しい！
• デザインパターンとして明文化されていると、事故が減るのでは？
• CDPって、どなたかメンテしてるんでしょうか？
• 目黒支部の発足でメンテされるようになるといいなー・・・
• CloudTrail（とCloudWatchLogs）、Assume Role、Federation認証なども絡めたパターンも検討したい
• 次回の本編で（可能な範囲で）具体的な設計パターンについて議論できたらいいなーと思っています！
2015/3/30 19
2015/3/30 20