2020-04-21

AWSをやっていく IAM/AWS Organizations

IAM

  • Identity and Access Managementの略

    • 安全にAWSの操作を実施するための認証の仕組みのこと
  • AWSではセキュリティに対して、AWSと利用するユーザーとで、責任分解して対応する責任共有モデルとなっている

    • AWSはインフラ部分(ハードウェア、ネットワーク)、ユーザー側は利用するAWSサービス部分(自分が作ったEC2インスタンス)など
  • 主要トピックは以下の4つ

    • ユーザー/グループ

      • ルートユーザー

        • ※ パワーユーザーはIAMユーザーやグループの管理以外全てのAWSサービスにフルアクセスする権限を有するユーザーで、ルートユーザーではないので注意
      • IAMユーザー

        • ルートユーザーにアカウントを発行してもらった個人 = IAMユーザー
        • 5000ユーザーまで作成可能
        • オプションとしてパス(/hoge/fuga みたいな)が設定でき、パスを元にユーザーを検索できる
        • 10グループまで所属できる
        • AWSサービスへのパーミッション
      • IAMグループ

        • IAMユーザーのまとまりをグループと呼ぶ = IAMグループ
        • 同じくパスなどを設定可能
        • グループに設定したパーミッションは、IAMユーザーに設定されたものと同時に評価される
    • ポリシー

      • JSON形式の文書で、アクセス権限について記述する

        • Effect/Action/Resource/Conditionの4つに大きく分かれている

          • Effect

            • Allowで許可、Denyで不許可が設定できる
          • Action

            • 対象のAWSサービスを指定する
            • s3:Get みたいに書く
          • Resource

            • 対象のAWSリソースの指定で、ARNで記述する
            • arn:aws:s3::mybucket みたいに書く
          • Condition

            • アクセス制御が有効となる条件を書くことができる
      • 管理ポリシーとインラインポリシーの2つある

        • 管理ポリシーにはAWS管理ポリシー(AWSが作成・管理するポリシー)と、カスタム管理ポリシー(AWSアカウント毎に作成・管理するポリシー)の2つある
        • インラインポリシーは自身で作成・管理するポリシー
      • ユーザーベースとリソースベースのポリシー適用が存在する

        • ユーザーはXXXサービスへアクセスできる(ユーザーに適用)
        • このサービス(S3など)はXXXサービスへアクセスできる(リソースに適用)
    • ロール

      • リソース(EC2など)に対してアクセス権限をロールとして付与することができる
      • EC2が別のEC2やS3にアクセスできるように設定したりできる
  • 以下のサービスを使用すると一時的なアクセス権限の付与が可能になる

    • Security Token Service(STS)

      • 動的にIAMユーザーを作り、一時的に利用するトークンを発行する
    • Temporary Security Credentials

      • 一時的な認証情報を作成する

IAMの設計

AWSを利用するユーザーの役割や権限を、自分の会社の組織構造と合わせて設計するのが重要

  • ベストプラクティス

    1. ルートユーザーは使わない
    2. MFA認証を有効化する
    3. 利用者毎にIAMユーザーを作成する
    4. 組織利用の場合は、役割毎のIAMグループを作成してグループで管理する

      • 少数利用であればIAMユーザーでもよい
      • ただし、今後組織が拡大することがわかっているのであれば、最初からグループを使うとよい(グループ利用が基本)
    5. 最小限の権限設定と、不要な認証情報は削除する
    6. 強度の強いパスワードポリシーを設定する
    7. EC2で稼働するアプリなどプログラムから利用する場合はなるべくロールを使用する
    8. 一時利用にはSTSなどで最小限の利用許可を行う
    9. アカウントアクティビティを常に監視する

ポリシー適用

IAM => ポリシーからポリシーの作成をおこなう

  • サービス

    • 対象となるサービスを選択する
  • アクション

    • 許可する操作を追加する
    • 項目数が半端ではなく多いので、アクセスレベルで一括設定するのがいいかもしれない
  • リソース

    • まだよくわかっていない
  • リクエストの条件

    • MFA必須とか、IP制限とかかけることができる

グループへの適用

  • IAM => グループからグループを作成する
  • 名前をつけ、↑で作成したポリシーをアタッチする
  • その後、作業者のIAMアカウントを発行し、上記グループへ入れていくことにより、グループに適用されているポリシーが所属ユーザーに適用される

ロールへの適用

  • なんらかのサービスへポリシーをアタッチするので、サービスを起動する(ここではEC2)
  • IAM => ロールからロールの作成を行う
  • ユースケースでEC2を選択する
  • ↑で作成したポリシーをアタッチする(ここではS3へのフルアクセスとする)
  • ロールが作成できたら、EC2 => インスタンス => 対象のインスタンスを選択し、アクションから IAMロールの割り当て を選択する
  • IAMロールの選択フォームで、作成したロールを選択して適用する
  • これで対象のEC2はS3へのアクセスが可能となる

AWS Organizations

IAMのアクセス管理を、大きな組織でも楽に実施できるようにするマネージド型サービス

  • 複数アカウント(ルートアカウント)の一元管理

    • 全てのルートアカウントの中から、マスターアカウントを決める(その他のアカウントはメンバーアカウントとなる)
  • 新規アカウント作成の自動化(コンソール/SDK/CLIなどから)
  • 一括請求(複数アカウントへの請求を一括化できる)

組織という単位を構成し、マスターアカウントがメンバーアカウントを管理するという仕組みになっている
↓は構成イメージ

- 組織
    - 管理者ルート(マスターアカウント。組織ポリシーを設定する)
        - 組織単位(OU)
            - メンバーアカウント
            - メンバーアカウント
            - メンバーアカウント
        - 組織単位(OU)
            - メンバーアカウント
            - メンバーアカウント
            - メンバーアカウント

相当大規模な会社じゃないと使わなさそう