AWS Black Belt Online Seminar AWSサービスの権限管理 参加レポート

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

丹内です。掲題のオンラインセミナーに参加したのですが、非常に素晴らしい内容でした。
公式ブログには時間内に答えきれなかったQAも載っているので、ぜひご覧ください。

今回のセミナー

「AWSサービスの権限管理」と銘打ってはいますが、権限と聞いてまず思いつくのはIAMです。
しかし今回のセミナーでは、IAMやAWSのセキュリティ関連サービスをある程度知っていることを前提として、実際の業務で権限をどのように設定するかまでを詳細に説明していました。
ドキュメントに載っていない、実務的な内容は他のBlack Beltでもいくつか取り上げられていましたが、今回のようにそれが中心になったのは、自分が知る限り初めてです。
大変有意義な内容だったと思います。

メモ

  • 権限設計は悩みが多い
    • APIが多いので権限も付随して多い
    • 組織が複雑で、ルールも組織ごとにバラバラ
  • 権限設計とはルールを適用する仕組み
    • 個人のスキルや性格に依存しない設計が重要
  • AWSの利用を開始してからできるだけ早く責任者を選出することが重要

まず机上で整理する

  • クラウドに関わる組織を書き出して理解すると良い
  • AWSの操作ポイント(CRUD)に着目して権限設計をする
    • どの組織がどの操作ポイントを担当するのか、を意識する
  • 次に作業を明確化する。書きだした組織図と合わせて、CRUDを実際の業務に対応させて明らかにする

次にIAMとして設定する

  • 認証と認可で分けて考える
  • 認証: ポリシードキュメント
    • 業務内容が必要とするリソースと操作を表にして、それを元にIAMポリシーを作る
  • IAMにはメンテが必要
    • 組織は固定されておらず移動や退職がある
    • その際使われていない権限は削除する
    • 他メンバーもメンテ可能なように、シンプルにすることが重要
  • 認可: アクセス手段。ロール、AMCログイン方法、AD
    • 組織が、システム上はどのような認可が業務上必要になるのかをマッピングする
  • 中央管理型: CCoEが幅広く管理行う
  • セルフサービス型:CCoEはテンプレの企画・開発のみ
    • EC2タグの権限委譲は難しいので、AWSアカウントの分割とServiceCatalogがある
    • ServiceCagalogを使うと、ユーザが権限を持っていなくてもSCを通じて操作が可能。EC2タグ付けの強制も可能
  • 認証委任型: 受発注企業で、委託先企業の組織はそちらで管理してもらう
    • 委託先管理者はIAMポリシー権限をDeny。
  • マネジメントコンソールへのアクセス制限
    • IAM固定パスワードを渡さないことで、外部からのアクセスを制限できる
    • AD連携で実現する。AD自体へのアクセスを社内に限定することで、コンソールへのアクセスも社内に限定できる
    • ADのFederated UserでログインしてもCloudTrailにログが残る

まとめ

「事業部毎に権限を分離したい」といったように、マネジメントコンソールを触る前に、まずやりたいことを明示するのが大事だと思いました。
日々AWSを触ってるとどうしても手を動かしたくなるのですが、普通の仕事同様、まずはルールを明らかにすることが、実装以前に重要だと感じました。