こちらの記事は、Anna Korkoshko氏により2020年01月に公開された『 AWS IAM: Permission Management is as Simple as Donuts. Concepts and Policies』の和訳です。
本記事は原著者から許可を得た上で記事を公開しています。
AWSでのすべてのプロジェクトの旅は、リソースの作成から始まります。確かに、サーバーレスで強力な高可用性について深く掘り下げたり、もしくは自分のロケットを今すぐにでも作りたい…などあなたがやりたいことは色々とあるでしょう。しかしまず最初に、間違いなく"Identity and Access Management Service (IAM)"にきちんと向き合う必要があります。
AWS IAMはすべてのリソース作成と密接に結びついており、エラーやセキュリティの問題を回避するために賢明にプロビジョニングする必要があります。このシリーズの記事では、基本から始め、次のパートに移っていきます。
この記事では、基本的なIAM概念とIAMのポリシーを、美味しいドーナツを例にして説明します。さあ、先にベーカリーに立ち寄って、それから楽しんでください！
IAMコンポーネントについて
まず、あなたが警官だと想像してみましょう。それであなたは警察署に来て、テーブルの上に沢山のドーナツがあることに気づきました。
あなたは食べてもよいのでしょうか？シェアされているのでしょうか？それとも、誰かがあなたのためだけにそれらを購入したのでしょうか？または、チーフのドーナツであるかもしれないので、あなたはドーナツを見たり嗅いだりさえしないほうがいいかもしれません。どうしたら知ることができるでしょうか？そう、ドーナツのためのポリシーがどこかにあるべきなのです。
ポリシーは行動規範の中にあるかもしれないし、あなたの頭の中にだけあるかもしれません。しかし、誰もが自分がドーナツを食べることが許されているかどうか知っているべきです。
では、ドーナツの観点から見たAWS IAMコンポーネントとは何でしょうか？
AWS IAMリソースは、あなたが食べることができるドーナツです。または、オフィスでやり取りできるその他の物です。
AWS IAMポリシーは、いくつかの許可文を宣言する文書です。これから、AWS IAMポリシーが何をどうやって宣言できるのか見ていきます。
AWSアイデンティティにはいくつかの種類があります。
AWS IAMユーザーはまさにあなたや、あなたの同僚や上司のような人です。
AWS IAMグループは、 権限基準で統一されたIAMユーザーの集まりです。警察署にだって、警察官、刑事、犯罪現場の捜査官などによって構成される、このようなグループがありますよね。（それか、警視、警部、警部補かもしれませんね）。1人のIAMユーザーが異なる複数のグループの一部になることができます。
ここで、AWS IAM ロールという別のアイデンティティタイプを紹介します。この時点では、もう少しあなたの想像力が必要です。
あなたは魅力的な警官の仕事とは別に、ドーナツベーカリーショップを経営しているとしましょう。
ドーナツショップには、クリーナー、シェフ、レジ係の3つの役割（ロール）があります。また、警官の役割もあります。この役割（ロール）を引き受けるには、この役割（ロール）に伴う権限と制限に従って行動する必要があります。それでは、「シェフの役割」を担ったと仮定して、シェフになりましょう。シェフだけがキッチンに行ってドーナツを作ることができますが、ドーナツを販売したり、顧客と話したりすることはできません。人々を逮捕することもできません！したがって、再び警官になるには、「シェフの役割（ロール）」を離れ、「警官の役割（ロール）」を引き受ける必要があります。うわー！これで再びバッジを獲得しました！また、ドーナツも食べられます！ただし、それでもまだ、あなたの役割をきちんと明確に知るためにドーナツポリシーを確認することをお勧めします。
つまり、役割（ロール）を引き受けることは、魔法のシェフの帽子をかぶって、しばらくの間、すべてのシェフの特権と禁止事項を備えたシェフになるようなものです。
AWS IAMポリシーの構文
それでは、最もエキサイティングな部分であるAWSポリシーに移りましょう。権限を規制するドキュメント（実際には単なるJSON）があることはすでに知っています。自分でjsonポリシーを作成するか、AWSマネジメントコンソールのビジュアルエディターを使用できます。では、詳しく見ていきましょう。
ポリシーはステートメントで構成され、1つのポリシーに1つ以上のステートメントを含めることができます。
次に、簡単なS3バケットポリシーの例を示します。
{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Principal":{"AWS":"arn:aws:iam::111122223333:root"},"Action":["s3:PutObject","s3:PutObjectAcl"],"Resource":["arn:aws:s3:::examplebucket/*"],"Condition":{"IpAddress":{"aws:SourceIp":"54.240.143.0/24"}}}]}「ARN」で始まる部分に注意してください。これは、Amazonリソース名を表し、AWSで作成するリソースの一意の識別子を意味します。
ステートメントの構成要素について説明しましょう
Effect：ポリシーを作成するときに、アクション/リソースへのアクセスを許可または制限するという2つの選択肢があります。したがって、Effect– 「許可」または「拒否」を指定する必要があります。
Principal（NotPrincipal）： アクセスが許可または拒否されたエンティティのことです。たとえば、ユーザー、ロール、AWSサービスなどです。Principalはリソースポリシーでのみ必要です（ポリシーの種類については次回の記事で説明します）
Action（NotAction）： Actionでは、許可または拒否するアクセスのタイプを宣言します。AWSサービスとこのサービスで利用可能なアクションの2つの部分で構成されています。
オフィスに「food」サービスがあるとします。そのサービスで食べ物を買ったり食べたりすることができます。そのサービスは、フード提供者を変えることもできます。
したがって、オフィスマネージャーは次のアクションが許可されるでしょう。
"Action":["food:buy","food:changeProvider"]次に、従業員は次のアクションが許可されます。
"Action":["food:eat"]次の２つの違いに注意してください。
"Effect":"Deny""Action":["food:eat"]"Effect":"Allow""NotAction":["food:eat"]最初の例では、foodサービスでの「食べる」という行為を明示的に否定しています。ただし、2番目の例では、アクション「食べる」を除く、サービス「food」からのすべてのアクションを許可しています。
Resource：アクションのターゲットであるAmazonリソースのことです。
実際には、ここでのリソースとは、あの美味しいドーナツのことです。これで、リソースとアクションを組み合わせることができます。
"Action":["food:eat"],"Resource":"pinkDonut"これは単に、foodサービスを使用してpinkDonutを食べることが許可されていることを意味します。
アクションは、特定のタイプのリソースに対してのみ有効であることに注意してください。アクション ”food: eat” を ”car” リソースで使用することはできません。といっても、それを駆動するサービスがどこかにあるかもしれませんが。
Condition： 定義されたアクセスの条件（condition）は有効です。
ポリシーに使用できるconditionはたくさんあります。conditionはポリシーの作成時に「場合だけに」のフレーズを使用する場合に必要になります。いくつかの実例です：
従業員がピンクドーナツを食べられるようにしたいのです が、彼らが「警部補」である場合だけに許可したいです。（彼らだけピンクドーナツを食べられる）
社員にピンクのドーナツを食べさせたいのですが、午後2時までの場合だけにです。（彼らの健康に気をつかっているようだ）
従業員がピンクのドーナツを食べられるようにしたいのですが、それは彼らが毎日の報告を終えた場合だけに限られます。（迅速な報告を奨励）
ワイルドカード
ポリシーの一部の要素にはワイルドカードを使用できます。いくつかの例を見てみましょう：
"Resource":"arn:aws:s3:::*"これは、ポリシーがs3のすべてのリソースに適用されることを意味します。
"Resource":"arn:aws:s3:::corporate*"このポリシーは、「corporate」で始まるすべてのバケットに適用されます。
"Action":"s3:*"このポリシーは、s3サービスからのすべてのアクションへのアクセスを提供します。
"Action":"ec2:*KeyPair*"このポリシーは、キーペア（DescribeKeyPairs、CreateKeyPair、DeleteKeyPair、ImportKeyPair）で使用可能なすべてのアクションへのアクセスを提供します。
ワイルドカードには細心の注意を払い、使用する前によく考えてください。ポリシーを具体的にすることは、セキュアな環境を構築するために従うべきベストプラクティスです。
“Action”: ec2:”と書くときに、品質保証エンジニアにインスタンスを終了する権限を本当に与えたいでしょうか？“ Resource”: “arn:aws:s3:::”と書いて、すべてのs3リソースへのアクセスを全員に許可したいでしょうか？バケットの1つに機密データが含まれているのに？現在、ec2サービスには350以上のアクションがあります。あなたはそれらすべてを知っていて、開発者にすべてのアクションへのアクセスを本当に許可したいのでしょうか？そしてさらに重要なポイントがあります。
ワイルドカードを使用すると、既存のアクション/リソースだけでなく 、将来、追加されるアクション/リソースへのアクセスも許可されます。
したがって、「ワイルドカード」は非常に便利な機能ですが、責任を持って使用してください。
少し実世界の練習
次に、シンプルで現実的なポリシーの例を実際に作成してみます。EC2インスタンスとS3バケットがある環境があるとします。私たちの仕事は、開発者向けのポリシーを構築することです。彼らは、すべてのインスタンスを見ることができて、（オフィスからのアクセスの場合だけに）特別なdevタグをもつインスタンスを停止および開始することができて、devリソースを持つS3バケットにアクセスできる必要があります。
最初に、ユーザーがec2サービスを使用して「インスタンスを説明」できるようにします。これは非常に簡単です。
{"Effect":"Allow","Action":"ec2:DescribeInstances","Resource":"*"}次に、インスタンスの開始と停止を許可する必要がありますが、ユーザーがオフィスのIPからAWSにアクセスする場合だけにです。覚えているでしょうか？「場合だけに」というフレーズは、Conditionを使用することを意味します。さらに、リソースタグの条件を使用して、devインスタンスとのみ対話できるようにします。
{"Effect":"Allow","Action":["ec2:StartInstances","ec2:StopInstances"],"Resource":"*","Condition":{"StringEquals":{"ec2:ResourceTag/env":"dev"},"IpAddress":{"aws:SourceIp":"210.75.12.75"}}}最後に、ユーザーがdevバケットのコンテンツを一覧できるようにし、その一覧からPutObjectとGetObjectを行えるようにします。そのためにs3サービスのアクションを使用します。
すべてのdevバケットの名前が「devdata」プレフィックスで始まると仮定しましょう。これは、ワイルドカードをうまく利用するのに適した場所です。
{"Effect":"Allow","Action":"s3:ListBucket","Resource":"arn:aws:s3:::devdata*"},{"Effect":"Allow","Action":["s3:PutObject","s3:GetObject"],"Resource":"arn:aws:s3:::devdata*/*"}はい、以上です。これで、すべてのポリシーの内容を確認することができます。ね、簡単でしょ？
{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Action":"ec2:DescribeInstances","Resource":"*"},{"Effect":"Allow","Action":["ec2:StartInstances","ec2:StopInstances"],"Resource":"*","Condition":{"StringEquals":{"ec2:ResourceTag/env":"dev"},"IpAddress":{"aws:SourceIp":"210.75.12.75/16"}}},{"Effect":"Allow","Action":"s3:ListBucket","Resource":"arn:aws:s3:::devdata*"},{"Effect":"Allow","Action":["s3:PutObject","s3:GetObject"],"Resource":"arn:aws:s3:::devdata*/*"}]}おわりに
ご覧のとおり、AWS IAMの基本コンポーネントは非常に単純で直感的でありながら、強力で柔軟です。多数のリソースとともに、100を超えるサービスの数百のアクションを使用できます。
きめの細かいアクセス管理は、すべてのセキュリティのベストプラクティスに従い、プロジェクトチームにとって便利な環境を実現するのに役立ちます。ポリシー作成の詳細については、IAMユーザーガイドでいつでも確認できます。
後続の記事では、さまざまなポリシータイプとそれらの相互作用について説明します。さらに、ドーナツの観点から分かりやすくポリシー評価プロセスを見ていきます。
翻訳協力
Original Author: Anna Korkoshko
Original Article: AWS IAM: Permission Management is as Simple as Donuts. Concepts and Policies
Thank you for letting us share your knowledge!
この記事は以下の方々のご協力により公開する事が出来ました。
改めて感謝致します。
選定担当: yumika tomita
翻訳担当: @_masa_u
監査担当: Aoi, takujio
公開担当: @_masa_u
私たちと一緒に記事を作りませんか？
私たちは、海外の良質な記事を複数の優秀なエンジニアの方の協力を経て、日本語に翻訳し記事を公開しています。
活動に共感していただける方、良質な記事を多くの方に広めることに興味のある方は、ぜひご連絡ください。
Mailでタイトルを「参加希望」としたうえでメッセージをいただく、もしくはTwitterでメッセージをいただければ、選考のちお手伝いして頂ける部分についてご紹介させていただく事が可能です。
※ 頂いたメッセージには必ずご返信させて頂きます。
ご意見・ご感想をお待ちしております
今回の記事は、いかがだったでしょうか？
・こうしたら良かった、もっとこうして欲しい、こうした方が良いのではないか
・こういったところが良かった
などなど、率直なご意見を募集しております。
いただいたお声は、今後の記事の質向上に役立たせていただきますので、お気軽にコメント欄にてご投稿ください。Twitterでもご意見を受け付けております。
みなさまのメッセージをお待ちしております。