はじめに こんにちは！デジタルエンジニアリング部24卒新入社員（佐々木、髙波、佐藤、森澤、髙橋、西村、沈）です！ 2024年6月20日、21日にAWS Summit Japanが幕張メッセで開催されました。 私たちは21日に現地に行き、様々なセッションに参加しました。 また、展示ブースや開発者向けライブステージもまわりました。 今回の記事では、AWS Summitを紹介するとともに、セッションの概要やその感想をお伝えしたいと思います。 AWS Summitとは AWS Summitは、日本最大の”AWSを学ぶイベント”です。 初心者から経験者まで学べるセッションやAWSを使ったサービスの事例、開発者向けの展示ブースなどがありました。 その他にも、AWSの基礎から応用までの技術相談ができるブースもありました。 会場はとても広く、幅広い年齢層の人々が集まっており、まるでライブのような雰囲気でした！ AWS Summit Japan 2024 多くの企業が出展しており、知っている企業や、我らがアジアクエストもありました！ 事例セッションレポート いくつか聴講したセッションの中で特に印象に残った2つのセッションについて、 内容を簡単にまとめたうえでメンバーそれぞれの感想を書いていきます！ より良い視聴体験を求めて、ニコニコ動画の配信基盤刷新の舞台裏 概要 登壇者：久保田陽介 氏（株式会社ドワンゴ） ニコニコ動画とは、ドワンゴ株式会社が提供する動画配信サービスです。 ニコニコ動画の動画配信サービスはもともとオンプレミスで提供されていましたが、2023年末からAWSを用いた新動画配信基盤での運用を開始しました。 旧基盤では、生放送と動画配信の運用によるシステムの複雑化やデプロイの難しさ、オンプレミスによるサーバの制約、さらには無駄なコストの発生といった問題点がありました。 しかし、AWSを用いてクラウドで管理することで、これらの問題を解決することに成功したとのことです。 AWSの導入に至った経緯から問題解決のための手順、苦労したポイントなど詳細な説明がされていたため、私たちのような初学者でも理解しやすい構成となっていました。 感想 初学者でもわかりやすいセッションでした。 事例とともにどのように成功したのか、どの部分が大変だったのかなどを詳細に解説いただくことで、AWSへの理解が深まりました。 身近なサービスである動画配信などの裏でもAWSが使用されていることを知り、意外性がありましたが、より身近に感じられるようになりました。 （佐々木） インフラをオンプレミスで管理するよりも、クラウドで管理することのメリットがとてもわかりやすい講演でした！ 特に、クラウドであればいつでもリソースを増やせるので、夜に視聴が多くなる動画配信サービスへの負荷を臨機応変に対応できる点がいいなと思いました。 画質を気にせずに動画を見れるのっていいですよね！ （森澤） 旧基盤のオンプレミスと新基盤のクラウドが対比された講演で、とても分かりやすかったです。 AWSを用いた配信基盤の運用が2023年末からと聞き、想像していたより最近だったため、近年クラウド化が進んでいることを改めて実感しました。 （西村） サイバーエージェントにおけるマルチモーダルな生成 AI 開発の取り組み 概要 登壇者：稲垣青空 氏（株式会社サイバーエージェント） インターネット広告事業を行っているサイバーエージェントでは、生成AIを活用して広告実績を2.3倍に向上させました。 この生成AIの一部は社内で開発されており、広告効果の向上に寄与しています。 開発の背景には、海外の生成AIが日本の文化を正しく認識できない問題がありました。 例えば、広島風お好み焼きを正しく認識できず、誤った内容が生成されることがありました。 サイバーエージェントは日本に特化した生成AIを開発するため、AWSの支援プログラムとGPUサービスであるAWS Trainiumを活用しました。 これにより、日本の文化情報を学習させた生成AIが開発され、正確な内容を生成できるようになりました。 今後は、音声や映像に特化した生成AIの開発も計画されており、さらなる発展が期待されます。 感想 サイバーエージェントのAI技術に関する講演は、日本語特化の大規模言語モデルの開発における技術的挑戦と、広告分野での応用例が非常に印象的でした。 特に、CLIPモデルや独自OCRモデルの開発による広告クリエイティブの最適化は、AI技術がどのように実際のビジネスに貢献できるかを具体的に示していました。 また、AWSの技術を活用することで、リソースの効率的な利用が可能になる点も興味深かったです。 （沈） サイバーエージェントがAWSの支援を受けながらAIの自社開発をしていたことに驚きました。 企業独自のAIがあるんですね！ 日本の言葉や文化をモデルに理解させるのが難しいというのも意外でした。 AWSの力を借りることで、2.3倍も広告実績を向上させたという話を聴いて、AWSを使ってこういうこともできるのか！と感じました。 アジアクエストがクラウドを活用していることにも納得です。 言語モデルやLLMなどの知らない用語が沢山出てきて全体的に難しいと感じましたが、お好み焼きの例は分かりやすかったです！ セッションに参加して、AIに少し興味が湧きました！ （髙波） サイバーエージェントの日本市場に特化した生成AIの取り組みが面白かったです。 日本文化や言語の特性を反映したAIモデルが、国内市場での競争力を一気に高めているのがよく分かりました。 AWSを活用することでAI開発のハードルが下がり、中小企業やスタートアップでもAI技術を導入しやすくなるため、最新技術をキャッチアップしないと取り残される感じがします。 今後は、動画や音声にも対応した特化型の生成AIの開発に取り組んでいるとのことで、未来を感じさせるセッションでした！ （佐藤） QuizKnockのパネル展 YouTubeなどで活動されているQuizKnockメンバーの伊沢拓司さん、鶴崎修功さん、falconさんの3名と、AWSメンバー5名による、「AWSで妄想してみた」というパネル展がありました！ ここでは、QuizKnockのメンバーが妄想した様々なアイディアが、複数枚のパネルに展示されていました。 特に私たちの印象に残ったものは、『外出するときの心配事をAWSが解決してくれるシステム』です。 このシステムが実現できれば、「カギ閉めたっけ？」や「ガス消したっけ？」という不安が解消されるそうです。 7つのサービスを組み合わせるだけでこのシステムを作れるらしいので、思ったよりシンプルな作りだと思いました。 少し頑張れば自分で作れそうですね笑 （髙橋） この他にもQuizKnockのメンバーが妄想したアイディアがたくさんありました！ 2024 Japan AWS All Certifications Engineers 受賞者 今年アジアクエストからは合計7名の方が2024 Japan AWS All Certifications Engineers を受賞しました。 表彰式で先輩方の名前が出ると、嬉しかったです！ 井川 朋樹さん（クラウドインテグレーション部1課6G） 今村 俊輝さん（クラウドインテグレーション部2課2G） 下平 敬介さん（クラウドインテグレーション部1課2G） ブーブァンフェさん（クラウドインテグレーション部2課4G） 満田 竜輔さん（デジタルエンジニアリング部エンタープライズエンジニアリング課2G） 向井 剛志さん（デジタルエンジニアリング部エンタープライズエンジニアリング課サブマネージャー） 渡邊 毅さん（クラウドインテグレーション部1課5G） そして、合計2名の方が2024 Japan AWS Jr. Championsを受賞しました。 井川 朋樹さん（クラウドインテグレーション部1課6G） 髙橋 建さん（クラウドインテグレーション部1課6G） おめでとうございます！ 受賞された今村さんの記事も公開されているので、ぜひご覧ください！ 2024 Japan AWS All Certifications Engineersを受賞するまでのきっかけと取り組み 最後に 今回AWS Summitに初めて参加して、セッションやブースの展示から多くのことを学びました。 現在、多くの企業でAWSが利用されており、それは幅広い用途に対応しています。 出展企業の中には馴染みのある企業もあり、難しいイメージがあったクラウドが少し身近に感じるようになりました。 さらに多くの知識を付けて、また参加したいと思います。 テンション爆上がりでした！とても楽しかったです！ AWS Summit最高！

 

概要 クラウドインテグレーション部クラウドソリューション2課の川井です。 今回は、AWS Organizations と AWS Security Hubの連携における構成と運用方法について記載します。 本記事では、構成についてのみ記載していきます。 AWS Security Hubは、AWS Organizationsとの連携を行うことで、組織内のすべてのアカウントのセキュリティ状態を一元管理できます。 AWS Security Hubとは AWS Security Hubとは、AWSクラウド環境におけるセキュリティの可視化と管理を一元化するサービスです。 自動化された継続的なセキュリティのベストプラクティスチェックによって検出された セキュリティイベントを自動検出して、可視化させます。 〇主な機能の特徴 ● セキュリティ基準チェック AWS 基礎セキュリティのベストプラクティスや、CIS AWS Foundations Benchmarkなどのセキュリティ基準に 基づく自動チェックを実行し、コンプライアンス状態を評価します。 サポートされているセキュリティ基準 参考:   Security Hub 標準のリファレンス 以下の画像が実際のコンソール画面で確認した、現在サポートされているセキュリティ基準です。 ● セキュリティイベントの管理 セキュリティイベントを自動的に分類し、重要度に応じてアラートを生成します。 これにより、優先的に対処すべき問題を迅速に特定できます。 重要度一覧 CRITICAL：この問題はエスカレートしないようすぐに修正する必要あり HIGH：この問題は優先事項として対処する必要があり MEDIUM： この問題は対処する必要があるが、緊急ではない LOW： この問題は単独で対処する必要はない INFORMATIONAL： 問題は見つからなかった ● 脅威インテリジェンスの統合 Amazon GuardDuty、Amazon Inspector、Amazon MacieなどのAWSセキュリティサービスやサードパーティー製品からの 検出結果を統合し、包括的な脅威インテリジェンスを提供します。 つまり、Security Hubと統合したAWSサービスの検出結果を、Security Hubのアラート検出結果の画面に 統合して表示されることができます。以下の画像が統合されているAWSリソース一覧の一部です。 ● 統合されたセキュリティビュー AWS Security Hubは、AWS環境全体のセキュリティ状況を一元的に可視化します。 これにより、異なるAWSアカウントやリージョンにまたがるセキュリティイベントを一箇所で確認できます。 これを実装するには、AWS Organizationsと連携が必須になります。 〇機能の仕組み Security Hubを有効化（使用）する上で、 AWS Config の有効化 が必須になります。 何故ならば、Security Hubを有効化するとAWS Config内に選択したセキュリティ基準に沿って、Security Hubにより Configルールが自動的に作成されます。 Security Hubのセキュリティチェックは、一部 Configルールを利用してセキュリティ評価を実行します。 具体的には、Security Hubのコントロールの一部はAWS Configルールをベースにしており、リソースの構成がセキュリティベストプラクティスに従っているかどうかをチェックしているからです。 流れは、以下のようになります。 １．Security Hub: Security Hubは、AWS Configルールを使用して、リソースの構成がセキュリティ基準に従っているかどうかを評価します。 例えば、「EC2インスタンスに対してセキュリティグループが適切に設定されているか」などのチェックを行います。 ２．AWS Configルールの評価: AWS Configルールは、指定された評価基準に従ってリソースの構成を継続的に監視し、評価結果をSecurity Hubに送信します。 ３．結果の統合とレポート: Security Hubは、AWS Configからの評価結果を統合し、Security Hubのダッシュボードで表示します。 構成のポイント 今回は、AWS Organizationsと連携してSecurity Hubを使用する想定です。 また、Security Hubのセキュリティイベントで『CRITICAL』と『HIGH』の重要度アラートを検知した際、通知させるようにします。 この構成のもと、考慮する要素を記載していきます。 〇リージョン間、集約の設定 まず、Security Hubは リージョン単位 のサービスなので、リージョンごとに有効化する必要があります。 例えば、東京と大阪、バージニア北部でリソースを作成しており、全てのリージョンで Security Hubを有効化するのであれば、全てのリージョンでSecurity Hubを有効化する必要があります。 ※ 組織設定の中央設定を用いれば、集約リージョンのホームリージョンの設定のみの対応可能 そして、Security Hubの集約リージョンの設定を用いることで、例えば、東京リージョンに集約させた場合、 他リージョンで発報したアラートを東京リージョンのSecurity Hubのコンソール画面に集約して、見る事が可能なので、 運用する際 アラート確認をする時に各リージョンに移動するなどの手間は回避できます。 設定例は以下の通りです。 バージニア北部リージョンと大阪リージョンのアラートをホームリージョンである東京リージョンで集約させる例です。 〇アカウント間、集約の設定 次は各アカウント間で、発報したアラート集約の件についてです。 Security Hubでは、AWS Organizationsと連携する事で、複数アカウントのアラートを集約することが可能です。 集約を設定するには、まず管理アカウントを選定し（DefaultではOrganizationsの管理アカウントがSecurity Hubの管理アカウントになっています）、そのアカウントで Security Hubを有効化にします。 次に各アカウントを、メンバーアカウントとして追加して Security Hubを使用するように設定します。 この設定により、全てのアカウントからのアラートが、管理アカウントに集約され、セキュリティアラートを一元管理することができます。 要は、管理アカウントにメンバーアカウントのアラートの検出結果を集約できるということです。 また、先のリージョン集約の設定が管理アカウントに設定されていれば、 管理アカウントの特定リージョンに、全てのメンバーアカウントの各リージョンの検出結果を集約させて見ることが出来ます。 ・ 設定上の注意点 管理アカウントにメンバーアカウントの検出結果を集約させるには、管理アカウントのSecurity Hubの設定で、 メンバーアカウントを追加します。しかし複数リージョンで Security Hubを有効にしている場合、 各リージョンごとで、メンバーアカウントへの追加を行わなければなりません。 ※ 組織設定の中央設定を用いれば、集約リージョンのホームリージョンの設定のみの対応可能 集約の流れとして、メンバーアカウントの検出結果は、まず、管理アカウントの各リージョンごとに集約されてきます。 バージニア北部なら管理アカウントのバージニア北部のSecurity Hubで、 東京なら管理アカウントの東京のSecurity Hubで集約されます。 もし集約リージョンの設定を入れていた場合は、 管理アカウントの集約リージョンの設定において、集約リージョンに全て検出結果が集まるという流れになります。 例えば、集約リージョンの設定を東京リージョンにしていれば東京リージョンに全ての検出結果が集約されます。 ・ 設定上の考慮点 AWS Organizations と AWS Security Hubの管理アカウントは、同様のアカウントにしないというのが、 AWSのベストプラクティスとなっています。 基本的に、Organizationsの管理アカウントが、Security Hubの管理権限を持っていますので、Security Hubの管理権限を 別のアカウントに委任するというのがAWSの推奨です。また、権限の委任は各リージョンごとに行う必要があります。 ※ 組織設定の中央設定を用いれば、集約リージョンに指定したリージョンは自動的に権限が委任される 〇組織設定の方法 組織設定の方法には、以下の2種類があります。 ・中央設定（参考： 中央設定の使用を開始する ） ・ローカル設定（Defaultの設定） 組織設定とは、管理アカウント（委任管理アカウント）でメンバーアカウントのSecurity Hubの設定を一括で行うものです。 例えば、Security Hubの有効化やどのセキュリティ基準を有効化する設定などです。 デフォルトでは、ローカル設定となっていますが、以下の設定画面にあるように推奨は中央設定となっています。 これは、中央設定の方が詳細な設定が可能であり、一括設定がしやすくなるためです。 先にも、※の所で記載していますが、Security Hubの有効化やメンバーアカウント追加処理、 Security Hubの権限委任の設定など一括で設定することが出来ます。 また、この中央設定を使用する場合は、Organizationsの管理アカウントから別のアカウントに、 必ずSecurity Hubの権限委任を行う 必要があります。 余談ですが、Security Hubを運用する上で、 Security Hubの不要なアラートを止める方法として、コントロールの無効化という設定があります。 これは、各アカウントごとで設定する必要があるものなので、各アカウントごとで無効化の設定をしなければなりませんが、 中央設定では管理アカウントでコントロールの設定を一括管理することが出来ます。 以下が中央設定のコントロール画面です。 〇検出結果の通知設定 セキュリティアラートが上がっても気付けなければ意味がなく、 また、Security Hubのコンソール画面に入って確認するというのも手間になるので、重要度『CRITICAL』と『HIGH』のアラートを検知したら、E-mailアドレスないしSlackのチャンネル等に通知を飛ばすという設定をします。 セキュリティアラートが発報する頻度についてですが、 有効化したセキュリティ基準により作成されたコントール（セキュリティルール）によって、再評価（セキュリティチェック）される時間は異なります。 最初にセキュリティ基準を有効化して始めのセキュリティチェックが入ってから、最短で12時間、最長で24時間ごとに、各コントール（ルール）ごとに再評価（セキュリティチェック）されていきます。 つまり、最初にセキュリティチェックが実行されて初期アラートが出てから24時間以内に、セキュリティアラートに対して特に何もアクションしていない場合、 Security Hubによって再評価された際、新たにセキュリティアラートが作成されてアラートが発報されます。 なので、初期アラート（例えば、S3にパブリックなアクセスから接続が許可されている）が検知された際、 何もアクションを取らなかった場合、最長24時間以内に同様のアラートがまた検知されます。 セキュリティアラートを検知するには、EventBridgeを使えば実装することが出来ます。 今回の構成では、セキュリティアラートを管理アカウントの特定のリージョンに集約させていますので、 集約させたアカウントのリージョンにのみEventBridgeを作成すれば問題ありません。 EventBridgeのイベントパターンの例を以下に記載します。 { "detail": { "findings": { "Compliance": { "Status": ["WARNING", "FAILED"] }, "ProductName": ["Security Hub"], "RecordState": ["ACTIVE"], "Severity": { "Label": ["HIGH", "CRITICAL"] }, "Workflow": { "Status": ["NEW"] } } }, "detail-type": ["Security Hub Findings - Imported"], "source": ["aws.securityhub"] } 一部説明を入れると、 Security HubはAWS GuardDutyやAWS Inspector等と統合されています。 なので、Security Hubの検出結果の画面に GuardDutyやInspectorの検出結果も表示されます。 そして、今回は Security Hubの検出結果のみ検知したいので、[ ProductName : [Security Hub] ]の一文を入れています。 また、新しく作成されたアラートのみ検知したいので、[ Workflow : {Status: [NEW]} ]を入れています。 抑制済みのワークフローステータスについては、今後記載する運用の所で説明しますが、ワークフローステータスが抑制済みに変更した場合のものを検知させたくないので、この一文をいれています。 構成図 構成ポイントを考慮した上で作成した構成図は以下のようになります。 異なる AWSアカウントやリージョンにまたがるセキュリティイベントを、Security Hubの権限を委任した 委任管理アカウント一か所に集約させ、 重要度が高い（CRITICALとHIGH）アラートを検知させます。 また補足ですが、リージョン集約の設定は管理アカウントで設定したものが各メンバーアカウントに自動的に反映されます。 これは、ローカル設定、中央設定どちらでも同様です。 なので、構成図のメンバーアカウントと管理アカウントのリージョン集約の設定は、先に記載したアラート集約の経路通りで、 委任管理アカウントへのアラート集約の経路とは関係ありません。 ただ単純に各アカウントごとで東京リージョンにアラートが集約される設定となります。 再度、集約の経路を記載すると、以下のようになります。 １．メンバーアカウント及び管理アカウントの検出結果は、委任管理アカウントの各リージョンごとに集約される。 ２．委任管理アカウントの集約リージョンの設定において、特定リージョンに全て検出結果が集約される。 Security Hubの設定 構成図通りに設定していきます。 1. AWS Organizationsで『信頼されたアクセス』を有効化する 管理アカウントのAWS Organizations の マネジメントコンソールでサービスへ移動します。 Security Hub を 「アクセス有効」 にします。これを行わないとアカウント間でのアラートの集約の連携が出来ません。 2. 管理アカウントで Security Hub を有効化する 東京リージョンで、Security Hubの有効化と、委任先のアカウントを入力します。 セキュリティ基準は、使用したいものを選定してチェックを入れて下さい。 先にも記載した通りで、Security Hubを使用するにはAWS Configの有効化が必要ですので先に有効化しましょう。 また、Configを有効化する際の注意点としては、 ConfigもSecurity Hubと同様リージョン単位のリソースなので、Security Hubを有効化するリージョンごとにConfigも有効化しなければなりません。 3. 権限委任先のアカウントで Security Hub を有効化する 委任先のアカウントで、Security Hubを有効化します。また、Configの有効化も行います。 この時点で、委任管理アカウント 及び メンバーアカウントに追加するアカウントのSecurity Hubを有効化するリージョンで、 先にConfigの有効化をしておきましょう。 4. 権限委任先のアカウントで リージョン集約の設定 委任先のアカウントで、集約リージョンの設定をします。集約したいリージョンで行います。 今回であれば、東京リージョンで設定します。 Security Hubを使用するリージョンが明確に決まっているのであれば、ここのチェックはいりません。 5. 権限委任先のアカウントで Security Hubの組織設定 委任先のアカウントで、Security Hubの組織設定をします。 ● ローカル設定の場合 Security Hubのコンソール画面の設定にいくと、Defaultがローカル設定になっているので、特に設定を変更する必要はありません。 そして、アカウントをメンバーアカウントに追加した際に Security Hubを有効化したい場合、『Auto-enable accounts』の箇所を有効化にします。 また、セキュリティ基準を有効化したい場合は、『Auto-enable default standards』の箇所を有効化します。 default standardsとは、セキュリティ基準の『AWS 基礎セキュリティのベストプラクティス v1.0.0 』と『CIS AWS Foundations Benchmark v1.2.0』の2つが有効化されます。 ローカル設定では詳細な設定が出来ないため、他のセキュリティ基準も一緒に有効化したい場合は中央設定を使用することをお勧めします。 ※ローカル設定では、この設定を各リージョンごとで行う必要があります。 今回の構成であれば、東京と大阪、バージニア北部のリージョンで行います。 また、Security Hubの権限委任も各リージョンごと行う必要があるので、まずは管理アカウントへ行って Security Hubの有効化と権限委任の設定を行います。 ● 中央設定の場合 1.『中央設定に変更』 設定に画面で編集を押し、Defaultがローカル設定になっているので、中央設定に変更して設定を開始します。 2.『中央設定のセットアップ（リージョン）』 リージョンの設定は、先に集約リージョンの設定をしていれば反映されているので、確認して続行します。 3.『中央設定のセットアップ（組織の設定）』 カスタマイズしたいので、設定タイプは Security Hub の設定をカスタマイズを選択します。 カスタムポリシーの設定は、Security Hubは有効化にし、 セキュリティ基準は『AWS 基礎セキュリティのベストプラクティス v1.0.0』のみ有効化 コントロール（セキュリティルール）は一旦全て有効化にします。 アカウントの設定は、全てのメンバーアカウントに適応します。 最後に、カスタムポリシー名を設定して、ポリシーを作成します。 ※中央設定では、カスタムポリシーで設定した集約リージョンで指定したリージョン 及び 指定したアカウントで 自動的にこのポリシーが適応されています。 今回の構成であれば、各メンバーアカウントの東京と大阪、バージニア北部のリージョンでも、今設定した内容が反映されます。 なので、中央設定で設定をしていれば 各リージョンごとに設定を行う必要がありません。他のリージョンの権限委任も自動的に行ってくれます。 6. EventBridgeの設定 先に記載したEventBridgeのルールイベントパターンを参考に、通知させたい通知先をターゲットに設定をしていただければ良いと思いますので、 EventBridgeの作成ついては省略いたします。 これで構成図通りの設定は完了です。 まとめ 今回は、AWS Organizationsを使ってSecurity Hubのセキュリティアラートを一元管理する方法を記載しました。 Security Hubは 有効化したけれども、そもそもどういう構成にしたらいいのかよく分からないという方々にとって、 Security Hubの構築方法の一つの例になれば幸いです。 次は、Security Hubを運用する上で考慮する点を記載していきますので、 引き続き、よろしくお願いいたします。   クラウドインテグレーション部 クラウドソリューション2課 川井　康敬