あすたぴのブログ

astap(あすたぴ)のブログ

AWSのIAMベストプラクティスをちゃんとやる(見る)

IAM のベストプラクティスをちゃんと理解しようというお話。

目的

このエントリでは、細かいやり方は書かない。 (ドキュメントを見ればいいし、コンソールを開けばわかる) こういうことをしたほうがいいんだよ。という内容を把握し、いざ、必要な時がきたときに知ってるいる状態にすることが目的

対象読者

  • AWSはEC2とかたてたりするけど、*1ルートアカウントでコンソールをいじってる人
  • EC2にIAMインスタンスプロファイルのロールを付けるとは??な人
  • 権限とか難しいから、フルアクセス付けてるよ?な人

IAMとは?

AWS Identity and Access Management (IAM) の略 アイアムって読んでます。(正しいかは知らない)

IAMを使うと、どんな事ができるのか

  • ルートアカウント以外にアカウントを作成できる。
    • 会社のAWSアカウントを複数人で触る際に、個人個人にアカウントを発行する。
    • 外部(CI等)から、AWSにアクセスする必要がある際に使うアカウントを発行する。
  • 作成したアカウントに対して、*2リソースごとにアクセスを制限できる

ルートアカウントを共有しない。 フルアクセス権限を全員に渡さない。 誰が何のリソースをどこまで操作できるか。を制限しよう。 というのがIAMを使う理由の認識です。

やること

AWS アカウント(ルート)のアクセスキーをロックする

ルートアカウントはすべての権限があるため、 ルートアカウントの権限を用いて、AWSコマンド等を使用すると、請求情報まで取得できる。 見られて困るものは、見れないようにしましょうね。という話し

  • アクセスキーを持ってるなら削除する
  • IAMで、管理権限を持つユーザーを作成する。
  • ルートアカウントのパスワードは強度の高いものを設定しよう。
  • ルートアカウントにMFAを設定する。

個々の IAM ユーザーを作成する

AWSにアクセスする必要がある場合は、IAMでユーザーを作成する。 IAMユーザーのアクセス許可は、いつでも、有効、無効にすることができる。 ※ルートアカウントは他人に絶対に教えてはいけない。 たとえ、個々のIAMユーザーに管理権限を付与するとしても、 ルートアカウントでない限りはアクセスを制限できるので、 必ず、IAMユーザーを都度、作る。

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

ポリシーとは AWSではアクセス権限を制御するのにポリシーという定義を利用する。

ポリシー例

{
    "Version": "2012-10-17",
    "Statement": [{
        "Effect": "Allow",
        "Action": [
            "aws-portal:*Billing",
            "aws-portal:*Usage",
            "aws-portal:*PaymentMethods",
            "budgets:ViewBudget",
            "budgets:ModifyBudget"
        ],
        "Resource": "*"
    }]

}

AWS内でデフォルトで定義されているポリシーを使って可能な限り、権限を割り当てる。 メリットとしては、簡単。 デメリットとしては、権限の単位がざっくりしている。

例 - AdministratorAccess - フルアクセス権限 - AWSCloudTrailReadOnlyAccess - ClourTrailの読み取り権限

職務によって、ポリシーがAWSで定義されている。 職務機能の AWS 管理ポリシー

IAM ユーザーへのアクセス許可を割り当てるためにグループを使います。

ポリシーをIAMユーザー一人ひとりに付けるのは面倒だし、 複数人いても大体同じ権限になる。という場合に、グループを使う。

グループの作成

ここらへんで、単語が増えてきて混乱してきたと思うので、 以下にユーザ、ポリシー、グループの関係を整理。

  1. グループ作成
  2. グループにポリシーをアタッチ(付与】
  3. ユーザーをグループに追加

ポリシーはユーザーに直接アタッチも可能。

最小限の特権を認める。

まずは、最小限のアクセス(特定サービスへの権限、リードオンリー)を割当て、 必要になった際に権限を解放していくようにしよう。という話し

Access Advisorを使う アクセスアドバイザーは、コンソールでIAMユーザーを見る場合にタブの1つである。 該当ユーザーが、権限が付与されているサービスにいつアクセスしたかがわかる。 この項目を参照し、1度もアクセスをしていないサービスがあれば、 その権限はそのユーザーには不要な可能性があるため、 権限の見直しに使える。

ユーザーのために強度の高いパスワードポリシーを設定する。

IAM ユーザー用のアカウントパスワードポリシーの設定

IAMユーザーのパスワードに、パスワードポリシーを設定できる

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

AWS での多要素認証 (MFA) の使用 ルートアカウント同様に、重要なリソースへの権限を持っているユーザーにはMFAを設定しようという話し。 例えば、(どのサービスでも)削除権限を持ってる人とか。

Amazon EC2 インスタンスで作動するアプリケーションに対し、ロールを使用する。

EC2上から別AWSサービスにアクセスすることはよくある。 そのアクセス権限は適切に定義しよう。という話し

ロールとは、AWSのリソースにアクセスできる権限の役割の定義

また新しい言葉が出てきたので、整理する。

  • IAM ポリシー
    • AWS上で扱う権限の一番小さい単位
  • IAM ユーザー
    • AWSにアクセスするユーザーの単位
    • グループに含めたり、ポリシーをアタッチして権限を付与する
  • IAM グループ
    • 複数のポリシーをまとめたもの
    • 複数のユーザーに同一の権限を与えるために使う
  • IAM ロール
    • 複数のポリシーをまとめたもの
    • ロールを付与したものに権限を委任することができる。
    • 主にはEC2インスタンスへ権限を付与する場合に使う
    • AWSアカウントのIAMユーザーにロールを付与することもできる。

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

さっきのロールの使い方での他AWSアカウントへは、アクセスキーを共有するんじゃなくて、 ロールを使おうね。という話し

認証情報を定期的にローテーションする。

定期的に認証情報を更新しようという話し

不要な認証情報の削除

使われていない認証情報があったら消そう。という話し

認証情報レポートや、awsコマンドで最後に使用した日付とかがわかるので、 それを見て、消す対象を精査できる。

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

ポリシーに対して、IPアドレスの制限が時間の制限を行うことができるので、 可能な限り、制限したほうがいいよ。という話し

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

  • cloudfront
  • cloudtrail
  • cloudwatch
  • aws config
  • S3

の、アクセスログを利用して、不正なアクセス、利用と監視しようという話し

まとめ

全部やるのは過剰なのかな?という気もしますが、 そこは自分たちのやり方に合わせて、うまくやっていくのがいいのかなと思います。

*1:ルートアカウントとは、メールアドレス、パスワードでログインをするユーザーのこと

*2:AWSでは、ARNごとに、1リソースとして扱う。