Ops JAWS Meetup#15 IAM勉強会 with 熊本支部（参加メモをただ貼る
Ops JAWS Meetup#15 IAM勉強会 with 熊本支部
https://opsjaws.doorkeeper.jp/events/74118
■OpsJAWSご紹介
○アンケート
https://goo.gl/PSs34p
■熊本支部の紹介
JAWS-UG熊本 第10回勉強会
熊本地震の時はmizuderu作ってました
http://mizuderu.info/
■リモートについて
Amazon Chime使ってる
＝＝＝＝＝＝＝＝＝＝
素晴らしきIAMポリシービジュアルエディターの世界（サーバーワークス 伊藤様）
簡単にこだわりのポリシーを実現
https://www.slideshare.net/qryuu/iam-98065746
■AWSの操作権限
- rootアカウントが必要
- メール送信制限解除申請
- CloudFrontキーペアの作成
- 契約情報の変更
■IAMリソース
- IAMユーザー
- ログインユーザー、APIユーザー
- IAMグループ
- IAMユーザーをまとめて管理するグループ
- IAMロール
- ユーザーの役割を一時的に切り替える
- EC2やAWSサービスに対して権限を割り当てる
- IAM管理ポリシー
- 権限を汎用的に管理する
■IAMポリシー
- IAMリソースに対して設定
- JSON形式で表現される権限設定
- Effect
- Principal, NotPrincipal
- Action, NotAction
- resource, NotResource
- Condition
■IAMビジュアルエディタ
サービス
アクション
リソース
リクエスト条件
- ビジュアルエディタでは、サービスごとにポリシーを簡単に設定できる
- サービスを選択
- アクションでは、一覧、読み込み、書き込み、権限設定の種類ごとに簡単にチェックボックスで選択可能
- リソース制限
- 許可したアクションの中にリソース制限が可能な操作があれば、自動的に指定可能なリソースの種類が表示されます。
- すべてのリソースを指定することも、個別のリソースを指定することもラジオボタンで選ぶだけ
- リソースタイプが自動的に分かれるので、指定も簡単
- [ARNの追加]をクリックするとわかりやすい入力欄が現れるのでコロンの数を間違えることがありません。
- リクエスト条件
- IAMビジュアルエディタの小技
- 複雑なポロシーは分割して指定
- [アクセス権限の拒否に切り替え]を使うことで許可と拒否とを切り替えできる
- ポリシー変数の設定も可能です
- IAMユーザーが自分のS３ホームディレクトリにプログラムによりコンソールでアクセスすることを許可する
- バージョニング
- ５つ前までのバージョンが残っている（ので設定を間違っても戻れる
- 複雑なポロシーは分割して指定
■IAMビュジュアルエディタの制限
- IAMグループポリシーに対応していない
■まとめ
- これまでJSONなので経験やドキュメントが必要だった
- ビジュアルエディタでは画面の警告に従うだけで細かいポリシー設定が可能
- 過去に作ったJSONをビジュアルエディタで見ると抜け漏れが発見できる場合がある
- ビジュアルエディタで適切な権限設定を簡単にできるようになる
JSONで書いてからビジュアルエディタにすると確認できる
＝＝＝＝＝＝＝＝＝＝
IAMの運用ベストプラクティス（クラスメソッド 森永様）
https://dev.classmethod.jp/cloud/report-opsjaws-13/
IAM運用どうしてます？
まずはAWS公式のベストプラクティスを見る
- AWSアカウントのルートユーザーのアクセスキーをロックする（MFAの登録
- 個々のIAMユーザーの作成
- IAMユーザーへのアクセス権限を割り当てるためにグループを使用する（ポリシーでも同様のことができるのでそちらでやるのも手
- AWS定義のポリシーを使用して可能な限りアクセス権限を割り当てる
- 新しいサービス追加に自動で追随
- 関連するAPIコールも追加してくれる
- 要らない権限までつく
- 最小権限を付与する
- やってはいけない操作を防ぐ
- 関係ないリソース操作を防ぐ
- 運用が死ぬほど大変
- アクセスレベルを使用してIAM権限を確認する
- ユーザーの強力なパスワードポリシーを設定
- 特権ユーザに対してMFAを有効化する
- 特権ユーザに限らずやるべき
- Amazon EC2インスタンスで実行するアプリケーションに対し、ロールを使用する
- IAMユーザーのアクセスキーではなくロールを使う（アクセスキーは漏れたらおしまい、ロールは一時的なアクセスキーを発行してる
- 認証情報を共有するのではなくロールを使って委託する
- １つのアカウントから別ロールへスイッチ可能
- 認証情報を定期的にローテーションする
- アクセスキーは基本的に使わないで、定期的にローテーションする
- 不要な認証情報を削除する
- アプリしか使わないユーザーはパスワード不要
- コンソールしか使わないユーザーはアクセスきー不要
- 追加セキュリティに対するポリシー条件を使用する
- AWSアカウントのアクティブティの監視
- ひとまず個人的まとめ
- ルートユーザーは使わない
- IAMユーザーは使わないでロールで
- アクセスキーは最終手段なのでロールで実現
- ログは取る
- MFAは基本的に有効化する（仮想でもいい
- パスワードは強力に
- IAMロールを使うと大体解決
- 残った課題
- IAMの権限をどうするか
- 最小権限にした時のよくあるシナリオ
- 権限不足→権限追加の嵐。つらい
- やれる体制があるならやった方がいい
リクルートテクノロジーズさん運用事例
https://www.slideshare.net/recruitcojp/20160517-security-jaws-miyazakisachie?ref=https://recruit-tech.co.jp/news/160517_001663.html
AWSでのセキュリティ運用
（棚卸しからの見直しで１週間以上かかる…
- PowerUser権限を渡して一部Deny
- 基本的に全てのサービス・リソースを触れる
- 触らせたくないのだけDeny
- 運用ほぼなし、権限不足で悩まない、けどセキュリティ的には
- PowerUserはIAMロールを付与できない
- iam:PassRoleの権限をつければいける
- iam:Get, iam:Listもつける
- 使うサービスの権限d酒AWS管理ポリシーを渡す
- EC2FullAccessなどの管理ポリシーを使う
- 運用は比較的楽dさが、別のサービスを見に行くサービスがあると困るし、許可したサービスについては何でもできちゃう（ReadOnlyは全部につけておいてもいいのでは
- 職務機能別のAWS管理ポリシーを使う
- DB管理者、システム管理者など職務別にポリシーが存在してるので流用する
- 足りない部分をたす。が、うまくハマればいいのでは程度
- どれを選択するかは組織体制やしくみづくり次第
- IAMの権限をガチガチにするより
- 問題発生時に対応できるしくみづくりが重要では？
- CloudTrail + AthenaとかConfigとかConfig Rulesで設定値を監視とか
- 外部から不正利用されないようにベストプラクティスを守る（内部犯行は防げない
- そもそも組織が違うならアカウント自体を変える
- 問題発生時に対応できるしくみづくりが重要では？
-
- 認証情報レポートが棚卸しに便利
- アカウント内のすべてのユーザとユーザの認証に関する情報が一覧にまとめられたレポート
- 認証情報レポートが棚卸しに便利
- まとめ
- IAMの権限管理は自分の組織に合わせて方針を決める
- 無理して厳しくしすぎずに即座に対応できる仕組みを
- 運用者も開発車も疲弊しないように最善を探る
- 自動チェックはどんどんやるべき（だが人力も必要
- まとめ（Developers.IOに
- QA
- AWSではIAM管理をどうしてるのか？
- ロールベースです。ツール使いながらロールベースで管理
＝＝＝＝＝＝＝＝＝＝
初めてさわるEC2ロール（熊本）山ノ内さん
https://www.slideshare.net/yoshinoriyamanouchi12/ec2-98014834
計算リソースとしてスポットインスタンスを使っているが、スポットだと突然死するのでAMIにアクセスキーを保存できないから再アクセスするのに…
→EC2にIAMロール割り当てればいいのでは
- S3アクセスポリシーの作成
- EC2用ロールの作成
- 上記のS3アクセスポリシーだけ当てる
- ロールを指定せずに起動
- ターミナルに接続（権限不足エラー
- 作成したロールを選択して起動
- 指定したS3にアクセスできる
- EC2ロールでアクセス可能なサービス → だいたい行ける
まとめ
ロールでまとめると楽
- QA
- ローンチテンプレートを使うともっと楽なのでは
https://dev.classmethod.jp/cloud/aws/try-launch-template-for-ec2/
＝＝＝＝＝＝＝＝＝＝
LT1：AWS Organizationによる権限管理（日本ユニシス 太田様）
- AWS Organizationとは
- AWS Organizationsによる権限管理
- SCP #1
- SCP #2
- ポリシーの許可・拒否は以下のように機能する
- 複数のポリシーを提供するとAND条件になる
- アカウント内のアクセス権限痛いしてフィルタとして動作する
- 許可
- 拒否
- IAMのアクセス可否
- アクセス可否の決定ロジック（デフォルトDeny < Allow < 明示的なDeny
- SCPを混ぜると（デフォルトDeny < Allow (IAM, SCP < 明示的なDeny（IAM or SCP
- 適用事例
- デフォルトのポリシー（FullAWSAccessはそのまま利用する
- 全体に対する拒否をSCP, OUで管理
- 個別の許可・拒否はIAMで管理
- SCPの制限を一時的に有効にしたい場合はOUを移動して制限をはずす
- OUは２階層
- FullAWSAccess
- OU1＝SCP2＝AWSアカウント解約を拒否
- OU2＝SCP3＝EC2削除を拒否
- OU3＝SCPなし
- OU1＝SCP2＝AWSアカウント解約を拒否
- とすると、EC2削除をしたい時にOU2 →OU3にアカウントを一時的に移動することで削除できるようになる
- まとめ
- AWS Organizationsを利用することで、複数のAWSアカウント、IAMユーザーに対して制限をかけてガバナンスを聞かせることができる
- OU, SCPを組み合わせて柔軟な運用を実現できる
- QA
- 社全体に適用・普及するにはどうすれば？
- 今回はとあるプロジェクトの範囲で適用してみた。社全体での適用は今後の課題
- （Qを聞き逃した
- MFAで入るアカウントを踏み台として使い、そのアカウントでは開発せず開発用ロールへスイッチロールする運用が良いのでは
