IAMを理解する第１回(機能編)
2020.01.30
こんにちは、BTCクラウドCoEの城前です。
クラウドCoEでは主にクラウド移行やAWS上のインフラ構築を担当しています。
今回のブログのテーマは「IAM」としました。
なぜIAMなのか
AWSを扱う上でセキュリティは最重要事項の1つであり、AWSのセキュリティはIAMの適切な設計と運用に掛かっていると言っても過言ではありません
記憶に新しい2019年8月に、米国の銀行であるCapital Oneから1億件以上の個人情報が漏洩しました。
直接的な原因としては、EC2上に構築したWAF(Web Application Firewall)の設定ミスを利用して侵入されたと言われています。
WAFの脆弱性を利用しIAMロールの認証情報を取得し、それを元に個人情報を取得したという形です。
一次的な原因としてはWAFの設定ミスですが、被害が拡大することになった真の問題はIAMロールに不用意に大きな権限を付与していたことです。
さらにこの事件で衝撃的だったのが、Capital Oneが起こしてしまったということです。
Capital OneはAWSのイベントなどでも多数講演しており、AWSを利用する上でのセキュリティに対するナレッジもトップクラスの会社の一つです。
このようにIAMの設計は非常に重要で一歩間違うと重大な事件に発展します。
そういった事態を防ぐために正しくIAMを理解しましょう。
IAMとは
IAMとは、AWS利用に関する認証と認可を制御するサービスです。
(認証と認可については後述します)
AWSの利用者が増える一方で、AWSを不正利用されることでの金銭的な被害も発生しています。その原因の多くが、IAMの運用を適切にしていかなったためです。
IAMを乗っ取られると、どれほどネットワークやサーバーセキュリティを固めていても、簡単に無効化されます。そういった意味で、AWSを利用する上でもセキュリティの根幹をなすサービスの一つといえるでしょう。
認証と認可とは
認証は本人性の確認（Authentication）であり、認可はリソースに対する利用権限の付与（Authorization）です。
ファイルサーバの利用を例に考えると、ユーザー名・パスワードの組み合わせで誰が利用しているかを判別するのが認証で、認証したユーザーに対してどのフォルダを参照や書込を許可させるかが認可です。
多くのシステムでは、認証と同時に認可を行いますが、本質的には別々の機能です。
IAMの機能
IAMを理解するうえで重要な次の５つの機能についてそれぞれの役割を確認していきましょう。
１．IAMユーザ
認証の機能を提供するのが、IAMユーザです。
AWSのアカウントには「AWSアカウント」と「IAMユーザ」と呼ばれる２種類があります。
AWSアカウントはルートユーザとも呼ばれ、AWSの全サービスに対して操作できる権限を持っており非常に強力です。
そのため、システム構築や運用する場合はAWSアカウントの利用は極力避け、IAMユーザを利用することが推奨されています。
アクセスの種類
IAMユーザでは次のコンソール画面の通り、「プログラムによるアクセス」と「AWSマネジメントコンソールへのアクセス」の２種類のアクセス方法があります。
どちらも有効にすることは可能なのですが、「プログラムによるアクセス」を有効にした際に作成されるアクセスキーは正しく管理をしないと重大な事故に繋がります。
アクセスキーは原則禁止に
昨今のAWSアカウントの不正利用の原因を整理するとアクセスキー・シークレットアクセスキーに起因するものが大半を占めています。
アクセスキー・シークレットアクセスキーの流出防止対策や流出した際の被害を最小限にする方法もありますが、後述するIAMロールを利用する等してそもそも作成しないに越したことはないです。
そのためアクセスキーの作成は原則行わず、必要になった場合に最小の権限で作成する事が推奨されています。
多要素認証(MFA)を設定する
IAMユーザでは多要素認証(MFA)をオプションで設定することができます。
セキュリティを強固にするため設定を有効にすることが強く推奨されています。
利用者ごとに作成する
共用のIAMユーザを作成すると、実際に誰が使っていたかログから追跡不能になるため、必ず利用者ごとに作成する事が推奨されています。
プログラムやツールから利用するためのIAMユーザを作成する場合も同様です。
認可の機能もある
さらにIAMユーザでは認証機能だけでなく、AWSのリソースへのアクセス権限を直接付与することも可能です。
つまり認可の機能も併せ持っているということです。
ただし、IAMユーザに直接権限を付与すると権限の付与漏れや過剰付与など、ミスが発生しやすくなるといった理由から、後述するIAMグループに権限を付与する方法がお勧めです。
２．IAMグループ
IAMグループでは、IAMグループに必要な権限を付与して、そのIAMグループに各IAMユーザを所属させることで、グループに所属する全てのユーザに同一の権限をまとめて付与することができます。
例えば管理者グループ、開発者グループ、運用グループといったIAMグループを作成し、権限に応じてIAMユーザを所属させるといった感じです。また、IAMユーザを複数のIAMグループに所属させることも可能です。
３．IAMポリシー
IAMポリシーは、AWSリソースやサービスに対する権限をまとめたもので認可の機能を提供します。
ポリシーはJSON形式で作成することも可能ですが、AWSが提供するビジュアルエディタにより選択式で作成することも可能です。
Action(どのサービスの)、Resource(どの機能を)、Effect(許可 or 拒否)という３つの大きなルールに基づいて、AWSの各サービスを利用する上での様々な権限を設定します。
IAMポリシーには、AWSが最初から用意しているAWS管理ポリシーと呼ばれるものとユーザが独自に作成するカスタマー管理ポリシーと２種類があります。
IAMに関する権限付与
IAMの権限設計時に気を付けるポイントとしてはIAMに関する権限の付与です。
IAM権限は自他IAMユーザに対して様々なAWSリソースの権限を付与出来てしまうため、実質Administrator権限と同義になります。
事実多くの不正利用ツールやボットでも最初に操作用のIAMを作成することから始めるそうです。
そのため、AWSのアカウント管理者以外は原則IAM権限を付与しないようにするべきです。
しかし単純にすべてのIAM権限を外すとユーザ自身のパスワード変更やMFAの設定が行えなくなってしまいます。
そこで必要な権限のみを付与していきます。
例えばユーザ自身のパスワード変更・MFA設定・アクセスキーの設定を許可するポリシーは次のようになります。
{
"Version": "2012-10-17",
"Statement": [
{
"Resource": [
"arn:aws:iam::XXXXXXXXXXXX:user/${aws:username}",
"arn:aws:iam::XXXXXXXXXXXX:mfa/${aws:username}"
],
"Action": [
"iam:ChangePassword",
"iam:CreateAccessKey",
"iam:CreateVirtualMFADevice",
"iam:DeactivateMFADevice",
"iam:DeleteAccessKey",
"iam:DeleteVirtualMFADevice",
"iam:EnableMFADevice",
"iam:GetAccountPasswordPolicy",
"iam:UpdateAccessKey",
"iam:UpdateSigningCertificate",
"iam:UploadSigningCertificate",
"iam:UpdateLoginProfile",
"iam:ResyncMFADevice"
],
"Effect": "Allow"
},
{
"Resource": "*",
"Action": [
"iam:Get*",
"iam:List*"
],
"Effect": "Allow"
}
]
}
リソース制限のXXXXXXXXXXXXの部分はAWSアカウントIDとなりますので自身のものに変更してください。
${aws:username}の部分はIAMポリシーエレメンタルと呼ばれる変数で、ログインしているIAMユーザ名、つまり自分自身に置き換えられます。
重要なポイントとしてはリソースで自分自身のみという制限を追加することです。
そうしないと人のパスワードを自由に変更し自分でログインができるというセキュリティの穴を作ることになってしまいます。
権限の付与方法
IAMエンティティ(グループ、ユーザ、ロール)への権限の付与方法は「管理ポリシー」と「インラインポリシー」の２種類があります。
それぞれ下記の特徴があります。
管理ポリシー
１つのポリシーを複数のIAMエンティティ(グループ、ユーザ、ロール)で共有することが可能で管理が容易
インラインポリシー
１つのIAMエンティティ(グループ、ユーザ、ロール)に直接埋め込んで利用するポリシー。そのIAMエンティティでしか利用できないため再利用は行えない。
インラインポリシーは、ポリシーとそれが適用されているIAMエンティティ(グループ、ユーザ、ロール)との厳密な１対１の関係を維持する必要がある場合に便利ですが、管理ポリシーが出る前の古い機能です。そのため基本的には利便性の高い管理ポリシーを利用する事が推奨されています。
４．IAMロール
IAMロールはその名称が示す通り、AWSサービスやIAMユーザに対して役割(ロール)を与える仕組みです。
主な使い方として次のようなケースがあります。
サービスロール
EC2やLambda等のAWSリソースからから異なるAWSのリソース(S3,DynamoDB等)にアクセスするケース。
EC2やLambdaにあらかじめ定義していたIAMロールをアタッチすることでアクセスキーとシークレットアクセスキーを設定することなくIAMロールの内容に応じて別のAWSリソースにアクセスすることが可能になります。
クロスアカウントアクセス用のロール
異なるAWSアカウント間でAWSサービスにアクセスしたいケース。
例えば開発環境と本番環境でAWSアカウントが異なっていて、開発環境から本番環境にあるS3バケットにあるファイルにアクセスしたい場合に本番環境側のAWSアカウントにクロスアカウント用のIAMロールを作成しておくことでこれを経由し本番環境のS3バケットへアクセス可能になります。
外部ユーザ用のロール
Active Directory等のAWS外のユーザIDを利用してAWS マネジメントコンソールにログインしAWSリソースを操作したいケース。
AWSアカウントに外部ユーザ用のIAMロールをあらかじめ定義し、IDフェデレーションという仕組みを利用することでIAMユーザを利用せずActive Directory等にあるユーザ情報を利用して、AWS マネージメントコンソールにログインしAWSリソースへのアクセスが可能になります。
５．パーミッション・バウンダリー
パーミッション・バウンダリーは2018年7月に追加された機能でIAMユーザまたはIAMロールが持つことができる最大のアクセス権限を制御するための機能です。
IAMユーザまたはIAMロールに付与した権限とパーミッション・バウンダリーで許可した権限と重なりあう部分のみ有効な権限として動作します。
逆に言うとパーミッション・バウンダリーを付与した場合は、パーミッション・バウンダリーで設定していない権限については、IAMユーザやIAMロールでどのように権限を付与しても一切利用できなくなります。
おわりに
このあとIAMポリシーの設計パターンやIAMの運用についてご紹介する予定でしたが、IAMの概要と機能について書いたところでかなりの量になってしまいました。
そのため今回はここまでにしたいと思います。続きは第２回で投稿させていただきます。
