(レポート) SEC302: IAM Best Practices To Live By #reinvent

渡辺です。

最近は何故か運用周りが多いので、IAM関係のセッション資料「(SEC302) IAM Best Practices To Live By」を読んでみました。

IAMベストプラクティス11

IAM関連は、とりあえずこうしておけって感じのベストプラクティスですね。 過去の資料に詳細があったので、それを踏まえて、さくっと解説します。 AWSアカウント周りの運用ポリシーを検討するにも役立つ内容です。

Users - 個別ユーザを利用する

共通ユーザを使わずに、担当者毎にユーザを作って運用しましょう。 共通ユーザでは、CloudTrailなどで誰が操作をしたかが解らなくなります。

Permissions - 最小限の権限

権限は最小限に。 なんでもAdministrator権限を与えてしまうのは簡単ですが、リスクも最大です。

Groups - グループで権限を管理する

ユーザ毎に権限を管理するのでは無く、グループを作り、そこに権限を与えます。 個々のユーザに権限を与えてしまうと、権限を変更したい場合などに、トラブルに巻き込まれること請け合いです。

Conditions - Conditionで権限をさらに絞る

Polic DocumentのCondition機能を使うことで、権限は特定のAWSリソースに制限するなどさらに絞り込むことができます。 アクセス許可は最小限にしましょう。

Auditing - AWS CloudTrailを有効にし、APIコールを記録する

AWS CloudTrailを有効にすることで、何時誰がどのAWSリソースを操作したかが記録されます。

Pawssword - 強力なパスワードポリシーを設定する

デフォルトは結構弱いので、8文字以上の英数記号混合にはしておきたいところです。

Rotate - セキュリティクレデンシャルはローテートする

アクセスキーなどは万が一のため、定期的なローテートが推奨されます。

MFA - MFAを有効にする

IDとパスワードによる認証をさらに強固にするには、MFA（Multi-Factor Authentication - 二要素認証）を有効にします。 近年はスマフォが普及し、仮想端末によるMFAが簡単になりました。

Sharing - Roleをシェアアクセスに利用する

AWSアカウント間で権限を委譲するためにRoleを利用します。 弊社のように多数のAWSアカウントを管理している場合など、特に有効です。

Roles - EC2インスタンスにはIAM Roleを利用する

EC2インスタンスにアクセスキーを与えるとローテーションなどのキー管理が煩雑です。 Roleを使うと自動的にキーがローテートされることにもなります。

Root - rootは原則として使わない

rootユーザのミス利用による事故を減らしましょう。 アクセスキーは削除し、強固なパスワードとMFAを設定して原則として利用できない状態としておきます。

vs

どっち使った方がいいんだろう？って機能の比較です。

IAMユーザ vs フェデレーションユーザ

AWSアカウントでユーザを管理するのであれば、IAMユーザを使います。 一方、オンプレミスでユーザを管理するのであれば、フェデレーションユーザを使います。

重要なことはクレデンシャル情報をシェアしないことです。

AWSアクセスキー vs パスワード

API・CLI・SDKからAWSにアクセスするにはアクセスキーを使います。 一方、コンソールからAWSにアクセスする場合はパスワードを利用します。 この時、MFAを設定することも忘れないでください。

インラインポリシー vs マネージドポリシー

インラインポリシーはポリシードキュメントで定義する従来のポリシーです。 一方、マネージドポリシーは次のような特徴があります。

• 再利用可能
• バージョン管理される
• ポリシードキュメントのサイズが大きい
• AWSで提供されるマネージドポリシーは自動的にアップデートされる

中々扱いが難しいマネージドポリシーです。 インスタンス毎にRoleを使い分けるような場合、ベースとなる共通のポリシーはBasePolicyのようなマネージドポリシーで管理し、アップデートを容易にすると便利です。 それに加えて個々のRoleで必要なポリシーはインラインポリシーを使うと良いでしょう。 やはり再利用可能な部分が一番の特徴ですね。 ただし、Roleにマネージドポリシーは最大で３つまでしか付けられないので注意してください。

グループ vs マネージドポリシー

グループとマネージドポリシーは似た特徴を持ちます。

幾つかのユーザに同じポリシーを適用したい場合は、グループを利用すると良いでしょう。 一方、グループはRoleやグループ自体に適用できません。 幾つかのグループ・Roleに同じポリシーを適用したい場合はマネージドポリシーの出番です。

リソース特定ポリシー vs タグベースのアクセスコントロール

ポリシーをConditionやResourceで制約すると、より強固なセキュリティとすることができます。

Resourceでリソースを特定するポリシーは、特定のS3バケットなどリソースを限定したアクセス許可を与えることができます。 一方、Conditionでタグを制限するポリシーは、ひとつのAWSアカウントに複数のプロジェクトが混在するような場合にも便利に使えます。 また、将来的に追加されるAWSリソースも、タグが付きさえすれば自動的にアクセス許可が与えられるという点も便利です（例えば、Env=DevのEC2インスタンスに対するアクセス許可など）。

単一AWSアカウント vs 複数のAWSアカウント

組織・プロジェクト・チームなどで明確な分割が必要な場合、AWSアカウントをそれぞれに作成するとアクセス許可が明確になります。 AWS CloudTrailのログもアカウント毎に分割して記録されるでしょう。 一方、まとめることでコストメリットが発生します。 これは、AWSアカウント内で「ｘｘ以上の通信が発生したらば単価減」「RIはAWSアカウント間で共有化」などのメリットを享受できるからです。

まとめ

たかがIAMと思うことなかれ。 適切なアクセス許可を必要最低限付与することでシステムは守られることになります。 安全なシステム運用をしていきたいですね。

特にタグベースのアクセスコントロールや、マネージドポリシーは深く掘り下げて考えてみたいところです。