AWSをやっていく IAM/AWS Organizations

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)
            - メンバーアカウント
            - メンバーアカウント
            - メンバーアカウント

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