この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
こんにちは、臼田です。
PCI DSSでは考慮することがいっぱいありますが、要件7、8あたりで認証認可について考える必要があります。今回もとあるQSAとのPCI DSS対応のための勉強会をしましたので情報共有します。
AWSでは基本的にはEC2やRDSなどのコントロールプレーンに対する制御はIAM、OSレイヤ以上のデータプレーンへのアクセスについてはネットワーク経由でsshを使用するなどOSユーザ等で認証認可を行います。しかし、それとは別にIAMを利用したデータアクセスを行う手法も最近増えてきました。
IAMでのデータアクセスはID管理を寄せたりアクセス経路を通常より絞れたりと便利な半面、IAMの権限管理や監査等のコンプライアンス面でいろいろ考える必要があるので、PCI DSSの要件に対してどのように考えて付き合っていくかをまとめるため勉強会のテーマとしました。
なお、各AWSリソースへの認証認可としてのIAMについては中山のほうで担当しました。下記をご参照ください。
資料
解説と考察
スコープ
従来のデータアクセス経路以外のIAMを利用したアクセスを行う下記を想定しています。
- EC2へのアクセス
- SSM Run Command
- SSM Session Manager
- SSM Session Manager SSH
- EC2 Instance Connect
- RDSへのアクセス
もちろんS3やDynamoDBなどもデータアクセスにIAMを利用しますが、これらは最初からIAM前提なので対象外です。これまで考えなくてよかった新しいデータアクセスの経路を対象としています。
EC2アクセス機能の一覧
下記ブログがめちゃくちゃよくまとまっています。
特に考えなければいけないこと
RDSのIAMによるアクセスはそんなに制御が難しくないです。EC2 Instance Connectも従来どおりのネットワーク経路が必要なためまだいいです。
しかし、SSMを利用したEC2アクセスが可能なRun CommandやSession Managerはネットワークからの経路がほぼ不要で利用できてしまうため各方面の対策が必要です。(EC2からの上り通信でSSMのAPIエンドポイントに通信できる必要がありますが、これは満たせる場合がほとんどです)
まず原則通りにIAMの権限を最小にすることです。SSMを利用する場合でも特にRun CommandやSession Managerは必要なユーザだけに割り当てます。また、対象のリソースを制限することも必要です。ただし、ポリシーを適切に管理し続けることは負担になりますし、一定のノウハウが必要です。
SSM自体の権限をすべて割り当てないという選択肢もありますが、SSMは機能が豊富でPCI DSSに対応するために有効な機能もあるため単純に利用しないという選択肢は取りづらいです。例えば、インベントリの収集でパッケージ情報を管理したり、パッチマネージャを使ってパッチ運用をすることもできます。
そして、SSMのAPI権限を適切に絞っていくことも難しいですが、最大の問題はSSMエージェントを使わせないこと(OS側での対策)が難しくなることです。万が一IAMの強い権限を持ったユーザが使えば(秘密鍵を使ったデータアクセスと比べて)簡単にアクセスできる可能性が高いです。抑止をする手法はありますが、なかなかきれいに付き合うことはできません。
どう付き合っていくか
やはりまずはSSMを利用しない方向に舵を切る可能性が高いという意見をいただきました。利便性も強い一方で便利すぎて制御が簡単ではないSSMを採用することはリスクになります。
また、SSMは利用しつつこのようなデータアクセスを許容するAPIを利用しない場合には、新しく出てくるサービスのことも考えて明示的に利用するサービスだけAllowを設定するという話も出てきました。例えばSSMのサービスについて"ssm:SendCommand"のように指定するとRun Commandを対象としますが、これをdenyしておくだけで残りを"ssm: *"で許可していたら、新しく出てきた"ssm:StartSession"を利用できる状態となりました。SSMでは様々な機能を内包しているため、使わないものをdenyするのではなく使うもののみをAllowとする方向が適切です。
まとめ
IAMによるデータアクセスについて解説と考察しました。便利になる一方で制御が大変な機能なので、すぐに採用するという選択肢を取ることは難しいですが、一方でsshの経路をネットワークから完全になくすことができるのでよく権限や運用を考慮して採用することもできると思います。
是非検討してみてください。
1
