# 2021/12/19 メンター相談

###### tags: `メンター相談`,`12月`

## 実際にプラハではどのようなIAM グループを設計、運用管理しているのでしょうか？

何か設計、運用の方針があればお聞きしたいです。（会社全体で作っているのか、プロジェクトごとに作っているのかなど）

- プロジェクトごとに性質が異なるので、会社の方針が無い
- AWSを使わないプロジェクトもある
- GCP
- Firebaseのみ
- 受託元のAWSアカウントを使用する場合もある
- プラハのアカウントでデモを作成して、よかったら相手のアカウントで同じものを作成する
- アクセス関係の手間を省ける
- 具体例
- 松原さんは現在のプロジェクトではGCPを使用している
- 受託開発の場合、受託元から提供されるアカウント、ルールがある場合が多い
- 上場企業など大きい会社の場合、すでにルールがある
- 大きな権限はもらえない
- プロジェクトに参加している人数が少ないので、あまり厳密に運用はしていない
- AWSの例は、後で社内に聞いてみる

## 以下のポリシーは実際にはどのように使い分けていますか？ユースケースがあればお聞きしたいです。

- アイデンティティポリシー
- 人主体
- リソースベースポリシー
- サービス主体
- 使い分けざるを得ない場合
- ラムダを使用する場合
- ラムダが何を呼び出せるか (アイデンティティ)
- 何がラムダを呼び出せるか (リソースベース)
- 例: イベントトリガーがラムダを呼び出す
- アカウントをまたいでロールを継承する場合
- AssumeRole (アイデンティティベース)
- [IAM ロールの継承において「AccessDenied」または「Invalid information」エラーが発生する場合のトラブルシューティング](https://aws.amazon.com/jp/premiumsupport/knowledge-center/iam-assume-role-error/)
- ロール自体に誰が継承できるかを設定する (リソースベース)
- どちらでも良い場合にどちらを使うか
- リソースベース
- リソースベースは、リソースが消えたときに消える
- このS3にアクセスできる、というポリシーは対象のS3が消えたら消えてほしいので、リソースベースを使う
- 他のアカウントのバケットからこちらのアカウントのバケットにデータをコピーする場合
- ロールの切り替え(アイデンティティベース)だと、両方を同時に見ることができず、手間がかかる
- リソースなら同時に見ることができる
- 特にS3はリソースベースを使用することが多いかも
- アイデンティティ
- Permission Boundaryによって制限できるという点が利点
- PermissionBoundary: ここまでの権限を渡していいよというのをユーザーごとに設定できる
- CTOなどがPermissionBoundaryを設定しておいて他の人にAdminを任せられる
- [Permissions boundaries for IAM entities - AWS Identity and Access Management](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html)
- 参考
- [AWS IAM: Identity vs Resource Policy | by Hamzah Abdulla | Medium](https://hamzahabdulla1.medium.com/aws-iam-identity-vs-resource-policy-abfe099e14d1)
- [How IAM roles differ from resource-based policies - AWS Identity and Access Management](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_compare-resource-policies.html)
- [Identity vs Resource-based AWS IAM Policies](https://sonalake.com/latest/identity-vs-resource-based-aws-iam-policies/)

## IAMポリシーの設定をするためのツールとして、Policy GeneratorやSimulatorが存在しているということなのですが、実際これらを使用したことはありますか？

例えば、以下のスライドのp47のツールなど
https://www.slideshare.net/AmazonWebServicesJapan/20190129-aws-black-belt-online-seminar-aws-identity-and-access-management-iam-part1

- Simulatorはデバッグで使ったことがある
- 権限の確認
- Generatorはあまり使ったことがない
- 権限設定について
- 「最小限のパーミッション」がベストプラクティス
- 何もできない状態から試しつつ少しずつ増やしていく

## その他

- Terraform or CloudFormation
- Terraformを使っている
- GCPを使用する場合があるので
- ベンダーロックインされないところが良い
- GCP or AWS
- 受託元に合わせる
- 受託元がサポート契約してくれている場合だと、わからないことを聞けるのでよい
- ハイクラスなサポート契約だと、会社にGCPの人が来てくれる(!)
- 選べるならAWSにするかも
- 社内にAWS得意な人がいる
- Firebaseを使うなら、GCPにするかも
- GAEが不便
- Standardがビルド時間10分固定
- 大きいフロントエンドだと時間が足りない
- Flexibleだと使用方法が変わり、設定が複雑
- 急に証明書の有効期限が消えた
- 権限の付与を間違えて事故ったエピソード
- 松原さん
- 事故ったことはない
- 業務委託、派遣の人が大きい権限をもっていたことが社内問題になったことがある
- (おそらく)監査的なもので発覚したのではないか
- その他
- [AWS で不正アクセスされて凄い額の請求が来ていた件 - yoya's diary](https://yoya.hatenadiary.jp/entry/20150404/aws)
- [IAM ロールを 1000 個作って遊んでいたら AWS 利用費が 50 ドルを超えていた話を JAWS-UG 初心者支部で LT しました | DevelopersIO](https://dev.classmethod.jp/articles/jawsug_bgnr-36-shikujiri-iamrole-1000/)
- 便利なツール
- [GoogleCloudPlatform/terraformer: CLI tool to generate terraform files from existing infrastructure (reverse Terraform). Infrastructure to Code](https://github.com/GoogleCloudPlatform/terraformer)
- [dtan4/terraforming: Export existing AWS resources to Terraform style (tf, tfstate) / No longer actively maintained](https://github.com/dtan4/terraforming)
- 権限を付与する人付与される人別れているか？
- kubotaさん: 別れている事が多い
- 松原さん
- 詳しい人がいれば任せたい
- プロジェクトを立ち上げた人がルートを持つ事が多い
- 開発環境だと自由に触れるようにすることが多い
- スラックに逐一設定のログを投げている (事故ったとき怖いので)
- 「この画面のこのボタンを押しました」等
- 詰まったときに調べたことなども書き残す
- GUI触るときは特に細かく書き残している