Ch.8 セキュリティとアイデンティティ
アカウントの種類
アカウントの種類は
- AWSアカウント(ルートユーザー)
- IAMユーザー
が存在する。更にAWSアカウントを束ねたAWS Organizations(組織アカウント)も存在する。これは複数のアカウントの請求を一括決済するために行われる。
AWSアカウントは全サービスにアクセスすることが出来る。またAWSアカウントにはIPアドレス制限などの利用制限の仕組みがない。そのため多要素認証が推奨される。
IAMユーザーは操作を許可するサービスをユーザー単位で指定できる。たとえば、EC2のStart/Stopだけ許可してTerminateは許可しない、と言ったことが可能になる。
IAMポリシー
- Action(どのサービスの)
- Resource(どのような機能を)
- Effect(許可/拒否)
の3つの要素で成り立っている。
全てのサービスについて、いちいち許可する機能を設定したのでは設定機能が煩雑になってしまう(このようなポリシーの設定方法もあり、それは【インラインポリシー】と呼ばれている)。そこで【AWS管理ポリシー】という実際のメンバーの職務に応じて許可/拒否すべきと想定されるポリシーのまとまりがAWSによって用意されている。
これに更に変更を加える場合は「カスタマー管理ポリシー」を利用する。【AWS管理ポリシー】をコピーしつつ必要に応じて変更を加えればよい。
IAMユーザーとIAMグループ
AWSコンソールを操作する人だけでなく、AWS CLIから各機能を呼び出すときも、プログラムがAPIを呼び出すときもIAMユーザーが必要になる。
IAMユーザーは次の方法で認証される。
- ユーザーID&PW
- アクセスキーとシークレットアクセスキー
ポリシーを一つのグループにアタッチしておき、グル―プに各IAMユーザが所属するかたちで各ユーザーのポリシーを設定することも出来る。各IAMユーザーは2つ以上のグループに所属することも出来る。ただし、グル―プの階層化は出来ない。
IAMロール
一時的なリソースへのアクセス権を設定する場合に「IAMロール」を使用する。対象は人のみならずEC2といった、AWSリソースに対してもロールを付与することが出来る。
例えば、EC2インスタンスに対してSESを呼び出してメールを送信するといった場合、
EC2に対するロールを作成し、権限(ポリシー)を付与する。ここではSESに対するポリシーを付与する。
EC2を起動する前に1.で作成したロールを付与する。ロールを付与することが出来るのはEC2インスタンスの初回起動前だけなので注意する(後からロールの付与は出来ない)。
EC2のプログラムからSESを呼び出す（ちなみにIAMロールを利用しない場合はSESから発行されるアクセスキーとシークレットアクセスキーがプログラムの中で必要になる。IAMロールを利用して権限を付与するとこれが不要になる）。
3.に見られるように、ソースコードの中にクレデンシャルを埋め込まなくても良くなるので、セキュアな開発が可能になる。
AWS KMS
Key Management Serviceはセンシティブなデータを扱う際の通信暗号化・復号化のための鍵の管理方法である。
一応、大規模システムで利用されるCloud HSMというサービスが存在するが、VPC内に専用のハードウェアを設けて鍵を管理するなど大規模でコストも高くつくためあまり利用されない(ただしパフォーマンスはこちらの方がよい)。
KMSで管理される鍵はCustomerMasterKey(CMK)とCustomerDataKey(CDK)があり、各データをCDKで暗号化し、CDKをCMKで更に暗号化する、という方式をっている。この「暗号化に利用した鍵を別の鍵で暗号化する」方法をエンベロープ暗号化と呼ぶ。
データキーは暗号化の対象とする各種サービスごとに作成される(S3とかRDSとか)。
クライアントサイド/サーバーサイド暗号化
各種ストレージサービスにデータを格納するときにクライアント側(≒ユーザー側の処理)で暗号化を行うか、各種ストレージ側が受け取ったデータを暗号化するか2パターン考えられる。
クライアントサイドで暗号化を行う場合、AWS SDKを利用して暗号化する。しかし、実装が複雑になってしまうためサーバーサイド暗号化が利用できる場合はサーバーサイド暗号化を利用すべき。
ストレージ側に送るまでの経路でセキュリティが担保できないときのみ、クライアントサイド暗号化を検討する余地がある。S3はクライアントサイド暗号化もサーバーサイド暗号化にも対応しているが、クライアントサイド暗号化に対応していないサービスも多い。
