こんにちは、広野です。 本記事は、以前公開した記事の続編です。つくった RAG の概要は以下の記事をご覧下さい。 React アプリに Agents for Amazon Bedrock への問い合わせ画面を組み込む [RAG・レスポンスストリーミング対応] Agents for Amazon Bedrock を使用して簡単な RAG をつくってみましたので、問い合わせ画面コードの一部を紹介します。 blog.usize-tech.com 2024.02.15 本記事では、Agents for Amazon Bedrock から Amazon Bedrock の Anthropic Claude Foundation Model に問い合わせる構成をメインに紹介します。 アーキテクチャ RAG 用の Knowledge Base (ベクトルデータ) には、Agents for Amazon Bedrock が自動作成してくれる Amazon OpenSearch Service Serverless を使用しています。別途 Amazon S3 バケットを作成し、そこに当社公式ホームページの情報を PDF 化したファイルを格納し、OpenSearch に Sync させます。 一般的な回答をするために使用する生成系 AI の基盤モデルには、Amazon Bedrock の Anthropic Claude 2.1 を使用しています。 ユーザからの問い合わせ内容が当社 (SCSK 株式会社) に関連するものであれば Agents for Amazon Bedrock が自動的に OpenSearch 内の情報を取得します。それ以外の内容であれば AWS Lambda 関数経由で Claude 2.1 モデルに問い合わせます。 この 分岐を司る部分を中心に 設定情報など紹介していきます。 つくったもの RAG 検索用 Knowledge Base Agents for Amazon Bedrock により RAG 用の Knowledge Base を作成する方法については、以下の記事を参考にしました。 生成AI初心者がAmazon BedrockのKnowledge baseを使ってRAGを試してみた AWS re:Invent2023にて、Amazon BedrockのKnowledge baseとAgentsがGAされたと発表がありました。今回はこのうちKnowledge baseを利用して、RAG（Retrieval Augment Generation）を試してみたいと思います。 blog.usize-tech.com 2023.12.07 一般検索用 AWS Lambda 関数 以下の関数コードを書きました。 Amazon Bedrock の Claude モデルに問い合わせるコードは既に世の中に溢れているコードサンプルと同じです。ただし、今回の構成ではこの AWS Lambda 関数の呼び出し元が Agents for Amazon Bedrock なので、その仕様に基づき event[‘inputText’] をプロンプトに入れています。 また、Agents for Amazon Bedrock に戻すレスポンスも所定のフォーマットにしないといけないので、その仕様に合わせています。 import boto3 import json bedrock = boto3.client('bedrock-runtime') def lambda_handler(event, context): enclosed_prompt = "\n\nHuman: " + "以下の質問文に対して適切な回答をしてください。\n" + event['inputText'] + "\n\nAssistant:"; body = { "prompt": enclosed_prompt, "max_tokens_to_sample": 3000, "temperature": 0.5, "top_k": 250, "top_p": 1, "stop_sequences": ["\n\nHuman:"], "anthropic_version": "bedrock-2023-05-31" }; res = bedrock.invoke_model( body=json.dumps(body), contentType='application/json', accept='application/json', modelId='anthropic.claude-v2:1' ) responsebody = json.loads(res['body'].read()).get('completion', '適切な回答が見つかりませんでした。') return { "messageVersion": "1.0", "response": { "actionGroup": event["actionGroup"], "apiPath": event["apiPath"], "httpMethod": event["httpMethod"], "httpStatusCode": 200, "responseBody": { "application/json": { "body": responsebody } } }, "sessionAttributes": event["sessionAttributes"], "promptSessionAttributes": event["promptSessionAttributes"] } Agents for Amazon Bedrock の設定 RAG 検索用 Knowledge Base および 一般検索用 AWS Lambda 関数が完成したら、それらをオーケストレートする Agents for Amazon Bedrock の設定をします。順に AWS マネジメントコンソールの画面スクリーンショットを追って説明します。 アクショングループには、一般検索用 AWS Lambda 関数を登録します。複数登録可能なので、決まった用途ごとに作成した Lambda 関数があれば登録し、それぞれに適切な説明を記入します。その説明内容をもとに、Agents for Amazon Bedrock が使用するアクショングループを選択することになるので説明は重要です。今回のケースでは、SCSK に関する問い合わせ以外には Claude に問い合わせるということを記載しています。たまたま英語で書きましたが、日本語でも大丈夫と思います。 ナレッジベースには、RAG 検索用ナレッジベースを登録します。複数登録可能です。こちらも同様に、用途ごとに説明を書きます。今回のケースでは、SCSK に関する情報が必要な場合はナレッジベースからデータを取得するよう指示しています。 モデルの詳細欄では、Agents for Amazon Bedrock 全体に指示する内容を書きます。1つは言語モデルで、執筆時点では Claude しか選択できませんでしたのでそれを選択しています。最重要なのはエージェントへの指示で、ここで RAG 検索と一般検索の使い分けルールを自然言語で記述します。プログラマティックな記法ではありません。今回のケースでは、日本語で回答することと、SCSK に関する情報はナレッジベースから、それ以外はアクショングループから情報を取得するよう指示しています。分岐の設定はこれだけで OK です。 アクショングループ設定時の注意点 アクショングループを設定するときには、以下 2 つの注意点があります。 AWS Lambda 関数を実行するための権限 OpenAPI の設定 AWS Lambda 関数を実行するための権限 Agents for Amazon Bedrock から AWS Lambda 関数を呼び出すには、一般的な Lambda 関数実行時と同様、呼び出し側に呼び出す権限を与える必要があります。なじみのない方もいらっしゃるかもしれませんが、Lambda 関数にリソースベースのポリシーを設定します。 AWS 公式ドキュメントのまま設定すれば OK です。 Permissions to create and manage an agent - Amazon Bedrock To use a custom service role for agents instead of the one Amazon Bedrock automatically creates, create an IAM role with the prefix AmazonBedrockExecutionRoleFo... docs.aws.amazon.com OpenAPI の設定 アクショングループを登録するときに、1 アクショングループにつき 1 つの OpenAPI スキーマを登録する必要があります。 上記スクリーンショットは途中で切れていますので、実際に使ったスキーマを以下に貼り付けます。 openapi: 3.0.0 info: title: LambdaBedrockAgentAgClaude version: 1.0.0 description: Lambda Function to invoke Bedrock Claude foundation model triggered from Bedrock Agent paths: "/": get: summary: Invoke Claude foundation model description: Invoke the Claude foundation model to answer for a general query except for the related to SCSK. responses: "200": description: response content: application/json: schema: type: object properties: body: type: string decription はおそらく Agents for Amazon Bedrock がこのアクショングループを使用するか否かを判断するのに重要だと思うので、目的を書いておきます。 paths の部分ですが、正直ここの記述は Lambda 関数を実行する上では使用しないので、適当に書いておきました。get とか書いてありますが、全く使用しません。一応定義はしないといけないので書いている感じです。これで動きました。 まとめ いかがでしたでしょうか。 Agents for Amazon Bedrock の設定は AWS マネジメントコンソールでノーコードでできます。分岐が増えた場合でも、応用してつくれると思います。 本記事が皆様のお役に立てれば幸いです。

こんにちは。SCSKのひるたんぬです。 2月も中頃となり、段々と過ごしやすい気候になってきましたね。ここ数日は気温差がすごく、服装に悩みます。 と同時に始まるのが花粉シーズン… 日本気象協会の発表 によると、今年の花粉飛散量は「例年並みか例年よりやや多い」そうです。 目鼻が悲惨なことにならないよう今から対策をしていきたいと思います。 話がそれますが、この文章を書きながら、ふと「花粉飛散量ってどうやって予測しているんだろう？」と思ったので調べました。 日本気象協会の花粉飛散予測は前シーズンの花粉飛散結果や今後の気温予測などの気象データをもとに、全国各地の花粉研究会や協力機関からの情報、花芽の現地調査の結果などをふまえて予測しています。（ 詳しい計算方法などは企業秘密です…すみません！ ） 引用元：日本気象協会 JWAニュース「 日本気象協会　2024年　春の花粉飛散予測（第3報）～まもなくスギ花粉シーズンスタート　ピークは2月下旬から～ 」 …肝心なところはやはり秘密なのですね。一方気象庁では、 （前略）花粉の飛散に影響を与える気温や風、降水等の予測データを提供しており、 今後、スーパーコンピュータやAIを活用し飛散予測を行う際の基礎情報 となる詳細な三次元の気象情報も提供して、民間事業者が実施する花粉の飛散予測をさらに支援していく計画です。 引用元：気象庁 知識・解説「 花粉飛散予測について 」 と記載があるので、これからはこのような分野にもAIが活用¹ されるのかもしれませんね！ ¹ 一部事例 もありましたが、現在はサービスの提供を行っていないようです。 話を戻します。今回は、私が配属され引き継いだ課内業務の中で、自動化できたら嬉しいなぁ…というものを、 PowerAutomateの無料枠を駆使して 実装したので、その工夫点についてご紹介いたします。 やりたいこと 今回は、 SharePoint（Microsoft Lists）に登録されたセキュリティパッチ適用に関する 発信文書をトリガーに、セキュリティパッチ適用の依頼メールを送付 する 期限日が近づいたら、 社内システムからパッチ未適用者を抽出し、リマインドメールを送付 する という2つの機能を構築しました。全体的な処理の流れを下図に示します。 今回はPower Automateのクラウドフロー（上図左・青）に加え、社内システムを利用する必要があったため、社内ネットワーク内のPCで動作するデスクトップフロー（同右・緑）を組み合わせております。 目的 現状の業務フローでは、 担当者が、セキュリティパッチ配布の発信文書の確認・メール送付、未適用者のリマインドを 手作業で行っており、担当者の人的・時間的負担 となっている という課題点がありました。私が配属後にこの担当業務を引き受けた際、「定型作業の塊だな…」と思ったので、勉強の意味合いを含めてこのフローを自動化することにしました。 これにより、フローに人間が関与することがなくなるので、 担当者の 人的・時間的負担の削減 業務の 正確・確実な遂行 が期待されます。 処理の流れ ここでは実装した処理につきまして、処理の流れに沿って概要を説明します。 太字 は、無料版で利用するために工夫した点なので、次の章にて詳しく説明いたします。 【クラウド】発信文書の登録 ▶ メール通知・カレンダー登録 このフローは、SharePointに発信文書が登録されたことにより起動します。発信文書にはセキュリティパッチの適用依頼の他にも日々多くの文書が登録されます。そのため、発信文書のタイトルにより絞り込みを行い、セキュリティパッチの適用依頼に関する発信文書のときにのみ処理を行うように設定します。下図にこのフローの大まかな流れを示します。   メールによる通知を行う前に、自分自身への事前確認を挿入しています。これにより、フローが発信文書を誤検知し誤ったメールを送付することを防ぎます。 【クラウド】カレンダーからリマインド日を検知 このフローは、毎日決まった時間に起動します。起動したらまず、その日のカレンダーを参照し、セキュリティパッチのリマインド日であるかを確認します。リマインド日であった場合は、次の デスクトップフローを実行するために自分宛てにメールを送信 します。   【デスクトップ】社内システムからパッチ未適用者を抽出 このフローは、 タスクスケジューラを用いて毎日決まった時間に起動 します。起動したら、自身のメールフォルダを確認し、リマインド日に関するメールを確認します。メールがあった場合は、社内システムにアクセスし、セキュリティパッチを適用していない方のメールアドレスを抽出します。そして、その アドレスを自分宛てに、特定の件名をつけた上で送信 します。   【クラウド】未適用者へリマインドメールを送付 このフローは、デスクトップフローで送信されたメールをトリガーとして起動します。デスクトップフローで送信されたメールかは、件名を用いて判別します。メールが存在した場合は、そのメールからメールアドレスを抽出し、 各自にリマインドメールを送信 します。   Power Automate 無料版の制約 今回の機能実装において無料版が原因で直面した主な制約は次の3点です。 「クラウドフロー」と「デスクトップフロー」間の連携は有料版のみ 無料版では、クラウドフローから他のフローの呼び出しができません。そのため、クラウドフローでカレンダーでリマインド日を検知した場合、それをデスクトップフローに通知する仕組みを一から構築する必要があります。 今回はこの仕組みをメールのやり取りによって実現しました。メールを利用したやり取りの流れを下図に示します。 これにより、デスクトップフローはクラウドフローから送信されたメール[TRIGGER]を確認することで、フローを実行するべきか判断をすることができます。また、デスクトップフローでの実行結果（抽出結果）をメール[RESPONSE]で送信することで、クラウドフローがそのメールをトリガーとして後段の処理を実行することを可能にしています。 【デスクトップ版】 トリガーも有料版のみの機能 先ほどの対処法により、クラウドフローとデスクトップフロー間での連携をすることが可能になりました。 しかし、無料版のPower Automate Desktopでは通常、フローは画面上の再生ボタン ▷（下図）をクリックし手動で実行する必要があります。 この状態ですと、先程ご紹介したクラウドフローからのメールが送られてきたとしても、手動でデスクトップフローを開始させなければなりません。これでは自動化できたとは言え無いですね… そこで、これに対処するために、Windowsに標準で搭載されているタスクスケジューラーを活用して一日一回、フローを自動実行するような処理を追加しました。 こちらにつきましては、以下の2つのサイトが非常に参考になりました。 【DX】PowerAutomate Desktop無料版を自動定期実行してみた！｜株式会社エアリー：技術ブログ みなさんこんにちは！エアリー社員のSです！ 今回はPower Automate Desktopの無償版で、 タスクスケジューラーを活用してフローの自動定期実行を実現します！！ なぜタスクスケジューラーを利用するのか Power Automate Desktopの無償版では定期実行を行うことができません。 なので、タスク... note.com [Power Automate Desktop]名前を指定してフローを実行するPowerShellスクリプト | 初心者備忘録 ここ数日、話題のPower Automate Desktop(PAD)を触っています。 多数のアクションが用意 www.ka-net.org これを参考にすることで、「デスクトップフローを毎日実行し、[TRIGGER]メールが来ていたら処理を実行する」というフローを作成することができました。 便利なアクションの多くは有料版でのみ提供 Power Automateの有料版では提供されている多くの機能、特に外部サービスとの連携について、無料版では多くが制限されています。その一例を以下に示します。 デスクトップ版… Teams・Outlookカレンダー・SharePoint など → フローをデスクトップ版に集約することができない → クラウドフロー・デスクトップフローを分けて実装 クラウド版… AWSサービス・Azure・その他外部サービス など → 今回のサービス構築には影響小 一方で、パッチ未適用者へのメール送付につきましてはデスクトップフローで行うことも可能ですが、今回はあえてメール送付のフローをクラウドフローにて実行しています。これは、無料版のクラウドフローでは、メール送付の他にもTeamsのチャットへの投稿にも対応しており、連絡方法が変更になった際にも柔軟に対応できるためです。   まとめ 今回はMicrosoftが提供するPower Automateを用いて、定型業務の自動化に取り組みました。普段はAWSに触れていますが、今回の取組を通して目的や用途に応じてサービスを使い分けることの大切さを実感しました。特定のサービスではなく、幅広いサービスを活用できるようになりたいですね！ 私の環境でもPower Automateの有料版が利用可能になる日が来ることを願って、この記事を締めくくりたいと思います。 最後までご覧いただき、ありがとうございました！

こんにちは！SCSKの江木です。 Dialogflow CXでチャットボットを作っていて、外部のAPIを利用することでチャットボットの機能を拡張したいと思うことがありました。 そのようなときに役立つのがWebhookです！ 今回はチャットボットに翻訳機能を追加するために、WebhookでTranslation APIを叩いてみようと思います！ Webhookとは？ Webhookの説明をする前に、Dialogflow CXについて触れておきます。 Dialogflow CXは、Google Cloudが提供する、自然言語理解と会話型AIの機能を備えたサービスです。一言で言うと、チャットボットを作ることが出来るサービスになります。 WebhookはこのDialogflow CXの会話セッション中に、ビジネスロジックをホストしたり、他のサービスを呼び出したりするために使います。 WebhookはCloud Functionsで実装します。また、Webhookの実行時の挙動は以下の通りです。 Webhookを使うことで外部からデータを受け取ることが出来るようになるので、ただ決まりきったことを返すだけのチャットボットに「今日の天気を返す」、「翻訳」、「外部のデータベースを検索する」などの機能を追加することができるようになるのです。   Webhook作成 Webhook作成の前にDialogflow CXのフローを作成します。また、作成する際は以下の点に留意してください。 APIキーの取り扱いには注意してください。 今回はGoogle Cloudのtranslation APIを使うので、Google Cloudに課金されますが、他のAPIを使う際はどこに課金されるのか把握しておいてください。 Dialogflow CXのフロー作成 翻訳機能をつけたいので、以下のようなフローを「asia-northeast1」リージョンで作成しました。 フローの流れは以下の通りです。 Start Pageで「こんにちは」と入力すると、「翻訳しましょう」と表示するRouteが選択され、Translateページに遷移する Translateページにて、翻訳したい言語と文章を入力すると、翻訳された文章を返す End Sessionページに遷移する   Translateページの設定は以下の通りです。   翻訳言語のパラメータであるlangのentity typeを設定しました。 Entityの値は以下のTranslation APIのドキュメントを参考にしました。 言語サポート  |  Cloud Translation  |  Google Cloud cloud.google.com Webhook作成 Translation APIに使用するAPIキーを作成 コンソールから[APIとサービス]→[認証情報]→[+認証情報を作成]→[APIキー]を押下し、APIキーをコピーします。 Cloud Functionsでwebhookを作成 1.Cloud Functionsのコンソールの[＋ファンクションを作成]を押下します。   2.関数名を入力後、「asia-northeast1」リージョンを選択し、[次へ]を押下します。   webhookをコーディング 今回はpythonを使いたいので、ランタイムはPython 3.12としました。エントリーポイントはコードの関数名と同じく、webhookとしました。 以下、main.pyのコードになります。 import functions_framework import requests @functions_framework.http def webhook(request):     response = request.get_json()   #Dialogflow CXからパラメータの取得   lang = response["sessionInfo"]["parameters"]["lang"]   text = response["sessionInfo"]["parameters"]["sentence"]     tag = response["fulfillmentInfo"]["tag"]   #$$$$$$$$$$$にはコピーしたAPIキーを入力してください。   url = "https://translation.googleapis.com/language/translate/v2?key=$$$$$$$$$$$"   params = {     "q": [text],     "target": lang,     "source": "ja"     }   #APIを叩く   output = requests.post(url, json=params)   if tag == "APITest":     #結果を格納     output_text = output.json()["data"]["translations"][0]["translatedText"]   else:       output_text = tag   response["fulfillmentResponse"] = {           "messages": [               {                   "text": {                       "text": [                           output_text                       ],                       "allowPlaybackInterruption": False                   }               }           ]       }     return response 続いて、requirement.txtは以下の通りです。こちらはmain.pyの実行に必要なpythonモジュールをインストールするために使用します。 functions-framework==3.* requests Webhookをデプロイ 1.コードが書けたら、[デプロイ]を押下します。   2.作成したWebhookのURLをコピーします。 権限設定 Cloud Functionsの第2世代はCloud Runで動作しています。それゆえに、Cloud Runの起動元の権限をDialogflowのサービスアカウントに付与する必要があります。 Dialogflow CXのサービスアカウントを確認 1.Dialogflow CXコンソールの右側にある[Agent settings]を押下します。   2.[Share]タブを選択し、Dialogflow CXのサービスアカウントをコピーします。 Cloud Runの起動元の権限をDialogflowのサービスアカウントに付与 Cloud Functionsコンソールで作成したwebhookを開き、[Powered by Cloud Run]を押下します。 画面上部の[サービスの詳細]を押下します。 作成したwebhookのCloud Runの左側ボックスにチャックを入れます。画面右の[権限]タブの中の[プリンシパルを追加]を押下します。 新しいプリンシパルにコピーしたDialogflow CXのサービスアカウントを入力し、ロールで[Cloud Run 起動元]を選択した後、[保存]を押下します。 Webhook設定 翻訳したい言語・文章をAPIに投げたいので、$page.params.status = “FINAL”ルートにWebhookを設定します。 ルートの[Webhook settings]→[Enable webhook]にチェックを入れます。 Webhookと書かれた枠内を押下し、[+Create Webhook]を選択します。 [Display name]と、webhook作成の際にコピーした[Webhook URL]を設定し、[Save]を押下します。 tagを設定し、[Save]を押下します。 実装結果 作成したAgentでテストし、翻訳機能が実装できているか確認します。 うまく翻訳機能を実装することができました。これらの他にもlangのentity typeに登録した言語であれば、翻訳することができます。 終わりに 今回はDialogflow CXのチャットボットにTranslation APIを利用して、翻訳機能をつけました。 多言語対応の翻訳機能なので、チャットボットの機能をかなり拡張できたと思います。 Translation APIの以外のAPIを利用することで様々な機能をチャットボットに搭載することが出来ます！！！ 最後まで読んでいただき、ありがとうございました。

どうも、Catoクラウドを担当している佐々木です。 Catoを使っていると、業務でアクセスするドメインが、CatoのSWG（Secure Web Gateway）機能でブロックしているカテゴリに 誤って分類され、通信できない！ということが時々ありますよね。 今回は、そんな問題が発生した場合の新しい回避策 カテゴリの手動修正  を紹介します。   ※画⾯は2024年2⽉時点のものです。機能アップデート等で変わる場合がありますので、あらかじめご了承ください。   CatoのSWG（Secure Web Gateway）について CatoのSWGでは、フィッシング、マルウェア、その他のインターネット経由の脅威からユーザーを保護します。 具体的には以下のような機能を提供しています。 70個以上の組み込みカテゴリと事前定義されたセキュリティポリシーによる即時保護 フィッシングサイトやマルウェア配信サイトに対する防御 検索エンジンによるポリシー回避の防止 カスタマイズ可能な通知によるエンドユーザーエクスペリエンスの最適化 SWGイベントのロギングとレポートによる完全な可視性   次世代L7Firewallと同じで、CMA上の 「Security」＞「Internet Firewall」 で設定できます。   なにが問題か CatoのSWGでは、特定のアプリケーションやドメインをジャンルごとに分類した「カテゴリ」で通信制御できます。 ※危なさそうなサイトやアプリケーションをまとめた「カテゴリ」でまとめて通信をブロックするなどが可能です。 ※どのアプリケーションがどのカテゴリに分類されるかは、Assets＞App Catalogで確認できます。   デフォルトでいくつかのカテゴリをブロックするルールが設定されており、また、個別に特定のアプリケーションカテゴリの ブロックルールを作成している場合もあるかと思います。   この時、 ブロックしたくない通信が誤ってブロックするカテゴリに分類されてしまい、 通信ができないという事象が発生することがありました。   これまでの対策 これまでは、こういう問題が発覚すると都度Catoに申告し、カテゴリの修正を依頼していました。 （xxxx.comは○○というカテゴリではありません。△△に修正してください、など）   だいたい3営業日程度で対応してくれましたが、それでも修正までタイムラグがあること、英語での依頼になることから、 運用担当者からすると修正までの一時対応含め、面倒な対応だったかもしれません。   これからの対策～カテゴリの手動修正～ 2024年1月29日に以下機能がリリースされました。 「Manually Override Default Domain Categorization（デフォルトのカテゴリ分類を手動で上書きする機能）」 この機能を利用すると 自身のテナント限定で特定のドメインを任意のカテゴリに 登録 する ことができます。   設定方法 「Assets」＞「App Catalog」 から 「Domain Lookup」 タブをクリックください。 検索ウィンドウでカテゴリを変更したいドメイン or URLを入力されると、ドメインが属するカテゴリが表示されます。   ▼scsk.jpで検索した結果   「Categories」 の右横にある 「Edit」 をクリックすると、任意のカテゴリに変更できます。 最後に 「Save Changes」 をクリックして完了です。   ちなみに、変更すると以下のような Audit Trail ログが残ります。   動作確認 今回は「scsk.jp」のカテゴリを「 BusinessInformation」から「Beauty」に変更してみました。 そして、Internet Firewallでアプリケーションカテゴリ「 Beauty」をブロックしてみます。   結果、以下のように「 Beauty」に分類され、 ブロックされました。   カテゴリを元に戻す方法 手動でカテゴリを変更したものの、元に戻したい場合は以下の方法で対応可能です。   Assets＞App Catalog から 「Domain Lookup」 タブをクリックください。 右端に表示されている 「 Show Account Overridden Domains」 をクリックすると、上書きしたドメイン一覧が表示されます。   削除したいドメインの右端にある 「ゴミ箱 アイコン」 をクリックすると、上書き設定が削除されます。 ※該当ドメインのカテゴリは初期設定に戻ります。 注意点 2024年2月時点ですべてのカテゴリが編集可能なわけではないようです。 ＜＜KBより抜粋＞＞ Only categories based on URL filtering services are editable. System categories defined by the Cato Security Research team can’t be edited.         “Catoセキュリティリサーチチームが定義したシステムカテゴリは編集できません”   実際何が変更できないかCatoにも確認してみましたが、現時点ではリストのようなものを提示することができないようで、 自分で設定変更しようとしてできないものがあれば、Catoに変更を依頼する必要があるとのことです。   まとめ 今回のポイントです。   ・ドメインのカテゴリを手動で変更できるようになった （Assets＞App Catalog ＞ Domain Lookupから） ・カテゴリ誤分類による通信トラブルが発生してもすぐに修正できるようになった ・ただし、仕様としてカテゴリ修正できない場合もある（この場合はCatoに変更依頼が必要） ・Catoの運用がちょっと楽になったかも！？   上記以外の情報についても弊社の 「Catoに関するFAQサイト」 に多数情報ございますのでご参考にください。 よくあるご質問 | Cato Cloud ケイトクラウド - SCSK Cato SASE Cloud Platform. powered by SCSK cato-scsk.dga.jp   最後に、SCSKではPoCから導入、運用まで幅広くCatoに関する支援を行っております。 本番構成への移行を見据えたPoC構成や、PoCでつまづきやすい点のサポートなど、豊富な導入実績を基にご支援いたします。 ぜひお声がけください！

こんにちは、SCSKでAWSの内製化支援『 テクニカルエスコートサービス 』を担当している貝塚です。 もっとNetwork Firewallの勉強がしたいのです 最近、AWS Network Firewallを触る機会が増えています。 インターネットを検索すれば、 Transit Gatewayと併用して、複数のVPC間通信やオンプレミスとの通信、インターネットとの通信など、Transit Gatewayを通るすべての通信をNetwork Firewallで検査するInspection VPCの構築方法を説明したAWSの記事 を読むことができます。ClassmethodさんやサーバーワークスさんなどのブログでもNetwork Firewallに関する記事を見つけることができます。もちろんAWS公式のマニュアルもあり、眺めていると日々項目が充実していくのが分かります。 それでも！！ Network Firewallに関するノウハウを知ることのできる記事が圧倒的に足りません[1]。設定項目の説明は公式マニュアルを見れば書いてあるかもしれませんが、こういうユースケースの時はこの設定を選ぶのがよい、こういう設定をするとこういうことができるのでおすすめです、などの情報が 分かりやすく (重要)説明された記事は、実際にNetwork Firewallを構築して運用してみようという人にとって十分なものとは言い難いと感じます。 [1] Network FirewallはSuricataというオープンソースのIDS/IPSソフトウェアをベースに作られているので、Suricataの情報を探して読めば必要なことの多くは知ることができるのかもしれませんが、そちらへはあまり足を踏み出せていません……。   というわけでそれでも何か情報が落ちていないかと探していると…… AWS re:Inforce 2023 でそれなりの数のNetwork Firewallに関するセッションがあったことが分かりました。 早速、動画を視聴してみる、のです、が……私、英語、聞き取れないんですよね。最近のYouTube動画は英語字幕もついていますが、スピーカーの速度に合わせて字幕を読みつつスライドも読むとなるとまったく追いつきません。これを丁寧に繰り返し観ていたら、時間がいくらあっても足りない…… やりたいこと そこで、考えました。生成AIを使って効率よくAWS Network Firewallの勉強できないか、と。生成AIにはハルシネーションと呼ばれる、事実に基づかない嘘情報を返す現象があることはよく知られていますので、生成AIにただ質問するだけではろくな成果が得られないであろうことは火を見るよりも明らかです。 しかし幸いにもAWSでは昨年11月にKnowledge Base for Amazon BedrockというRAG(Retrieval-Augmented Generation/検索拡張生成)のサービスが一般提供を開始していますので、動画の字幕情報やプレゼンテーションのスライドを登録してやれば、内容を要約してもらったり、要約からさらに知りたい部分を詳しく説明してもらったりすることが可能なのではないでしょうか……？ データの準備 先ほどの、AWS re:Inforce 2023のNetwork and Infrastructure Security関連の動画一覧 からNetwork Firewallに関係ありそうな動画を見繕い、字幕をダウンロードします。字幕のダウンロードにはこちらのサイト( DownSub.com )を利用しました。(特におすすめサイトというわけでもないので、ご利用は自己責任でお願いします)。字幕に表示時刻を併記したsrtという形式のファイルもダウンロードできますが、あまりメリットを得られなさそうだったのでtxt形式でダウンロードしています。 ついでに動画に対応するプレゼン資料(PDF)もダウンロードし、他にもSecurity JAWSの日本語のプレゼン資料なども加えました。Knowledge Base for Amazon Bedrockに登録した動画字幕およびプレゼン資料は下記一覧の通りです。この一覧も念のためテキストファイルにしてKnowledge Baseに登録しています。 Title: Security-JAWS DAYS - AWS Network Firewall && DNS Firewallで解決できること YouTube URL: PDF URL: https://speakerdeck.com/tsumita/20230826-securityjaws-nwfw-dnsfw Title: AWS re:Inforce 2022 - Deploying AWS Network Firewall at scale: athenahealth's journey (NIS308) YouTube URL: https://www.youtube.com/watch?v=VMVeTvX4OLw PDF URL: https://d1.awsstatic.com/events/aws-reinforce-2022/NIS308_Deploying-AWS-Network-Firewall-at-scale-athenahealths-journey.pdf Title: AWS re:Inforce 2023 - Policy and Suricata compatible rule creation for AWS Network Firewall (NIS308) YouTube URL: https://www.youtube.com/watch?v=67pVOv3lPlk PDF URL: https://d1.awsstatic.com/events/Summits/awsreinforce2023/NIS308_Policy-and-Suricata-compatible-rule-creation-for-AWS-Network-Firewall.pdf Title: AWS re:Inforce 2023 - How AWS threat intelligence becomes managed firewall rules (NIS301) YouTube URL: https://www.youtube.com/watch?v=oURlWfLjdqE PDF URL: https://d1.awsstatic.com/events/Summits/awsreinforce2023/NIS301_How-AWS-threat-intelligence-becomes-managed-firewall-rules.pdf Title: AWS re:Inforce 2023 - Outbound security implementation with AWS Network Firewall & Route 53 (NIS305) YouTube URL: https://www.youtube.com/watch?v=9zDk-EaMUpc PDF URL: https://d1.awsstatic.com/events/Summits/awsreinforce2023/NIS305_Outbound-security-implementation-with-AWS-Network-Firewall-and-Route-53.pdf Title: AWS re:Inforce 2023 - Build secure global connectivity with AWS (NIS302) YouTube URL: https://www.youtube.com/watch?v=4pywOCWTXyQ PDF URL: https://d1.awsstatic.com/events/Summits/awsreinforce2023/NIS302_Build-secure-global-connectivity-with-AWS.pdf Title: AWS re:Inforce 2023 - Advanced approaches to traffic inspection & network diagnosis w/ AWS (NIS304) YouTube URL: https://www.youtube.com/watch?v=c3xzxvyD14U PDF URL: https://d1.awsstatic.com/events/Summits/awsreinforce2023/NIS304_Advanced-approaches-to-traffic-inspection-and-network-diagnosis-with-AWS.pdf Title: AWS re:Inforce 2023 - Achieving Zero Trust with AWS application networking (NIS307) YouTube URL: https://www.youtube.com/watch?v=PiCtF_XbZTM PDF URL: https://d1.awsstatic.com/events/Summits/awsreinforce2023/NIS307_Achieving-Zero-Trust-with-AWS-application-networking.pdf Title: AWS re:Inforce 2023 - Firewalls, and where to put them (NIS306) YouTube URL: https://www.youtube.com/watch?v=lTJxWAiQrHM PDF URL: https://d1.awsstatic.com/events/Summits/awsreinforce2023/NIS306_Firewalls-and-where-to-put-them.pdf Title: AWS re:Inforce 2023 - Setting up AWS Verified Access (NIS223) YouTube URL: https://www.youtube.com/watch?v=GaDqIZ5bQBc PDF URL: https://d1.awsstatic.com/events/Summits/awsreinforce2023/NIS223_Setting-up-AWS-Verified-Access.pdf Title: AWS re:Inforce 2023 - Use AWS Network Firewall for enterprises: Egress & ingress inspection (NIS222) YouTube URL: https://www.youtube.com/watch?v=lDavmXWdBTI PDF URL: https://d1.awsstatic.com/events/Summits/awsreinforce2023/NIS222_Use-AWS-Network-Firewall-for-enterprises-Egress-and-ingress-inspection.pdf Title: AWS re:Inforce 2023 - Deploy distributed egress policies with a central AWS Network Firewall (NIS233) YouTube URL: PDF URL: https://d1.awsstatic.com/events/Summits/awsreinforce2023/NIS233_Deploy-distributed-egress-policies-with-a-central-AWS-Network-Firewall.pdf Title: AWS re:Inforce 2023 - Enhance network security by integrating with AWS Security Hub (NIS251) YouTube URL: PDF URL: https://d1.awsstatic.com/events/Summits/awsreinforce2023/NIS251_Enhance-network-security-by-integrating-with-AWS-Security-Hub.pdf Title: AWS re:Inforce 2023 - Managing multi-Region & multi-account AWS Network Firewall resources (NIS341) YouTube URL: PDF URL: https://d1.awsstatic.com/events/Summits/awsreinforce2023/NIS341_Managing-multi-Region-and-multi-account-AWS-Network-Firewall-resources.pdf Title: AWS re:Inforce 2023 - Codify your network security compliance at scale with AWS Network Firewall and IaC (NIS342) YouTube URL: PDF URL: https://d1.awsstatic.com/events/Summits/awsreinforce2023/NIS342_Codify-your-network-security-compliance-at-scale-with-AWS-Network-Firewall-and-IaC.pdf Title: AWS re:Inforce 2023 - AWS Network Firewall & DNS Firewall security in multi-VPC environments (NIS373) YouTube URL: PDF URL: https://d1.awsstatic.com/events/Summits/awsreinforce2023/NIS373_AWS-Network-Firewall-and-DNS-Firewall-security-in-multi-VPC-environments.pdf Title: AWS re:Inforce 2023 - Stopping zero-day attacks and ransomware with effective egress controls (NIS374) YouTube URL: PDF URL: https://d1.awsstatic.com/events/Summits/awsreinforce2023/NIS374_Stopping-zero-day-attacks-and-ransomware-with-effective-egress-controls.pdf Knowledge Baseの作成 字幕テキストファイル、プレゼン資料、資料一覧をひとつのS3バケットに放り込み、対応リージョン(今回はオレゴンを利用)のAmazon Bedrock → ナレッジベース から、ナレッジベースを作成します。ナレッジベースの作成は、下記記事を参考にしました。 生成AI初心者がAmazon BedrockのKnowledge baseを使ってRAGを試してみた AWS re:Invent2023にて、Amazon BedrockのKnowledge baseとAgentsがGAされたと発表がありました。今回はこのうちKnowledge baseを利用して、RAG（Retrieval Augment Generation）を試してみたいと思います。 blog.usize-tech.com 2023.12.07 ナレッジベースに質問してみる 今回は私自身がNetwork Firewallの勉強をできればそれでよいので、ナレッジベースに付属しているテスト画面で早速質問を入れてみます。基盤モデルにはAnthropic Claude 2.1を使用しました。また、ほぼ英語しか入っていないナレッジベースに日本語で質問しても翻訳の問題に悩まされそうなので、英語で質問して英語で回答してもらっています。 ネットワークファイアウォールのベストプラクティスを聞く Please provide a list of 10 best practices for the design and configuration of AWS Network Firewall. Network Firewallの設計・設定のベストプラクティスを10個挙げてもらうことにしました。実は事前に(聞き取れないのを頑張って)『 Policy and Suricata compatible rule creation for AWS Network Firewall (NIS308) 』の動画を視聴しており、その中で10個のベストプラクティスが紹介されていることを知っていました。ですので、AIが回答しやすい、易しい質問のはずです。 回答がこちら。 わりとしっかり回答できている感じがしますね。回答をどのデータソースから引っ張ってきたのか分かるように注がつくのもありがたいです。ただ、データソースの一覧を見ていると、字幕ファイルがひとつもないことが分かりました。 ……調べてみるとPDFの方に10個のベストプラクティスを一覧にしたスライドがあり、回答はそのスライドをまるまる引っ張ってきているだけでした。……まあ今回の質問はPDFの方に「正解」がそのまま書かれているわけですから、仕方ない。 返してきたベストプラクティスのうちのひとつについて詳しく説明するようにお願いしてみます。 詳細を尋ねる Please elaborate “8. Prefer “flow:to_server, established”” ちゃんと説明にはなっています。ただやっぱり気になるのは、データソースがPDFしかありません。字幕ファイルが仕事してくれない……。他にもいくつか詳細を聞いてみましたが、データソースになるのはPDFばかりで、字幕ファイルが出てきません。 ちなみに、PDFをナレッジベースに入れる前(字幕ファイルしかないとき)に同じ質問(ベストプラクティス10個)をしたらどうなったかというと、こちら。 10個挙げてくれていないし、回答も嘘ではないけれども特に意味もない情報という感じです。動画字幕から適切な情報を得るのは難しいのかな？？ ここに至り、複数の動画字幕/プレゼン資料から適切な情報を抜き出してくてくれると期待するのはあきらめて、動画を指定して内容の要約をやってもらうことにします。 動画の要約を作成する ナレッジベースに登録したうちのひとつのプレゼンテーションを指定して要約を作成してもらうことにします。 Please summarize the presentation “AWS re:Inforce 2023 – Outbound security implementation with AWS Network Firewall & Route 53 (NIS305)” in approximately 200 words. 字幕ファイルの冒頭にプレゼンテーションタイトルを追記しておいたので、それを足掛かりにうまく要約してくれるかもしれません……！ ……唯一の引用マークは、私が作った動画一覧を参照しています……。これでまともな要約が作れるわけがない……と思いきや、要約自体はそこまで悪くない感じがします。 Bedrockには retrieveというAPI があり、プロンプトを投げるとナレッジベースから情報を検索し、検索結果と関連度スコアを表示してくれます。これを使って、いったいどういう情報を使って答えてくれたのか確認してみましょう。 以下、APIのレスポンスです。 { "ResponseMetadata": { (略) "retrievalResults": [ { "content": { "text": "v=oURlWfLjdqE\r PDF URL: https://d1.awsstatic.com/events/Summits/awsreinforce2023/NIS301_How-AWS-threat-intelligence-becomes-managed-firewall-rules.pdf\r \r Title: AWS re:Inforce 2023 - Outbound security implementation with AWS Network Firewall & Route 53 (NIS305)\r YouTube URL: https://www.youtube.com/watch?v=9zDk-EaMUpc\r PDF URL: https://d1.awsstatic.com/events/Summits/awsreinforce2023/NIS305_Outbound-security-implementation-with-AWS-Network-Firewall-and-Route-53.pdf\r \r Title: AWS re:Inforce 2023 - Build secure global connectivity with AWS (NIS302)\r YouTube URL: https://www.youtube.com/watch?v=4pywOCWTXyQ\r PDF URL: https://d1.awsstatic.com/events/Summits/awsreinforce2023/NIS302_Build-secure-global-connectivity-with-AWS.pdf\r \r Title: AWS re:Inforce 2023 - Advanced approaches to traffic inspection & network diagnosis w/ AWS (NIS304)\r YouTube URL: https://www.youtube.com/watch?" }, "location": { "type": "S3", "s3Location": { "uri": "s3://xxxxxxxxxxxxxxxx/KnowlegeBase/file_list.txt" } }, "score": 0.80244076 }, (略) { "content": { "text": "\u00a9 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved. \u00a9 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved.\u00a9 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved. Codify your network security compliance at scale with AWS Network Firewall and IaC Adil Kazi (he/him) N I S 3 4 2 Cloud Infrastructure Architect AWS Pradeep Kumar (he/him) Cloud Infrastructure Architect AWS \u00a9 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved. Problem statement \u2013 Why? Solution \u2013 What and how? Let\u2019s code Agenda \u00a9 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved. Prerequisites \u2022 Terraform installed \u2022 AWS Organizations \u2022 AWS Config enabled \u2022 AWS Resource Access Manager (AWS RAM) enabled \u2022 Management AWS account with an IAM user that has the appropriate permissions \u2022 Spoke AWS account with an AWS Network Firewall policy deployed \u00a9 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved." }, "location": { "type": "S3", "s3Location": { "uri": "s3://xxxxxxxxxxxxxxxx/KnowlegeBase/NIS342_Codify-your-network-security-compliance-at-scale-with-AWS-Network-Firewall-and-IaC.pdf" } }, "score": 0.7409537 }, (略) { "content": { "text": "Title: AWS re:Inforce 2023 - Outbound security implementation with AWS Network Firewall & Route 53 (NIS305) - Hello everyone and welcome to our session on Outbound security with AWS Network Firewall and DNS Firewall. Super excited to be with our customer, Robinhood. - I'm Paul Radulovic, head of platform security for Robinhood. - All right, so agenda-wise we're gonna be looking at what is egress security, a quick overview of this two primary security services that we see customers being successful with around egress control. And then why are customers doing this? You know, why are customers investing and spending time on this? Then we'll zoom in a little bit on a specific exploit just to understand how these things typically work and the opportunities that we have to both detect and block bad things from happening. And then I'll pass it off to Paul to talk about Robinhood's egress security journey. So what in the world is egress security? Egress security, in terms of an AWS VPC, it's really your workloads making a network connection out to somewhere else, usually the internet, right?" }, "location": { "type": "S3", "s3Location": { "uri": "s3://xxxxxxxxxxxxxxxx/KnowlegeBase/[English] AWS re_Inforce 2023 - Outbound security implementation with AWS Network Firewall & Route 53 (NIS305) [DownSub.com].txt" } }, "score": 0.73764765 }, (略) { "content": { "text": "\u00a9 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved. \u00a9 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved.\u00a9 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved. Outbound security implementation with AWS Network Firewall & Route 53 Jesse Lepich N I S 3 0 5 Sr. Security Solutions Architect AWS Paul Radulovic (he/him) Head of Platform Security Robinhood \u00a9 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved. Agenda What is egress security Quick overview of AWS Network Firewall & Route 53 Resolver DNS Firewall Why are AWS customers spending time on egress security? Anatomy of an exploit Robinhood\u2019s egress security journey, lessons learned, and best practices \u00a9 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved.\u00a9 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved. What is egress security? \u00a9 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved. What is egress security?" }, "location": { "type": "S3", "s3Location": { "uri": "s3://xxxxxxxxxxxxxxxx/KnowlegeBase/NIS305_Outbound-security-implementation-with-AWS-Network-Firewall-and-Route-53.pdf" } }, "score": 0.7173835 }, (略) uriが、S3のどのファイルから情報を検索してきたか、textが抜き出してきたテキスト、scoreが関連度スコアです。uriを見ると、要約したかったNI305の字幕ファイルもPDFも含まれているので、虚空から回答を作り出したわけではなさそうです。 まとめ AWSのイベントの動画(字幕)とプレゼン資料PDFをRAG(Knowledge Base for Amazon Bedrock)のデータソースにして、AWS Network Firewallの勉強に使えるかを試してみました。所感は以下の通りです。 字幕情報だけではろくな回答が出力されず、予想以上に役に立っていなかった。なぜこれほど有用情報の検索に寄与しなかったのか考えるのは今後の課題。 プレゼン資料PDFは逆に予想よりは役に立った。パワーポイント系の資料がもとになっているので、文字が細切れになっていたり、画像化されている文字情報も多く、あまり役に立たないのではないかと予想していた。細切れにはなっていても要点はしっかりまとめられていたということだろうか。 Knowledge Base for Amazon Bedrockが裏でプロンプトエンジニアリングを頑張ってくれている[1]とはいえ、より適切な情報を引き出すためにプロンプトエンジニアリングをもっと頑張る必要があったのかもしれない。 結果的には、自分の知らない情報を効率よく知ることができたとは言い難い。(この記事を執筆するために結局一部のプレゼンPDFを読むことになり、そちらの作業の方が実りあるものだった) [1] Knowledge Base for Amazon Bedrockの実行ログはCloudWatch Logsに出力されます。このログを見ると、ハルシネーションが発生しないようにしたり、情報をどこから引用したのか分かるようにIDをつけるように指定したりと、裏でのプロンプトエンジニアリングの努力が垣間見えます。 おまけ Knowledge Base for Amazon Bedrockで試行錯誤しているうちに、Microsoft CopilotでYouTube動画の内容を要約できると知り、試してみることにしました。対象動画は、前述のNetwork Firewall Top 10 best practices を説明している Policy and Suricata compatible rule creation for AWS Network Firewall (NIS308) です。 自分 この動画を要約してください。 Copilot この動画の要約 [00:00:02]1 – [00:28:13]2:           この動画では、AWS Network FirewallとSuricata互換のルール作成について説明しています。Suricataのベストプラクティスやポリシーの考慮事項について解説し、カスタムSuricataルールの作成方法をデモで紹介しています。 ハイライト: [00:01:07]3 AWS Network Firewallの概要 高可用性、フルマネージド、スケーラブルなサービス AWSが提供する脅威シグネチャやドメインの管理ルールセットを利用可能 Suricataという強力で柔軟なルールエンジンを使用 ディープパケットインスペクションやプロトコル検証などの機能を提供 (以下略) いいですね！実行するたびに出力内容が違って、要約の品質にもだいぶ幅があるのが気になりますが、嘘らしい嘘はついていないように思います。その内容が動画のどの時間で言及されているか記載があるのもとてもありがたいです。 動画内容の詳細を質問してみます。 自分 この動画で説明されているSuricataルールの例について、この動画で説明されている範囲でできる限り詳しく説明してください。 Copilot この動画では、カスタムSuricataルールの例として、以下のようなルールを紹介しています。          TLSトラフィックを許可するルール：このルールは、TLSプロトコルを使用しているトラフィックを検出し、パスアクションで許可します。2このルールは、tls.versionというキーワードを使って、TLSのバージョンを指定します。34このルールは、tls.sniというキーワードを使って、TLSのサーバ名を指定します。 TCPトラフィックをブロックするルール：このルールは、TCPプロトコルを使用しているトラフィックを検出し、ドロップアクションでブロックします。5このルールは、flowというキーワードを使って、トラフィックの方向と状態を指定します。67このルールは、flow:to_server,establishedというオプションを使って、TLSトラフィックを許可するルールと同じレベルで評価されるようにします。8 HTTPトラフィックをログに記録するルール：このルールは、HTTPプロトコルを使用しているトラフィックを検出し、アラートアクションでログに記録します。このルールは、http.methodやhttp.hostといったキーワードを使って、HTTPのメソッドやホスト名を指定します。このルールは、msgやsidといったキーワードを使って、ログに表示するメッセージやルールのIDを指定します。 UDPトラフィックをポート番号で制限するルール：このルールは、UDPプロトコルを使用しているトラフィックを検出し、ドロップアクションで制限します。このルールは、ヘッダー部分にポート番号を指定することで、特定のポートに対するトラフィックをフィルタリングします。このルールは、dsizeというキーワードを使って、データサイズを指定します。 ドメイン名を許可するルール：このルールは、TLSやHTTPの通信におけるドメイン名を検出し、パスアクションで許可します。2このルールは、tls.sniやhttp.hostといったキーワードを使って、ドメイン名を指定します。4このルールは、contentやpcreといったキーワードを使って、ドメイン名のパターンを指定します。 これらのルールの詳細な説明やデモは、動画の[00:36:00] 1 から[00:49:54] 2 までの部分をご覧ください。この部分では、ルールの構文やオプション、効果やログの確認方法などを具体的に示しています。この情報が役立つことを願っています。9他に何か質問がありましたら、お気軽にどうぞ。10よろしくお願いいたします。11 「この動画で説明されている範囲で」という限定をつけてみましたが、どうやら動画で触れられていない内容が紛れ込んでいるように見えます(UDPトラフィックのdsizeキーワードとか)。このあたりはもっと厳密にプロンプトエンジニアリングをしてあげなければいけないところなのでしょうか。Knowledge Base for Amazon Bedrockを使って得た回答に比べるとはるかに内容が充実していて勉強できている感はありますが、誤情報が紛れ込んでいないか油断のできないところです。最後の段落の「この情報が役立つことを願っています」「他に何か質問がありましたら、お気軽にどうぞ」あたりがいかにもChatGPTっぽく、不安を増幅してくれます。 また、「dsizeというキーワードを使って、データサイズを指定します」とか「contentやpcreといったキーワードを使って、ドメイン名のパターンを指定します」とか、詳細を語っているっぽいキーワードを散りばめていて何だか分かった気分になれますが、結局どう使えばよいのかまではよくわかりません。これは動画ではスライドを使って「このルールはこれこれこういう意味で…」と説明しているのに対して、おそらく音声(字幕)情報だけ使用して回答を生成していることを考えると仕方のないことかもしれませんが、結局、詳細を知ろうとすると動画の該当箇所を観ることは避けられないようです。もちろん、この出力を読んだうえで動画を観るのとそうでないのとでは理解度が全く違うので、これだけでも非常にありがたいことではあります。 おまけ　その2 この記事を書くためにPDF資料を読み込んでいたら、半月ほどず～っと悩んでいた事象に対する答えが見つかりました。 ( https://d1.awsstatic.com/events/Summits/awsreinforce2023/NIS308_Policy-and-Suricata-compatible-rule-creation-for-AWS-Network-Firewall.pdf より引用)  TCPはTLSより低レイヤのプロトコルだから、ルールの順序を無視してTCPのルールが先に適用される、とのこと。そういうことだったのか……(納得)。 この情報は生成AIを使った勉強では一切引っかかりませんでした。結局自分で資料を読み込むのが一番ということなんですかねえ。

本記事の内容は、以下のCato Networks社の記事を元に日本語へ意訳、再構成したものとなります。 Cato Firewall-as-a-Service (FWaaS) Cato Secure Web Gateway (SWG) CatoクラウドのFWaaS、およびSWGは、標準サービス内に含まれます。セキュリティオプション（追加費用）は不要です。 それでは、CatoクラウドのFWaaSとSWGについて解説します。 Cato FWaaSについて Firewall-as-a-Service（FWaaS）は、ファイアウォールやその他のネットワークセキュリティ機能をクラウドサービスとして提供する新しく画期的な方法です。レガシーな物理ファイアウォールや仮想ファイアウォールの制約や複雑さを解消し、ネットワークセキュリティをあらゆる場所で一貫して利用できるようにします。 死角のない完全なトラフィック検査 Catoクラウドは、クラウドProxyやSSE（Security Service Edge）と異なり、インターネット（南北）だけでなくWAN（東西）を含むすべての送信元からすべての宛先へのネットワークトラフィックを検査します。これには、HTTP（S）トラフィックだけに限らず、すべてのポートとプロトコルのトラフィックが含まれます。 Catoは、企業が本社・拠点とデータセンターの両方のファイアウォールアプライアンスを廃止し、CatoクラウドのFWaaSに置き換えるのを支援します。Catoは、従来のファイアウォール機能をすべてネットワーク（プロキシではなく）アーキテクチャで、クラウドからマルチギガスループットで提供できるため、ファイアウォールの廃止が可能です。 Cato FWaaSを使用することで、企業はコンフィギュレーションのギャップや盲点を回避し、データ侵害のリスクを低減することができます。 スケーラブルなファイアウォールルールセット管理 Cato FWaaSは、ルールセット内の順序に基づいてルールを処理し、最初のヒットで停止します。ルールセットが多数のルールで溢れるのを避けるため、各ルールに特定の例外設定をすることもできます。Catoは、管理者がルールをセクションにグループ分けすることで、読みやすくし、サードパーティの監査人が効率的にレビューできるようにします。 Catoは、ルールで使用できる豊富なオブジェクトセット（ユーザーID、組織単位、デバイス、ホスト、アプリケーション、プロトコル、ロケーション、ネットワーク、VLAN、その他多数）と、複数のオブジェクトタイプを組み合わせることができる論理グループで管理する機能を提供します。 ※ファイアウォールアプライアンスと異なり、ルールやオブジェクトに制限（上限）はありません。 詳細な分析とレポートのための完全なログとモニタリング Cato FWaaSのすべてのルールとアクションは、イベントを記録し、Catoクラウドのプラットフォームに保存するよう設定できます。 電子メール通知は、定義された期間中に繰り返される選択されたイベントについて、定義された緊急度で警告するように設定することができます。 イベントのモニタリングと分析は、専用のダッシュボードや、使いやすい検索とフィルタリングを提供するイベントモニタリングインタフェースを通じて利用できます。 監査証跡は、追跡、監視、監査のためにすべての管理者の活動を記録します。 あらゆるニーズに対応する無制限の処理・検査能力 CatoクラウドのFWaaSは、クラウドネイティブなソフトウェアアーキテクチャを採用したクラウドサービスです。また、自律的かつ弾力的なスケーリングとセルフヒーリングにより、高いパフォーマンスとサービスの回復力を保証します。 Catoは、管理者がパフォーマンスや可用性を心配することなく、TLSインスペクションを含むすべての機能を有効にし、任意のタイプと数のオブジェクト、グループ、ルールを使用できるようにします。 Catoのクラウドネイティブ・ソフトウェア・アーキテクチャは、CPU負荷、パケットドロップ、デバイス障害によるレイテンシーの増加の懸念を排除します。同様に、計算能力不足によるアプライアンスの中途交換のリスクも回避できます。 リスク低減のマイクロセグメンテーション、アクセス制御、ゼロトラスト マイクロセグメンテーションは、機密性の高いリソースへのアクセスを制限するために簡単に設定することができます。グループ、ネットワーク、VLAN、およびホストやユーザーなどの個々のオブジェクトに基づいてポリシーを設定し、ビジネス要件を満たすきめ細かなアクセスを管理できます。ゼロトラストのために、Catoは、管理者がユーザーのアイデンティティだけでなく、地理的な位置、接続方法、セキュリティ姿勢などを考慮したアイデンティティ間、アイデンティティからアプリ、アプリ間のアクセスポリシーを設定することができます。 DPIベースのアプリケーションとユーザーの認識（識別） CatoクラウドのFWaaSには、すべてのポートとプロトコルにまたがる何千ものアプリケーションに対する認識が組み込まれており、カスタムアプリケーションを定義する機能もあります。 Deep Packet Inspection（DPI） エンジンは、ペイロードを解読することなく、最初のパケットと同時にアプリケーションやサービスを識別します。 Catoは、ユーザとそのユーザが所属する組織単位のアイデンティティを考慮したポリシーの設定と実施を可能にします。ユーザディレクトリと同期し、Catoクライアントのアイデンティティエージェントを使用することで、ユーザアイデンティティがすべてのネットワークフローに関連付けられます。 ※Catoクライアントは、アイデンティティエージェントとして機能します。   Cato SWGについて Cato SWG（Secure Web Gateway）は、インターネットの脅威から保護するための追加レイヤーを提供することで、セキュリティを強化し、Webサイトのコンテンツとリスク分類に基づいて、Webサイトアクセスの企業基準を実施します。 80以上の組み込みカテゴリと事前定義されたセキュリティポリシーによる即時保護 CatoクラウドのSWGは、インターネットセキュリティのベストプラクティスに沿った、すぐに使えるポリシーを提供します。一度有効化されたポリシーは、即座に企業全体に適用されます。また、Cato SWGには、80以上のカテゴリに分類されたWebサイトが含まれており、管理者は、機密性の高いコンテンツや不適切なコンテンツへのアクセスを管理する企業のコンプライアンス要件を容易に遵守できます。必要に応じて、ユーザーID、場所、デバイスなどの詳細な属性を使用してポリシーを絞り込むことができます。また、各ポリシーに対して、管理者は許可、ブロック（Block）、プロンプト（Prompt）などの必要なアクションを選択できます。 フィッシングおよびマルウェア配信サイトからの防御 悪意のあるドメイン、危険なドメイン、フィッシングドメイン、およびパークドメイン（ドメインのみが存在）カテゴリーをブロックすることで、ユーザーがWeb上の脅威にさらされる可能性を低減します。Catoは、常に変化するドメインランドスケープ全体で悪意のあるドメインの最新のブラックリストを維持し、最適なセキュリティ態勢を確保します。悪意のあるサイトへのアクセス試行は、記録、さらなる分析、セキュリティトレーニングの優先順位付け、常習犯の識別のためにログに記録することができます。 検索エンジンによるポリシー迂回の防止 検索エンジンでは、ユーザーが検索エンジンのドメインから離れることなく、画像を閲覧したり、動画コンテンツをプレビューしたりできるため、組織のコンプライアンス・ポリシーを回避できることがよくあります。CatoクラウドのSWGは、管理者が一般的な検索エンジンのセーフサーチとYouTubeのコンテンツ制限を実施することを可能にし、ユーザによるポリシーの回避を防ぎます。この機能は数回クリックするだけで有効化でき、最小限の労力ですべてのユーザーとロケーションの保護を強化できます。 カスタマイズ可能な通知でエンドユーザーエクスペリエンスを最適化 CatoクラウドのSWGは、Webサイトへのアクセスが妨げられたり、遅延したりした場合に、ユーザーに明確な通知を行い、例外を要求したり、エラーを報告したりすることができます。管理者は、Catoのブロック（Block）とプロンプト（Prompt）ページを自由うにカスタマイズして、企業ブランドロゴや、情報システム部の連絡先、再カテゴライズ要求のプロセスなど、ユーザーに提供される特定の通知テキストを組み込むことができます。 ※ブラウザにセットされている言語での自動切換え表示も可能です。 SWGイベントのログとレポートによる総合的な可視性 すべてのイベントデータは自動的に保持され、Catoのデータレイクに正規化され、SIEM（Security Information and Event Management）のような機能を備えた組み込みのイベントエンジンを使用してクエリできます。管理者は、一般的なユースケースをカバーする様々な定義済みクエリから選択するか、必要なフィルタを選択してカスタムクエリを迅速に構築できます。PDFレポートも生成でき、監査や経営陣の可視化を目的としたドキュメントを簡単に作成できます。   まとめ Catoクラウドの標準サービスに含まれるFWaaSとSWGの記事をご紹介させていただきました。 Catoクラウドに少しでも興味をお持ちになられた方は、遠慮なくSCSKまでお問い合わせください。 SASE、Cato Networks社、Catoクラウド（Cato Cloud/Cato SASE Cloud）自体の知名度もまだまだ低い状況です。 SCSKでは、2021年からSASEの主要ソリューションを一同に紹介を行うオンラインセミナー「SCSK SASE Solution Summit（通称S4 エスフォー）」を定期的に開催しております。これまで14回開催し、1,800名以上の方にご参加いただいております。 S4については、次回2024年4月以降に開催する予定ですので、改めてご案内します。 来月、2024年3月14日に、Catoクラウドの主要機能を2時間・デモ形式でご覧いただけるセミナーを開催しますので、ご興味のある方は是非ご参加ください。 Catoクラウドデモセミナー～Catoクラウドの主要機能を2時間で網羅～ 本セミナーでは、世界初のSASEである「Catoクラウド」の概要をたっぷり2時間、デモ形式でご覧いただきます。 また、ご希望の方（先着10名様）は、デモ環境に対して、お手元の環境からハンズオン形式でCatoクラウドに触れて頂くことが可能な参加型セミナーです。 www.scsk.jp SASE、Catoクラウドセミナー以外に、Catoクラウドのお客様導入事例の制作、FAQサイト運営、この TechHarmony（技術ブログ）で、皆様のお役に立て、Catoクラウドの知名度アップに少しでも貢献できればと考えております。

本記事の内容は、以下のCato Networks社の記事を元に日本語へ意訳し、再構成したものとなります。 CatoクラウドのIPSおよびNGAMは、標準サービスではなく、セキュリティオプション「 Threat Prevention 」に含まれるサービスとなります。 以前は、マルウェア対策（Anti-Malware：AM）、次世代型のマルウェア対策（Next-Generation Anti-Malware：NGAM）、不正侵入検知システム（Intrusion Prevention System：IPS）が、それぞれ3つのセキュリティオプションとして存在していましたが、AM、NGAMが、NGAMとして統合され、さらに2024年2月に、NGAMとIPSが、 Threat Preventionへ統合されています。 それでは、IPSとNGAMについてそれぞれ解説します。 Cato IPSについて CatoクラウドのIPSは、既知および未知のエクスプロイトを利用する高度な脅威や攻撃から組織をリアルタイムに保護します。IPSによる保護は、インターネット、WAN、クラウドを含むすべてのトラフィックに適用され、ランサムウェアの配信や伝播、データの盗難を防止します。 リアルタイムAI/MLによるフィッシング＆マルウェア対策 攻撃者は、レピュテーション（評判/風評）ベースの防御ツールを回避するために、 ドメインスクワッティング （不正な目的でドメインを登録する）やドメイン生成アルゴリズム（Domain Generation Algorithms： DGA ）のようなテクニックをしばしば使用します。CatoのIPSは、リアルタイム検査エンジンに複雑なAI/MLモデルを統合し、ドメインスクワッティングとDGAを検出します。脅威は、ディープラーニングモデルと、ドメインの人気度、年齢、文字パターンなどのデータポイントの相関関係を使用して識別されます。ファビコン（favicon）、画像、テキストなどのウェブページコンポーネントの分析により、ブランド偽装を検出します。 これまで事後分析でしか利用できなかったツールをリアルタイム防御に移行することで、防御の有効性と企業のセキュリティ態勢が劇的に改善されます。 ランサムウェア配信、C&C通信を防止 ランサムウェア攻撃を成功させるには、ランサムウェアの配信、攻撃者とのコマンド・アンド・コントロール（C&C）通信、そして最大の影響を与えるためのネットワーク全体への伝播が必要です。 Cato IPSは、インターネットとWANの両方のトラフィックを完全に可視化します。悪意のあるファイルのダウンロード、ランサムウェアや悪意のあるアクティビティに関連するドメインやIPアドレスへのアクセスをブロックすることで、マルウェアの配信やC&C通信を防止します。WAN全体への伝播は、横方向の移動パターンとインジケータの検出とブロックによって防止されます。 Cato IPSの包括的な可視化により、ランサムウェアの露出を減らすだけでなく、ランサムウェア攻撃の潜在的な影響を最小限に抑えることができます。 新たな脅威を迅速かつシームレスに緩和 企業は、新たな CVE （Common Vulnerabilities and Exposures：共通脆弱性識別子）からネットワークを保護するためのプロセス、リソース、および時間に苦労することがよくあります。Cato IPS は仮想パッチ適用機能を提供し、ミティゲーション（緩和/軽減）に要する時間が非常に重要な場合に、お客様のネットワークを迅速に保護します。Catoの専門家チームは、記録的な速さで新しいIPSルールを構築、テスト、展開し、お客様の関与を必要とすることなく、新しいCVEに迅速に対応します。この「仮想パッチ適用」により、企業は、影響を受けるシステムを更新し、パッチを適用している間、リスクの高い新たな脅威から保護されているという保証を得ることができます。 クラウドスケールのトラフィック検査 Catoクラウドは、クラウドネイティブアーキテクチャのパワーを活用し、TLS暗号化トラフィックを含むすべてのトラフィックを検査できる、伸縮性と拡張性に優れたIPSを提供します。大規模なクラウドコンピューティングリソースにより、シグネチャセットを微調整したり、IPSに送信されるトラフィックを制限したりする必要がありません。クラウドインフラストラクチャ、本社・拠点、リモートユーザーを含むすべてのロケーションとユーザーがCatoのIPSで保護されるため、FW/IPSアプライアンスの拡張やアップグレードが不要になります。Catoを使用することで、企業はリソースの制約により、一部のトラフィックしか検査できないIPSや、限られたシグネチャセットしか使用できないIPSを廃止することができます。 攻撃サーフェス削減のためのジオフェンシング 組織の攻撃サーフェスを削減する最も簡単な方法の1つは、組織がビジネス上やり取りする必要のない国をブロックすることです。CatoのIPSでは、すべてのユーザーとロケーションに適用される単一のグローバルポリシーで、特定の地域のトラフィック（インバウンド、アウトバウンド、またはその両方）を迅速にブロックできます。 ※ジオフェンシングは、特定エリアに仮想的なフェンス（柵）を作る仕組みです。 SASEを活用した専用ヒューリスティック言語 Cato IPSは、脅威や攻撃をリアルタイムで識別するためにヒューリスティック（経験則や先入観に基づき、直感で素早く判断）を使用します。ヒューリスティックは、実際のネットワーク・トラフィックに対して検証された一連の条件から構成されます。 CatoのSingle Pass Cloud Engine (SPACE)の一部であるCato IPSは、URL分類、アプリID、ターゲットリスクスコア、ターゲットの人気度、デバイスフィンガープリント、ユーザー認証など、スタンドアロンIPSソリューションが考慮できないデータを可視化します。 真のSASEコンバージェンス（収束）を活用するように設計された専用ヒューリスティック言語により、企業は脅威をリアルタイムで強固に防御することができます。 自動化されたAI管理型脅威インテリジェンス 最新の脅威インテリジェンスは、マルウェア、フィッシング、C&Cサイトに対するIPSの有効性、および誤検知による摩擦の低減が鍵となります。Cato IPSは、250以上の脅威インテリジェンスフィードからの情報を自律的に集約し、スコアリングする専用のAIベースのレピュテーションシステムを使用しています。このシステムは、フィード間の重複を継続的にマッピングしてクリアし、脅威記録の品質と関連性を測定し、実際のトラフィックへの潜在的な影響をシミュレートします。更新され集約されたブラックリストは、すべてのCato PoPに自動的に公開され、ほぼゼロの誤検知と顧客の関与なしに最新の保護を保証します。   Cato NGAMについて ネットワークベースの次世代型マルウェア対策（NGAM）は、ファイルがインターネットや企業WANを経由して送信される際に、リアルタイムでマルウェアから組織を保護します。マルウェアは、高度なヒューリスティックと高度に訓練された機械学習アルゴリズムによって識別されます。 ゼロデイマルウェアからのリアルタイム保護 CatoのNGAMは、ゼロデイマルウェアとポリモーフィックマルウェアをリアルタイムで検出します。SentinelOneとの提携により、機械学習アルゴリズムが何千ものデータポイント間の接続をマッピングし、良性、疑わしい、または悪意のある判定を返します。リアルタイムのゼロデイマルウェア保護により、情報システム部に過度の負担をかけ、ユーザーエクスペリエンスを損なうレガシーのサンドボックスソリューションへの依存がなくなります。 きめ細かなポリシーとシンプルな例外コントロール ポリシー管理は簡単で、管理者はインターネットやWANの宛先、送信元（ユーザー、IPアドレス、ホスト）、アプリケーションなどのコンテキストに基づいて、許可、ブロックのアクションを定義できます。スキャンの例外は、特定することも、アカウント全体に適用することもできます。CatoのNGAMを使用することで、企業はより厳格なセキュリティアプローチを採用することができ、ポリシーの変更がわずか数分でグローバルに反映されるため、ビジネスニーズを満たす俊敏性を維持することができます。 TLSインスペクションによる完全なマルウェア対策 最近のWebトラフィックの90%以上は暗号化されており、企業はそのトラフィックに脅威がないかは復号化して検査する必要があります。Catoクラウドは、TLS検査を大規模に実行するため、従来のセキュリティアプライアンスのようにサイズや規模を変更する必要がありません。検査ポリシーはきめ細かく適用できるため、企業は必要なだけのトラフィックを検査できます。TLSインスペクションを有効にすると、パフォーマンスへの影響はなく、Cato NGAMの完全な可視性により、すべてのトラフィックでマルウェアを検出してブロックすることができます。 ネストされたアーカイブと暗号化ファイルの保護 CatoクラウドのNGAMは、複数のファイルタイプをサポートし、ネストされたアーカイブファイル内の複数のレベルをスキャンすることができます。アーカイブファイルは、エンジンがファイルの全コンテンツにマルウェアがないことを確認するまで保持されます。暗号化されたファイルやパスワードで保護されたファイルはスキャンできませんが、ポリシールールによってブロックすることができます。これらの機能は、脅威者がセキュリティエンジンを回避するために使用するテクニックの1つに対処することで、組織の安全を確保するのに役立ちます。 常に最新の保護 CatoクラウドのNGAMは、すべてのファイルをワイヤスピードでスキャンし、Catoによって継続的に更新および最適化されるシグネチャおよびヒューリスティックデータベースに照らしてファイルを継続的に評価します。お客様は、従来のファイアウォールやUTMのマルウェア対策エンジンを置き換えることができ、固定アプライアンスのリソースの制約を受けることなく、すべてのファイルが包括的で最新のマルウェア対策データベースに照らして評価されるようになります。   まとめ Catoクラウドのセキュリティオプション「 Threat Prevention 」に含まれるIPSとNGAMの記事をご紹介させていただきました。 Catoクラウドに少しでも興味をお持ちになられた方は、遠慮なくSCSKまでお問い合わせください。 SASE、Cato Networks社、Catoクラウド（Cato Cloud/Cato SASE Cloud）自体の知名度もまだまだ低い状況です。 SCSKでは、2021年からSASEの主要ソリューションを一同に紹介を行うオンラインセミナー「SCSK SASE Solution Summit（通称S4 エスフォー）」を定期的に開催しております。これまで14回開催し、1,800名以上の方にご参加いただいております。 S4については、次回2024年4月以降に開催する予定ですので、改めてご案内します。 来月、2024年3月14日に、Catoクラウドの主要機能を2時間・デモ形式でご覧いただけるセミナーを開催しますので、ご興味のある方は是非ご参加ください。 Catoクラウドデモセミナー～Catoクラウドの主要機能を2時間で網羅～ 本セミナーでは、世界初のSASEである「Catoクラウド」の概要をたっぷり2時間、デモ形式でご覧いただきます。 また、ご希望の方（先着10名様）は、デモ環境に対して、お手元の環境からハンズオン形式でCatoクラウドに触れて頂くことが可能な参加型セミナーです。 www.scsk.jp SASE、Catoクラウドセミナー以外に、Catoクラウドのお客様導入事例の制作、FAQサイト運営、この TechHarmony（技術ブログ）で、皆様のお役に立て、Catoクラウドの知名度アップに少しでも貢献できればと考えております。

先日新しくインターネット標準となった『 RFC 9421 : HTTP Message Signatures 』が気になって読み、自分の考えをまとめてみましたので、その内容を共有します。 仕様の概要 RFC 9421 は HTTP メッセージの電子署名に関する仕様です。HTTP メッセージの送信者はヘッダの一部やボディから署名を作成し、その署名を HTTP ヘッダに付加して送信し、受信者はそれを検証するというものです。RFC には署名の作成・検証方法、署名やアルゴリズム等の伝達方法、その他考慮点が記載されています。 署名には通信相手の認証や改ざん検知といった機能がありますが、TLS には署名の機能が含まれているにも関わらずなぜ HTTP のレイヤで署名が必要なのか、当然気になります。この疑問の答えは第一章に書かれています。 TLS はそのピア同士の間の通信を保護するものですが、HTTP クライアントとサーバのエンドツーエンドで保護されているわけではないということが課題感として挙げられています。例えば CDN が利用されているようなケースでは、クライアントは CDN との間で TLS 通信を行い、CDN はオリジンであるサーバとの間で TLS 通信を行います。このとき CDN で設定ミス・バグ・侵害・内部不正などがあって不正な HTTP レスポンスを返したとしても、そのことにクライアントは機械的には気付けません。また、クライアント側で TLS インスペクションを行うセキュリティ製品を利用しているようなケースでも、同様のことが言えます。こういった課題を HTTP レイヤで解決しようというのが RFC 9421 です。 なお、AWS の API ではクライアントはリクエストに署名を行い、API サーバは署名を検証してクライアントの認証を行っています。他にも同様のことを行っているサービスやシステムがあり、こういった既存の実装もこの RFC の下地になっているものと思います。 仕様で定められていること HTTP メッセージの署名を作成・検証する際、署名の対象とする HTTP メッセージのバイトデータの形式が問題になります。 HTTP では次のような仕様や実運用が存在します。 ロードバランサやリバースプロキシなどの中継サーバが HTTP ヘッダを追加・変更する ヘッダ名の大文字・小文字の違いが許容されている HTTP/2 では HTTP ヘッダがキャッシュされており、毎回送受信されるわけではない HTTP/2 と HTTP/1.1 ではメッセージの形式が根本的に異なる（バイナリ／テキスト） HTTP メッセージをバイトデータとして表現したときの形式が署名者・検証者の実装によって異なってしまうと署名が機能しないため、メッセージの正規化や署名対象ヘッダの選択方法が仕様として定められています。これにより複数の実装間での相互運用性を保とうとしたわけですね。 また、署名者と検証者は同一の暗号アルゴリズムやハッシュアルゴリズムを用いる必要があります。これについて、仕様ではどのアルゴリズムを用いて署名を作成したか、署名者から検証者に HTTP ヘッダを用いて伝達する方法が定められています。さらに、署名の作成日時や有効期限、nonce、利用した鍵のIDなども伝達情報として定められています。 一方で、署名で利用する鍵をどのようにして交換するかについては定められておらず、共通鍵暗号方式と公開鍵暗号方式のどちらを利用するかについても定められていません。TLS のように公開鍵を伝達する仕組みは定められていませんので、クライアントとサーバの間であらかじめ鍵を交換し合っておく必要があるものと思います。DKIM 署名のように DNS を用いて公開鍵を配布するという方法も考えられます。 署名の仕組みがどこで活用されるか RFC で定められているのはあくまでも署名の仕様であり、署名をどこで活用するかについては各開発者が考えるべきことですね。 まず、ブラウザベースの Web アプリケーションでの活用を考えたくなります。Web サーバが署名を付けたレスポンスを返してきたときに、ブラウザが自動的に署名を検証し、検証失敗ならユーザに通知するといった感じのことです。しかし、これは各ブラウザが実装してくれるかどうかに依存しますし、鍵交換の部分の仕様が今は存在しないので、まだその時期ではないように思います。 Web アプリケーションでの活用の他実装として、JavaScript で署名を検証するという方法も考えられます。RFC では、ブラウザ上で動く JavaScript からも署名を扱えるようにするということが要件事項として挙げられていますので、想定の活用方法のはずです。ただし、署名の検証を行う JavaScript を Web サーバがクライアントに返すようにしていたとしても、中継サーバを侵害した悪意者は署名の検証を行わない JavaScript を返せてしまい、署名が機能しないようにできてしまいます。そのため、こういった不正を防止したい組織（金融機関など）は署名の検証を行うブラウザの拡張機能を独自に開発し、ユーザにあらかじめ導入しておいてもらうといった活用事例が生まれてくる可能性はありえそうです。検証のための公開鍵の配布の問題もブラウザの拡張機能の中に埋め込むことで解決できますので。とはいえ、自前の Web サーバで TLS を終端し、かつ証明書のピンニングも行えば中間者攻撃を防止できますので、積極的に署名を行う動機にはなりにくいかもしれません。 サーバがクライアントを認証する際の活用も当然考えられます。クライアント側で秘密鍵と公開鍵を生成し、その公開鍵をサーバ側に登録しておいた上で、その後の通信では署名を用いてクライアントを認証するといった活用です。ただし、ブラウザベースの Web アプリケーションでは鍵交換の問題やどうやって署名するかという問題があるため現実的ではなく、そのようなことがしたいのであれば今はパスキーを利用すべきですね。非ブラウザ環境で Web API を実行するクライアントの認証という活用であれば、ブラウザによるパスキーのサポートがありませんので、署名の活用は十分ありえそうです。もちろん、証明書のピンニングでサーバが期待する通信相手であることを保証したうえで、ヘッダベースの Bearer 認証でも良いとは思いますが。。 まとめ RFC 9421 : HTTP Message Signatures を読んで自分の考えをまとめてみました。 活用方法として2点（ブラウザ拡張機能を用いた中間者攻撃の防止、Web API でのクライアント認証）挙げてみましたが、それが合っているのかどうかはよくわかりませんし、他にもあるとも思います。 インターネット標準だからといってそれを活用しなければならないものではありませんが、将来それがどう活用されるかを想像しつつ、これまで解決できずに困っていた課題を解決できるのであれば、それに向けて取り組むのは非常に楽しいですね。

本記事の内容は、以下のCato Networks社の記事を元に日本語へ意訳し、再構成したものとなります。 Cato Cloud Access Security Broker (CASB) Cloud Access Security Broker (CASB) CASB provides IT managers with comprehensive insight into their organization’s cloud application usage, covering both sanctioned and unsanctioned (Shadow IT) ap... www.catonetworks.com Cato Data Loss Prevention (DLP) Data Loss Prevention (DLP) Cato DLP empowers organizations to consistently protect sensitive data across users, locations, and clouds. www.catonetworks.com Cato Networks社は、2022年に、Cloud Access Security Broker （CASB）とData Loss Prevention （DLP）をリリースしています。 CASBとDLPは、Catoクラウドの標準サービスではなく、ともにセキュリティオプション（追加費用）となります。また、DLPについては、CASBの契約が前提となります。 それでは、CatoクラウドのCASBとDLPについてご紹介します。 Cato CASBについて CatoクラウドのCASBは、公認アプリケーション（Sanctioned）と非公認アプリケーション（Unsanctioned＝シャドーIT）の両方をカバーし、IT管理者に組織のクラウドアプリケーション使用に関する包括的な洞察を提供します。CatoのCASBは、各SaaSアプリケーションの潜在的なリスクを評価し、最小限の特権と最小限のリスク・エクスポージャーを確保するために、非常にきめ細かく柔軟なアクセス・ルールを定義することを可能にします。 クラウドアプリケーションの完全な可視化とシャドーITコントロール 企業のリスク管理を担当する管理者は、各SaaSやクラウドアプリケーションのコンプライアンスを手作業で確認することができません。Cato CASBは、自動化されたデータ収集とMLベースの分析により、すべてのクラウドアプリケーションのリスクスコアを算出します。クラウドアプリケーションカタログに表示される各アプリケーションのプロファイルは、アプリケーションの説明、コンプライアンス遵守、セキュリティコントロールで強化されています。管理者は、アプリケーションの使用に関して十分な情報に基づいた意思決定を行い、リスクと暴露を制限するポリシーを定義するために必要なすべての情報を表示できます。例えば、特定のリスクスコア以上のアプリケーションへのアクセスを防止したり、MFAやSSOのないアプリケーション、セキュリティ標準に準拠していないアプリケーションなどです。 クラウドアプリケーション内でのユーザの行動を制御 CatoクラウドのCASBは、より広範なリスクとコンプライアンスベースの制御だけでなく、ユーザーがアプリケーション内で実行できる特定のアクションのきめ細かなインライン監視と制御も提供します。HTTP(S)やAPI経由で送信されるコマンドを検査することで、ログイン、ダウンロード、アップロード、表示などのきめ細かなユーザーアクションを特定します。管理者は、アクションの許可を制御するポリシーを作成し、ユーザーの生産性とデータ・セキュリティのバランスをとることができます。例えば、承認されていないファイル共有アプリからのアップロードはブロックするが、外部組織とのデータ交換のためのダウンロードは許可するといった現実的な状況です。 インライン・アウトオブバンドのアプリケーションアクセスコントロール ユーザは、オフィスとリモート、企業デバイスとBYODの両方からクラウドアプリケーションにアクセスするため、帯域外制御のインライン制御が必要になります。インライン・トラフィックの可視化と制御に加え、Cato CASBは一般的なエンタープライズ・クラウド・アプリケーション用のAPIコネクタを提供します。APIコネクタにより、アプリケーションのアクセスをほぼリアルタイムで監視し、データ漏洩、データ共有の設定ミス、マルウェアの伝播から保護します。Cato CASBは、インラインとアウトオブバンドの両方で動作するため、管理者はクラウドアプリケーションの使用状況を包括的かつ完全に可視化し、すべてのアプリケーションのアクセスシナリオで一貫した制御を行うことができます。 エンタープライズSaaSのテナント制限でデータ漏えいを防ぐ 企業によって認可され、許可されたSaaSアプリケーションも、従業員によって私的に使用されている可能性があり、機密データ漏えいのリスクをもたらします。業界のベストプラクティスに従って、Cato CASBは、企業の知的財産が明示的な許可なしに社外に流出しないように、許可されたアプリケーション内の許可されたテナントにアクセスを制限することができます。   Cato DLPについて CatoクラウドのDLPは、ユーザー、場所、クラウドを問わず、機密データを一貫して保護することを可能にします。包括的なDLPコントロールは、GDPR、PCI DSS、HIPAAなどの規制へのコンプライアンスを確保し、知的財産や専有情報を保護するために不可欠です。 センシティブデータタイプの完全なカタログで、価値実現までの時間を短縮 DLPの導入は、誤検知やユーザーの生産性に影響を与えることなく、データを正確に分類することを目的としているため、ほとんどの組織にとって困難なことです。Cato DLPは、テストおよび検証済みの350以上の定義済みデータタイプのカタログを備えており、すぐに使用できるため、セキュリティチームは先手を打つことができます。このカタログは、機密データ、PII、金融情報の保護、複数の地域にわたる規制コンプライアンスの達成など、一般的なユースケースをカバーしており、迅速かつ効率的なDLPの展開を可能にします。 Cato DLPへの秘密度（機密）ラベルの持ち込み 企業は秘密度（機密）ラベルを使用して、データを効率的に分類し、複数のプラットフォームでデータ保護の精度を向上させます。Cato DLPは、Microsoft Information Protection (MIP)とカスタム秘密度（機密）ラベルをサポートしています。簡単な設定により、企業のMIPラベルをCato DLPが認識し、該当するデータ保護ポリシーで使用できます。DLPルールにおける一貫した秘密度（機密）ラベルの使用により、企業は全社的で統一されたデータ保護を実現できます。 機密データ型のカスタマイズと検証 DLPは万能なソリューションではなく、カスタムデータタイプを作成する機能は、組織に適したデータ保護ポリシーを作成するために不可欠です。CatoのDLPでは、管理者は秘密度（機密）ラベル、キーワード、辞書、正規表現に基づいてカスタムデータタイプを作成できます。さらに、誤検知を減らすために、Cato DLPはインスタント検証ツールを提供しており、管理者は本番環境でポリシーを適用する前に、サンプルファイルに対してデータ保護ポリシーをテストすることができます。企業特有のポリシー作成と微調整の労力を最小限に抑えます。 インライン・アウトオブバンドのデータ保護 ユーザは、オフィスとリモート、企業デバイスとBYODの両方からクラウドアプリケーションにアクセスするため、帯域外とインラインのデータ保護が必要になります。Cato DLPは、インライントラフィックの可視化と制御に加え、一般的なSaaSアプリケーションのAPIを使用して、データ使用状況をほぼリアルタイムで監視し、データ漏洩やデータ共有の設定ミスを防止します。このように、Cato DLPは、すべてのアプリケーションとデータアクセスシナリオにおいて、包括的で完全なデータ保護を提供します。 企業データ保護のための1つのダッシュボード データ保護は、継続的な実施、監視、微調整を必要とする継続的な責任です。Cato DLPは、DLPイベントと関連アクティビティを効率的に可視化するための専用ダッシュボードを提供します。管理者は、ユーザー、違反者、ファイルタイプ、データプロファイル別の機密データ使用違反など、主要なDLPメトリクスを即座に把握できます。長期的かつ地域横断的に分析することで、リスクおよびコンプライアンスチームは、企業のポリシーやプロセスに必要な調整を特定することができます。 すべてのトラフィックを360度データ保護 Cato DLPエンジンは、オンプレミスとクラウドのデータセンター、およびSaaSアプリケーションのプライベートアプリケーションに向かうすべてのトラフィックを検査します。CatoのDLPエンジンは、センシティブなデータの利用を特定し、トラフィックの送信元や送信先に関係なく、一貫したデータ保護ポリシーを適用します。Cato DLPはクラウドサービスとして提供されるため、特定の場所で検査するためにトラフィックをバックホールする必要がなく、DLP制御がアプリケーションの応答性やユーザーの生産性に与える影響を最小限に抑えることができます。   まとめ CatoクラウドのセキュリティオプションであるCASBとDLPの記事をご紹介させていただきました。 Catoクラウドに少しでも興味をお持ちになられた方は、遠慮なくSCSKまでお問い合わせください。 SASE、Cato Networks社、Catoクラウド（Cato Cloud/Cato SASE Cloud）自体の知名度もまだまだ低い状況です。 SCSKでは、2021年からSASEの主要ソリューションを一同に紹介を行うオンラインセミナー「SCSK SASE Solution Summit（通称S4 エスフォー）」を定期的に開催しております。これまで14回開催し、1,800名以上の方にご参加いただいております。 S4については、次回2024年4月以降に開催する予定ですので、改めてご案内します。 来月、2024年3月14日に、Catoクラウドの主要機能を2時間・デモ形式でご覧いただけるセミナーを開催しますので、ご興味のある方は是非ご参加ください。 Catoクラウドデモセミナー～Catoクラウドの主要機能を2時間で網羅～ 本セミナーでは、世界初のSASEである「Catoクラウド」の概要をたっぷり2時間、デモ形式でご覧いただきます。 また、ご希望の方（先着10名様）は、デモ環境に対して、お手元の環境からハンズオン形式でCatoクラウドに触れて頂くことが可能な参加型セミナーです。 www.scsk.jp SASE、Catoクラウドセミナー以外に、Catoクラウドのお客様導入事例の制作、FAQサイト運営、この TechHarmony（技術ブログ）で、皆様のお役に立て、Catoクラウドの知名度アップに少しでも貢献できればと考えております。

本記事の内容は、以下のCato Networks社の記事を元に日本語へ意訳し、再構成したものとなります。 Cato DNS Security DNS Security Cato’s DNS Security inspects all DNS traffic, preventing malicious activity attempts hiding within the protocol’s traffic and blocking DNS requests to malicious... www.catonetworks.com Cato Remote Browser Isolation (RBI) Remote Browser Isolation (RBI) Remote Browser Isolation balances security and user productivity by allowing access to unknown websites in a safe, isolated environment. www.catonetworks.com CatoクラウドのDNS Securityは、セキュリティオプション「 Threat Prevention 」に含まれます。 また、Remoto Browser Isolation（RBI）については、Catoクラウドのセキュリティオプション「 RBI 」となります。 それでは、DNS SecurityとRBIについて解説します。 Cato DNS Securityについて CatoのDNS Securityは、すべてのDNSトラフィックを検査し、プロトコルのトラフィックに隠れた悪意のあるDNSアクティビティを防止し、接続が行われる前に悪意のある宛先へのDNSリクエストをブロックします。 AIベースのDNS検査がインラインフィッシング対策を実現 フィッシングは、すべてのCISOが懸念する攻撃のトップです。 Catoのグローバルで膨大なデータレイクを用いて、AIとMLアルゴリズムを継続的にトレーニングすることで、CatoのDNS Securityは、ドメインの不法占拠やその他のWebサイトのなりすましの試みをインラインで識別できるようになります。これは、Webページコンポーネント、ドメインエイジ、人気度、フィッシングサイトで使用されるツールキットに関連するパターンのリアルタイム分析によって実現されます。このフィッシング攻撃のインライン検知は、クレデンシャルハーベスティング（資格情報の搾取）、マルウェア配信、機密データの損失防止に役立ちます。 接続前に悪意のあるドメインとC&Cサイトをブロック マルウェアをリモートで管理するコマンド＆コントロール（C&C）サーバをホストする悪意のあるサイトの数は膨大です。攻撃者は、検出やブラックリスト入りを避けるために、サイト間でC&Cサーバーを絶えず移動させています。CatoのDNS Securityは、Catoのタイムリーかつ継続的に最適化された脅威インテリジェンスシステムを使用して、悪意のあるドメインとC&Cサイトを特定し、それらへのトラフィックとそれらからのトラフィックをリアルタイムでブロックします。CatoのDNS Securityを使用することで、企業は何百万ものWebベースの攻撃にさらされる機会を劇的に減らすことができます。 DNSトンネリングによるデータ損失と悪意のある活動を阻止 DNSトンネリング攻撃は、データ流出やC&Cアクセスの手法として、DNSトラフィックがセキュリティ制御を通過する必要性を利用しています。CatoのDNS Securityは、パケットサイズ、レコードタイプ、ユニークなサブドメインの比率などのDNSリクエストプロパティを分析し、DNSトンネリング攻撃の異常や指標を特定します。CatoのAI/MLアルゴリズムは、DNSトンネリングを識別するために継続的に訓練されており、脅威行為者やドメイン名に関する特定の知識に依存しない保護を可能にします。 暗号通貨マイニングからのリソース流出を防ぐ 暗号通貨マイニングは、システムの不安定化、ユーザーエクスペリエンスの低下、組織のコスト増につながる金銭的利益を得るために、侵害された企業のエンドポイントを使用します。Catoは、専用のルールとヒューリスティックを活用して、暗号通貨マイニングに使用されるドメインを特定し、これらの宛先へのDNSリクエストをブロックします。Catoにより、企業はユーザーの生産性とセキュリティを不正使用による影響から保護します。 新規登録ドメインのブロックでリスク軽減 悪意のあるドメインはすぐに特定され、分類されるため、ほとんどのセキュリティエンジンでカテゴリーベースのブロックが行われます。攻撃者は、カテゴリベースのセキュリティ制御を回避するために新しいドメインを登録します。Catoの DNS Securityは、14日未満のドメインをリアルタイムで識別し、アクセスをブロックします 。新しく登録されたドメインのほとんどは悪意があるか疑わしいものであるため、これらをブロックすることで、攻撃対象が減少し、ユーザーへの影響を最小限に抑えながらセキュリティ態勢が改善されます。 DNSセキュリティの脅威とイベントを完全に可視化 すべての脅威アクティビティはCatoのデータレイクに記録され、管理者は単一のコンソールから必要な脅威情報に即座にアクセスできます。DNS Security イベントは、DNS保護に関連するすべてのイベントへのフィルタリングとドリルダウン機能を備えたセキュリティ脅威ダッシュボードに表示されます。セキュリティチームは、複数のデータソースを集約したり、複数のコンソール間を移動したりすることなく、組織に対するDNSの脅威を迅速に理解し、評価することができます。   Cato Remote Browser Isolationについて Remote Browser Isolation（以下、RBI）とは、安全で隔離された環境で未知のWebサイトへのアクセスを行うことで、セキュリティとユーザーの生産性のバランスをとります。インスタントオン（即時起動）RBIにより、管理者はブロックされたサイトへのアクセスを要求するチケットを大幅に削減でき、ユーザーは安全で合理化されたエクスペリエンスで中断のない生産性を享受できます。 クラウド型セーフブラウジングの即時導入 Cato RBI は、追加のハードウェアやソフトウェアを導入することなく、すべてのロケーションとユーザーに対して、わずか数クリックですぐに有効にすることができます。 カテゴライズされていないWebサイトへのアクセスは、自動的にリモートセッションで隔離され、Webコンテンツのグラフィカルな表示がユーザーのブラウザにストリーミングされます 。 Webベースの攻撃リスクの低減 Webブラウジングは、コードがユーザーのデバイス上でローカルに実行されるため、マルウェアの配信、クレデンシャル情報の盗難、その他の悪意のある行為を可能にする可能性があり、重大なリスクをもたらします。RBIは、コンテナ化された環境でサイトをレンダリング（データ処理し映像を表示させる）し、セッション終了時に完全に破棄することで、Webサイトのコードをエンドポイントから分離します。このプロセスは、ユーザーに対してシームレスかつ透過的に行われ、悪意のあるコードがデバイスに到達するのを防ぎます。 リスクの高いWebアクセスパターンの管理と制御 管理者は、インターネットアクセスのパターンとリスクを理解し、どのサイトにRBIが読み込まれ、どのユーザーが最も頻繁にRBIを使用しているかを追跡・監視する必要があります。Catoは、管理者が統合イベントログを簡単にフィルタリングし、宛先、ユーザーID、ボリューム、その他のメトリクスに基づいてRBIイベントを追跡することを可能にします。RBIポリシーは、企業固有のニーズに合わせて微調整できる。管理者は、Cato管理アプリケーション（CMA）を使用して、調査やトラブルシューティングのためにRBIを手動で読み込むことができます。 フィッシングやランサムウェアに対する重要な防御策 未定義サイト（Undefined）や未分類サイト（Uncategorized）は、フィッシングキャンペーンやランサムウェアの配信によく使用されます。Cato RBIは、完全に隔離された環境で未定義サイトや未分類サイトを自動的に起動し、ユーザーデバイスとの間でデータやファイルが転送されるのを防ぎます。その結果、RBIはこのようなWebサイトを脅威のベクトルとして排除し、労力ゼロでユーザーの生産性に影響を与えることなく、フィッシングやランサムウェアから組織を大幅に強力に保護します。   まとめ CatoクラウドのDNS SecurityとRBIの記事をご紹介させていただきました。 Catoクラウドに少しでも興味をお持ちになられた方は、遠慮なくSCSKまでお問い合わせください。 SASE、Cato Networks社、Catoクラウド（Cato Cloud/Cato SASE Cloud）自体の知名度もまだまだ低い状況です。 SCSKでは、2021年からSASEの主要ソリューションを一同に紹介を行うオンラインセミナー「SCSK SASE Solution Summit（通称S4 エスフォー）」を定期的に開催しております。これまで14回開催し、1,800名以上の方にご参加いただいております。 S4については、次回2024年4月以降に開催する予定ですので、改めてご案内します。 来月、2024年3月14日に、Catoクラウドの主要機能を2時間・デモ形式でご覧いただけるセミナーを開催しますので、ご興味のある方は是非ご参加ください。 Catoクラウドデモセミナー～Catoクラウドの主要機能を2時間で網羅～ 本セミナーでは、世界初のSASEである「Catoクラウド」の概要をたっぷり2時間、デモ形式でご覧いただきます。 また、ご希望の方（先着10名様）は、デモ環境に対して、お手元の環境からハンズオン形式でCatoクラウドに触れて頂くことが可能な参加型セミナーです。 www.scsk.jp SASE、Catoクラウドセミナー以外に、Catoクラウドのお客様導入事例の制作、FAQサイト運営、この TechHarmony（技術ブログ）で、皆様のお役に立て、Catoクラウドの知名度アップに少しでも貢献できればと考えております。

2024年1月の製品アップデート情報にて、Catoからのアラートとシステム通知に関して Webhook を用いて、ServiceNow・Jira・Slack などのサードパーティ プラットフォームにアラートを送信できる機能がリリースされました。 アラートなどの通知が普段利用しているサービスで気づければ便利ですよね。 なので、Catoが提供しているWebhook機能を実際に試していきたいと思います！   Webhookとは ？ Webhookとは、Webアプリケーションに対して、特定のイベントが発生した際に、別のWebアプリケーションに通知の発行が可能になる仕組みです。 Catoクラウドでは、セキュリティルールやSocketがダウンした場合、メール通知のサポートはしておりますが、今回のアップデートにてWebhook機能を用いて、ServiceNow・Jira・Slack などのサードパーティ プラットフォームにアラートを送信することが可能となりました。   CatoクラウドでWebhookを利用するには CMA（Catoクラウドの管理画面）で行う操作としては Webhookを機能させるためのルールを作成する ↓ 作成したルールを設定し適用させる といった流れとなります。 Webhookのルールを作成する際に、Webhook 経由でアラートを受信しているサービスの URL と、関連する認証情報をCMAにて入力する必要があるのでその準備が必要となります。   機能を実践してみる 今回行う内容は、Socketのダウンを検知をして、Webhookを介しSlackへ通知を送り、アラート内容の確認が可能であるかを実践していきたいと思います。 ルール作成 まずは、Webhookを機能させるためのルールを作成していきます。 該当箇所は、Administration > Subscriptions > Integrations　にて行っていきます。 ※機能が反映されていない場合、Administrationmの配下にSubscriptionsは表示されません。 本機能は順次展開されておりますので、反映までに時間がかかる場合がございます。   今回はSlackに通知を飛ばす設定をいれていきます。 Slackの他には現状ですと、ServiceNow・Jira、そしてWebhook 経由でアラートを受信しているサービスに対応しております。 設定は以下のように行いました。 「Connection Details」の項目に、通知させたいサービスのURLを入力します。 今回はSlackに連携させたいため、通知を確認したいチャンネルを作成し、URLの取得を行いました。 そして、取得したURLを「Connection Details」の項目に入力していきます。 入力したURLに対して接続性があるか、画面下にある「Test」にて確認が可能です。 問題ない場合は、「Test passed successfully」と表示が出てきます。 テスト接続は問題なく行えました。   また、アラート内容を下記 JSONのテンプレートにて任意で追加や削除できる項目があります。 今回はデフォルトの設定値にてアラート内容を確認していきたいと思います。 アラート内容に表示できる項目は以下が可能です。 Field Description account Id アカウント ID。Cato管理アプリケーションのURLの番号 account Name Cato管理アプリケーションにおけるCatoアカウントの名前 alert Type アラートの種類 content アラート コンテンツのフリー テキスト、サポートされている形式は以下となります。 テキスト – contentText HTML – contentHTML (英語) マークダウン – contentMarkdown end Date 監視対象の問題が終了したタイム スタンプ level アラートのレベルまたは優先度 policy Name ルールのCato管理アプリケーションでのポリシー名 rule Id アラートをトリガーしたポリシールールの一意のCato ID rule Name アラートをトリガーしたルール名 site Name アラートをトリガーしたサイト名 start Date 監視対象の問題が開始されたタイム スタンプ subject アラートの簡単な概要 time アラートが送信されたタイム スタンプ title アラートのタイトル   設定する内容は以上となります。 作成したルールを設定する 実際にSocketのWANを落としてみて通知が来るか確認してみたいと思います。 Socketダウンの通知やフェイルオーバーが発生したなどの際に通知させたい場合は、 Network＞Link Health Rules＞Connectivity Health Rules にて設定が可能です。 今回は、Connectivityに関するイベントをすべて対象にし、ダウン状態が1分以上続いた際に、上記で作成したSlackに通知させるといったルールを設定していきます。 実際に、WANをダウンさせてみました。 CMAにて以下のようにDisconnectedのログを検知しました。   すると、Slackにも以下のようにDisconnectedを検知した通知が来ました。 対象サイト、発生時間、アラート内容、接続状況などの情報が確認できました。 通知内容についてカスタマイズでき、通知を即座に確認できるため問題解決の時間が短縮されるなと感じました。   今回行ってみたLink Health Rulesだけでなく、他にもセキュリティ・ネットワーク機能のルールでも通知先としてWebhookの指定することも可能ですので、すぐに気付きたいルールがございましたら、ぜひ活用いただければと思います。 2024年2月時点での、CatoクラウドにてWebhookとしてアラートを飛ばせる機能・設定は以下となります。 Webhook機能でのアラート一覧 Network LAN Monitoring Remote Port Forwarding Connectivity Health Rules Quality Health Rules Security機能 Internet Firewall WAN Firewall IPS DNS Protection Anti-Malware Detection & Response CASB DLP SaaS Security API   Servicenow・Jira・Slack以外でのWebhook利用時の注意点 今回、SlackにてWebhook機能を確認してみましたが、Servicenow・Jira・Slack以外でのWebhookを送信する場合に設定内容について異なる部分がありますのでそちらを説明していきます。 ルールを作成する際、Webhookを指定するとAuthentication Methodという認証方式を設定できる項目が表示されます。   こちらの項目では、以下の認証方式が選択可能となります。 None：認証方法なし Basic：ユーザーネームとパスワード Bearer：Token Custom：認証鍵とToken 利用するサービスごとに必要な認証方式が異なってきますので、サービス元の認証方法をご確認ください。 送信先に合わせてBody とヘッダーのカスタマイズが可能となります。   ③Custom Headersの項目にて、任意でHeadersでの認証情報の指定ができます。 ④Custom Bodyの項目にて、 送信先に合わせて Body のカスタマイズが行えます。 テンプレートを選択し、通知先に応じて必要な情報を書き込むことが可能となります。 また、Webhook機能全体の話ですが、1つのルールで複数の宛先（URL）の指定ができないため、通知を確認したいサービスが複数ある場合は通知先ごとにルールの作成が必要となります。   最後に 実際にWebhookの機能を試してみましたが、今回行った活用方法としてはSlackを用いてシステムの異常を検知した時、Webhookを介して即座に通知を送り、管理者が迅速に対応できるようにするという内容を行いました。 ただこういった対応だけではなく、Webhook機能には他にも良い活用方法があるかと思います。 例えば、Socketがダウンをしたことを履歴として残したい際、チケット管理システムやタスク管理ツールにWebhook機能を用いて通知を飛ばし、通知をトリガーにチケットを自動起票し管理の手間を省くなどが可能になっていくかと思います。 Webhookの機能を実践してみて、有用性のある自動化や効率的なワークフローが実現できるかもしれないという期待が感じられ、これから有効活用していきたいと思いました。

こんにちは。SCSKのふくちーぬです。 前回は、Amazon Data Firehoseを利用して、CloudWatch LogsのログをS3に転送する手法をご紹介しました。こちらの記事を読んでいない方は、是非ご一読ください。 Amazon CloudWatch Logs を Amazon Data Firehose のみ利用して、解凍処理して Amazon S3 に転送する [Amazon Data Firehose + AWS Lambda + Amazon CloudWatch + Amazon S3 + AWS CloudFormation] Amazon CloudWatch Logs のログを Amazon Data Firehose を利用して解凍済みのログとして Amazon S3 に転送する方法を紹介します。 blog.usize-tech.com 2024.02.15 今回は、Amazon Data FirehoseでS3へ転送する際にタイムゾーンを指定したプレフィックスがサポートされたので紹介します。 Amazon Data FirehoseでS3に転送時にタイムゾーンが指定できるようになりました 以前までは、UTC形式でプレフィックスが付与されていました。例としてJST形式でプレフィックスを付与したい場合は、Dynamic Partitioning（動的パーティショニング）機能を利用する必要があり、ひと手間かかっていました。 Amazon Data Firehose での動的パーティショニング - Amazon Data Firehose Amazon Data Firehose の動的パーティショニングのメカニズムについて説明します。 docs.aws.amazon.com 今回のアップデートにより、ご自身が利用する国の時間帯を利用することが可能となり視認性も向上します。また、Athena等でのETL処理が容易になることも利点となります。 Amazon Data Firehose enables selecting a time zone for bucket prefixes when delivering streams to Amazon S3 aws.amazon.com   検証 実際にやってみます。リソースは、前回デプロイしたものを利用します。 Amazon Data Firehoseのマネジメントコンソールを開きます。 “送信先の設定”を確認すると、新たにタイムゾーンの欄が追加されています。 “編集”を押下して、タイムゾーンを指定します。今回は、”Asia/Tokyo”を指定します。もちろん他の国のタイムゾーンもサポートされています。 ログの確認 Lambdaにてテストイベントを作成して実行します。CloudWatch Logsへログが出力され、FirehoseでS3へのログ転送を実施します。 S3のプレフィックス及びファイル名に、日本時間でタイムスタンプが付与されていることを確認できました。   最後に いかがだったでしょうか。 Data Firehose のタイムゾーンについて解説しました。 S3バケットにオブジェクトが配信された日時と、Data Firehose によって配信されたS3プレフィックス及びファイル名が揃っていることは運用時にも嬉しいですね。 本記事が皆様のお役にたてば幸いです。 ではサウナラ～🔥

こんにちは。SCSKのふくちーぬです。 2/9にて Amazon Kinesis Data Firehose の名称が、Amazon Data Firehose に変更されましたね。もともと取っつきにくい名前だったのに、さらに混乱しそうなところではあります。 Introducing Amazon Data Firehose, formerly known as Amazon Kinesis Data Firehose aws.amazon.com 今回は、Amazon CloudWatch Logs のログを Amazon Data Firehose を利用して解凍済みのログとして Amazon S3 に転送する方法を紹介します。 Amazon Data Firehose にてログの解凍処理ができるようになりました 以前までは、CloudWatch LogsのログをS3に転送する際にgzip形式のまま転送されていました。運用管理者がログの中身を見るためには、Lambdaにて解凍処理を実施させておくか、運用管理者自身が解凍ツール（7zip等）を使うひと手間が必要でした。 2023/12/15のアップデートにより、Amazon Data Firehose 側で解凍処理を任せることが可能になりました。 Amazon Kinesis Data Firehose が、解凍された CloudWatch Logs の送信先への配信をサポート aws.amazon.com Amazon Data Firehose 解凍処理には、0.00403USD/1GBの料金がかかることは注意しましょう。また、解凍後のデータとなるためS3のストレージ料金もわずかながら増大します。やはり大量のログデータを分析する際には、圧縮された状態で（gzip形式等）Athenaで分析する手段を取ることには変わりはないです。しかし、S3でログをすぐに確認する用途で利用できそうなので検証してみます。 検証 CloudWatch Logs のデータを Data Firehose にて、解凍処理を実施した上でS3に転送します。またリソースの構築には、全て CloudFormation を利用します。 アーキテクチャー Lambda実行ログをCloudWatch Logsに保存する CloudWatch Logsにログが入ったことを検知するサブスクリプションフィルターにて、Data Firehose に流す Data Firehose にてログの解凍処理を実施の上、S3に転送する CloudFormationテンプレート 以下のテンプレートをデプロイしてください。 AWSTemplateFormatVersion: "2010-09-09" Description: "kinesis stack" Parameters: ResourceName: Type: String BUCKETNAME: Type: "String" Resources: # ------------------------------------------------------------# # S3 # ------------------------------------------------------------# S3BucketForlog: Type: "AWS::S3::Bucket" DeletionPolicy: "Delete" Properties: BucketName: !Sub "${BUCKETNAME}-${AWS::AccountId}" AccessControl: "Private" PublicAccessBlockConfiguration: BlockPublicAcls: "true" BlockPublicPolicy: "true" IgnorePublicAcls: "true" RestrictPublicBuckets: "true" # ------------------------------------------------------------# # Kinesis (Kinesis Firehose,Iam Policy,Iam Role,Log Grop,Log Stream) # ------------------------------------------------------------# Deliverystream: DependsOn: - "DeliveryPolicy" Type: "AWS::KinesisFirehose::DeliveryStream" Properties: DeliveryStreamName: !Sub "${ResourceName}-KDF-LogDeliveryStream" ExtendedS3DestinationConfiguration: BucketARN: !Sub "arn:aws:s3:::${S3BucketForlog}" BufferingHints: IntervalInSeconds: "60" SizeInMBs: "50" CompressionFormat: "UNCOMPRESSED" Prefix: !Sub "${ResourceName}-logs/" RoleARN: !GetAtt "DeliveryRole.Arn" DynamicPartitioningConfiguration: Enabled: "false" ProcessingConfiguration: Enabled: "true" Processors: - Type: Decompression CloudWatchLoggingOptions: Enabled: "true" LogGroupName: !Sub "/aws/firehose/${ResourceName}-KDF-LOG" LogStreamName: "error" Tags: - Key: Name Value: !Sub "${ResourceName}-KDF-LogDeliveryStream" DeliveryPolicy: Type: "AWS::IAM::Policy" Properties: PolicyName: "firehose_delivery_policy" PolicyDocument: Version: "2012-10-17" Statement: - Effect: "Allow" Action: - "s3:AbortMultipartUpload" - "s3:GetBucketLocation" - "s3:GetObject" - "s3:ListBucket" - "s3:ListBucketMultipartUploads" - "s3:PutObject" Resource: - !Sub "arn:aws:s3:::${S3BucketForlog}" - !Sub "arn:aws:s3:::${S3BucketForlog}/*" - Effect: "Allow" Action: - "logs:PutLogEvents" Resource: - !Sub "arn:aws:logs:${AWS::Region}:${AWS::AccountId}:log-group:/aws/firehose/${ResourceName}-log-DeliveryStream:*" PolicyName: "IPL-KinesisFirehoseAccessPolicy" Roles: - !Ref "DeliveryRole" DeliveryRole: Type: "AWS::IAM::Role" Properties: AssumeRolePolicyDocument: Version: "2012-10-17" Statement: - Sid: "" Effect: "Allow" Principal: Service: "firehose.amazonaws.com" Action: "sts:AssumeRole" Condition: StringEquals: sts:ExternalId: !Ref "AWS::AccountId" RoleName: "IRL-KINESISDATAFIREHOSE-LogDeliveryStream" LogGroupFirehose: Type: "AWS::Logs::LogGroup" Properties: LogGroupName: !Sub "/aws/firehose/${ResourceName}-KDF-LOG" LogStreamFirehose: Type: "AWS::Logs::LogStream" Properties: LogGroupName: !Ref "LogGroupFirehose" LogStreamName: "error" # ------------------------------------------------------------# # Lambda (Lambda,Iam Policy,Iam Role,Log Grop,Log Stream) # ------------------------------------------------------------# HelloWorldFunction: Type: "AWS::Lambda::Function" Properties: Code: ZipFile: | def lambda_handler(event, context): print("Hello,World") return { 'statusCode': 200, 'body': "Hello,World" } FunctionName: !Sub "${ResourceName}-LMD-HelloWorld" Handler: "index.lambda_handler" Role: !GetAtt "HelloWorldFunctionRole.Arn" Runtime: "python3.12" Timeout: "3" Architectures: - "x86_64" FuncLogGroup: Type: "AWS::Logs::LogGroup" Properties: LogGroupName: !Sub "/aws/lambda/${HelloWorldFunction}" SubscriptionFilterLambda: Type: "AWS::Logs::SubscriptionFilter" Properties: FilterName: !Sub "${ResourceName}-SFL-HelloWorld" DestinationArn: !GetAtt Deliverystream.Arn FilterPattern: " " LogGroupName: !Sub "${FuncLogGroup}" RoleArn: !GetAtt "LogsRole.Arn" HelloWorldFunctionRole: Type: "AWS::IAM::Role" Properties: AssumeRolePolicyDocument: Version: "2012-10-17" Statement: - Action: - "sts:AssumeRole" Effect: "Allow" Principal: Service: - "lambda.amazonaws.com" ManagedPolicyArns: - "arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole" RoleName: "IRL-LAMDA-HelloWorld" LogsRole: Type: "AWS::IAM::Role" Properties: AssumeRolePolicyDocument: Version: "2012-10-17" Statement: - Effect: "Allow" Principal: Service: !Sub "logs.${AWS::Region}.amazonaws.com" Action: - "sts:AssumeRole" Path: "/" Policies: - PolicyName: "root" PolicyDocument: Version: "2012-10-17" Statement: - Effect: "Allow" Action: - "firehose:*" Resource: !GetAtt Deliverystream.Arn RoleName: "IRL-CLOUDWATCHLOGS-HelloWorld"   ログの確認 Lambdaにてテストイベントを作成して実行します。CloudWatch Logsにログが出力されていることを確認します。 問題なければFirehoseが動きS3にてログが転送されます。新たなオブジェクトが作成されていますね。 オブジェクトをダウンロードして、ファイルを開いてみます。 中身をみると、解凍されたログになっていますね。 視認性を向上させるために、少し整形します。 Lambdaの実行ログの内容を無事確認することができました。 最後に いかがだったでしょうか。 Data Firehose の新機能である解凍処理について解説しました。 ただのストリーミング処理だけではなく、今まで Lambda が担っていた処理を Data Firehose が肩代わりしてくれる嬉しいアップデートかと思います。要件に応じて、利用の検討をいただければ幸いです。 本記事が皆様のお役にたてば幸いです。 ではサウナラ～🔥

こんにちは、広野です。 先日、React アプリに Amazon Bedrock に問い合わせる画面をつくってみた系の記事を公開いたしました。 React アプリに Amazon Bedrock への問い合わせ画面を組み込む [レスポンスストリーミング対応] React アプリに Amazon Bedrock に問い合わせる画面をつくってみたので React と AWS Lambda 関数のコードを紹介します。 blog.usize-tech.com 2024.01.16 今回は、Agents for Amazon Bedrock に問い合わせる画面をつくってみましたので紹介します。前回の記事の内容と似ていますが、一部アーキテクチャと API の仕様が異なります。 Agents for Amazon Bedrock についてはこちら。簡単に説明しますと、複数のデータソースの情報をもとにユーザからの問い合わせに自然言語で回答してくれるオーケストレーションサービス？のようなものです。今流行りの RAG 構築にも使われます。 Agents for Amazon Bedrock - Amazon Bedrock Learn about how to set up conversational agents using Amazon Bedrock docs.aws.amazon.com それでは、目次です。 つくったもの 一般的な質問はテキスト生成系 AI モデルから、当社 (SCSK 株式会社) に関する質問は別途用意したナレッジベースから情報を取得し、自然言語で返してくれます。最小構成の RAG という感じです。 一般的な質問（京都のお勧め観光地） 当社に関する質問 ※ 実は 当社に関する質問 を一般的な質問としてテキスト生成系 AI に投げると、残念なことに 誤った回答を返します 。（ハルシネーションと言われる現象）そのため、当社に関する質問は独自データベース (Knowledge Base) から情報を取得し回答するよう作り込んでいます。それが RAG と呼ばれる機能です。 ※ 上記画像は問い合わせから返事までの待ち時間をカットしています。実際には、1分近い待ち時間が発生しています。 アーキテクチャ RAG 用の Knowledge Base (ベクトルデータ) には、Agents for Amazon Bedrock が自動作成してくれる Amazon OpenSearch Service Serverless を使用しています。別途 Amazon S3 バケットを作成し、そこに当社公式ホームページの情報を PDF 化したファイルを格納し、OpenSearch に Sync させます。 一般的な回答をするために使用する生成系 AI の基盤モデルには、Amazon Bedrock の Anthropic Claude 2.1 を使用しています。 ユーザからの問い合わせ内容が当社 (SCSK 株式会社) に関連するものであれば Agents for Amazon Bedrock が自動的に OpenSearch 内の情報を取得します。それ以外の内容であれば AWS Lambda 関数経由で Claude 2.1 モデルに問い合わせます。 Agents for Amazon Bedrock に問い合わせるのは AWS Lambda 関数 (Node.js 20) です。関数 URL を持たせており、React アプリから直接呼び出します。 Lambda 関数を介さずに Agents for Amazon Bedrock の API に直接問い合わせることもできましたが、レスポンスのデータ構造がわからずあきらめました。 その AWS Lambda 関数からのレスポンスはレスポンスストリーミング対応にしています。それにより、Agents for Amazon Bedrock が回答を作成しつつ、レスポンスを画面に表示できるようにしています。ただ、実際に出来上がった画面を見てみると流れるようなテキスト表示はされていないので引き続き経験を積んで確認していきたいと思います。Agents for Amazon Bedrock を呼び出す API はレスポンスストリーミング対応の InvokeAgentCommand を使用しています。 補足ですが、React アプリから AWS Lambda 関数 URL を認証付きで呼び出す構成は以下参考記事の構成にしています。本記事では説明を割愛します。 やってみたら面倒くさい、React アプリからの Amazon Cognito 認証付き AWS Lambda 関数 URL 呼出 Amazon Cognito 認証を施した React アプリから、認証済みユーザのみ AWS Lambda 関数を呼び出せるようにする React コードを紹介します。 blog.usize-tech.com 2024.01.15 また、Agents for Amazon Bedrock により RAG 用の Knowledge Base を作成する方法については、以下の記事が参考になります。マネジメントコンソールで簡単につくれます。 生成AI初心者がAmazon BedrockのKnowledge baseを使ってRAGを試してみた AWS re:Invent2023にて、Amazon BedrockのKnowledge baseとAgentsがGAされたと発表がありました。今回はこのうちKnowledge baseを利用して、RAG（Retrieval Augment Generation）を試してみたいと思います。 blog.usize-tech.com 2023.12.07 図で表すと以下の赤枠部分のことです。ここについては今後の別記事でもう少し踏み込んで解説したいと思います。 AWS Lambda 関数コード AWS Lambda 関数に関数 URL を持たせる設定や、レスポンスストリーミングを有効にする設定は以下 AWS 公式ドキュメントを参照ください。この点において難しいことはありません。 Lambda 関数 URL の作成と管理 - AWS Lambda Lambda 関数の URL を設定して、他の AWS のサービスとの統合を必要とせずに、HTTP エンドポイントを Lambda 関数に割り当てます。 docs.aws.amazon.com ストリームレスポンスに Lambda 関数を設定する - AWS Lambda レスポンスをストリーミングする Lambda 関数を作成します。 docs.aws.amazon.com InvokeAgentCommand の API が Agents for Amazon Bedrock からのレスポンスを chunk 分割された状態で受け取るので、chunk ごとに React アプリへのレスポンス用ストリーム responseStream に放り込んでいます。レスポンスは Blob なので、途中で人が読み取れるテキストデータに変換する処理が入っています。 const { BedrockAgentRuntimeClient, InvokeAgentCommand } = require("@aws-sdk/client-bedrock-agent-runtime"); const bedrockagent = new BedrockAgentRuntimeClient({region: "${AWS::Region}"}); exports.handler = awslambda.streamifyResponse(async (event, responseStream, _context) => { try { const args = JSON.parse(event.body); if (args.prompt == '') { responseStream.write("No prompt"); responseStream.end(); } const agentInput = { "agentId": " BedrockAgentId ", //BedrockのエージェントIDが入る "agentAliasId": " BedrockAgentAliasId ", //BedrockのエージェントエイリアスIDが入る "sessionId": args.jobid, //セッションIDを入れる "enableTrace": false, "endSession": false, "inputText": args.prompt, //プロンプトを入れる "sessionState": { "promptSessionAttributes": { //任意で情報を入れることが可能 "serviceid": args.serviceid, "user": args.username, "datetime": args.datetime } } }; const command = new InvokeAgentCommand(agentInput); const res = await bedrockagent.send(command); const actualStream = res.completion.options.messageStream; const chunks = []; for await (const value of actualStream) { const jsonString = new TextDecoder().decode(value.body); const base64encoded = JSON.parse(jsonString).bytes; const decodedString = Buffer.from(base64encoded,'base64').toString(); try { chunks.push(decodedString); responseStream.write(decodedString); } catch (error) { console.error(error); responseStream.write(null); responseStream.end(); } } responseStream.end(); } catch (error) { console.error(error); responseStream.write('error'); responseStream.end(); } }); Python を採用していない理由は、AWS 公式ドキュメントにもありますが AWS Lambda 関数がレスポンスストリーミングをネイティブにサポートしているランタイムが Node.js のみだからです。※執筆時点 sessionId というパラメータを Agents for Amazon Bedrock に送信しています。UUID など一意の ID を生成して入れることで、2回目以降の問い合わせも同じ sessionId であれば過去の問い合わせ内容を自動的に関連付けて回答してくれます。便利！ 私のケースでは sessionId はアプリ側でも必要な情報なので、アプリ側で生成した ID を Lambda 関数に渡しています。 React コード React アプリ側は、Lambda 関数 URL を呼び出すために fetch を使用します。 AWS Lambda 関数 URL から chunk 分割されたレスポンスが送られてくるので、それを順次、直前の chunk と繋げて state に突っ込むだけの、非常に原始的なループのコードです。もっと簡単かつ効率的な処理になる SDK を AWS が開発してくれることを期待しております。 //レスポンス表示用、セッションID用state const [response, setResponse] = useState(""); const [jobid, setJobid] = useState(); //date、セッションID(jobid)とか const dt = new Date(); const datetime = dt.toISOString(); setJobid(uuidv4()); //送信するデータ const body = { prompt: prompt, jobid: jobid, serviceid: serviceid, user: username, datetime: datetime }; //Lambda関数URL呼出 try { const res = await window.fetch( "https://xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.lambda-url.us-west-2.on.aws", { method: 'POST', body: JSON.stringify(body), headers: signedRequest.headers //認証用の署名(説明割愛) } ); const reader = res.body.getReader(); const decoder = new TextDecoder(); const sleep = ms => new Promise(resolve => setTimeout(resolve, ms)); while (true) { const { value, done } = await reader.read(); if (done) break; const chunk = decoder.decode(value, { stream: true }); if (chunk) { setResponse(prevData => prevData + chunk); } await sleep(100); //100msごとに届いたchunkを処理(=画面更新) } } catch (error) { console.error('Error fetching:', error); } sleep のミリ秒数を調整することで、受け取ったレスポンス文章表示の流暢さを調整できます。 すみません、チャットボット画面の UI についてはややこしくなるので割愛させて頂きます。考え方としては、上記コード内にある response ステートをユーザのプロンプト prompt と交互に並べて表示することになります。 セッション ID はコード内では jobid という state に格納していますが、過去の問い合わせとの関係性をクリアするときには jobid を取得し直す処理が必要です。 まとめ いかがでしたでしょうか。 Amazon Bedrock のモデルを呼び出すコードと Agents for Amazon Bedrock とではレスポンスの仕様が異なるため全く同じというわけにはいきませんでした。AI/ML 領域は技術革新が激しいので、本記事の陳腐化も早いと思います。引き続きキャッチアップしていきたいと思います。 本記事が皆様のお役に立てれば幸いです。

こんにちは。今回は Amazon Redshift のクラスターを作成する時に遭遇したプチトラブルに対して、ブラウザの開発者ツールを使ったごく簡単なトラブルシュート方法について書いてみます。 今回の趣旨は、インフラ系技術者の方でWEBブラウザでのトラブルはあまり対応したことがない、という方に向けて、漠然と色々試すのではなく、トラブルの原因を探る一つの方法をお伝えすることです。この記事では Amazon Redshift のクラスター作成時のトラブルについて取り上げていますが、やり方自体は他のサービスでも使えるものです。 想定するトラブル AWSマネジメントコンソールでRedshiftクラスターを作成する際に、諸々の設定をして「クラスターを作成」をクリックしたが、何も反応がない、という状況を想定します。※実話です。 多くのケースでは、設定に問題があった時には画面上部に赤背景でエラーメッセージが出るので、それに応じて対処をすればよいのですが、しばしば今回のケースのように、何もエラーメッセージは出ていないのにクリックしても無反応で手掛かりがない、という状態に遭遇することがあります。 ブラウザの開発者ツールを使ったトラブルシュートの流れ こんな状況で、トラブルシュートの手がかりになり得るのが開発者ツールです。これはWEBブラウザに付属のツールで、ブラウザが裏でどのような通信をしたかやそのレイテンシ、どんなスクリプトを実行してどこで問題があったのか、等を表示してくれるもので、WEBアプリを作る際にはすぐ使える便利なツールとして一般に使用されています。Google Chrome、Edge等、有名なブラウザであれば大体実装されていますが、今回は私が普段使っているGoogle Chromeを例にお話します。 まず、「クラスターを作成」を押そうとした画面で、F12キーを押せば開発者ツールが起動します。 デフォルトでは、右下にコンソールがあり、エラー等のログはここから確認できます。 ここで、「クラスターを作成」をクリックした時に何か手がかりになるエラーが出力されていないか、試してみます。開発者ツールを起動した状態で、再度「クラスターを作成」をクリックします。 コンソールに1件エラーが出力されています。ログの内容は以下です。 Uncaught TypeError: Cannot read properties of undefined (reading 'keySource’) at t.createSnapshotCopyGrantMessage (main.js:2167:915175) at n.onCreateButtonClick (main.js:2167:898441) at l (main.js:27:153561) at onClick (main.js:27:567037) at Object.<anonymous> (main.js:2087:1410) at S (main.js:2087:1448) at main.js:2087:1594 at T (main.js:2087:1680) at O (main.js:2087:2129) at N (main.js:2087:1941) エラーのスタックトレースが出力されています。スタックトレースでは、処理のネスト構造がある場合は下から上に向かってネスト構造を深堀りしていく順に出力されますので、一番直近の（直接的な）エラーの原因は「at t.createSnapshotCopyGrantMessage」の行です。その前の「at n.onCreateButtonClick」という名称と、エラーの原因の直前に出力されていることから想像すると、「クラスターを作成」ボタンを押した時に流れる処理の中で、「t.createSnapshotCopyGrantMessage」という処理があり、ここでエラーが発生したのだろう、と予想がつきます。 さて、この「createSnapshotCopyGrantMessage」、名称上、すごく関係がありそうな入力項目がコンソールにあります。 怪しげですね。クロスリージョンスナップショットを設定する場合、スナップショットコピー権限の設定は必須なので、クロスリージョンスナップショットは一旦Disableで作っておいて、構築後にEnableする作戦で回避できないか試します。 無事作成が始まりました。これで問題としては解決しました。（後でクロスリージョンスナップショットをEnableするところは省略）。しかし、何がいけなかったのか気になるので、もう少しだけ調べてみます。 開発者ツールに戻って、直近の問題になっていた、「t.createSnapshotCopyGrantMessage」というのはどんな処理なのか確認します。コンソールには、エラーメッセージそのものの他、スクリプトのどこでその問題が起こったのか、ソースコードへのリンクが張られています。 ここをクリックすると、こんな感じのソースコードが見れます。 このソースコードを全て読み解くのは骨なので、ざっと見てわかることがないか考えます。 バツ印で具体的にどの行で問題があったのかを示してくれています。読んでみると、「KMS_KEY_SOURCE_AWS_OWNED」という文言があります。Redshiftに詳しい方ならピンとくるかもしれませんが、今回暗号化設定を入れており、AWS KMSの使用かつデフォルトのRedshiftキーを使用する、という選択にしていました。 後で実際に試してみたら、この暗号化を無効にすることで、クロスリージョンスナップショットをEnableにしていてもクラスターは作成できました。要はクラスター作成のワークアラウンドとしては、暗号化をDisableにするか、クロスリージョンスナップショットをDisableにするかどちらかを選択することになります。どちらでも問題はないと思いますが、まあ感覚的に言えば、クロスリージョンスナップショットの設定の方が暗号化と比べれば軽微な変更なので、クロスリージョンスナップショットをDisableにする方でいいかな、と思います。 まとめ 今回はAWSマネジメントコンソールでの操作が無反応だった時のトラブルシュートの方法として、ブラウザの開発者ツールを使う方法をお伝えしました。この方法では、AWSマネジメントコンソールのスクリプトまでは必ずしも理解する必要はなく、今回の例でもトレースしていたのはあくまで名前から怪しいコンポーネントを類推する方法でした。 それでもわからなければマニュアルを漁ったり設定を一つ一つ変更して切り分けを進めたりすることになりますが、ある程度の精度で素早く原因の当たりをつける、という意味で、ぜひ開発者ツールを活用してみてください。

こんにちは。SCSKのふくちーぬです。 皆さんは、AWS内の疎通テストをどのように実施していますでしょうか。pingコマンドやTest-NetConnectionコマンドを利用しているでしょうか。 今回は、VPC Reachability Analyzerを用いた疎通テストの手法をご紹介します。 VPC Reachability Analyzer AWS内のリソース間の接続性を擬似的にテストし、どの経路地点で問題があるか分析する機能です。 新機能 – VPC Reachability Analyzer | Amazon Web Services Amazon Virtual Private Cloud (VPC) を使用すると、お客様は、論理的に分離され aws.amazon.com Reachability Analyzerを利用することで、ルートテーブルやセキュリティグループのどこに設定不備があるか表示され、どこのネットワークに問題があるか容易に切り分けすることができます。到達不能箇所を特定することで、通信の到達性に関する問題の解決を手助けしてくれます。 How Reachability Analyzer works - Amazon Virtual Private Cloud Learn more about how Reachability Analyzer works. docs.aws.amazon.com 気になる料金は、一律で1回の分析あたり0.10 USDとなります。 アーキテクチャ EC2・VPCエンドポイントは、プライベートサブネットに配置する EC2からVPCエンドポイントに向けて、Reachability Analyzerを用いてTCP:443の疎通を実施する 検証① EC2インスタンスから、各VPCエンドポイントの疎通テストを実施し到達不能箇所を特定する CloudFormationテンプレート（ネットワークスタック） 下記のリソースを作成するCloudFormationテンプレートです。 VPC プライベートサブネット ルートテーブル セキュリティグループ VPCエンドポイント EC2 IAMロール 以下のテンプレートをデプロイしてください。 AWSTemplateFormatVersion: 2010-09-09 Description: cfn private EC2 Parameters: ResourceName: Type: String Resources: # ------------------------------------------------------------# # VPC # ------------------------------------------------------------# VPC: Type: AWS::EC2::VPC Properties: CidrBlock: 10.0.0.0/16 EnableDnsSupport: true EnableDnsHostnames: true Tags: - Key: Name Value: !Sub "${ResourceName}-VPC" # ------------------------------------------------------------# # Subnet # ------------------------------------------------------------# PrivateSubnet1a: Type: AWS::EC2::Subnet Properties: VpcId: !Ref VPC CidrBlock: 10.0.2.0/24 AvailabilityZone: ap-northeast-1a MapPublicIpOnLaunch: false Tags: - Key: Name Value: !Sub "${ResourceName}-PrivateSubnet-1a" PrivateSubnet1c: Type: AWS::EC2::Subnet Properties: VpcId: !Ref VPC CidrBlock: 10.0.3.0/24 AvailabilityZone: ap-northeast-1c MapPublicIpOnLaunch: false Tags: - Key: Name Value: !Sub "${ResourceName}-PrivateSubnet-1c" # ------------------------------------------------------------# # RouteTable # ------------------------------------------------------------# PrivateRouteTable: Type: AWS::EC2::RouteTable Properties: VpcId: !Ref VPC Tags: - Key: Name Value: !Sub "${ResourceName}-PrivateRouteTable" PrivateSubnet1aAssociation: Type: AWS::EC2::SubnetRouteTableAssociation Properties: SubnetId: !Ref PrivateSubnet1a RouteTableId: !Ref PrivateRouteTable PrivateSubnet1cAssociation: Type: AWS::EC2::SubnetRouteTableAssociation Properties: SubnetId: !Ref PrivateSubnet1c RouteTableId: !Ref PrivateRouteTable # ------------------------------------------------------------# # EC2 # ------------------------------------------------------------# EC2: Type: AWS::EC2::Instance Properties: ImageId: ami-0b193da66bc27147b InstanceType: t2.micro NetworkInterfaces: - AssociatePublicIpAddress: "true" DeviceIndex: "0" SubnetId: !Ref PrivateSubnet1a GroupSet: - !Ref EC2SecurityGroup Tags: - Key: Name Value: !Sub "${ResourceName}-ec2" EC2SecurityGroup: Type: "AWS::EC2::SecurityGroup" Properties: VpcId: !Ref VPC SecurityGroupIngress: - IpProtocol: tcp FromPort: 80 ToPort: 80 CidrIp: 10.0.0.0/16 GroupName: !Sub "${ResourceName}-ec2-sg" GroupDescription: !Sub "${ResourceName}-ec2-sg" Tags: - Key: "Name" Value: !Sub "${ResourceName}-ec2-sg" # ------------------------------------------------------------# # IAM Role # ------------------------------------------------------------# EC2Role: Type: AWS::IAM::Role Properties: Path: / RoleName: !Sub "${ResourceName}-ec2-Role" AssumeRolePolicyDocument: Version: 2012-10-17 Statement: - Effect: Allow Principal: Service: - ec2.amazonaws.com Action: - sts:AssumeRole MaxSessionDuration: 3600 ManagedPolicyArns: - arn:aws:iam::aws:policy/service-role/AmazonEC2RoleforSSM InstanceProfile: Type: AWS::IAM::InstanceProfile Properties: Path: / Roles: - !Ref EC2Role # ------------------------------------------------------------# # VPCEndpoint # ------------------------------------------------------------# SSMEndpoint: Type: AWS::EC2::VPCEndpoint Properties: ServiceName: !Sub "com.amazonaws.${AWS::Region}.ssm" SubnetIds: - !Ref PrivateSubnet1a - !Ref PrivateSubnet1c VpcId: !Ref VPC VpcEndpointType: Interface SecurityGroupIds: - !Ref EndpointSecurityGroup PrivateDnsEnabled: true EC2MessageEndpoint: Type: AWS::EC2::VPCEndpoint Properties: ServiceName: !Sub "com.amazonaws.${AWS::Region}.ec2messages" SubnetIds: - !Ref PrivateSubnet1a - !Ref PrivateSubnet1c VpcId: !Ref VPC VpcEndpointType: Interface SecurityGroupIds: - !Ref EndpointSecurityGroup PrivateDnsEnabled: true ssmmessagesEndpoint: Type: AWS::EC2::VPCEndpoint Properties: ServiceName: !Sub "com.amazonaws.${AWS::Region}.ssmmessages" SubnetIds: - !Ref PrivateSubnet1a - !Ref PrivateSubnet1c VpcId: !Ref VPC VpcEndpointType: Interface SecurityGroupIds: - !Ref EndpointSecurityGroup PrivateDnsEnabled: true EndpointSecurityGroup: Type: "AWS::EC2::SecurityGroup" Properties: VpcId: !Ref VPC GroupName: !Sub "${ResourceName}-endpoint-sg" GroupDescription: !Sub "${ResourceName}-endpoint-sg" Tags: - Key: "Name" Value: !Sub "${ResourceName}-ec2-sg"   CloudFormationテンプレート（分析スタック） 下記のリソースを作成するCloudFormationテンプレートです。 パスと分析 以下のテンプレートをデプロイしてください。 AWSTemplateFormatVersion: 2010-09-09 Description: Rechability Analyzer Test Parameters: ResourceName: Type: String InstanceId: Type: String VPCeIdForSSM: Type: String VPCeIdForSSMMesssages: Type: String VPCeIdForEC2Messsages: Type: String Resources: # ------------------------------------------------------------# # Rechability Analyzer Test01 # ------------------------------------------------------------# EC2NetworkInsightsPathForSSM01: Type: "AWS::EC2::NetworkInsightsPath" Properties: Destination: !Ref VPCeIdForSSM FilterAtSource: DestinationPortRange: ToPort: 443 FromPort: 443 Protocol: "tcp" Source: !Ref InstanceId Tags: - Key: Name Value: !Sub ${ResourceName}-test01-ssm EC2NetworkInsightsPathForSSMMessages01: Type: "AWS::EC2::NetworkInsightsPath" Properties: Destination: !Ref VPCeIdForSSMMesssages FilterAtSource: DestinationPortRange: ToPort: 443 FromPort: 443 Protocol: "tcp" Source: !Ref InstanceId Tags: - Key: Name Value: !Sub ${ResourceName}-test01-ssmmessages EC2NetworkInsightsPathForEC2Messages01: Type: "AWS::EC2::NetworkInsightsPath" Properties: Destination: !Ref VPCeIdForEC2Messsages FilterAtSource: DestinationPortRange: ToPort: 443 FromPort: 443 Protocol: "tcp" Source: !Ref InstanceId Tags: - Key: Name Value: !Sub ${ResourceName}-test01-ec2messages EC2NetworkInsightsAnalysisForSSM01: Type: AWS::EC2::NetworkInsightsAnalysis Properties: NetworkInsightsPathId: !Ref EC2NetworkInsightsPathForSSM01 EC2NetworkInsightsAnalysisForSSMMessages: Type: AWS::EC2::NetworkInsightsAnalysis Properties: NetworkInsightsPathId: !Ref EC2NetworkInsightsPathForSSMMessages01 EC2NetworkInsightsAnalysisForEC2Message: Type: AWS::EC2::NetworkInsightsAnalysis Properties: NetworkInsightsPathId: !Ref EC2NetworkInsightsPathForEC2Messages01  分析結果の確認 以下のように、VPCエンドポイントにアタッチしているセキュリティグループに適切なインバウンドルールがないことが判明しました。 検証② 各VPCエンドポイントのセキュリティグループのインバウンドルール（インバウンドルールに、HTTPS:443を許可する）を修正する 再度疎通テストを実施し到達可能を確認する CloudFormationテンプレート（ネットワークスタック） VPCエンドポイントにアタッチ済みのセキュリティグループを修正を行います。 以下のテンプレートをデプロイして、スタックの更新をします。 AWSTemplateFormatVersion: 2010-09-09 Description: cfn private EC2 Parameters: ResourceName: Type: String Resources: # ------------------------------------------------------------# # VPC # ------------------------------------------------------------# VPC: Type: AWS::EC2::VPC Properties: CidrBlock: 10.0.0.0/16 EnableDnsSupport: true EnableDnsHostnames: true Tags: - Key: Name Value: !Sub "${ResourceName}-VPC" # ------------------------------------------------------------# # Subnet # ------------------------------------------------------------# PrivateSubnet1a: Type: AWS::EC2::Subnet Properties: VpcId: !Ref VPC CidrBlock: 10.0.2.0/24 AvailabilityZone: ap-northeast-1a MapPublicIpOnLaunch: false Tags: - Key: Name Value: !Sub "${ResourceName}-PrivateSubnet-1a" PrivateSubnet1c: Type: AWS::EC2::Subnet Properties: VpcId: !Ref VPC CidrBlock: 10.0.3.0/24 AvailabilityZone: ap-northeast-1c MapPublicIpOnLaunch: false Tags: - Key: Name Value: !Sub "${ResourceName}-PrivateSubnet-1c" # ------------------------------------------------------------# # RouteTable # ------------------------------------------------------------# PrivateRouteTable: Type: AWS::EC2::RouteTable Properties: VpcId: !Ref VPC Tags: - Key: Name Value: !Sub "${ResourceName}-PrivateRouteTable" PrivateSubnet1aAssociation: Type: AWS::EC2::SubnetRouteTableAssociation Properties: SubnetId: !Ref PrivateSubnet1a RouteTableId: !Ref PrivateRouteTable PrivateSubnet1cAssociation: Type: AWS::EC2::SubnetRouteTableAssociation Properties: SubnetId: !Ref PrivateSubnet1c RouteTableId: !Ref PrivateRouteTable # ------------------------------------------------------------# # EC2 # ------------------------------------------------------------# EC2: Type: AWS::EC2::Instance Properties: ImageId: ami-0b193da66bc27147b InstanceType: t2.micro NetworkInterfaces: - AssociatePublicIpAddress: "true" DeviceIndex: "0" SubnetId: !Ref PrivateSubnet1a GroupSet: - !Ref EC2SecurityGroup Tags: - Key: Name Value: !Sub "${ResourceName}-ec2" EC2SecurityGroup: Type: "AWS::EC2::SecurityGroup" Properties: VpcId: !Ref VPC SecurityGroupIngress: - IpProtocol: tcp FromPort: 80 ToPort: 80 CidrIp: 10.0.0.0/16 GroupName: !Sub "${ResourceName}-ec2-sg" GroupDescription: !Sub "${ResourceName}-ec2-sg" Tags: - Key: "Name" Value: !Sub "${ResourceName}-ec2-sg" # ------------------------------------------------------------# # IAM Role # ------------------------------------------------------------# EC2Role: Type: AWS::IAM::Role Properties: Path: / RoleName: !Sub "${ResourceName}-ec2-Role" AssumeRolePolicyDocument: Version: 2012-10-17 Statement: - Effect: Allow Principal: Service: - ec2.amazonaws.com Action: - sts:AssumeRole MaxSessionDuration: 3600 ManagedPolicyArns: - arn:aws:iam::aws:policy/service-role/AmazonEC2RoleforSSM InstanceProfile: Type: AWS::IAM::InstanceProfile Properties: Path: / Roles: - !Ref EC2Role # ------------------------------------------------------------# # VPCEndpoint # ------------------------------------------------------------# SSMEndpoint: Type: AWS::EC2::VPCEndpoint Properties: ServiceName: !Sub "com.amazonaws.${AWS::Region}.ssm" SubnetIds: - !Ref PrivateSubnet1a - !Ref PrivateSubnet1c VpcId: !Ref VPC VpcEndpointType: Interface SecurityGroupIds: - !Ref EndpointSecurityGroup PrivateDnsEnabled: true EC2MessageEndpoint: Type: AWS::EC2::VPCEndpoint Properties: ServiceName: !Sub "com.amazonaws.${AWS::Region}.ec2messages" SubnetIds: - !Ref PrivateSubnet1a - !Ref PrivateSubnet1c VpcId: !Ref VPC VpcEndpointType: Interface SecurityGroupIds: - !Ref EndpointSecurityGroup PrivateDnsEnabled: true ssmmessagesEndpoint: Type: AWS::EC2::VPCEndpoint Properties: ServiceName: !Sub "com.amazonaws.${AWS::Region}.ssmmessages" SubnetIds: - !Ref PrivateSubnet1a - !Ref PrivateSubnet1c VpcId: !Ref VPC VpcEndpointType: Interface SecurityGroupIds: - !Ref EndpointSecurityGroup PrivateDnsEnabled: true EndpointSecurityGroup: Type: "AWS::EC2::SecurityGroup" Properties: VpcId: !Ref VPC SecurityGroupIngress: - IpProtocol: tcp FromPort: 443 ToPort: 443 CidrIp: 10.0.0.0/16 GroupName: !Sub "${ResourceName}-endpoint-sg" GroupDescription: !Sub "${ResourceName}-endpoint-sg" Tags: - Key: "Name" Value: !Sub "${ResourceName}-ec2-sg"   CloudFormationテンプレート（分析スタック） 再度パスの分析を実行します。 以下のテンプレートをデプロイして、スタックの更新をします。  AWSTemplateFormatVersion: 2010-09-09 Description: Rechability Analyzer Test Parameters: ResourceName: Type: String InstanceId: Type: String VPCeIdForSSM: Type: String VPCeIdForSSMMesssages: Type: String VPCeIdForEC2Messsages: Type: String Resources: # ------------------------------------------------------------# # Rechability Analyzer Test01 # ------------------------------------------------------------# EC2NetworkInsightsPathForSSM01: Type: "AWS::EC2::NetworkInsightsPath" Properties: Destination: !Ref VPCeIdForSSM FilterAtSource: DestinationPortRange: ToPort: 443 FromPort: 443 Protocol: "tcp" Source: !Ref InstanceId Tags: - Key: Name Value: !Sub ${ResourceName}-test01-ssm EC2NetworkInsightsPathForSSMMessages01: Type: "AWS::EC2::NetworkInsightsPath" Properties: Destination: !Ref VPCeIdForSSMMesssages FilterAtSource: DestinationPortRange: ToPort: 443 FromPort: 443 Protocol: "tcp" Source: !Ref InstanceId Tags: - Key: Name Value: !Sub ${ResourceName}-test01-ssmmessages EC2NetworkInsightsPathForEC2Messages01: Type: "AWS::EC2::NetworkInsightsPath" Properties: Destination: !Ref VPCeIdForEC2Messsages FilterAtSource: DestinationPortRange: ToPort: 443 FromPort: 443 Protocol: "tcp" Source: !Ref InstanceId Tags: - Key: Name Value: !Sub ${ResourceName}-test01-ec2messages EC2NetworkInsightsAnalysisForSSM01: Type: AWS::EC2::NetworkInsightsAnalysis Properties: NetworkInsightsPathId: !Ref EC2NetworkInsightsPathForSSM01 EC2NetworkInsightsAnalysisForSSMMessages01: Type: AWS::EC2::NetworkInsightsAnalysis Properties: NetworkInsightsPathId: !Ref EC2NetworkInsightsPathForSSMMessages01 EC2NetworkInsightsAnalysisForEC2Message01: Type: AWS::EC2::NetworkInsightsAnalysis Properties: NetworkInsightsPathId: !Ref EC2NetworkInsightsPathForEC2Messages01 # ------------------------------------------------------------# # Rechability Analyzer Test02 # ------------------------------------------------------------# EC2NetworkInsightsPathForSSM02: Type: "AWS::EC2::NetworkInsightsPath" Properties: Destination: !Ref VPCeIdForSSM FilterAtSource: DestinationPortRange: ToPort: 443 FromPort: 443 Protocol: "tcp" Source: !Ref InstanceId Tags: - Key: Name Value: !Sub ${ResourceName}-test02-ssm EC2NetworkInsightsPathForSSMMessages02: Type: "AWS::EC2::NetworkInsightsPath" Properties: Destination: !Ref VPCeIdForSSMMesssages FilterAtSource: DestinationPortRange: ToPort: 443 FromPort: 443 Protocol: "tcp" Source: !Ref InstanceId Tags: - Key: Name Value: !Sub ${ResourceName}-test02-ssmmessages EC2NetworkInsightsPathForEC2Messages02: Type: "AWS::EC2::NetworkInsightsPath" Properties: Destination: !Ref VPCeIdForEC2Messsages FilterAtSource: DestinationPortRange: ToPort: 443 FromPort: 443 Protocol: "tcp" Source: !Ref InstanceId Tags: - Key: Name Value: !Sub ${ResourceName}-test02-ec2messages EC2NetworkInsightsAnalysisForSSM02: Type: AWS::EC2::NetworkInsightsAnalysis Properties: NetworkInsightsPathId: !Ref EC2NetworkInsightsPathForSSM02 EC2NetworkInsightsAnalysisForSSMMessages02: Type: AWS::EC2::NetworkInsightsAnalysis Properties: NetworkInsightsPathId: !Ref EC2NetworkInsightsPathForSSMMessages02 EC2NetworkInsightsAnalysisForEC2Message02: Type: AWS::EC2::NetworkInsightsAnalysis Properties: NetworkInsightsPathId: !Ref EC2NetworkInsightsPathForEC2Messages02 分析結果の確認 VPCエンドポイントへの擬似的な疎通テストが成功していることを確認しました。 この後の作業としては、実際に各エンドポイントのAPIを叩くことにより適切なレスポンスが返却されるかテストしていただく流れになるかと思います。その際に、例えばアクセスエラーが出ればIAMロールの権限不足である可能性が濃厚となります。 最後に いかがだったでしょうか。 VPC Reachability Analyzerを用いて、容易に疎通テストを実行することができました。 検証作業等でネットワーク疎通不可事象が発生することが多いかと思います。その際には、AWSサポートへ問い合わせする前にご自身で疎通テストを実施し到達不能箇所を特定した上で調査していただければ幸いです。 本記事が皆様のお役にたてば幸いです。 ではサウナラ～🔥

こんにちは、SCSK株式会社の盛です。 今回は皆様にお知らせしたいことがあり、TechHarmonyに初寄稿しました。それは… SCSK株式会社は、 JAWS DAYS 2024   へ協賛します！ ランチセッション他、計３セッションに登壇します！　ご来場お待ちしております！ JAWS DAYS とは JAWS-UG ( J apan AWS U ser G roup) 主催、アマゾン ウェブ サービス ジャパン合同会社後援で開催される JAWS-UG 最大の エンジニアコミュニティイベント です。 JAWS-UGは日本全国に60以上の支部を持つ Amazon Web Services（以下AWS）のユーザーグループで、全国の各支部では、AWSに関する技術交流や人材交流が毎週のように行われ、AWSユーザーの技術力向上およびビジネスの拡大に寄与しています。 JAWS DAYS 2024 のテーマは 「 LEAP BEYOND 」 リアルなイベント会場で 「ビジネスとテクノロジー」「地方と都市」「学生と社会人」 など、さまざまなバックグラウンドを持つ人が同じ空間を共有します。この空間の中で、異なる価値観の人たちが、自分たちのコミュニティを飛び越えて偶然に出会う場を提供することで、新しい可能性を探っていく主旨となっています。 AWS初心者から上級者までのエンジニア、経営者や人事、マーケティング、エンタープライズからスタートアップ、中小企業など職種や業態・会社規模を問わず、たくさんの方に参加いただけるイベントです。   イベント概要 開催日時： 2024年3月2日(土)  – セッション：10:00〜17:00  – 懇親会：17:30〜19:30（予定） 場所：池袋サンシャインシティ 展示ホールA  – 住所：〒170-8630 東京都豊島区東池袋3-1   弊社からの登壇について それでは、弊社登壇者のセッション内容について、簡単にご紹介させていただきます。 CIer・SIer集まれ！！ クライアントワークな私たちとAWSの良い関係を考えよう！ 講演時間 ： 11:00～11:50 講演場所 ： セッションE SCSK登壇者 ： 木澤 朋隆 (AWS Ambassador) 受託開発経験者3名のCIer・SIerによる、よもやまパネルディスカッションに弊社木澤がパネリストとして参加します。 クライアントワークならではの苦労話や成功事例を知って、共に考え、楽しく学べるセッションです。 セッション詳細 エンジニアブログ「TechHarmony」注目記事のご紹介 講演時間：12:45～13:00（ランチセッション） 講演場所：セッションE SCSK登壇者： 齋藤 友宏 (AWS Jr.Champions) ・ 木澤 朋隆   本エンジニアブログTechHarmony から、選りすぐりの記事に触れ、解説するセッションです。 皆様のお役に立とうと日々のAWSアップデートをキャッチアップするKawarimonoたちが、業務中にふと得られた気付きであったり、ふと閃いたことなどについて執筆している本ブログですが、その中から選りすぐりの記事をご紹介します。 皆様にとって、偶発的なshi AW a S eを手繰り寄せる何かが見つかれば幸いです。 セッション詳細 子育てエンジニアパネルディスカッション ～コーディングとおむつ替えの狭間で～ 講演時間：16:10～17:00 講演場所：セッションC SCSK登壇者： 中村 朋世 SCSKは ダイバーシティ＆インクルージョン(D&I)の施策 を全社で推進しており、多様な人材が活躍しています。特に ワーク・ライフ・バランス の推進は業界に先駆けて行われており、多数の社員にて育児との両立が行われています。 本パネルディスカッションには弊社からパネリストとして中村が登壇し、子育てと日進月歩で進化する技術のキャッチアップ、両面を追いかけるコツについて語り合います。 セッション詳細 他にもセッションが多数！ JAWS DAYS 2024では、その他にも素敵なセッションが多数あります。 詳細は イベントサイト（セッション一覧） をご覧下さい。   お申込み 本イベントへの申込はイベント公式サイトからどうぞ。 （人数制限がございます。早めの登録がオススメです） Click Here ！ 👇🖱 JAWS DAYS 2024 JAWS DAYS 2024 Official HP jawsdays2024.jaws-ug.jp 当日は池袋サンシャインシティにてお待ちしております。 是非ご来場下さい！

こんにちは、SCSK 浦野です。 1月があっという間に過ぎてしまい、すでに2月の中旬であることに焦りを覚えている筆者です。 昨年は自分の中では生成AIに驚かされ続けた1年でした。興味がある分野でもありましたので、自宅でRVCでボイスチェンジをしてみたり、Stable Diffusion で絵を生成してみたりしていましたが、ここのところはあまり触れていませんでした。 そんななか、AWSのブログを見ていたところ「 Amazon Bedrock を利用して、画像生成アプリケーションを開発してみた！ 」という記事を見つけました。 昨年 Amazon Titan Image Generator G1 が発表されておりましたが、こちらも触れられていなかったので、モデルを Amazon Titan Image Generator G1 に変更して試してみました。その際に少し追加の手順が必要になりましたので、共有できればと思います。 前提など 手順は「 Amazon Bedrock を利用して、画像生成アプリケーションを開発してみた！ 」を参考に実施致します。 但し、Amazon Titan Image Generator G1 を使ってみたいので、モデルの選択で Amazon Titan Image Generator G1 を選択、呼び出し等はそれに合わせて変更します。 Amazon BedrockでTitan Image Generator G1を利用可能にする Amazon Bedrock を開き、左ペインの「モデルアクセス」をクリック、右上の「モデルのアクセスを管理」をクリックします。 表示された画面でTitan Image Generator G1のチェックボックスにチェックを入れて、「変更を保存」をクリックします。 変更後、アクセスのステータスが「アクセスが付与されました」となっていることを確認します。  S3バケット作成 生成された画像を保存するバケットを作成します。 コンソールでS3に移動し、「バケットを作成」から適当な名前を付けえたバケットを作成します。バケットの設定は全てデフォルトで作成します。  Lambda関数作成 コンソールでLambdaに移動し、 「関数の作成」をクリック 適当な関数名を指定、ランタイムで「Python 3.12」を選択し、その他はデフォルトで「関数の作成」をクリックします。 コードを書きたいところですが、先に Lambda の IAM ロールを変更します。 この際に Titan Image Generator G1を利用するので、Resource の部分で amazon.titan-image-generator-v1 を指定します。  { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "bedrock:InvokeModel" ], "Resource": [ "arn:aws:bedrock:us-east-1::foundation-model/ amazon.titan-image-generator-v1 " ] }, { "Effect": "Allow", "Action": [ "s3:GetObject", "s3:PutObject" ], "Resource": [ "arn:aws:s3:::{作成したバケット名}/*" ] } ] }   コードを記述します。Titan Image Generator G1を利用するため、Titan Image Generator G1に合わせた設定で記述します。 コードを保存後に、「設定」からタイムアウトを3分程度に変更します。(筆者が試した範囲では1枚生成されるのに30秒前後かかっていました) import json import boto3 from io import BytesIO import base64 from PIL import Image from botocore.config import Config import uuid def lambda_handler(event, context): bedrock_runtime = boto3.client('bedrock-runtime') my_config = Config(region_name="us-east-1", signature_version="s3v4") s3 = boto3.client("s3", config=my_config) bucket_name = '{作成したバケット名}' text = event['input_text'] image_num = 1 body = json.dumps({ "taskType": "TEXT_IMAGE", "textToImageParams": { "text": text, }, "imageGenerationConfig": { "numberOfImages": image_num, "quality": "premium", "height": 768, "width": 1280, "cfgScale": 7.5, "seed": 0 } }) response = bedrock_runtime.invoke_model( body=body, modelId="amazon.titan-image-generator-v1", accept="application/json", contentType="application/json" ) response_body = json.loads(response['body'].read()) images = [Image.open(BytesIO(base64.b64decode(base64_image))) for base64_image in response_body.get("images")] presigned_urls = [] for img in images: img_data = BytesIO() img.save(img_data, format='PNG') img_data.seek(0) random_uuid = uuid.uuid4().hex s3_key = f"{random_uuid}.png" s3.upload_fileobj(img_data, bucket_name, s3_key, ExtraArgs={'ContentType': 'image/png'}) presigned_url = s3.generate_presigned_url( 'get_object', Params={'Bucket': bucket_name, 'Key': s3_key}, ExpiresIn=3600 ) presigned_urls.append(presigned_url) return { 'statusCode': 200, 'body': json.dumps({'presigned_urls': presigned_urls}) } Lambda Layerの登録 記載したコードでは画像処理ライブラリのPillowを利用していますが、デフォルトのランタイムには含まれていない為、Lambda Layerの登録を行う必要があります。 python 3.12の環境でライブラリをインストールし(Cloud9等で環境を準備できます)、zipファイルに圧縮してレイヤーにアップロードして登録後、Lambda関数側の「レイヤー」から登録したレイヤーを追加してください。   テスト実行 Lambdaの画面にある「Test」ボタンを押し、テストイベントを設定します。イベントJSONには、以下のような形で生成を希望するテキストを記述します。「保存」を押して保存後に、「テスト」を押すと生成が実行されます。 { "input_text": "Mt Fuji" } 実行し、成功するとレスポンスとしてURLが返されますので、ブラウザにURLを入れると生成された画像を見ることができました。 参考元では、APIの設定やフロントの作成もありますが、同様の手順で実装できますので本記事ではスキップさせて頂きます。

本記事の内容は、以下のCato Networks社の記事を元に日本語へ意訳し、再構成したものとなります。 Cato Endpoint Protection (EPP) Endpoint Protection (EPP) Cato Endpoint Protection (EPP) is the industry’s first SASE-managed EPP solution protecting endpoints against advanced malware, evasive attacks and zero-day thr... www.catonetworks.com Cato Extended Detection and Response (XDR) Extended Detection and Response (XDR) Cato XDR is the industry’s first SASE-based detection and response solution empowering security teams with granular and efficient threat investigation and remed... www.catonetworks.com Cato Networks社 は、2024年2月5日に、端末のマルウェア対策である Endpoint Protection (EPP) と、SASEのネットワークのログだけでなく、エンドポイント（EPP/EDR）も含めた様々なログを統合し、総合的に分析し、インシデント対応を一元化する Extended Detection and Response (XDR) をリリースしました。 Cato EPPは、これまでのSASEとしてのネットワーク層を超え、エンドポイントにまでセキュリティ範囲を拡張する製品 となり、Cato管理アプリケーション（Cato Management Application、以下、CMA）に完全に統合され、クラウドネイティブな他のセキュリティスタックと連携して動作します。 Cato XDRは、世界初のSASEベースのXDR（Extended Detection and Response） です。Catoクラウドのセキュリティ機能である NGFW、SWG、IPS、NGAM、DNS Security、CASB、DLP、RBIの各種データを始め、Cato EPP、さらに、Microsoft Defender、CrowdStrike、SentinelOne などの主要EDRソリューションと連携により、エンドポイントからネットワークにまたがる豊富なネイティブセンサーから収集される上質なデータから、脅威の探索・検出・対応に単一の共有コンテキストを提供することが可能になります。 それでは、CatoクラウドのEPPとXDRについてご紹介します。 Cato EPPについて Cato エンドポイントプロテクション（EPP）は、高度なマルウェア、回避型攻撃、ゼロデイ脅威からエンドポイントを保護する世界初のSASE管理型EPPソリューションです。 Cato EPPは、CatoのマルチレイヤーSASEアーキテクチャにエンドポイント保護と検出機能を追加し、管理オーバーヘッドを削減し、セキュリティチームの効率を高め、企業のセキュリティ体制を改善します。 ファイル実行前とランタイムでマルウェアを阻止 Cato EPPは、アーカイブやパックされたファイルを含む300以上のファイルタイプをスキャンします。高度なルールベースの分析と機械学習アルゴリズムを使用し、ファイルの特性分析に基づいて、既知のマルウェア、ポリモーフィック、ゼロデイマルウェアを識別します。Cato EPPは、ヒューリスティックとプロセス行動分析を使用して、疑わしい悪意のあるアクティビティをリアルタイムで検出します。この機能により、システムメモリ内で直接動作するファイルレス・マルウェア、回避型エクスプロイトやゼロデイ攻撃、正規のツールを悪意のある目的に活用する Living Off The Land （※） 攻撃の検出と防止が可能になります。攻撃対象領域をさらに最小化するために、Catoはデバイス制御によってUSBドライブの使用をブロックすることができます。 （※）Living Off The Land（環境寄生型）とは、対策側の監視や調査を回避することを目的として、持ち込んだ正規ツールの悪用や被害者の環境にあるシステムを悪用する、痕跡を残さない攻撃手法。 侵害されたエンドポイントに対する柔軟な封じ込めオプション マルウェアによる潜在的な被害を最小限に抑えるには、脅威へのリアルタイムな対応が不可欠です。しかし、自動化されたレスポンスとユーザの生産性の間には、微妙なバランスが必要です。Catoは、脅威のブロック、ファイルの隔離、プロセスの終了など、組織のセキュリティ要件に合わせて封じ込めポリシーを調整できる柔軟性を管理者に提供します。 EPPをSASEに統合し、セキュリティ管理を合理化 Cato EPPは、Cato管理アプリケーション（CMA）を通じて完全に管理され、他のすべてのCatoクラウドのプラットフォーム機能とシームレスに統合されています。管理者は、ユーザーデータ、ネットワーク情報、およびセキュリティポリシーが統合された統一コンソールから、保護されたエンドポイントを監視できるという利点があります。Cato EPPにより、管理者はスタンドアロンのエンドポイント保護ソリューションを統合、維持、管理する必要がなくなります。すべてのEPPイベントとアラートがCatoクラウドプラットフォームのネイティブな一部となったため、手動によるSIEM統合も不要になりました。 迅速な導入とユーザー影響のない即時保護 Cato EPPは、Cato管理アプリケーション（CMA）またはお客様が選択したモバイルデバイス管理ツール（MDM）を介してプロビジョニングすることができます。管理者は、数分で数千のエンドポイントの保護を開始できます。インストール後、Cato EPPエージェントはバックグラウンドで実行され、エンドユーザーには完全に透過的です。ログイン不要で、エンドポイントでセキュリティイベントが発生すると、ユーザーは即座に保護され、アラートが表示されます。アドホックなマルウェアスキャン活動は、ユーザーまたは管理者がCato管理アプリケーション（CMA）から直接開始できます。 ネットワークとエンドポイントが同じデータレイクを使用することで検出とレスポンスをより速く（XDR対応） Cato EPPのイベントは、Catoクラウドプラットフォームの各種エンジンによって生成された他のすべてのイベントと同じデータレイクに保存されます。Cato XDRは、AI/ML脅威の検知と調査を最適化するために、ネットワークベースのセンサーとともに、高品質のエンドポイントデータを活用します。管理者は、1つの画面でエンドポイントとネットワークのすべてのセキュリティイベントの統一されたリストを見ながら、ユーザーやデバイスごとにイベントを簡単にフィルタリングすることができ、効率的なインシデント調査と対応が可能になります。   Cato XDRについて Cato XDRは、世界初のSASEベースのXDRソリューションであり、セキュリティチームにきめ細かく効率的な脅威調査・修復ツールを提供します。Cato XDRのAIとMLアルゴリズムは、膨大なデータレイクから脅威を特定し、Cato管理アプリケーション（CMA）内で分析と解決のために管理可能な方法で浮上させます。 脅威防御エンジンのアラート疲れを見抜く Cato XDRは、Catoのリアルタイムセキュリティエンジンによって生成されたブロックイベントを集約し、単一の脅威防御インシデントにグループ化します。これらのインシデントは、セキュリティチームがアラート疲れを克服し、侵害されたデバイスを迅速に検出し、適切な封じ込めと修復のアクションを取るのに役立ちます。 回避的なセキュリティ脅威の検出と修復 Cato XDR 脅威ハンティング（ Threat Hunting ）インシデントは、CatoのAI/MLエンジンによって作成されます。脅威ハンティングエンジンは、データレイクを継続的にスキャンし、防御レイヤーでブロックされなかった常駐脅威の異常な指標を探します。脅威ハンティングエンジンは、さまざまなシグナルを1つのインシデントにグループ化し、セキュリティ・アナリストがさらに調査を行います。さらに、MLアルゴリズムは各インシデントにリスクスコアを提案し、セキュリティチームが脅威の調査に優先順位をつけられるようにします。 異常検知で不審なユーザー行動を調査 Cato XDRは、悪意を示す可能性のある異常な行動を特定するために、 エンドユーザー行動分析（EUBA） 機能を統合しています。異常検知AI/MLエンジンは、ユーザーのネットワークアクティビティを事前に計算されたベースラインと比較し、異常検知インシデントの作成を通じて、疑わしい逸脱について警告します。セキュリティ・チームは、報告されたインシデントが悪意あるものか良性かを効率的に調査・判断し、それに応じて行動を起こすための詳細な情報と洞察を得ることができます。 生成AIとMITRE ATT&CKマッピングでインシデント調査をスピードアップ Cato XDRは、セキュリティチームの効率的な運用を可能にするため、複数のAI技術を使用している。生成AIは、Cato XDRのインシデント「ストーリーテラー」に使用されており、インシデントのデータポイントを脅威のストーリーにシームレスに結び付け、理解しやすく伝わりやすい要約を作成します。 脅威とリスクの分析をさらに支援するために、Cato XDRのインシデントは特定の MITRE ATT&CK TTPs（Tactics Techniques and Procedures） にマッピングされ、セキュリティチームが攻撃のキルチェーンにおける攻撃者の進捗状況を正確に理解するのに役立ちます。 エンド・ツー・エンドの可視性と迅速な修復を実現 XDRソリューションの一般的な課題は、修復アクションが異なるプラットフォーム上で実行されることです。 Cato XDRは、Catoクラウドプラットフォームのネイティブ機能であり、セキュリティチームが同じソリューション内でアクティブな脅威を修復することを可能にします。エンドポイントと攻撃封じ込めのためのファイアウォールルールは数分で設定でき、インターネットとの悪意のあるトラフィックをブロックし、WANを介したマルウェアのさらなる拡散を防止します。EPPスキャンは即座にトリガーされ、感染や侵害の可能性があるエンドポイントをプロアクティブにクリーニングします。 高度に訓練された実証済みAI/MLを搭載したオープンなXDR Cato XDRは、Catoクラウドプラットフォームのネイティブセンサーからの生のデータと、サードパーティのEDRソリューションなどの外部センサーからのイベントを、単一のデータレイクに収集するオープンなXDRソリューションです。Cato XDRは、脅威ハンティングと異常検知のために高度なAIとMLアルゴリズムを使用しています。このアルゴリズムは、元軍人のセキュリティ・アナリストとデータ・アナリストによって開発され、ペタバイトのデータと数兆件のイベントで訓練され、すでに数万件の確認されたセキュリティ・インシデントで実証されています。Cato XDRは、SOCチームが脅威の滞留時間を短縮し、セキュリティ・インシデントを迅速に修復することを可能にします。 脅威の検知、調査、対応（TDIR）のための単一コンソール Cato XDRは、脅威の検知、調査、対応（ Threat Detection , Investigation and Response：TDIR ）を行い、インシデントのライフサイクル全体を管理する単一のコンソールをSOCチームに提供します。Cato管理アプリケーション（CMA）内のXDRダッシュボードは、すべてのインシデント、そのステータス、MLで計算されたリスクと優先度を表示します。個々のインシデントの調査は、ワンクリックで完了し、AIを活用した洞察と推奨によって強化された、さらなる分析のための共通のデータ表示構造を備えています。SOCチームは、管理コンソールを切り替える手間を省き、効率を高め、ヒューマンエラーの可能性を減らすことができます。 業界で最も広範なネイティブセンサーが、より優れた検知と迅速なレスポンスを実現 Cato XDRは、Catoクラウドプラットフォームのセキュリティ機能をネイティブセンサーとして使用します。Catoクラウドの NGFW、SWG、IPS、NGAM、DNS Security、CASB、DLP、RBIからのデータは、Catoデータレイクに保存され、Cato XDRへの高品質なインプットとして機能します。ネイティブセンサーのデータはソースで削減されないため、Cato XDRのAI/MLアルゴリズムは、外部ソースからのデータを処理するAI/MLに比べて、重要なシグナルを見逃す可能性が大幅に低くなります。SOCチームは、比類のないレベルのインシデント精度と豊富な調査用データから利益を得ることができます。 MLを活用したクラウド規模の脅威インテリジェンスにより、有効性を向上し、誤検知を削減 Cato XDRは、250以上の脅威インテリジェンスソースによって強化されており、500万件以上の有効なIoCレコードを生成します。Catoは、専用に構築されたクラウドスケールのMLプラットフォームを使用して、何百ものソースから脅威インテリジェンスフィードを取り込み、その中の各IoCレコードを処理して検査し、正確で最新のブラックリストとホワイトリストを維持します。 Catoは、セキュリティチームに最新の脅威インテリジェンスデータを提供し、誤検知をほぼゼロに抑えた効率的な運用を実現します。 まとめ CatoクラウドのSASEから少し離れて、EPP、XDRの記事をご紹介させていただきました。 Catoクラウドに少しでも興味をお持ちになられた方は、遠慮なくSCSKまでお問い合わせください。 SASE、Cato Networks社、Catoクラウド（Cato Cloud/Cato SASE Cloud）自体の知名度もまだまだ低い状況です。 SCSKでは、2021年からSASEの主要ソリューションを一同に紹介を行うオンラインセミナー「SCSK SASE Solution Summit（通称：S4 エスフォー）」を定期的に開催しております。これまで13回開催し、1,600名以上の方にご参加いただいております。 次回は、2024年2月15日に開催いたしますので、ご興味のある方は是非ご参加ください（2024年2月時点） さらに、2024年3月14日には、Catoクラウドの主要機能を2時間・デモ形式でご覧いただけるセミナーを開催しますので、ご興味のある方は是非ご参加ください。 【好評につき追加開催決定！】SCSK SASE Solution Summit (S4)ー主要4製品の違いや強みを横並びでご紹介！ー 弊社グループにて取り扱っている4つのSASE製品の気になるポイントをギュッと凝縮しており、製品比較や選定行っていくための情報を一度に収集できるため、「SASEの関する情報収集中の方」だけでなく、「自社の課題解決に最適なSASEを知りたい方」、「他社の導入成功事例を聞きたい方」のご参加を心よりお待ちしております！ www.scsk.jp Catoクラウドデモセミナー～Catoクラウドの主要機能を2時間で網羅～ 本セミナーでは、世界初のSASEである「Catoクラウド」の概要をたっぷり2時間、デモ形式でご覧いただきます。 また、ご希望の方（先着10名様）は、デモ環境に対して、お手元の環境からハンズオン形式でCatoクラウドに触れて頂くことが可能な参加型セミナーです。 www.scsk.jp SASE、Catoクラウドのセミナー以外に、Catoクラウドのお客様導入事例の制作、FAQサイト運営、この TechHarmony（技術ブログ）で、皆様のお役に立て、Catoクラウドの知名度アップに少しでも貢献できればと考えております。

こんにちは、広野です。 2024 年 4 月から正式リリースされる AWS 認定の新試験、Data Engineer – Associate のベータ版試験を 2023 年 12 月に受験しておりまして、先日合格通知が届きました。その受験記や対策っぽい情報を紹介したいと思います。 Data Engineer – Associate 試験って？ 冒頭にも書きましたが、新たに新設される AWS 認定試験です。近年のデータ活用、AI/ML 技術の注目度合いから、従来のソリューションアーキテクト、ディベロッパー系に次ぐ新たな体系をつくったものと想像します。 公式情報はこちらをご覧下さい。 AWS Certified Data Engineer - Associate 認定 | AWS 認定 AWS テクノロジーを使用して分析や実用的なインサイトを得るためにデータを変換することにご関心がおありの場合、このベータ試験は、この新しい認定の最初の取得者となる機会を提供します。AWS は、試験ガイド、テスト問題のサンプル、トレーニングリソースを提供しています。詳細をご覧ください。 aws.amazon.com ベータ版試験って？ AWS が試験を新設する場合、正式リリース前にベータ版試験をリリースします。実際の受験者のフィードバックを受けて、正式リリースまでに改修を入れるのが目的と思います。 ベータ版試験には、以下の特徴があります。 期間限定 英語でしか受けられない 費用は半額で受けられる（バウチャーの併用は不可） 合格発表は受験から数か月後 合格すれば正式資格として認定される デフォルトで半額で受けられるメリットはありますが、日本人的には英語でしか受けられないというのがデメリットでしょう。 試験対策は？ 今後の正式リリースのために、執筆時点での対策を残しておきます。ベータ版試験からの個人的な見解なので、正式リリースされた試験とは若干違いがあると思いますが、そこはご了承ください。 そもそも新試験なので、今時点、受験対策本などはありません。公式情報に頼るしかありません。 まずは公式「試験ガイド」で試験範囲を押さえる 前述、公式サイトのリンクに試験ガイドの PDF 資料があります。これで、ある程度どんなことが問われるのかは想像できます。わかりやすく言いますと、今後廃止予定ではありますが Data Analytics – Specialty (DAS) と同じ領域ですので、内容はほぼ同じと思ってよいと思います。試験対策も DAS の対策をすれば半分以上は取れるかな、と思います。 出題イメージを押さえる AWS Skill Builder という AWS 公式の e-Learning サイトに 20 問だけですが公式練習問題が掲載されています。日本語もあります。こちらを見れば、どんな出題がされるのかイメージは湧くと思います。 出題されるサービスを理解しておく 全てを理解する必要はないのですが、各サービスで何ができるのか、他のサービスと組み合わせるとどのようなユースケースに対応できるのか、を理解するとよいと思います。次の章で特に理解しておくべきサービスを紹介します。 絶対に理解しておくべき AWS サービス 以下 5 つ。データ活用の中核となる AWS サービスです。 Amazon Redshift Amazon QuickSight Amazon Athena AWS Glue Amazon RDS これらは、AWS の Blackbelt 等でまんべんなく理解しておく必要があります。RDS に関しては、SAA や DBS 試験の知識で兼ねることができます。その他、SAA, DVA, SOA の知識で賄える部分があるので、それらを合格している状態で受験されることをお勧めします。 AWS Glue は特に Glue XXXXX といった Glue 系のいくつかのサービスに分かれているので、それらのユースケースを全て理解しておきましょう。 Amazon Redshift には Redshift Spectrum というサービスがあります。Redshift との違いはしっかり押さえておきましょう。 あまり深入りすると試験規約上よろしくないので、この程度にとどめておきます。 その他学習しておいた方がよいこと 以下、勉強しておいて良かったな、と感じたことです。 データレイクの考え方。Amazon S3 にあらゆるデータを集約させ、Glue で ETL、Athena でクエリー、QuickSight で可視化、という王道の設計パターンの理解は必須です。加えて、Lake Formation でできること、たとえばアクセス制御はどんなことができるかは押さえておきましょう。 データ活用の過程で、データを処理するパイプラインを作成するユースケースがあります。このとき、パイプラインを作成するソリューションとして以下 3 つが挙げられます。使い分けを理解しておくとよいでしょう。 AWS Step Functions AWS Glue Workflow Amazon Managed Workflows for Apache Airflow ETL ジョブのスケジュールも、以下 3 つの違いは押さえておきましょう。 Amazon EventBridge AWS Batch AWS Glue Workflow オンプレミスからの大量データ移行も押さえておきましょう。AWS DMS や AWS DataSync が一般的です。 こうして見ると、結構幅広いですね。 まとめ いかがでしたでしょうか。情報少なくて申し訳ないです。 DEA はアソシエイトレベルとは言え、かなり難易度高かった印象です。記事内で申しておりましたが、DAS と同じレベルと思ってもらえればと思います。今後は SAA、DVA、SOA と並ぶ試験になりますし、データ活用も今後必要な知識になりますので、是非皆様もチャレンジ頂けたらと思います。 本記事が皆様のお役に立てれば幸いです。