概要 クラウドインテグレーション部クラウドソリューション2課の川井です。

はじめに 本記事では、Laravel上でポリモーフィック関連となるデータ構造をEloquentのリレーションでどう実装するか について紹介を行います。 ポリモーフィック関連とは？ 1つの子テーブルから複数の親テーブルを参照する関連のことを指します。 具体例 例えば、ブログや商品にコメントを添付する機能を実装する場合、ポリモーフィック関連を利用するのが良いとされています。 テーブル構造は以下のような形になります。 posts - id : 主キー - tilte : ブログタイトル - content : 内容 products - id : 主キー - name : 商品名 - discription : 商品説明 comments - id : 主キー - content : コメント内容 - commentable_type : 関連レコードのモデル名 - commentable_id : 関連レコードの主キー この設計では、 commentsテーブル の commentable_id と commentable_type がポリモーフィック関連における外部キーとなり、 postsテーブル や productsテーブル のレコードと関連付けられます。 commentable_type によって、コメントがどのテーブルに属するのかを特定できます。 LaravelでのMigrationの記述方法 Laravelではポリモーフィック関連のサポートが行われているため、簡単にMigrationを記述できます。 例で示した commentsテーブル のMigration記述例は以下になります。 Schema :: create( 'comments' , function ( Blueprint $table ) { $table -> text( 'comment' ) -> comment( 'コメント内容' ); $table -> morphs( 'commentable' ); }); $table->morphs('〇〇'); こちらの記述により、 ポリモーフィック関連における外部キー用のカラム( 〇〇_type , 〇〇_id )の作成が一括で行えます。 Laravelでのポリモーフィックのリレーション Laravelのモデルでリレーションの記述を行うことによって、   子テーブルのモデル から、 親テーブルのモデル の取得が行えるようになります。 リレーションの記述、利用方法について紹介を行っていきます。 1対1の場合 親テーブルと子テーブルが1対1である場合のリレーションの記述、利用方式について紹介していきます。 テーブルの構造は以下とします posts - id : 主キー - tilte : ブログタイトル - content : 内容 products - id : 主キー - name : 商品名 - discription : 商品説明 comments - id : 主キー - content : コメント内容 - commentable_type : 関連レコードのモデル名 - commentable_id : 関連レコードの主キー リレーションの記述方法 < ? php namespace App\Models ; use Illuminate\Database\Eloquent\Model ; class Post extends Model { public function comment () { return $this -> morphOne( Comment :: class , 'commentable' ); } } < ? php namespace App\Models ; use Illuminate\Database\Eloquent\Model ; class Product extends Model { public function comment () { return $this -> morphOne( Comment :: class , 'commentable' ); } } < ? php namespace App\Models ; use Illuminate\Database\Eloquent\Model ; class Comment extends Model { public function commentable () { return $this -> morphTo( __FUNCTION__ , 'commentable_type' , 'commentable_id' ); } } リレーションの利用方法 親モデルから子モデルを取得する方法は use App\Models\Post ; $post = Post :: find( 1 ); $comment = $post -> comment ; となります。 こちらにより、親モデル（ Postモデル ）から、子モデル（ commentモデル ）を取得することができます。 逆に、子モデルから親モデルを取得する方法は use App\Models\Comment ; $comment = Comment :: find( 1 ); $value = $comment -> commentable ; となります。 こちらにより、子モデル（ commentモデル ）から親モデル（ Postモデル ,   Productモデル ）を取得することができます。 取得されるモデルは comment.commentable_type に記述されているモデル名に応じて変化します。 1対多の場合 親テーブルと子テーブルが1対多である場合のリレーションの記述、利用方式について紹介していきます。 1対多の場合でも、1対1と同じようなテーブル構造・リレーションの記述になります。 テーブルの構造は以下とします。 posts - id : 主キー - tilte : ブログタイトル - content : 内容 products - id : 主キー - name : 商品名 - discription : 商品説明 comments - id : 主キー - content : コメント内容 - commentable_type : 関連レコードのモデル名 - commentable_id : 関連レコードの主キー リレーションの記述方法 < ? php namespace App\Models ; use Illuminate\Database\Eloquent\Model ; class Post extends Model { public function comments () { return $this -> morphMany( Comment :: class , 'commentable' ); } } < ? php namespace App\Models ; use Illuminate\Database\Eloquent\Model ; class Product extends Model { public function comments () { return $this -> morphMany( Comment :: class , 'commentable' ); } } < ? php namespace App\Models ; use Illuminate\Database\Eloquent\Model ; class Comment extends Model { public function commentable () { return $this -> morphTo( __FUNCTION__ , 'commentable_type' , 'commentable_id' ); } } リレーションの利用方法 親モデルから子モデルを取得する方法は use App\Models\Post ; $post = Post :: find( 1 ); $comments = $post -> comments ; となります。 こちらにより、親モデル（ Postモデル ）から、紐づくすべての子モデル（ commentモデル ）を取得することができます。 逆に、子モデルから親モデルを取得する方法は use App\Models\Comment ; $comment = Comment :: find( 1 ); $value = $comment -> commentable ; となります。 こちらにより、子モデル（ commentモデル ）から親モデル（ Postモデル ,   Productモデル ）を取得することができます。 取得されるモデルは comment.commentable_type に記述されているモデル名に応じて変化します。 多対多の場合 親テーブルと子テーブルが多対多である場合のリレーションの記述、利用方式について紹介していきます。 テーブルの構造は以下とします posts - id : 主キー - tilte : ブログタイトル - content : 内容 products - id : 主キー - name : 商品名 - discription : 商品説明 comments - id : 主キー - content : コメント内容 commentables - comment_id : コメントID - commentable_type : 関連レコードのモデル名 - commentable_id : 関連レコードの主キー リレーションの記述方法 < ? php namespace App\Models ; use Illuminate\Database\Eloquent\Model ; class Post extends Model { public function comments () { return $this -> morphToMany( Comment :: class , 'commentable' ); } } < ? php namespace App\Models ; use Illuminate\Database\Eloquent\Model ; class Product extends Model { public function comments () { return $this -> morphToMany( Comment :: class , 'commentable' ); } } < ? php namespace App\Models ; use Illuminate\Database\Eloquent\Model ; class Comment extends Model { public function Posts () { return $this -> morphedByMany( Post :: class , 'commentable' ); } public function Products () { return $this -> morphedByMany( Product :: class , 'commentable' ); } } リレーションの利用方法 親モデルから子モデルを取得する方法は use App\Models\Post ; $post = Post :: find( 1 ); $comments = $post -> comments ; となります。 こちらにより、親モデル（ Postモデル ）から、紐づくすべての子モデル（ commentモデル ）を取得することができます。 逆に、子モデルから親モデルを取得する方法は use App\Models\Comment ; $comment = Comment :: find( 1 ); $posts = $comment -> posts ; $products = $comment -> products ; となります。 こちらにより、子モデル（ commentモデル ）からそれぞれの親モデル（ Postモデル ,   Productモデル ）を取得することができます。 まとめ 今回紹介したリレーションによって、 Laravelではポリモーフィック関連のテーブルの場合でも、簡単に関連テーブルの取得が行えるようになります。 実務で行っている案件上で、ポリモーフィック関連のテーブルを扱う際に「Laravel上でどのように行えばよいのか」が理解しづらかったので、今回紹介させていただきました。 Laravelを利用した開発の手助けの一因になれれば幸いです。 ここまで読んでいただきありがとうございました。 参考 Laravel 11.x Eloquent:リレーション   Laravel 11.x マイグレーション

  はじめに 本記事ではAWS Elemental MediaLive、AWS Elemental MediaPackageを用いて、動画配信サービスを構築します。 構成 動画配信サービスの構成を以下に記載します。 各項目の役割については、以下の通りです。 OBS Studio、XSplitなど 各クライアントからAWS Elemental MediaLiveへ映像を配信 各クライアントから動画を配信するために必要な配信ソフトです。 今回はOBS Studioを利用しますが、AWS Elemental Linkという、AWSが有償で提供している配信用ハードウェアを用いることも可能です。   AWS Elemental Link AWS Elemental MediaLive ブロードキャスト配信用のビデオ入力をライブ出力に変換 各クライアントから配信された動画のエンコードを行います。 またAWS Elemental MediaPackageへの出力を行います。   AWS Elemental MediaPackage ジャストインタイム形式の変換を使用した動画配信 AWS Elemental MediaLiveから出力された動画のパッケージングを行います。 またAmazon CloudFrontのオリジンとしての役割も担います。   ハンズオン AWS上に環境を構築していきます。 以下の手順で作業を進めていきます。 MediaPackageチャネルの作成 MediaPackageエンドポイントの作成 MediaLive入力の作成 MediaLiveチャネルの作成 OBSの設定 動画配信確認   MediaPackageチャネルの作成 AWSマネジメントコンソールから「MediaPackage」を検索し、「新しいチャネルの作成」を選択します。 「ID」と「説明」に適切な値を入力し、「作成」を選択します。 今回は設定しませんが、必要に応じて、アクセスログ記録の設定をしましょう。 MediaPackageエンドポイントの作成 チャネルが作成できましたので、続いてエンドポイントの設定を行います。 「エンドポイントの管理」を選択します。 「ID」「説明」に適切な値を入力し、「保存」を選択します。 その他の項目は、今回は設定しませんが、必要に応じて設定してください。 以下の通り、オリジンエンドポイントが作成されました。 MediaLive入力の作成 AWSマネジメントコンソールから「MediaLive」を検索し、左のメニュータブから「入力」を選択、「入力の作成」を選択します。 「入力名」に任意の値を入力し、「入力タイプ」はOBSからRTMPで配信をするため、RTMP（プッシュ）を指定します。 「入力セキュリティグループ」に動画配信元のIPアドレスを入力し、「入力セキュリティグループの作成」を選択します。 「入力の送信先」では「アプリケーション名」と「アプリケーションインスタンス」に任意の値を入力しますが、OBSで配信する際のキーとなりますので、外部公開しないようにご注意ください。 入力が完了しましたら、「入力の作成」を選択します。 以下の通り、入力が作成されました。 URLは後にOBSで配信先として設定しますので、控えておいてください。 MediaLiveチャネルの作成 左のメニュータブから「チャネル」を選択、「チャネルの作成」を選択します。 「チャネルと入力の詳細」を選択し、「チャネル名」に任意の値を入力、「IAMロール」はテンプレートからロールを作成、「テンプレート」としてHTTP live streaming(MediaPackage)を選択します。 入力アタッチメントの「追加」を選択し、先ほど作成したMediaLive入力を「入力」で選択、「確認」を選択します。 「テンプレート」としてHTTP live streaming(MediaPackage)を選択したため、出力グループが自動的に追加されています。 「MediaPackage-1」を選択し、「MediaPackageチャネルID」に先ほど作成したMediaPackageのチャネルを入力、「名前」は任意の値を入力します。 テンプレートから作成したため、出力が大量に作成されていますが、今回は1280_720を使用するため、その他の出力は削除します。 今回は変更しませんが、「出力1:1280_720_1」を選択すると、動画のレートやフレームレートなどの項目を設定したり、オーディオのコーデックを変更することが可能です。 必要な項目を設定し終えたら、「チャネルの作成」を選択します。 これでチャネルの作成は完了です。 「開始」を選択すると、配信の受け付け状態になりますが、 実行状態がRunningの状態 だと、 高コスト となりますので、配信時以外は停止することを推奨します。 OBSの設定 「設定」、「配信」から「サービス」でカスタムを選択し、「サーバー」にはMediaLive入力の作成時に控えたURLのアプリケーション名までを入力し、「ストリームキー」にはアプリケーションインスタンスを入力します。 例）URLが「rtmp://XXX.XXX.XXX.XXX/live/testkey」だった場合 　　　サーバー：rtmp://XXX.XXX.XXX.XXX/live 　　　ストリームキー：testkey 動画配信確認 以上で設定は完了しましたので、MediaLiveを開始し、配信ができているかを確認します。 MediaLiveで配信を開始した後、チャンネルの状態がRunningになったことを確認します。 Runningになった後、OBSで配信開始を選択すると、通信が疎通していることがわかります。 実際の配信状況を確認する際はMediaPackageのチャネルを選択し、エンドポイントのプレビューを選択すると、外部サイト(hls.js demo)で配信の内容を確認することができます。 hls.js demo 以上でAWS Media Servicesを利用した動画配信サービスの構築は終了となります。

はじめに こんにちは！デジタルエンジニアリング部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課 川井　康敬