はじめに
AWS,GCP,Azureを使っているのですが対応している用語が分かりづらかったのでまとめました。
また弊社のように今は小規模な組織で厳密に権限管理をするほどではないけど、スケールする可能性があり将来的な負債にはしたくないという方向けの低工数だけど効果がある最適なベストプラクティスをまとめました。
1年前の自分に読ませてあげたいことが書いてあります。
階層
| 階層 | AWS | GCP | Azure |
|---|---|---|---|
| ルート | 組織 | 組織 | AzureAD ※2 |
| 環境の グループ ※1 |
OU | フォルダ | 管理グループ |
| 独立した環境 | アカウント | プロジェクト | サブスクリプション |
| VMなどの グループ |
リソースグループ | ||
| VMなど | リソース | リソース | リソース |
※1:環境だけでなくグループ化したものもグループ化できる、ファイルとディレクトリをイメージすると分かりやすい
※2:厳密にはAzureADは認可認証サービスなので少し違う
ベストプラクティス
AWSのアカウントなど「独立した環境」レイヤーで開発、本番環境を分離することをお勧めします。
独立している環境なのでヒューマンエラーが起きにくくなります。
また、組織が大きくなったときに「独立した環境」をそのまま「環境のグループ」に移動するのは比較的簡単ですが、「独立した環境」内を整理するのは大変です。
ユーザー
| ユーザー | AWS | GCP | Azure |
|---|---|---|---|
| 個人 | ユーザー | Google アカウント ※3 |
ユーザー |
| グループ | グループ | Google グループ |
グループ |
| マシンユーザー ※1 | ロール ※2 | サービス アカウント |
サービス プリンシパル |
※1:プログラムなど人以外がアクセスするときの認証情報を持った仮想のユーザー
※2:「プログラムによるアクセス」ユーザーという選択肢もある
※3:個人のGoogleアカウントではなくGsuiteもしくはCloudIdentityを用いた方が管理が楽です
ベストプラクティス
組織がスケールする可能性があるならば、個人ではなくグループで管理することをお勧めします。入退社や新規開発の度に管理するのは組織が大きくなるとどんどん大変になります。
マシンユーザーはコード管理をお勧めします。環境による差分を生じさせないためです。
「独立した環境」の定義された権限
| ユーザー | AWS | GCP | Azure |
|---|---|---|---|
| 全ての権限 | Administrator Access |
オーナー | 所有者 |
| 権限以外の権限 | PowerUser Access |
編集者 | 共同作成者 |
| 閲覧者 ※1 | |||
| 読み権限 | ReadOnly Access |
参照者 | 閲覧者 |
※1：Firestoreのレコード書き換えることができてしまうので注意
ベストプラクティス
各環境で必要な権限をグループに付与しましょう。
開発者グループには
開発環境では「全ての権限」もしくは「権限以外の権限」、
本番環境では「読み権限」と必要ならば特定のリソースのみの権限がお勧めです。
弊社では、開発者・ITインフラ・ITインフラ特権・アドミンにグループ分けをして各環境で必要な最小権限を与えております。
最後に
最後までご覧いただきありがとうございます。
最小権限の原則を満たしつつ権限不足で業務に支障が出ないようにすることは大変難しいですが、ITインフラ担当者の腕の見せ所だと思いますので私を含め皆さん頑張りましょう！
間違いなどございましたらコメントいただけますと幸いです。