AWS Config による継続的コンプライアンス実現に向けた取り組み

AWS Config による 継続的コンプライアンス 実現に向けた取り組み 2020/11/24 Security-JAWS #19 株式会社ビズリーチ（Visionalグループ） Yuuki Nagahara 1

自己紹介 長原 佑紀（ナガハラ ユウキ） 所属：株式会社ビズリーチ（Visionalグループ） システム本部 プラットフォーム基盤推進室 経歴：SIer → 株式会社ビズリーチ 好きなAWSサービス：AWS Lambda 2

アジェンダ ● グループ・会社紹介 ● はじめに ● 導入背景の課題 ● AWS Config について ● AWS Config 導入事例 ● まとめ 3

グループ・会社紹介 4

グループ概要 設立 ：2020年2月（ビジョナル株式会社設立） 創業 ：2009年4月（株式会社ビズリーチ創業） 代表者 ：ビジョナル株式会社 代表取締役社長 南 壮一郎 グループ従業員数：1,370名（2020年7月末時点） 資本金 拠点 ：49億4,302万円（資本剰余金含む）※2020年10月31日時点 ：東京、大阪、名古屋、福岡 5

グループミッション 6

グループ経営体制について 株式会社 ビズリーチ ビジョナル ・ インキュベーション 株式会社 株式会社 スタンバイ BINAR 求人検索エンジン 「スタンバイ」 の運営 ハイスキル ITエンジニア 転職プラットフォーム 「BINAR」の運営 株式会社 HR Techの プラットフォーム・ SaaS事業の運営 新規事業開発 ※Zホールディングス株式会社 との合弁事業会社 トラボックス 株式会社 国内最大級の物流DX プラットフォーム 「TRABOX（トラボック ス）」 の運営 ビジョナル株式会社（ホールディングカンパニー） 7

所属組織について 運営サービス システム本部 プラットフォーム基盤推進室 （株式会社ビズリーチ に帰属） グループのクラウド / SaaS 全体管理、CCoE（Cloud Center of Excellence）活動、 クラウド共通のプラットフォーム開発・運用 8

はじめに 9

本日の発表内容 今年9月の AWS Summit Online Japan 2020 で発表 させていただいた「大規模な組織変遷と100以上の AWSアカウントの横断的セキュリティガードレール運用 について」の AWS Config にフォーカスした内容です。 Visional Engineering Blog「100を超えるAWSアカウ ント運用におけるガードレール構築事例」 にて、発表の 詳細記事を公開しています。 10

• https://pages.awscloud.com/rs/112-TZM-766/images/CUS-06_AWS_Summit_Online_2020_Visional Inc.pdf
• https://engineering.visional.inc/blog/171/awssummit_securityguardrail/

導入背景の課題 なぜこの取り組みを始めたのか 11

Through 2025, 99% of cloud security failures will be the customer’s fault. source: Gartner 2025年には、クラウドセキュリティの事故の 99％ は カスタマーに起因するものとなります。 12

• https://www.gartner.com/smarterwithgartner/is-the-cloud-secure/

責任共有モデル customer’s fault target カスタマーが責任を負う範囲を適切に管理・運用することが重要 13

導入背景の課題 グループ全体で数多くの AWS アカウントを運用する中で、クラウドのセ キュリティや信頼性に関わる設定不備や考慮不足などの不適切な管理 ・運用によるセキュリティインシデントやサービス障害が過去に度々発 生していました。 主な原因 ● 各部署のエンジニアの増加・多様化によるクラウドスキルのバラツキ ● 部署によって非機能要件に対して求めるレベルや優先度が異なる ● 人による作業のため作業のミスや考慮漏れを防ぎきれない ● 社内のクラウド利用に関するポリシーの整備が不十分 14

導入背景の課題 課題解決に向け、グループ全体でサービス開発・運用におけるポリシーを定め、 チェックリストで評価して改善する取り組みを開始（2018-） ● ● 半年周期及び新規サービスはローンチ前に評価 内包して、システムの脆弱性診断、OSSの脆弱性ス キャンを定期的に実施 チェックリストによって、全てのサービスを正確かつ適切にチェックするのは困難 ● ● ● ● 担当部署のセルフチェックで実施するため、評価対象・基準の揺れが発生 人手によるチェックのため、誤りや見落としが存在 各部署にてチェックを行うことで、多くの工数が必要 動的に変更されるシステムの特定時点をチェックするため、問題検出の見逃しや遅延が発生 15

ソリューション クラウドのリソースマネジメントやコンフィグレーションの範囲を対象に、 チェックを自動化し、継続的モニタリングを実施する チェックの 正確性、 リアルタイム性、 効率性 を向上を狙う チェックリスト 項目レイヤー チェック項目抽象度 組織 プロセス 高 プラクティス アーキテクチャ 【アプリケーション】 インプリメンテーション ライブラリ 【クラウド】 リソースマネジメント コンフィグレーション 低 チェックに不適合な箇所を検出後、適切に是正措置を取るプロセスを構築することで ”継続的コンプライアンス” の実現を目指す 16

AWS Config について 簡単におさらい 17

AWS Config AWS リソースの設定を記録・評価する AWS サービス AWS Config では、リソースの設定が継続的に記録され、設定したルールに基づきリソースの設 定を自動的に評価。修復アクションを設定することでリソースの自動修復も可能。 18

AWS Config: Config Rules マネージドルール AWS により提供される定義済みの評価ルール カスタムルール カスタムで評価ロジックを作成できる独自定義の評価ルール ※AWS Lambdaで実装 ■ マネージドルール「vpc-sg-open-only-to-authorized-ports」の評価イメージ VPC の SG （セキュリティグループ）にて、認可されたポート以外は送信元がフルオープン（0.0.0.0/0）でないことを 評価するルール 【例】認可ポート＝ 80, 443 の場合 ● sg1: inbound 0.0.0.0/0 port 443 allow → COMPLIANT（準拠） ● sg2: inbound 10.10.0.0/16 port 22 allow → COMPLIANT（準拠） ● sg3: inbound 0.0.0.0/0 port 22 allow → NON_COMPLIANT（非準拠） 19

AWS Config: Config Rules マネージドルールの一覧（164ルールが利用可能 ※2020.11時点） iam-inline-policy-blocked-kms-actions iam-customer-policy-blocked-kms-actions access-keys-rotated account-part-of-organizations acm-certificate-expiration-check alb-http-drop-invalid-header-enabled alb-http-to-https-redirection-check alb-waf-enabled api-gw-cache-enabled-and-encrypted api-gw-endpoint-type-check api-gw-execution-logging-enabled approved-amis-by-id approved-amis-by-tag autoscaling-group-elb-healthcheck-required cloudformation-stack-drift-detection-check cloudformation-stack-notification-check cloudfront-default-root-object-configured cloudfront-origin-access-identity-enabled cloudfront-origin-failover-enabled cloudfront-sni-enabled cloudfront-viewer-policy-https cloud-trail-cloud-watch-logs-enabled cloudtrail-enabled cloud-trail-encryption-enabled cloud-trail-log-file-validation-enabled cloudtrail-s3-dataevents-enabled cloudtrail-security-trail-enabled cloudwatch-alarm-action-check cloudwatch-alarm-resource-check cloudwatch-alarm-settings-check cloudwatch-log-group-encrypted cmk-backing-key-rotation-enabled codebuild-project-envvar-awscred-check codebuild-project-source-repo-url-check codepipeline-deployment-count-check codepipeline-region-fanout-check cw-loggroup-retention-period-check dax-encryption-enabled db-instance-backup-enabled desired-instance-tenancy desired-instance-type dms-replication-not-public dynamodb-autoscaling-enabled dynamodb-in-backup-plan dynamodb-pitr-enabled dynamodb-table-encrypted-kms dynamodb-table-encryption-enabled dynamodb-throughput-limit-check ebs-in-backup-plan efs-in-backup-plan ec2-ebs-encryption-by-default ebs-optimized-instance ebs-snapshot-public-restorable-check ec2-instance-detailed-monitoring-enabled ec2-instance-managed-by-systems-manager ec2-instance-no-public-ip ec2-instances-in-vpc ec2-managedinstance-applications-blacklisted ec2-managedinstance-applications-required ec2-managedinstance-association-compliance -status-check ec2-managedinstance-inventory-blacklisted ec2-managedinstance-patch-compliance-statu s-check ec2-managedinstance-platform-check ec2-security-group-attached-to-eni ec2-stopped-instance ec2-volume-inuse-check efs-encrypted-check eip-attached elasticsearch-encrypted-at-rest elasticsearch-in-vpc-only elasticache-redis-cluster-automatic-backup-check ec2-imdsv2-check eks-endpoint-no-public-access eks-secrets-encrypted elasticsearch-node-to-node-encryption-check elb-cross-zone-load-balancing-enabled elb-tls-https-listeners-only elb-acm-certificate-required elb-custom-security-policy-ssl-check elb-deletion-protection-enabled elb-logging-enabled elb-predefined-security-policy-ssl-check emr-kerberos-enabled emr-master-no-public-ip encrypted-volumes fms-security-group-audit-policy-check fms-security-group-content-check fms-security-group-resource-association-check fms-shield-resource-policy-check fms-webacl-resource-policy-check fms-webacl-rulegroup-association-check guardduty-enabled-centralized guardduty-non-archived-findings iam-no-inline-policy-check iam-group-has-users-check iam-password-policy iam-policy-blacklisted-check iam-policy-in-use iam-policy-no-statements-with-admin-access iam-role-managed-policy-check iam-root-access-key-check iam-user-group-membership-check iam-user-mfa-enabled iam-user-no-policies-check iam-user-unused-credentials-check internet-gateway-authorized-vpc-only kms-cmk-not-scheduled-for-deletion lambda-concurrency-check lambda-dlq-check lambda-function-public-access-prohibited lambda-function-settings-check lambda-inside-vpc mfa-enabled-for-iam-console-access multi-region-cloudtrail-enabled rds-cluster-deletion-protection-enabled rds-instance-deletion-protection-enabled rds-instance-iam-authentication-enabled rds-logging-enabled redshift-backup-enabled rds-in-backup-plan rds-snapshot-encrypted redshift-require-tls-ssl rds-enhanced-monitoring-enabled rds-instance-public-access-check rds-multi-az-support rds-snapshots-public-prohibited rds-storage-encrypted redshift-cluster-configuration-check redshift-cluster-maintenancesettings-check redshift-cluster-public-access-check required-tags restricted-common-ports restricted-ssh root-account-hardware-mfa-enabled root-account-mfa-enabled s3-bucket-default-lock-enabled s3-default-encryption-kms securityhub-enabled sns-encrypted-kms s3-account-level-public-access-blocks s3-bucket-blacklisted-actions-prohibited s3-bucket-policy-not-more-permissive s3-bucket-logging-enabled s3-bucket-policy-grantee-check s3-bucket-public-read-prohibited s3-bucket-public-write-prohibited s3-bucket-replication-enabled s3-bucket-server-side-encryption-enabled s3-bucket-ssl-requests-only s3-bucket-versioning-enabled sagemaker-endpoint-configuration-kms-ke y-configured sagemaker-notebook-instance-kms-key-co nfigured sagemaker-notebook-no-direct-internet-ac cess secretsmanager-rotation-enabled-check secretsmanager-scheduled-rotation-succe ss-check service-vpc-endpoint-enabled shield-advanced-enabled-autorenew shield-drt-access vpc-default-security-group-closed vpc-flow-logs-enabled vpc-sg-open-only-to-authorized-ports vpc-vpn-2-tunnels-up waf-classic-logging-enabled wafv2-logging-enabled 20

AWS Config: Conformance Packs コンフォーマンスパック（適合パック） コンプライアンス基準や業界ベンチマークに関連したマネージドルール（+ 修復アクション）の集合体 コンフォーマンスパックの一覧（57 が利用可能 ※2020.11時点） AWS Control Tower Detective Guardrails Conformance Pack Operational Best Practices for ABS CCIG 2.0 Material Workloads Operational Best Practices for ABS CCIG 2.0 Standard Workloads Operational Best Practices for ACSC Essential 8 Operational Best Practices for ACSC ISM Operational Best Practices for AI and ML Operational Best Practices for Amazon DynamoDB Operational Best Practices for Amazon S3 Operational Best Practices for APRA CPG 234 Operational Best Practices for Asset Management Operational Best Practices for BCP and DR Operational Best Practices for BNM RMiT Operational Best Practices for CIS Top 20 Operational Best Practices for CMMC Level 1 Operational Best Practices for CMMC Level 2 Operational Best Practices for CMMC Level 3 Operational Best Practices for CMMC Level 4 Operational Best Practices for CMMC Level 5 Operational Best Practices for Compute Services Operational Best Practices for Data Resiliency Operational Best Practices for AWS Identity And Access Management Operational Best Practices for AWS Well-Architected Framework Reliability Pillar Operational Best Practices for AWS Well-Architected Framework Security Pillar Operational Best Practices for Databases Services Operational Best Practices for Data Lakes and Analytics Services Operational Best Practices for EC2 Operational Best Practices for Encryption and Key Management Operational Best Practices for Esquema Nacional de Seguridad (ENS) Low Operational Best Practices for Esquema Nacional de Seguridad (ENS) Medium Operational Best Practices for FDA Title 21 CFR Part 11 Operational Best Practices for FedRAMP(Low) Operational Best Practices for FedRAMP(Moderate) Operational Best Practices for FFIEC Operational Best Practices for HIPAA Security Operational Best Practices for K-ISMS Operational Best Practices for Load Balancing Operational Best Practices for Logging Operational Best Practices for Management and Governance Services Operational Best Practices for MAS Notice 655 Operational Best Practices for MAS TRMG June 2013 Operational Best Practices for Monitoring Operational Best Practices for NBC TRMG Operational Best Practices for NERC CIP Operational Best Practices for NCSC Cloud Security Principles Operational Best Practices for NCSC Cyber Assesment Framework Operational Best Practices for Networking and Content Delivery Services Operational Best Practices for NIST 800-53 rev 4 Operational Best Practices for NIST 800 171 Operational Best Practices for NIST CSF Operational Best Practices for NYDFS 23 Operational Best Practices for PCI DSS 3.2.1 Operational Best Practices for Publicly Accessible Resources Operational Best Practices for RBI Cyber Security Framework for UCBs Operational Best Practices for RBI MD-ITF Operational Best Practices for Security, Identity, and Compliance Services Operational Best Practices for Serverless Operational Best Practices for Storage Services 21

AWS Config: Config ダッシュボード AWS Config ダッシュボードで、リソースの構成記録やコンプライアンス状況を確認可能 記録された リソースの 構成情報 ルール及びリソースのコ ンプライアンス状況 ※ AWS Config ダッシュボード は、アカウント /リージョン単位で確 認が必要 非準拠ルールと 非準拠リソース数 ルール評価対象リソース個別の コンプライアンス状況 22

AWS Config: Config アグリゲータ マルチアカウント/マルチリージョンのデー タを集約するため、アグリゲータのアカウ ント/リージョンを設定することで、自動的 な集約と集約ビューの利用が可能 AWS Config Aggregate AWS Config AWS Config 23

AWS Config 導入事例 どのように AWS Config を導入し、活用しているのか 24

導入概要 前提情報 AWS 利用状況 ● AWS アカウント：100 以上 ● AWS リージョン：16 エンジニア組織 ● 組織：20 程度 ● エンジニア：250 名程度 ○ AWS 運用：100 名以上 25

実現したこと 1. ルール選定 導入 AWS 組織全体の 評価を行うまで 2. マルチアカウントセットアップ 3. ルールの管理・評価 4. 可視化 拡張・運用 5. 通知 実運用のための独自 拡張、運用について 6. 運用 26

実現したこと 1. ルール選定 導入 2. マルチアカウントセットアップ 3. ルールの管理・評価 4. 可視化 拡張・運用 5. 通知 6. 運用 27

1. ルール選定：選定方法 ① ② マネージドルール コンフォーマンスパック 個別のルール単位より選定 ルールの集合体より選定 自由にルールの選択が可能 ルールの調整が必要な場合は、 カスタムコンフォーマンスパックにす ることで、個別にルールの調整も可 能 セルフサービス ③ セキュリティ標準 セキュリティの標準より選定 規定のコントロール（ルール）の調整は、有効 化/無効化のみ可能 提供されているセキュリティ標準 - CIS AWS Foundations Benchmark - Payment Card Industry Data Security Standard (PCI DSS) - AWS 基本的なセキュリティのベストプラクティス マネージド 当社では、① マネージドルール の一覧よりルールを選定 ● ● ② コンフォーマンスパック は、選定時点（2019秋頃）は未提供であったため未検討 ③ セキュリティ標準 は、選定時点は CIS AWS Foundations Benchmark のみ提供で、一部項目が適応しないため見送り 28

1. ルール選定：選定ポイント マネージドルール：セキュリティ/信頼性に関わるグループ全社共通の準拠必須ルールを選定 ● 非準拠に対する例外の発生を避けるため 導入ルール一部抜粋 パブリックアクセス ● rds-snapshots-public-prohibited / RDSスナップショットパブリック禁止 ● ebs-snapshot-public-restorable-check / EBSスナップショットパブリック禁止 ● s3-bucket-public-write-prohibited / S3バケットパブリック書込禁止 ● lambda-function-public-access-prohibited / Lambda関数パブリックアクセス禁止 ● rds-instance-public-access-check / RDSインスタンスパブリックアクセス禁止 ● dms-replication-not-public / DMSレプリケーションパブリックアクセス禁止 ● redshift-cluster-public-access-check / Redshiftクラスタパブリックアクセス禁止 ● vpc-sg-open-only-to-authorized-ports / セキュリティグループ認証ポート外開放禁止 ROOT アカウント管理 ● iam-root-access-key-check / IAMルートユーザアクセスキー制限 ● root-account-mfa-enabled / RootアカウントMFA有効化 必須サービス有効化 ● guardduty-enabled-centralized / GuardDuty有効化 ● securityhub-enabled / SecurityHub有効化 ログ出力設定 ● cloudtrail-enabled / CloudTrail有効化 ● cloud-trail-log-file-validation-enabled / CloudTrailログファイル検証有効化 ● elb-logging-enabled / ELBロギング有効化 ● api-gw-execution-logging-enabled / API Gatewayロギング有効化 29

1. ルール選定：選定ポイント カスタムルール：以下の 3 つのケースを必要に応じて作成 ● マネージドルールに存在しない準拠必須のルール ○ 例：AMIのパブリック公開禁止 ● EBSスナップショットの共有と同様のリスクを抱えるため ● マネージドルールを独自仕様へ変更したルール ○ 例：VPC FlowLog ロギング有効化（ENI を保有する VPC のみ） ● 全リージョンのデフォルト VPC で大量の非準拠が検出されたため、ENI を保有する利用されているVPCのみロギ ングを必須とするため ● 社内ポリシーへの準拠を確認するルール ○ 例：IAM ユーザのログインプロファイル設定禁止 ● IAM ユーザでのマネージドコンソールアクセスを禁止する社内ポリシーを評価するため マネージドルール、及びカスタムルールとして、約 30 ルール を選定して導入 30

実現したこと 1. ルール選定 導入 2. マルチアカウントセットアップ 3. ルールの管理・評価 4. 可視化 拡張・運用 5. 通知 6. 運用 31

2. マルチアカウントセットアップ 評価対象の全 AWS アカウント/リージョンの AWS Config の有効化・設定が予め必要 共通設定項目 ● ● ● AWS Config サービス有効化・設定 Config アグリゲータ設定 IAM Role / CloudWatch Events 作成 方式 ● ● Terraformベースのマルチアカウントの ベースライン管理の仕組みを利用 ○ 詳細は Visional Engineering Blog を参照 StackSets などで代替可能 32

• https://engineering.visional.inc/blog/171/awssummit_securityguardrail/

実現したこと 1. ルール選定 導入 2. マルチアカウントセットアップ 3. ルールの管理・評価 4. 可視化 拡張・運用 5. 通知 6. 運用 33

3. ルールの管理・評価 Organization Config Rules ● ● マスターアカウントの AWS Organizations の AWS Config の機能を利用してルールを一元管理 組織のメンバーアカウントの AWS Config へルールを 自動反映 カスタムルールの Lambda 関数 ● ● マスターアカウントにて一元管理 メンバーアカウントの IAM Role へ AssumeRole し、 クロスアカウントにて対象リソースを評価 ○ IAM Role は、監査向けの SecurityAudit マネー ジドポリシーにて参照権限のみを許可 34

3. ルールの管理・評価：ルール評価対象アカウントの区分 評価対象に区分を設ける理由 ● ルールへの準拠が、本番アカウントでは必須、それ以外のアカウ ントでは必須ではないケースに対応し、対応への例外を作らない ため 方式 ● ● ● ルールに評価対象 ProductionOnly と All を独自定義 AWS Organizations の AWS アカウントのタグにて環境種別を 管理 メンバーアカウントへのルールの反映の除外は organization-config-rule の exclude-accounts を利用 ○ ProductionOnly のルールには、環境種別がproduction 以 外のアカウントリストを指定 35

実現したこと 1. ルール選定 導入 2. マルチアカウントセットアップ 3. ルールの管理・評価 4. 可視化 拡張・運用 5. 通知 6. 運用 36

4. 可視化 独自に可視化を行う目的 ● 組織全体の可視性を高め、調査・分析を可能にするため ○ 時系列の推移傾向の確認 ○ アカウント別やルール別、リージョン別などの状況分析 ○ 独自のルールの重要度をダッシュボードにて統合 ○ 非 AWS マネージドコンソールにて必要な人が閲覧可能 方式 ● ● Elasticsearch Service の Kibana にて可視化 AWS Config のアグリゲータへ集約されたマルチアカウント/リージョ ンの評価結果を、定期実行の Lambda にて Elasticsearch Service へデータ投入 37

4. 可視化：組織全体状況ダッシュボード 38

4. 可視化：AWS 運用者向け非準拠結果ダッシュボード 39

実現したこと 1. ルール選定 導入 2. マルチアカウントセットアップ 3. ルールの管理・評価 4. 可視化 拡張・運用 5. 通知 6. 運用 40

5. 通知 独自に通知を行う目的 ● 新たな非準拠検出タイミングで関係者へ通知し、問題を 検知して適切な対応アクションを取るため 方式 ● ● マルチアカウント/リージョンの評価イベントを CloudWatch Events にて集約アカウントのイベントバ スへ送信することでイベント集約 集約アカウントにて、イベントバスの評価イベントをトリ ガーに Lambda を呼び出して Slack へ通知 41

5. 通知：Slackメッセージ 非準拠検出時に通知 非準拠通知 ● 担当者とセキュリティ部門向けに非準拠結果を通知 ○ ルール/アカウント/リージョン/対象リソース 解決通知 ● 非準拠通知メッセージを解決済みとして更新 ○ “非準拠”から“準拠” 又は “対象外”へ遷移後 非準拠解決後 メッセージを解決へ更新 方式 ● 非準拠通知の際に評価結果と Slack メッセージ ID を 解決まで DynamoDB へ一時的に保管しておくことで メッセージとの紐付けを管理し、メッセージの更新を実 現 42

実現したこと 1. ルール選定 導入 2. マルチアカウントセットアップ 3. ルールの管理・評価 4. 可視化 拡張・運用 5. 通知 6. 運用 43

6. 運用：非準拠検出時の流れ 44

6. 運用：ルール重要度の設定 ルールに重要度を設ける理由 ● ルール毎に非準拠検出時の対応の緊急度が異なるため、適切な緊急度で対応するため （対応期間内に未解決の場合、セキュリティ部門より担当者へ連絡） ● Critical : 即時対応を実施 ○ ○ ○ ● High : 2-3 営業日内対応を実施 ○ ○ ● サービスの信頼性やセキュリティに関わる事故が発生する可能性のあるもの ログ出力設定でアカウントや VPC 全体に関わるもの Medium : 計画的対応を実施 ○ ○ ○ ● セキュリティ事故に直結する可能性があるもの クリティカルな異常に気付けない状況にあるもの（脅威検出サービスが無効等） AWS Root アカウントに関連するもの 多層防御の一部レイヤーで発生しており、セキュリティ事故に直結しないもの セキュリティリスクを含むが、影響が限定的なもの ログ出力設定で局部のみに関わるもの Organization Config Rules はリソースタグを非サポートのため、Terraform で定義したルール独自の属性 情報をマスターアカウントの S3 へ JSON 出力し、通知/可視化の機能より参照することで実現 45

6. 運用：準拠状況レポート通知 レポートを全社へ展開する理由 ● AWS Config 導入後、過去リソースに対して多くの非準拠が 検出された状況となったため、グループ全体で計画的に改善 に取り組む必要があるため ○ 高準拠率や前月比高改善率の担当者への賞賛 ○ 低準拠率の担当者への危機意識の醸成 方式 ● 月次のバッチにて、Elasticsearch Service のデータを元に AWS アカウントのコンプライアンスに関するレポートを Slack にて自動通知 46

6. 運用：その他 現場のエンジニアへ向けて ● AWS Config 社内勉強会の開催 ● Config ルールリストの社内公開 ○ ルールの評価方法、非準拠に対するリスク、対応するためのアクション、 準拠済み Terraform 設定例 など、担当エンジニアの理解を深め対応負荷を軽減する工夫 ● 個別部署との非準拠結果レビュー会 ○ 非準拠結果を合同でレビューし、リスクや対応方法を確認して改善を促進するための会 経営へ向けて ● 経営層 / 各事業長への状況報告 ○ 定期的に各事業のコンプライアンス状況をレポーティング 47

まとめ 48

まとめ チェックリストにて、多くのサービスを正確かつ適切に評価するのは困難 ● AWS Config は AWS リソースの設定を自動的に評価するソリューション ○ 正確性、リアルタイム性、効率性の高い評価を実現可能 ● あらゆるチェックの自動化は難しいため、チェックリストと併用して運用 継続的コンプライアンスの実現に向けた取り組み ● 導入：ルール選定後、AWS 組織全体の評価を実施 ● 拡張：独自のモニタリングやアラーティングの仕組みを構築 ● 運用：非準拠へ適切に対応するプロセスを整備 ● 文化：グループ全体で改善を推進するための工夫 エンジニア全体の意識が変わり始めたことで、改善が定着し、 継続的なコンプライアンスの実現に近づいてきています。 49

Thank you. We are hiring. 一緒に働く仲間を募集中です。 https://www.bizreach.co.jp/recruit/ 詳しく知りたり方は Tech Blog まで。 https://engineering.visional.inc/blog/ 50

• https://hrmos.co/pages/hrmos/jobs/160009210080
• https://www.bizreach.co.jp/recruit/
• https://engineering.visional.inc/blog/