この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
はじめに
こんにちは。三井田です。先日、昨年の12月16日、クラスメソッドAWSチームにて「re:Growth Tokyo 2014」を開催しました。私はIAMのReadOnly権限について、運用を委託される立場からチューニングをお話をしました。
AWS謹製ポリシーテンプレート
IAMについておさらい
AWSで操作できる各アクションは、原則的に全てAPIに定義されています。そして、AWS Identity and Access Management(IAM) サービスにより、各APIアクションを許可・拒否することで、AWSリソースに対して何を実行できるかが決まって来るのです。
IAMについての様々な記事は、弊社ブログにて多数紹介されていますので、参考にしてください。
参照:『特集カテゴリーIAM』
AWS謹製のポリシーテンプレート
ポリシーテンプレートは、IAMのマネジメントコンソールから、任意のUser・Group・Roleを選ぶと、「Attach User Policy」といったボタンで開ける画面にて選択可能です。
AWSサービス全般に関する「Administrator Access」「Power User Access」「Read Only Access」を始めに、CloudFromation、CloudFront、CloudSearch、CloudTrail・・・ など、各サービス向けの「Full Access」「Read Only」などが用意されています。
MSPという立場でAWS謹製のポリシーテンプレートで課題と感じるところ
弊社では、AWSのリセラー・コンサルティングパートナーとして、多数のお客様からのお問合せの一次窓口を提供しています。まず、弊社にてお客様のAWS環境で障害や設定不備が無いかを確認して、弊社で回答できるものはそのまま回答、より詳細をAWSに確認してもらう必要があるものは、AWSサポートへエスカレーションして対応しています。
ここで、課題となってくるのが、「お客様のAWS環境で障害や設定不備が無いかを確認」するために、どのような権限が適切かという点です。
原則として弊社ではお客様の機密情報など実際のデータには触れない運用を目指してます。Read Only権限を用いるのですがAWS謹製のRead Only権限では課題と感じるところがありました。
Read Only権限はお客様の実データをも読込み可能な権限をもつ
ポリシーテンプレートのRead Only権限は、API経由で実データを取得できるサービスについては、データを取得できる権限も付与されています。S3とDynamoDBを例に挙げて説明します。
- S3
- GetObject: オブジェクト(実データ)をダウンロードできる権限です
- DynamoDB
- GetItem, BatchGetItem, Query, Scan: いずれも、Itemを取得でき、Itemには、Key-Valueペア(実データ)が含まれています
Read Only権限に含まれていない有益な権限もある
一方、通常のRead Only権限のテンプレートには含まれていない、トラブルシュートに有益な権限もあります。一例として、EC2のコンソールログを参照する権限を紹介します。
- EC2
- GetConsoleOutput: OS起動時などのコンソールログを表示する権限ですね。GUIのマネジメントコンソールですと、EC2 Instance -> Actions -> Instance Settings -> Get System Logで表示されるものです
チューニング
先に述べた課題と感じる点を、MSPという立場でどのようにチューニングしたかをいくつかの例を挙げて紹介しました。
実データ読み込み権限の剥奪
S3やDynamoDBのRead Only権限から、実際のデータ内容を参照できる権限を剥奪する例を紹介します。
S3編
S3のRead Only権限のポリシーテンプレートは以下のようになっています。今回は変更点を単純に示すため、元テンプレートとして「Amazon S3 Read Only Access」を用いて説明します。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:Get*",
"s3:List*"
],
"Resource": "*"
}
]
}
7行目の「Get*」というワイルドカード指定で、「GetObject」も許可されてしまっているので、ここを編集していきます。
まず、他にどのような「Get〜」APIがあるのでしょうか。Amazon S3 API Referenceを確認してみます。
ちょっと読み解くのに手間がかかりましたので、手っ取り早く、IAM Policy Simulatorを使って覗いてみます。
AWSアカウントにログインして、IAM Policy Simulator (https://policysim.aws.amazon.com/home/index.jsp?#)にアクセスすると表示されます。
「Select Service」で「Amazon S3」を選び、「Select Action」をクリックすると以下のようにActionの一覧が表示されます。Get*は、枠線で囲んだあたりに表示されています。
Get系には、「GetBucket〜」「GetLifecycleConfiguration」「GetObject」「GetObject〜」があることが確認できます。GetObject系だけワイルドカード指定を外し、GetObjectを指定しないように編集しました。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:GetBucket*",
"s3:GetLifecycleConfiguration",
"s3:GetObjectAcl",
"s3:GetObjectTorrent",
"s3:GetObjectVersion",
"s3:GetObjectVersionAcl",
"s3:GetObjectVersionTorrent"
"s3:List*"
],
"Resource": "*"
}
]
}
DynamoDB編
続いて、DynamoDBの例です。元テンプレートとして「Amazon DynamoDB Read Only Access」を用いて説明します。DynamoDBの利用に関係の深い、CloudWatchやData Pipeline、SNSに関する権限も含まれてますが、説明からは省略します。
{
"Version": "2012-10-17",
"Statement": [
{
"Action": [
<<cloudwatch:〜 を省略>>
<<datapipeline:〜 を省略>>
"dynamodb:BatchGetItem",
"dynamodb:DescribeTable",
"dynamodb:GetItem",
"dynamodb:ListTables",
"dynamodb:Query",
"dynamodb:Scan",
<<sns:〜 を省略>>
],
"Effect": "Allow",
"Resource": "*"
}
]
}
GetItem, BatchGetItem, Query, Scanが実データを参照できるAPIでしたので、これらを取り除けば良いことになります。
以下のように、シンプルに「DescribeTable」「ListTables」を残すのみとなりました。
{
"Version": "2012-10-17",
"Statement": [
{
"Action": [
<<cloudwatch:〜 を省略>>
<<datapipeline:〜 を省略>>
"dynamodb:DescribeTable",
"dynamodb:ListTables",
<<sns:〜 を省略>>
],
"Effect": "Allow",
"Resource": "*"
}
]
}
トラブルシュートに有益な権限の追加
EC2のコンソールログ参照権限
元テンプレートとして「Amazon EC2 Read Only Access」を用いて説明します。EC2と縁の深いELBやCloudWatch、AutoScailngのポリシーも記載されてますが、バッサリ省略します。最初は以下のようになっています。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "ec2:Describe*",
"Resource": "*"
},
<<省略>>
]
}
GetConsoleOutputを追加して以下のようにします。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "ec2:Describe*",
"Action": "ec2:GetConsoleOutput"
"Resource": "*"
},
<<省略>>
]
}
その他のサービスのRead Only権限
「Read Only Access」という総括したテンプレートには、比較的新し目のサービスのRead Only権限は含まれてないことがあります。例えば、CloudWatch LogsやRoute 53 Domainsなどが該当します。ポリシーテンプレート「CloudWatch Logs Read Only Access」や「Amazon Route53 Domains Read Only Access」の内容をAPIリファレンスで紐解いて、実データアクセス・編集が出来ないような内容であれば、それぞれ適用してしまうのが良いでしょう。
CloudWatch Logsについては、Read Onlyにデフォルトで含まれる「GetLogEvents」は現状は実データと扱って含めないようにしました。
まとめ
- まずは、MSPとしてどの範囲を請け負うかのポリシーの決定が重要
- 契約で「PowerUserで運用請け負います!」と宣言することもポリシーの1つかも知れません
- しかし、セキュリティのベストプラクティスに沿って、サービス提供者として提供に必要な権限に絞るのが望ましいでしょう
- ポリシーに沿って厳密にリファレンスを紐解くのは、実は骨が折れます
- でも、旨味もあって、AWSでどのような操作が出来るのか、詳しくなり、ナレッジになります