AWSコンソールのログイン用アカウントをIAMのベストプラクティスに従って作成してみた(設定編)

147件のシェア(ちょっぴり話題の記事)

はじめに

AWSチームのすずきです。

1つのAWSアカウントを複数の関係者で利用する環境で、AWSコンソールのログイン用アカウント(IAMユーザ)を AWSが公開しているベストプラクティスに従って作成する機会がありました。

多要素認証(MFA)や接続元IPアドレス制限などによる不正なログインの抑止と、 管理者権限が行使された際の通知を、AWSのサービスを利用して実現する方法について紹介させていただきます。

AWS Identity and Access Management ユーザーガイド: IAM のベストプラクティス

方針

  • AWSコンソールの認証パスワードが漏洩した場合でも、悪意をもった第三者によるシステム影響を抑える事を目標とします。
  • AWSの標準サービスを利用し、システムコストの発生や、管理者、作業者の作業効率が低下を抑えた対策をとる事とします。
  • AWS環境が不正に利用された場合でも、通知による早期対応と、操作ログの適切な保管による影響範囲の確認を実現します。

設定

上記方針と、AWSのベストプラクティスとして掲載されている推奨事項を元に、以下の様なAWS環境の設定を行いました。

個々の IAM ユーザーの作成

  • AWSアカウントを利用する担当者毎に、ログイン用のIAMユーザを用意しました。

IAM ユーザーへのアクセス権限を割り当てるためにグループを使用する

  • ログイン用のIAMグループとして管理者、作業者、参照用の3つを用意しました。

  • IAMユーザは、IAMグループに所属する事で、アクセス権限を利用するものとしました。

AWS 定義のポリシーを使用して可能な限りアクセス権限を割り当てる

  • AWS提供のマネージドポリシー(管理ポリシー)をログインユーザが利用するロールに割り当てました。
  • インラインポリシーは、マネージドポリシーで設定出来ないリソース単位のアクセス制限の実現などに限った利用としました。

最小権限を付与する

  • ログイン用のIAMユーザで可能なAWS環境の操作は参照と、自身のパスワード変更、MFA設定に必要な権限のみとしました。
  • IAMユーザの役割に応じ、管理者、作業者用のIAMロールの利用権限を与えました。

特権ユーザーに対して MFA を有効化する

  • 初期発行のIAM管理者(Admin)ユーザはRootアカウント同様に非常用とし、平時の作業では利用しないものとします。

  • 強固なパスワードとMFAを設定、アクセスキーも解除して保管するものとしました。

  • MFA(多要素認証)が未設定のIAMユーザによるロール利用は禁止としました。

認証情報を共有するのではなく、ロールを使って委託する

  • 管理者、作業者用のIAMロールを用意しました。

追加セキュリティに対するポリシー条件を使用する

  • 管理者、作業者グループに所属するIAMユーザに限り利用出来るようにしました。
  • AWS環境の操作が固定IPを持つ拠点のみで実施される環境や、VPNなどのリモートアクセスが整備されている場合、接続元のIPアドレス制限も可能としました。

管理者グループ用のポリシードキュメント

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Condition": {
                "Bool": {
                    "aws:MultiFactorAuthPresent": "true"
                },
                "IpAddress": {
                    "aws:SourceIp": [
                        "0.0.0.0/0"
                    ]
                }
            },
            "Action": [
                "sts:AssumeRole"
            ],
            "Resource": [
                "arn:aws:iam::000000000000:role/iam-role-admin",
            ],
            "Effect": "Allow"
        }
    ]
}
  • S3、DynamoDBに保存された情報が漏洩するリスクを軽減するため、参照専用権限からS3、DynamoDB操作権限を限定しました。
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": [
                "s3:GetObject",
                "DynamoDB:Get*",
                "DynamoDB:Scan",
                "DynamoDB:Query",
                "DynamoDB:BatchGetItem"
            ],
            "Resource": [
                "*"
            ],
            "Effect": "Deny"
        }
    ]
}
  • 作業者によるCloudTrail設定は変更禁止としました。
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": [
                "CloudTrail:DeleteTrail",
                "CloudTrail:StopLogging",
                "CloudTrail:UpdateTrail"
            ],
            "Resource": [
                "*"
            ],
            "Effect": "Deny"
        }
    ]
}

AWS アカウントのアクティビティの監視

  • 管理者(Admin)権限を持つロールへのスイッチ時に通知を行うようにしました。

  • 非常用としたIAMユーザ、およびRootアカウントのログイン時にも通知を行うようにしました。

  • 通知はAmazon SNSのトピックにメールアドレスを登録し、通知先として利用しました。

  • SNSと連動するLambda関数を用意する事で、Slack、Chatworkなどへの通知も可能です。

Lambdaの「Blueprint」で簡単にSlackとCloudWatchを連携してみた(2017年版)

  • 必要に応じCloudTrailログのS3保存を設定します。

【新機能】AWS CloudTrailでイベント履歴の表示期間が90日になりました

まとめ

AWSコンソールの利用にあたり、多要素認証(MFA)の導入や接続元IPアドレスによる制限を行う事で、 第三者による不正利用リスクを削減できます。

また、権限を最小限に留めたIAMユーザでAWSコンソールにログインし、 上位権限を必要とする場合にスイッチロールを行う、Unix系OSで普及している「sudo」的な利用を行う事により、 平時の事故防止効果も期待できるかと思います。

今回紹介させて頂いた環境は、以下の「CloudFormation」テンプレートで設置する事が可能です。 こちらの紹介は次の記事で紹介予定です。

CloudFormationテンプレート