(C) Recruit Technologies Co.,Ltd. All rights reserved. 大規模AWS共通基盤上の 発見的統制への挑戦

(C) Recruit Technologies Co.,Ltd. All rights reserved. 発表者紹介 1 河村 聖悟 リクルートテクノロジーズ ITインテグレー ション本部 サイトリライアビリティエンジニアリング部 シニアマネジャー 宮崎 幸恵 リクルートテクノロジーズ ITインテグレー ション本部 サイトリライアビリティエンジニアリング部

(C) Recruit Technologies Co.,Ltd. All rights reserved. 本日の内容について 1. リクルートテクノロジーズのAWS基盤について 2. アイデンティティとアクセス管理の実装について 3. インフラストラクチャ保護とネットワーク設計 4. 発見的統制のこれまでと実装 5. AWS ControlTowerでのLandingZoneとガードレールの実装 6. 全体のまとめ 2

(C) Recruit Technologies Co.,Ltd. All rights reserved. リクルートテクノロジーズの AWS基盤について 3

(C) Recruit Technologies Co.,Ltd. All rights reserved. リクルートテクノロジーズのインフラ基盤について  リクルートテクノロジーズでは、大きく2つのサービス向けインフ ラを運用しています 4 オンプレミス基盤 RAFTEL クラウド基盤 Rクラウド 共通インフラ運用 クラウド運用 サーバ構築

(C) Recruit Technologies Co.,Ltd. All rights reserved. AWS基盤としての対応範囲  責任共有モデルで、ユーザー側の責任範囲となっている一部を共通 提供しています 5

(C) Recruit Technologies Co.,Ltd. All rights reserved. AWS基盤について  2012年ごろから共通クラウド基盤としてAWSを整備しています  現在500弱のアカウントを管理しています 6 2012年 2014年 2016年 2018年 オンプレミス基盤 との接続 共通認証基盤整備 システムセキュリティ 強化施策実施 ネットワーク設計 見直し ログ監査システム 実装

(C) Recruit Technologies Co.,Ltd. All rights reserved. AWSのアカウント構造について  共通提供機能はほぼ一つのアカウントに集約しており、各アカウン トに接続をしています 7 AWS Cloud VPC VPC VPC 認証/認可機能 システム セキュリティ機能 ログ集約 監査機能 AWS Cloud 共通提供機能アカウント 各サービスアカウント ×~500アカウント AWS Cloud AWS Cloud AWS Cloud AWS Cloud AWS Cloud AWS Cloud AWS Cloud AWS Cloud AWS Cloud AWS Cloud AWS Cloud AWS Cloud AWS Cloud AWS Cloud AWS Cloud AWS Cloud AWS Cloud ・ ・ ・・・

(C) Recruit Technologies Co.,Ltd. All rights reserved. Well-Architected フレームワーク5本の柱  Well-Architectedフレームワークの5本の柱のセキュリティの中で も以下3観点を中心とした実装事例を本日はお話しします 8 運用上の 優秀性 セキュリティ 信頼性 パフォーマ ンス効率 コスト 最適化 アイデン ティティと アクセス管 理 発見的統制 インフラス トラクチャ 保護 データ保護 インシデン ト対応

(C) Recruit Technologies Co.,Ltd. All rights reserved. アイデンティティとアクセス管理 の実装について 9

(C) Recruit Technologies Co.,Ltd. All rights reserved. アイデンティティとアクセス管理について  2012年当初は各ユーザーをIAMユーザーで認証/管理していました が、2014年ごろにロールでのフェデレーションユーザーに統合し ました  その後さらに別のIDプロバイダーに認証統合しています 10 AWS Identity and Access Management (IAM) AWS Cloud AWS Management Console VPC Amazon EC2 IdP VPC 認可プロキシ 踏み台 AWS Management Console Ldap VPC

(C) Recruit Technologies Co.,Ltd. All rights reserved. リソースの認可：IAMでの制限  IAMの権限はAction単位で制御していた時もありましたが、その後 はよりシンプルに整備しました 11 ope dev adm SuperAdm Master より強い権限 インフラ基盤Tが利用 利用ユーザーに許可し ている最高権限 一般的な管理権限 サービスを限定した操 作権限 ほぼリソース閲覧のみ

(C) Recruit Technologies Co.,Ltd. All rights reserved. アイデンティティとアクセス管理について  AWSには役割ごとのIAMロールのみを作成し、ロールをIDプロバイ ダーに渡し、IDプロバイダー側でユーザー紐づけを行うことで、不 要なログインユーザーがAWSに残留するリスクを低減しています 12 Role User Miyazaki ロールをIdPに渡す Rcloud_role_SuperAdm Rcloud_role_Master Rcloud_role_Adm Rcloud_role_Dev Rcloud_role_Ope AWS Management Console AWS STS AWS Cloud ID Provider Rcloud_role_Master User Miyazakiに 紐づく情報 SAML assertion

(C) Recruit Technologies Co.,Ltd. All rights reserved. アイデンティティとアクセス管理について  アクセスを許可するグルーピングに基づき、ユーザーごとにVPC単 位でのアクセスを制御しています 13 VPC 認可プロキシ 踏み台 ユーザー管理 認証サーバ VPC Amazon EC2 VPC VPC VPC User Miyazaki, Rcloud_cmn_VPC AWS Cloud User Miyazaki

(C) Recruit Technologies Co.,Ltd. All rights reserved. アイデンティティとアクセス管理について  認証機能では認証/認可要件とログ取得を重点的に実装しています  その他ユーザーの利便性や運用容易性も要件としては含めています ユーザーIDの一元管理 操作ログの集約 アクセスログの集約 他基盤との認証一元化：ユーザー利便性の向上、運用容易性 14 インフラ基盤要件

(C) Recruit Technologies Co.,Ltd. All rights reserved. インフラストラクチャ保護ならびに ネットワーク構成 15

(C) Recruit Technologies Co.,Ltd. All rights reserved. ネットワーク構成について  VPCが数百～以上あるにも関わらず、共通機能を一つのアカウント /複数VPCに集約していることから、ネットワーク構成は非常に複 雑化しています VPC同士の1:1の場合はVPC Peeringを利用 オンプレミスとの接続はDirect ConnectもしくはVPN接続 VPCをまたいだ通信はルーターを独自配置 16

(C) Recruit Technologies Co.,Ltd. All rights reserved.  構成の中でも特に複雑化していたVPNやVPCをまたいだ接続箇所に ついては、Transit Gatewayへの置き換えを進めています Transit Gatewayでの集約検討 17 ・ ・ ×70VPC～ ×9VPC 認証基盤 監視機能 システムセキュリティ機能 認可プロキシ VPCpeering ・ ・ ×60VPC～ ×200VPC～ オン プレ ミス 環境 ・ ・ ×70VPC～ ×9VPC 認証基盤 監視機能 システムセキュリティ機能 認可プロキシ VPCpeering ×60VPC～ ×200VPC～ オン プレ ミス 環境 Transit Gateway Direct Connect利用のAWS 内通信を集約 Transit Gateway VPN利用AWS内通信を集約 Transit Gateway VPN利用VPCを集約

(C) Recruit Technologies Co.,Ltd. All rights reserved. Transit Gateway利用のメリット  複数のVPC間の通信をTransit Gatewayで集約することで、より厳 密に経路を限定することができます  複数アカウントにまたがるVPCを管理している場合は、意図せぬ経 路を作らないためにも、非常に有効な手段です 18

(C) Recruit Technologies Co.,Ltd. All rights reserved. ここまでのまとめ  複数アカウント、数千人のユーザー管理を当初から想定し、認証機 能とIDは管理を統合してきました  IAMでのリソース制限はしておりますが、利用初期よりはシンプル な役割単位での定義にしています  認可機能はEC2を利用した実装をしています  共通機能のネットワーク構成はVPCの多さから複雑化していますが、 Transit Gatewayへの移行により、意図せぬ接続のリスク減ととも に、運用容易性も向上しつつあります 19

(C) Recruit Technologies Co.,Ltd. All rights reserved. 発見的統制のこれまでと実装 20

(C) Recruit Technologies Co.,Ltd. All rights reserved. 監査手法の検討について  インフラ基盤観点で利用ユーザーに実施させたくない操作、また自 動で作成されるが、利用されたくない設定についての対策を初期よ り検討してきました 2014年～2015年ごろまではIAMでかなり厳密にユーザーの操作権限を制限 その後徐々に付与権限管理を緩和するとともに、望ましくない操作の検知とア クション実行する方式に移行 21

(C) Recruit Technologies Co.,Ltd. All rights reserved. 実装方式の変遷  2014年ごろまではEC2を使った単純な検知の仕組みのみでしたが、 2015年～2016年にはAWS Configでの検知を実装していました  その後2017年以降からは徐々にCloudWatchEventのRuleを使った 検知とLambdaでのアクション実行へ変更しました 22 2012年 2014年 2016年 2018年 AWS Identity and Access Management (IAM) Amazon EC2 AWS Config AWS CloudTrail AWS Lambda Amazon CloudWatch Rule

(C) Recruit Technologies Co.,Ltd. All rights reserved. 初期の実装  前提として望ましくない操作はIAMでActionを厳密に制限します  その上で設定値を定期的に確認し、自動的に排除する仕組みとして いました 23 AWS Identity and Access Management (IAM) User Miyazaki Elastic Beanstalkの操作 権限を付与されています Instance Security group AWS Elastic Beanstalk Instance 自動で作成されたSecurity Groupに 望ましくないルールがあります 監査サーバ 定期的にチェックし、設定を削除 します

(C) Recruit Technologies Co.,Ltd. All rights reserved. AWS Configでの実装  AWS Configのリリース後はAWS Configでカスタムルールを実装 し、ルールに該当したものを通知し、Lambdaを使って削除する実 装に変更しました 24 AWS Config カスタムルールを設定し ます AWS Lambda 変更を検知したら Lambdaを呼びます 望ましくない設定を削除 するアクションを実行し ます AWS Lambda

(C) Recruit Technologies Co.,Ltd. All rights reserved. AWS Configでの実装  AWS Configを使う場合、いくつか課題があり、その後 CloudWatchイベントを使った実装へ変更しています 複数アカウントで同じカスタムルールの維持が必要 ActionはLambdaで動かすことになりLambdaの同時起動上限数に苦戦 Configだけでは操作したユーザー名が取れず、CloudTrailと組み合わせ る必要があったため、処理が複雑化 検知までの時間がかかった  2018年にAWS Configはマルチアカウント、マルチリージョンで のデータ集約機能がでていますので、今は複数アカウントでの利用 もしやすくなっています 25

(C) Recruit Technologies Co.,Ltd. All rights reserved. CloudWatchとLambdaを利用した実装  ユーザーアカウントではActionのみを渡すLambdaを用意します 26 AWS Cloud CloudWatch rules Lambda Lambda Lambda Lambda Lambda Lambda AWS Cloud CloudWatch rules Lambda ・ ・ ・ us-east-1 us-east-1 us-west-2 us-west-2 ap-northeast-1 Ticket 共通機能アカウント Mail/Chattool ユーザーアカウント ・ ・ ・ ×Region Lambda function of each action ×Region

(C) Recruit Technologies Co.,Ltd. All rights reserved. CloudWatchとLambdaを利用した実装  ユーザーアカウントからのAction通知を受け取るLambdaは1:1と なります  これは全てのユーザーアカウントで同一設定を入れたいためになり ます 27 Lambda Lambda Lambda AWS Cloud ユーザーアカウント 共通機能アカウント １：１ １：多 Lambda Lambda アクション単位でLambda を用意しています

(C) Recruit Technologies Co.,Ltd. All rights reserved. 検知と実行について  Criticalのアクションの場合は、チケットへ自動起票がされ、通知の みの場合は、チャットへの通知のみとなります  検知したアクションはかならず以下のどちらかの対応となります 確認せずに自動修正（設定削除など）されるタイプのアクション 基盤運用メンバが内容をチェックし、操作実行者への確認をしてから対 処を決めるアクション 28 チケット起票 通知 Lambda 設定は自動修正さ れて結果のみ通知 操作ユーザーに意 図を確認する

(C) Recruit Technologies Co.,Ltd. All rights reserved. EC2での実装について  EC2からのプログラム実行機能を残しています  監査に利用しているLambdaそのものを削除される場合の対策や、 定期実行するような操作については、EC2上のプログラムで実行し ています 29 Instance 監査サーバ Lambda AWS Cloud ユーザーアカウント ユーザーアカウントに配置している Lambdaが変更されたり削除されて いないかを監視

(C) Recruit Technologies Co.,Ltd. All rights reserved. IAMでの権限制限  明確に変更されたくない設定については、IAMの権限で対応してい ます CloudTrailのように設定変更自体をさせたくないリソースはIAMで制限してし まったほうがベター 30

(C) Recruit Technologies Co.,Ltd. All rights reserved. 監査とモニタリング  インフラ基盤として明らかに望ましくない設定が排除できていれば 問題ないため、監査については設定の一覧やリソース取得などのモ ニタリングはしていません  利用ユーザー側にも実行の詳細も含めて見せておらず、要確認の Actionがあったときのみ通知しています  運用上は、Lambdaによって起票されたチケットで確認しています 31

(C) Recruit Technologies Co.,Ltd. All rights reserved. 監査機能としての課題  複数アカウントへの同一Lambdaの配置、維持が必要なため、常時 別の手段（現在はEC2上のプログラム）の監視が必要  最終的なActionまで決めているNG項目のみ基盤側では対応してい ますが、人による確認には時間がかかりがちです 32

(C) Recruit Technologies Co.,Ltd. All rights reserved. ここまでのまとめ  現状の監査機能はCloudWatch、Lambda、EC2での実装です  検知後のアクションもすべて決めて運用しています  複数アカウントでの同一設定の維持管理と、人での運用作業が運用 工数増につながりがちで、この2点に課題が残っています 33

(C) Recruit Technologies Co.,Ltd. All rights reserved. AWS ControlTowerでの LandingZoneとガードレールの実装 34

(C) Recruit Technologies Co.,Ltd. All rights reserved. AWS基盤でのガードレールの考え方  AWS基盤ではこれまで独自に2つのガードレールとなり得る基準を もって設計/運用してきました 1. システム基盤設計上ユーザーでの自由な設計が許容できないもの ネットワークにかかわる設定（VPC、VPN、DirectConnectなど）  システムリスクの回避 システム上明らかにリスクのある設定（S3のPubket Policyなど） IDと認証にかかわる設定 35

(C) Recruit Technologies Co.,Ltd. All rights reserved. ガードレールの実現手段としてのControl Tower  AWSのマネージド機能では、AWS Control Towerでガードレール の概念が実装されています  AWS Control Towerには大きくLanding Zoneとガードレールの2 つの機能が含まれています 36 AWS Control Tower ガードレール  必須のガードレール  推奨のガードレール  選択的ガードレール Landing Zone

(C) Recruit Technologies Co.,Ltd. All rights reserved. Landing Zoneと現状の実装の対応 37  現状の実装と、AWS Control Towerが定義するLanding Zoneを比 較しましたが、相当する実装はほぼすべて完了しています  Landing ZoneはControl Towerでは3アカウント設定されますが、 実装では一つで運用しています AWS CloudFormation ▲ AWS Organizations 〇 AWS Service Catalog ▲ AWS CloudTrail 〇 Amazon CloudWatch 〇 AWS Identity and Access Management 〇 AWS シングルサインオン 〇 AWS SNS 〇 AWS Lambda 〇 AWS S3 〇

(C) Recruit Technologies Co.,Ltd. All rights reserved.  必須のガードレールについてもほぼ実装しています 必須ガードレールとの対応 38 ログアーカイブの保管時に暗号化を有効にする ー ログアーカイブのアクセスログを有効にする 〇 ログアーカイブのポリシー変更を禁止する 〇 ログアーカイブへのパブリック読み取りアクセスを禁止する 〇 ログアーカイブへのパブリック書き込みアクセスを禁止する 〇 ログアーカイブの保持ポリシーを設定する 〇 CloudTrail の設定変更を禁止する 〇 CloudTrail イベントと CloudWatch ログを統合する 〇 利用可能なすべてのリージョンで CloudTrail を有効にする 〇 CloudTrail ログファイルの整合性の検証を有効にする 別手段にて代替 AWS Control Tower によって設定された CloudWatch の変更を禁止する ※相当の設定変更は不可 AWS Control Tower によって設定された AWS Config の集計の変更を禁止する ※相当の設定変更は不可 AWS Config の設定変更を禁止する 〇 利用可能なすべてのリージョンで AWS Config を有効にする ▲ AWS Control Tower によって設定された AWS Config ルール の変更を禁止する ※相当の設定変更は不可 AWS Control Tower によって設定された IAM ルールの変更を禁止する ※相当の設定変更は不可 AWS Control Tower によって設定された Lambda 関数の変更を禁止する ※相当の設定変更は不可 AWS Control Tower によって設定された Amazon SNS の変更を禁止する ※相当の設定変更は不可 AWS Control Tower によって設定された Amazon SNS サブスクリプションの変更を禁止する ※相当の設定変更は不可

(C) Recruit Technologies Co.,Ltd. All rights reserved. AWS Control Towerの使いどころ  既に利用が進んでいる場合であれば、AWS Control Tower相当の 実装は実現できている可能性が高いです Cloudtrailは全アカウント必須、IDプロバイダーでID管理 など  新規にAWSの利用を進める場合にランディングゾーンやガードレー ルの考え方は参考になると考えられます  既にAWSを利用し、ある程度運用ができあがっている場合でも不足 している観点がないかどうかのチェックに使うことができます 39

(C) Recruit Technologies Co.,Ltd. All rights reserved. 全体のまとめ  AWSのサービスアップデートに準じてその時々で最適と考えられる 方式に更改してきました  結果的にAWS Well-Architectedや、その手段のひとつであるAWS Control Towerのベストプラクティスに沿った実装になっています  継続的にフルマネージドサービスの活用検討を進め、現運用課題の 解決と運用効率の最大化を模索し続けたいと考えています 40

(C) Recruit Technologies Co.,Ltd. All rights reserved. ご清聴ありがとうございました 41