Slide 1

Slide 1 text

AWS Systems Manager Session ManagerとIAMでシンプルに ユーザーを管理する Masayuki Nakano / @maaaato JAWS DAYS 2020 Masayuki Nakano / @maaaato JAWS DAYS 2020 1

Slide 2

Slide 2 text

SRE 筋トレ歴3年目 ベンチプレス100kg 1rep blog: https://blog.nikuniku.me dev.to: https://dev.to/maaaato github: https://github.com/maaaato SRE / Emacs / AWS / Terraform / Ansible / Workout / English / Personal trainer Masayuki Nakano @maaaato @Stand_IO 2

Slide 3

Slide 3 text

想定聴講者 ● AWS初心者の方 ● スタートアップでいつの間にかAWSの管理をしている方 ● SessionManager, IAMに興味がある方 ● 社員数が増えてきてそろそろAWSのユーザー管理をどうしようかなと考えている方 本セッションは「初心者カテゴリ」のセッションです 3

Slide 4

Slide 4 text

● SessionManagerの具体的なユースケースとIAMの組み合わせについて理解する ● マルチアカウント運用について理解する ● 自社のAWS運用の見直しのキッカケに ゴール ※本日お話する内容はnulabの話ではなく、個人で進めているプロジェクトの内容、発見のシェアになります 4

Slide 5

Slide 5 text

1. SessionManagerの概要、具体的な使い方 2. SessionManagerとIAMを組み合わせる 3. マルチアカウント、SSOについて 4. まとめ アジェンダ 5 TIPS

Slide 6

Slide 6 text

It describes the major challenge here. SessionManagerとは 6

Slide 7

Slide 7 text

● エンジニアがジョインしたタイミングでサーバーへSSH鍵の登録 ● エンジニアが退職した時にSSH鍵の削除 ● 誰がどのユーザーを使いサーバー上で何をしたのか知りたい/知る必要がある 日々の業務でこんな事はないですか? 7

Slide 8

Slide 8 text

”Session Manager はフルマネージド型 AWS Systems Manager 機能であり、インタラクティブな ワ ンクリックブラウザベースのシェルや AWS CLI を介して Amazon EC2 インスタンス、オンプレミスイ ン スタンス、および仮想マシン (VM) を管理できます。Session Manager を使用すると、インバウンド ポートを開いたり、踏み台ホストを維持したり、 SSH キーを管理したりすることなく、監査可能なインスタ ンスを安全に管理できます。 また、Session Manager を使用すると、マネージドインスタンスへの簡単 なワンクリックのクロスプラットフォームアクセスをエンドユーザーに提供しつつ、インスタンスへの制御 されたアクセス、厳格なセキュリティプラクティス、 完全に監査可能なログ (インスタンスアクセスの詳細 を含む) が要求される企業ポリシーに簡単に準拠できます。 “ 8

Slide 9

Slide 9 text

● SSHの鍵の登録をせずにインスタンスへログイン(Privateも可) ● インスタンスのSecurityGroupにSSHを許可する必要がない ● インスタンス内での操作ログをS3へ保存 ● 「いつ」「だれが」「どのインスタンスへログインしたか」証跡を取れる ● Linux,Windowsにも対応 つまりこんなことができる… 9

Slide 10

Slide 10 text

以前、SSH鍵登録でこんなことを... S3にSSH鍵とその鍵のユーザー名を記述した テキストを用意 Autoscalingで起動したインスタンスの cloud-initに S3からSSH鍵とテキストを取得するようにし、起動時 に自動作成 結局、S3にある鍵の管理をしないといけない。 インスタンス起動時にユーザーは作るがそれ以降は 作らないので、途中で SSH鍵を登録する場合、 Ansibleなどで作成する必要があった。 10

Slide 11

Slide 11 text

1. ssm-agentのインストール 2. 適切なIAMロールポリシー 3. Session Manager Plugin 4. VPCエンドポイントとPrivateLink SessionManagerを使うために必要なこと... 11

Slide 12

Slide 12 text

1. ssm-agentのインストール 2. 適切なIAMロールポリシー 3. Session Manager Plugin 4. VPCエンドポイントとPrivateLink SessionManagerを使うために必要なこと... 12

Slide 13

Slide 13 text

Amazon Linux: Amazon Linux1 2017年9月以降のAMIに関してはインストール済み それ以前のAMIやAmazon ECS 対応のAMIは手動インストールが必要 Ubuntu: 20180627で識別されるUbuntu Server 16.04 以降のAMIに関してはインストール済み それ以前のAMIは手動インストールが必要 その他: 手動インストールが必要 ssm-agentのインストール 13

Slide 14

Slide 14 text

1. ssm-agentのインストール 2. 適切なIAMロールポリシー 3. Session Manager Plugin 4. VPCエンドポイントとPrivateLink SessionManagerを使うために必要なこと... 14

Slide 15

Slide 15 text

AmazonEC2RoleforSSMは将来的に非推奨になる AmazonSSMManagedInstanceCoreはSSMに関するアクションを兼ね揃えている SessionManagerに限ったインスタンスプロファイルを作成 適切なIAMロールポリシー https://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/session-m anager-getting-started-instance-profile.html 15

Slide 16

Slide 16 text

1. ssm-agentのインストール 2. 適切なIAMロールポリシー 3. Session Manager Plugin 4. VPCエンドポイントとPrivateLink SessionManagerを使うために必要なこと... 16

Slide 17

Slide 17 text

ローカルからSessionManager経由でインスタンスにログインする為に必要 Windows、macOS、Linux、Ubuntuで利用可能 aws ssm start-session --target i-08c9cxxxxxxxxxxxx 接続先を指定するにはインスタンスIDを使う必要がある Session Manager Plugin https://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/session-m anager-working-with-install-plugin.html 17

Slide 18

Slide 18 text

1. ssm-agentのインストール 2. 適切なIAMロールポリシー 3. Session Manager Plugin 4. VPCエンドポイントとPrivateLink SessionManagerを使うために必要なこと... 18

Slide 19

Slide 19 text

VPCエンドポイントとPrivateLinkの例 VPCエンドポイント VPC内からVPC外のサービスにアクセスする為に使用 SessionManagerの場合、S3へログの書き出しがある為、 VPCエンドポイントとしてS3が必要 加えて、SessionManagerのエンドポイントとして PrivateLinkの設定が必要 ※NAT Gatewayでも可能 PrivateLink ルートテーブル 19

Slide 20

Slide 20 text

VPCエンドポイントとPrivateLinkの例 Public Subnet Private Subnet 20

Slide 21

Slide 21 text

SessionManagerのhistory 「いつ」「だれが」「どのインスタンスで」「なにをしたのか」 ISMS監査で必要になる トラブル時の原因追求のサポート 21

Slide 22

Slide 22 text

CloudWatchLogsのフィルタと組み合わせる CloudWatchLogs SNS Lambda CloudWatchLogsでフィルタし、特定のコマンド(文字列)がヒットしたら SNS、Lambda、Alartを呼びだし通知 する事ができる 例えば、sudoコマンドを実行されたら通知したいなど Alarm 22

Slide 23

Slide 23 text

It describes the major challenge here. SessionManagerと IAMを組み合わせる 23

Slide 24

Slide 24 text

● SessionManagerでログインした時のユーザーを変えたい ○ デフォルトのユーザーはssm-userになるので指定したい ● インスタンス毎にログインできるIAMユーザーを指定したい ○ ユーザーAはtag: Production、ユーザーBはtag: Developと分けたい SessionManagerとIAMを組み合わせる 24

Slide 25

Slide 25 text

1. SessionManagerの設定画面でRun As supportを有効にする 2. IAMユーザー/ロールのタグにKey:SSMSessionRunAsを追加し、ValueにOSのユー ザーを指定する SessionManagerでログインするユーザーは変えられる https://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/session-pr eferences-run-as.html 25

Slide 26

Slide 26 text

SessionManagerでログインするユーザーは変えられる 26

Slide 27

Slide 27 text

SessionManagerでログインするユーザーは変えられる IAMユーザー/IAMロールのTagsに追加 ValueにSessionManagerでログインするユーザー名を指定 このユーザーはOSに作成しておく必要がある 27

Slide 28

Slide 28 text

インスタンス毎にログインできるIAMユーザーを指定する Deny Allow Allow Allow Name:Production Name:Develop UserA UserB 28

Slide 29

Slide 29 text

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": ["ssm:StartSession"], "Resource": "*", "Condition": { "StringLike": { "ssm:resourceTag/Name": ["Production"], "ssm:resourceTag/Name": ["Develop"] } } } ] } インスタンス毎にログインできるIAMユーザーを指定する https://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/getting-started-restrict-acc ess-examples.html { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": ["ssm:StartSession"], "Resource": "*", "Condition": { "StringLike": { "ssm:resourceTag/Name": ["Develop"] } } } ] } UserA UserB 29

Slide 30

Slide 30 text

● SSHの鍵管理の作業から開放 ● パブリックにSSHポートを開く必要が無いのでセキュリティ向上に繋がる ● IAMと組み合わせる事で「だれが」「どのインスタンスで」「なにをしたのか」がわかる ● IAMユーザー/ロールを見ればどのユーザーでログインできるのか、どのインスタンスにログインできるかわかる SessionManagerを使うと... 30

Slide 31

Slide 31 text

It describes the major challenge here. マルチアカウントとSSO 31 TIPS

Slide 32

Slide 32 text

単一のアカウントだと管理するアカウントが一つなので運用が楽になる一方、以下のような 問題が起こるケースがある ● 本番環境と開発環境がアカウント内に共存している為、オペミスで本番環境へ影響を 与える可能性がある ● ガバナンスの観点から本番環境を閲覧できるユーザーを絞るのが大変 なぜマルチアカウント... 32

Slide 33

Slide 33 text

マルチアカウントのメリットは以下の通り ● 本番環境と開発環境がアカウント単位で分かれるのでお互いの環境に影響を与えるこ とが少なくなる(権限管理をしっかりしないとゼロにはならない) ● ガバナンスの観点から本番環境、開発環境へアクセスできるユーザー管理がしやすく なる 詳しくは以下の資料が参考になります https://www.youtube.com/watch?v=vVt60Ja7nEk https://d0.awsstatic.com/events/jp/2017/summit/slide/D4T2-2.pdf 33 マルチアカウントのメリット

Slide 34

Slide 34 text

マルチアカウントのデメリットは以下の通り ● アカウントが増えることによって構築コストが増える ● 支払い管理が煩雑になる ● アカウント作成のコストが高い マルチアカウントのデメリット 34

Slide 35

Slide 35 text

”AWS でのワークロードを拡大しスケールするときに、 AWS Organizations は環境の一元管理に役立ちま す。成長しているスタートアップでも、大規模な企業でも、 Organizations があれば、請求の一元管理や、ア ク セス、コンプライアンス、セキュリティの制御、 AWS アカウント間でのリソースの共有ができます。 AWS Organizations を使用すると、アカウントの作成を自動化し、ビジネスニーズを反映したアカウントのグ ループを作成し、それらのグループにポリシーを適用して管理できます。 すべての AWS アカウントに対して単 一の支払い方法を設定すれば、請求を簡単にすることもできます。他の AWS のサービスと統合して Organizations を使用すれば、組織のアカウント全体の設定とリソース共有を一元的に定義できます。すべ ての AWS のお客様は、追加料金なしで AWS Organizations を利用できます。” 35

Slide 36

Slide 36 text

● 複数アカウントの一元管理 ● AWSアカウント管理の自動化 ● 請求の簡素化(Consolidated Billing) つまりこんなことができる… 36

Slide 37

Slide 37 text

● 組織 ● マスターアカウント ● ルート ● 組織単位(Organizations Unit) ● アカウント ● ServiceControllPolicy(SCP) AWS Organizationsの概要図 https://docs.aws.amazon.com/ja_jp/organizations/latest/userguide/orgs_getting-s tarted_concepts.html 37

Slide 38

Slide 38 text

組織の中にルート、OU、アカウントなどが含まれる 1つのAWSアカウントが複数の組織のメンバーになることはできない 組織/AWS Organizations 38

Slide 39

Slide 39 text

組織にアカウントを作成、招待、削除、招待管理、ポリシー適応が出来る マスターアカウント/AWS Organizations マスターアカウント 39

Slide 40

Slide 40 text

組織のすべてのアカウントが設定された親コンテナポリシーをルートに適用する場 合は、組織内のすべてのOUとアカウントに適用される ルート/AWS Organizations 40

Slide 41

Slide 41 text

OUの枝があり、先端にツリーの葉であるアカウントが紐づく OUは厳密に親を1つ持つ事ができ、現在各アカウントを厳密に1つのOUメンバーにする事が できる 組織単位(OU)/AWS Organizations 41

Slide 42

Slide 42 text

マスターアカウント以外のアカウントをメンバーアカウントと呼ぶ アカウントが組織のメンバーになる事ができるのは一度に1つのみ(OUも同様) アカウント/AWS Organizations 42

Slide 43

Slide 43 text

組織内のすべてのアカウントの最大使用アクセス権限を一元的に管理できる機能 SCPとアカウント内のIAMポリシー、両方で許可されているアクションが実行可能 SCP/AWS Organizations 43

Slide 44

Slide 44 text

SCP SCP/AWS Organizations Allow: S3:* Allow: SQS:* Allow: S3:* Allow: EC2:* IAM(アカウント内) SCPとIAMで指定されている S3へのアクションのみ実行可能 一致していないEC2への アクションは実行不可能 44

Slide 45

Slide 45 text

AWS Organizationsを使った例 Admin/OU Service/OU Sandbox/OU Audit Custodian API/Prod API/Dev Developer Sandbox Organization 45

Slide 46

Slide 46 text

Custodianアカウントの使用例 Admin/OU Service/OU Sandbox/OU Audit API/Prod API/Dev Developer Sandbox Organization Custodian OUにAdminを作成し、管理関係のアカウントを Admin配下に作成する CustodianアカウントにてIAMユーザーの管理を行い、 Admin他、Service、 SandboxへのログインはCustodianを経由する 46

Slide 47

Slide 47 text

クロスアカウントアクセス あるアカウントのユーザーと別のアカウントのロール を紐付け、別のアカウントへログインしたり、ロールに 紐づくアクションを実行できる IAMユーザーはCustodianにのみで管理 他のアカウントに関しては Switchロールでログインす る IAMユーザーを各アカウント毎に用意する必要が無く なる Custodian経由で各アカウントへログイン マスターアカウント Custodian Audit API / Prod API / Dev Developer 47

Slide 48

Slide 48 text

マルチアカウント + SSO(GSuite) GSuite マスターアカウント Custodian Audit API / Prod API / Dev Developer マスターアカウントの管理用ロールへ Switch(一部のユーザー) 一般ユーザーのルート ● 管理ユーザーはマスターアカウントと Custodianにある IAMロールのarnを設定 ● 一般ユーザーは CustodianにあるIAMロールのarnを設 定 48 管理ユーザー 一般ユーザー

Slide 49

Slide 49 text

● AWSOrganizationsを使えば複数アカウントの一元管理、アカウント管理の自動化が 図れる ● SSOを使うことでIAMユーザーを増やすことがなくIAMロールで完結する ● IdP側でユーザーとロールのarnを管理するのではなく、Custodian側をコード管理す るとわかりやすい マルチアカウント + SSOで出来ること 49

Slide 50

Slide 50 text

It describes the major challenge here. まとめ 50

Slide 51

Slide 51 text

SessionManagerを使うことでSSH鍵の登録作業が解決 作業ログの取得、フィルタによる検知が可能 IAMと組み合わせることでアクセス可能なインスタンスのコントロールが可能 まとめ 51 マルチアカウントによってガバナンスの向上が可能 一方、ガバナンスと利便性のバランスが課題になる 普段の業務で使っているツールと組み合わせできるのかは要検証

Slide 52

Slide 52 text

It describes the major challenge here. ご清聴ありがとうございました 52