こんにちは、SCSK石黒です。 最近案件でTerraformを触る機会がありIaCについて勉強中なのですが、 Google Cloudが提供するIaCサービス、Infrastructure Managerを触ったことが無かったので、 今回はInfrastructure Managerを使って自動構築をしてみようと思います。 Infrastructure Managerとは サービス概要 Infrastructure Manager（Infra Manager）はTerraform を使用した、リソースのデプロイと管理を自動化できるサービスです。 2023/9にリリースされた比較的新しいサービスとなります。 Terraform Cloudについての概要は以下をご確認ください。 TerraformによるGoogle Cloud環境構築 TerraformによるGoogle Cloud環境構築の手順を、セットアップ方法から紹介します。 blog.usize-tech.com 2024.11.22 Terraform Cloudとの違い Terraform Cloudは、Cloudshellやローカル環境にTerraformをインストールする等の環境構築を行ってから実行する必要がありますが、Infrastructure Managerを使えばそのような環境構築をせずともTerraformを実行できます。 コードを実行するためのtfファイルをGCSに置いてInfrastructure Managerを実行するだけでスピーディーに自動構築ができます。 また、実行がGoogle Cloud上で完結するため、環境制約がTerraform Cloudと比較して少ないことも挙げられます。 料金 Cloud Build の実行と Cloud Storage のストレージに対して課金がされる仕組みとなります。 詳しい料金体系は公式ページをご確認ください。 料金  |  Infrastructure Manager  |  Google Cloud Infra Manager の料金を確認する cloud.google.com   実際に使ってみた 今回はBigQueryテーブルを自動構築してみたいと思います。 CLIから構築するやり方と、コンソール画面から構築するやり方の2パターンがありますので、 それぞれ記載します。 ※基本的な流れは以下公式ドキュメントのクイックスタートを参考にしています。 クイックスタート: Infrastructure Manager を使用して VPC をデプロイする  |  Google Cloud Infrastructure Manager を使用して VPC をデプロイします。 cloud.google.com APIの有効化 CLI Cloudshellで該当のプロジェクトにログイン後、以下を実行します。 gcloud services enable config.googleapis.com   コンソール コンソール上から「Infrastructure Manager API」を検索し、開きます。 APIを有効にします。有効後以下の画面になればOKです。 サービスアカウント作成 CLI Infrastructure Managerを使用する際にサービスアカウントの指定が必要です。 今回は「inframg_test」というサービスアカウントを作成して使用します。 サービスアカウントの名前は適宜変換してください。 gcloud iam service-accounts create inframg_test   コンソール IAMの画面の「サービスアカウント」から「サービスアカウントを作成」をクリックします。 サービスアカウント名を入力して完了をクリックします。 権限付与 CLI サービスアカウントにInfrastructure Managerを使用する際に必要な権限を付与します。 サービスアカウント名と「PROJECT_ID」の個所は適宜変更してください。 gcloud projects add-iam-policy-binding PROJECT_ID --member = "serviceAccount:inframg_test@ PROJECT_ID .iam.gserviceaccount.com" --role = roles/config.agent また、自動構築するリソースを作成するのに必要な権限も付与します。 今回はBigQueryテーブルを作成するので、「roles/bigquery.admin」を付与して実行したいと思います。 gcloud projects add-iam-policy-binding PROJECT_ID --member = "serviceAccount:inframg_test@ PROJECT_ID .iam.gserviceaccount.com" --role =roles/bigquery.admin   コンソール IAMの「アクセスを許可」から「roles/config.agent」を付与します。 同様に「roles/bigquery.admin」を付与します。 tfファイル作成 CLI/コンソール共通 ローカル上で以下3つのtfファイルを作成します。 ・main.tf 作成するリソースの内容を記載します。 今回は既存のデータセット「infratest」に「infratest_table」というテーブルを作成します。 ※データセットは事前に作成しておきます。 idとnameという2カラムをスキーマに加えたいと思います。 「deletion_protection」はTerraformで削除されないようにする削除保護の項目です。後で削除の検証もしたいので、今回は明示的にfalseを指定しています。 resource "google_bigquery_table" "bqtable" { project = var.project_id dataset_id = " infratest " table_id = " infratest_table " schema = jsonencode([{ name = "id" type = "STRING" maxLength = "10" }, { name = "name" type = "STRING" }]) deletion_protection = false }   ・provider.tf provider "google" { project = var.project_id }   ・variables.tf project_idを宣言していませんが、Infrastracture Managerは実行時に変数を指定できるため、今回は割愛しています。 variable "project_id" { type = string } GCSバケット作成/tfファイル配置 CLI tfファイル配置用のバケットと、ログ保管用のバケットの2つを作成します。 バケット名はそれぞれ「infra_test_tf」と「infra_test_logs」とします。 gcloud storage buckets create gs:// infra_test_tf --location=asia-northeast1 gcloud storage buckets create gs:// infra_test_logs --location=asia-northeast1 ローカルで作成した3つのtfファイルを「infra_test_tf」に配置します。 gsutil cp ./local-file-path gs:// infra_test_tf /   コンソール GCSの画面から「作成」をクリックします。 バケット名、ロケーションを指定して作成します。 「infra_test_tf」に3つのtfファイルをアップロードします。 事前準備はこれで終わりです。 Infrastructure Manager実行 CLI 以下を実行します。 PROJECT_IDは適宜該当するものを入れてください。 gcloud infra-manager deployments apply projects/ PROJECT_ID /locations/asia-northeast1/deployments/test \ --service-account projects/ PROJECT_ID /serviceAccounts/ inframg_test @ PROJECT_ID .iam.gserviceaccount.com \ --gcs-source=gs:// infra_test_tf \ --input-values=project_id= PROJECT_ID \ --artifacts-gcs-bucket = gs:// infra_test_logs 実行が完了すると、以下のような表示がでます。 Updating the deployment… logs=gs://infra_test_logs/test/r-1/logs …done. BigQueryを確認すると、テーブルが作成できてました。 コンソール Infrastructure Manager画面から「Create new deployment」をクリックします。 以下を入力し、「続行」をクリックします。 ・Deployment ID：test　（任意の値で問題ないです） ・リージョン：asia-northeast1 ・Service Account：inframg_test　（作成したサービスアカウント） ・Source of Terraform configuration：GCS ・Source：gs://infra_test_tf　（作成したバケット） Input Valuesは変数を定義できます。 今回はproject_idというキーに実際のプロジェクトIDを割り当てます。 「Value 1」にプロジェクトIDを入力し、「続行」をクリックします。 Artifacts GCS bucketにgs://infra_test_logs　（作成したログ用のバケット）を入力し、 Create Deploymentをクリックします。 少し待つと完了しました！ テーブルも無事作成されていました。 ログについて ログ格納に指定した「gs://infra_test_logs」を見てみます。 以下の階層でリビジョンごとに各ログが格納されています。 バケット/ ├ archived-deployments/　 #削除されたInfrastructure Manager IDのLogが入る └ID/　 #Infrastructure Manager ID └ r-0/　 #リビジョン │　├ apply_results/ │　│　├artifacts/　 #作成したリソースの情報が入っている │　│　└content/　 #作成に使用したtfファイルなどの情報が入っている │　└ logs/　 #裏で動いているCloud Buildのログが入っている ├ r-1/　 #リビジョン : : infra_test_logs/test/r-0/apply_results/artifacts/resources.jsonを見てみると、作成したリソースの種類が記載されていました。 infra_test_logs/test/r-0/apply_results/contentには構築に使用したtfファイルなどがコピーされています。 いつどのtfファイルを使用してどのような更新をしたか、という情報がリビジョンごとにわかりやすく集約されており、ログの一元管理ができるため使い勝手は良いように感じました。 リソースを修正/削除したい場合 修正する場合 CLI/コンソール共通 リソースの値などを修正したい場合は、tfファイルを修正→再度Infrastructure Manager実行することで反映されます。   削除する場合 CLI 以下を実行します。 少し待つとリソースが削除されます。 gcloud infra-manager deployments delete projects/ PROJECT_ID /locations/asia-northeast1/deployments/quickstart-deployment   コンソール 対象のInfrastracture Manager IDをクリックし、「削除」ボタンをクリックします。 少し待つと削除が完了し、リソースも削除されます。 使ってみた所感 Terraform Cloudと比較して、事前の環境構築が不要で実行が簡単でした。 ローカル環境からTerraformを実行できないなどのセキュリティ的な制約がある場合や、小規模な開発をスピーディーに行いたい場合などは有用であると思いました。 また、一切CLIを使わずにコンソール上だけでデプロイができるので、これからTerraformを勉強したい！という方がTerraformを理解する入口としてはおすすめのサービスだと思います。 ただし、Terraform Cloudであればterraform planで見ることのできるリソースの変更箇所を、Infrastructure Managerを使うとデプロイ前に確認できない点は注意が必要です。 Google Cloudが提供する代表的なIaCサービスであったGoogle Cloud Deployment Manager（CDM）の2025/12/31でのサポート終了（2025/5/1現在の情報）もあり、今後より注目度は高まっていくのではないでしょうか。 みなさんもぜひ、Infrastracture Manager使ってみてください。

2025年3月18日（火）に横浜みなとみらいにて開催されたYokohama リリースミートアップで初めてLT登壇させていただきました。 今回の記事は、LTの内容をブログとして再掲したものとなります。 【セッション資料】 Yokohama リリースミートアップ Yokohama リリースを記念し、Put AI to Work Summit: Yokohama のアフターパーティとして、横浜みなとみらいで開催しました。   セッション資料   2025/3/18(火)に開催された Yokohama ... www.servicenow.com   はじめに YokohamaリリースにおけるUIの変更点について、個人的に気になった個所をピックアップして紹介します。 比較対象は「Xanadu Patch 6」と「Yokohama Patch 0」となります。 ユーザー設定（User Preferences） ユーザー設定は、各ユーザーが自身の言語やタイムゾーン、通知などの設定をカスタマイズできる画面となります。 Xanadu ServiceNowを扱うどのペルソナの人でも一度は触ったことがあるであろうこの画面ですが、毎年のバージョンアップで、以下のように思ったことがある方もいるのではないでしょうか？ 「カテゴリーの数が増えてる？いつも使っている設定はどこのカテゴリーに含まれていたっけ？」 また、初めて触る方の場合、目的の設定を探すために2つの画面の遷移を繰り返す必要があり操作が大変だと感じた方もいるかもしれません。 気になってドキュメントで調べてみたところ、新リリースのたびにカテゴリーの数が増えていき、UtahからXanaduにかけて2倍となっていることが分かりました。   Yokohama Yokohamaリリースで以下画像のようにUIが変更されました。 新しいUIでは目的の設定をより簡単に素早く探せるようになりました。 検索バーから設定を探すことができるようになった カテゴリーと、カテゴリーの中に含まれる設定が一つの画面で表示されるようになった（画面遷移が不要）   Workspaceのリストビューにおける検索 個人的に一番お気に入りのYokohamaリリースのUI変更です。 Xanadu XanaduまでのWorkspaceのリストビューにおける検索では、カラム検索の場合、ラベル横のアイコンをクリックしてモーダルを表示させる、コンディションビルダーの場合、漏斗アイコンをクリック⇒Advanced Viewボタンをクリック→表示されたモーダルに検索条件をセットする、といった手順を踏む必要があり、Native UIにおける検索とは操作方法が異なりました。 そのため、普段Native UIの操作に慣れている人にとっては、少し使いずらさを感じていた方もいるかもしれません。 Yokohama Yokohamaリリースでは、カラムの検索ボックスやコンディションビルダーの配置がNative UIと同じになりました。 また、モーダル表示も不要となったため、簡単に操作できるようになりました。 モーダルの表示が無くなった Native UIと同じ操作感で検索できるようになった   アプリケーション開発ツール間の移動 Xanadu 近年のリリースでアプリ開発ツールが新機能として追加されていますが、どれも見た目が似ています。 また、各機能への入り口は異なるため、どのメニューからアクセスできるか把握する必要がありました。   Yokohama Yokohamaリリースでは、エクスペリエンススイッチャーという機能が追加されました。 画面左上にスイッチャーが追加され、Creator Studio ⇔ ServiceNow Studio ⇔ ServiceNow IDE間を簡単に移動できるようになりました。   その他変更点 リストコントロールのフォームレイアウト Xanaduまでは沢山の設定項目がフォーム上にずらっと一律に並んでいました。 Yokohamaからは、各設定項目が3つのタブでカテゴライズされ、目的の設定が探しやすくなりました。   通知設定（Notification Preferences） 各ユーザーが自身に通知されるメールのオン/オフを切り替えることができる画面になります。 Yokohamaからカテゴリーやチャネルなど複数の条件を組み合わせで検索できるようになりました。 キーボードショーカット Now Platformにおける各操作（メニューを開く、代理操作するなど）に対するキーボードショートカットの一覧を確認できる画面となります。Yokohamaから検索ボックスが追加され目的のキーボードショートカットをより簡単に探せるようになりました。 また、キーボードショートカットのカスタマイズも可能になっています。   最後に 年2回の新バージョンリリースで多くの機能が追加されますが、増えていく機能を簡単、かつ効率よく使うことができるようUIも常に進化していることに改めて気づくことができました。

ServiceNowのCSMポータルにて、アイテムを「ドラフトして保存」できるようにするという実装を行う機会があったので、その方法を紹介させていただきます。 本記事は執筆時点（2025年4月）の情報です。最新の情報は製品ドキュメントを参考にしてください。 投稿の経緯 「CSMポータルからケースを申請する際に、一度ドラフト保存したい」という要望から実装方法を調査しました。 とても簡単にできたので、皆さんのナレッジになれば、、ということで記事にさせていただきます。 実装方法・画面 実装手順 1, メニューから[sys_properties.list]を入力し、プロパティリストに移動 2, [New]を押下して、新規で[glide.sc.enable.save_as_draft.portal.csm]を作成 Typeは [true|false] で作成し、[Value] は [true] とする ※[glide.sc.enable.save_as_draft.portal.○○○]　○○○にはアクセスするポータルのURLサフィックスを入力 3, プロパティが新規作成されたことを確認   実際の画面 実装前 CSMポータル内の [製品のケースを作成] アイテムの申請画面には [送信] ボタンのみ表示される 実装後 [送信] ボタンの上に [ドラフトとして保存]  ボタンが表示   tips [glide.sc.enable.save_as_draft.portal.○○○] プロパティは Washington DC から使用できるようになったもので、 標準では sp,esc,mesp が実装されています。 [glide.sc.enable.save_as_draft.portal.csm] プロパティを有効化すると CSMポータル内すべてのカタログアイテム・レコードプロデューサーの申請画面に「ドラフトとして送信」が表示されますが 各アイテムの [Portal Settings] タブから [Hide ‘Save as Draft’] にチェックを入れて特定のアイテムには表示させない という切り分けも可能です。 ※参考画像 感想 見た目だけだと複雑な実装をしなければいけないように見えて少し億劫ですが、実際にはプロパティで簡単に実装できるので驚きました。 また、各アイテムごとに表示/非表示の制御もかけられるのがメリットの一つだと思います。 機会があれば、皆さんも実装してみてください。

はじめに 今回は「 Prisma Cloud の API を呼び出してみた 」の第二弾です。 1回目は こちら で、APIでアラート件数を取得する方法を記載しています。 Prisma Cloudのアクセスキーについて解説後、 最後に使用した日付が1か月前以上のアクセスキー一覧を取得するツールをPythonを使用して作成します。 アクセスキーの解説後、実際に作成したアクセスキーを使用して、最後に使用した日付が1ヵ月以上前のアクセスキー一覧を出力するツールをPythonで作成します。 このツールを使用することで1か月以上前のアクセスキー一覧がすぐに確認できるので、Prisma Cloudコンソールに行く手間などを省くことができます。 アクセスキーとは Prisma Cloud APIにアクセスするための認証情報で、サードパーティとの結合にも使用できます。 アクセスキーIDとシークレットキーのペアで構成され、有効期限を設定可能です。 特定のロールに関連付けすることもできます。 また、アクセスキーに関連付けられたロールが削除されるとアクセスキーも削除されます。 アクセスキーの確認方法 Prisma Cloud コンソールにアクセスします。 右上「Settings」>左ペイン「Access Control」>「Access Keys」に遷移します。 遷移後、各アクセスキーの権限情報が確認できます。 アクセスキー作成方法 Prisma Cloud コンソールにアクセスします。 「Settings」>「Access Control」>「Access Keys」に遷移します。 以下画像に遷移します(アクセスキーの確認方法と同様) 右上の「Add」>「Access Key」から作成することができます。 ※アクセスキーはログインに使用したロールに基づいて「Role」と「Permission Group」が紐づけられ作成されます。    参考: アクセスキーの作成と管理 今回は有効期限ありで作成します。             ラベル 入力フィールド Name 任意の名前 Enable Expiration ONにすると有効期限を設定することができます 以下画像は有効期限なし 以下画像は有効期限あり Access Key Expirationが有効期限になります。任意の日付を指定してください 「Save」を押下後、アクセスキーを作成することができます。 SecretAccessKeyは以下画像の画面でしかダウンロード、値のコピーを行うことができないので、今ダウンロードなどを行います。 ダウンロード後、「Done」を押下します。 「アクセスキー作成方法」と同じ手順で画面を遷移し、作成した名前と同じアクセスキーがあることを確認します Prisma Cloud APIを使用してアクセスキー一覧を取得するツールの作成 次は先ほど発行したアクセスキーとPrisma Cloud APIを使用して、アクセスキー一覧を取得できるツールを作成していきます。 1ヵ月使用していないアクセスキーの名前と最後にアクセスキーを使用したUnix時間を出力できるようにします。 ライブラリのインポート 今回使用するライブラリ群をインポートします。 import requests import json import time from time import sleep from datetime import datetime, timezone, timedelta Prisma Cloud APIに必要なトークンの発行 Prisma CloudのAPIに必要なトークンを発行する関数を作成します。 ここで発行したアクセスキーとシークレットキーを使用します。 変数名usernameがアクセスキーで、変数名passwordがシークレットキーになっています。 def get_token(): # 発行したアクセスキーを書く username = "12345" password = "12345" # https://pan.dev/prisma-cloud/api/cspm/app-login/ url = "https://api.anz.prismacloud.io/login" # リクエストパラメータ（username,password）の編集 payload = '{\"username\":\"' + username + \ '\",\"password\":\"' + password + '\"}' headers = { "Accept": "application/json; charset=UTF-8", "Content-Type": "application/json; charset=UTF-8" } wasResponseError = False # APIリクエスト実行 while True: # https://prisma.pan.dev/api/cloud/cspm/login#operation/app-login response = requests.request("POST", url, data=payload, headers=headers) # リクエスト実行結果の判定 if response.status_code == 200: token = json.loads(response.text)['token'] wasResponseError = False break else: print(f"You couldn't be authenticated [status_code:{response.status_code}]") # APIのベストプラクティス if wasResponseError: exit() else: sleep(32) wasResponseError = True return token Prisma Cloud APIを使用してアクセスキー一覧を取得 発行したトークンを使用してアクセスキー一覧を取得する関数を作成します。 こちらの関数はPrisma Cloud の発行されているアクセスキー一覧を取得する関数になります。 def get_accesskeys(token): url = "https://api.anz.prismacloud.io/access_keys" payload = {} headers = { "Content-Type": "application/json; charset=UTF-8", "x-redlock-auth": token } wasResponseError = False 　　# APIリクエスト実行 while True: response = requests.request("GET", url, headers=headers, data=payload) if response.status_code == 200: access_key_data = json.loads(response.text) wasResponseError = False break else: print(f"Bad Request[status_code:{response.status_code}]") if wasResponseError: exit() else: sleep(32) wasResponseError = True return access_key_data 1ヵ月前のUnix時間を算出する処理の作成 1か月前のUnix時間を算出する必要があるので1ヵ月以上前のUnix時間を算出する関数を作成します。 def get_one_month_ago_unix_time(): # 現在の日付を取得 current_time = datetime.now() # 1か月前の日時を取得 one_month_ago = current_time - timedelta(days=30) # 1か月前のDatetimeオブジェクトをUnix時間に変換 one_month_ago_unix_time = int(time.mktime(one_month_ago.timetuple())) * 1000 return one_month_ago_unix_time Unix時間を日本時間に変換する処理の作成 Unix時間を日本時間に変換する関数を作成します。 def convert_unix_millis_to_jst(unix_millis): # ミリ秒を秒に変換 unix_seconds = unix_millis / 1000.0 # Unix時間をUTCのdatetimeオブジェクトに変換 utc_time = datetime.fromtimestamp(unix_seconds, tz=timezone.utc) # 日本標準時（JST、UTC+9）に変換 jst_time = utc_time.astimezone(timezone(timedelta(hours=9))) return jst_time アクセスキー一覧を出力する処理の作成 アクセスキー一覧を出力する関数を作成します。 def print_list_accesskeys(access_key_data, one_month_ago_unix_time, jst_time): print("=== 長期間使用されていないアクセスキー一覧 ===") for data in access_key_data: # 最後に使用した時間が1ヵ月以上前だった場合 if data['lastUsedTime'] < one_month_ago_unix_time: print(f"AccessKey Name: {data['name']}, Last Used: {jst_time.strftime('%Y-%m-%d')}") main関数の作成とエントリーポイントの作成 最後に1~6までに作成した関数を使用したmain関数とエントリーポイントを作成します。 def main(): # トークンを取得 token = get_token() # アクセスキー一覧を取得する(JSON形式) access_key_data = get_accesskeys(token) #1ヵ月前のUnixTime時間を取得 one_month_ago_unix_time = get_one_month_ago_unix_time() # UnixTime時間から日本時間に変換 jst_time = convert_unix_millis_to_jst(one_month_ago_unix_time) # アクセスキー一覧を出力する print_list_accesskeys(access_key_data, one_month_ago_unix_time, jst_time) if __name__ == "__main__": 　　main() プログラム実行結果 プログラムを実行すると以下の様に出力されます。 ※name-accesskeysは実際にはPrisma Cloudコンソールのアクセスキー欄と同じ名前が出力されています。 === 長期間使用されていないアクセスキー一覧 === AccessKey Name: name-accesskeys, Last Used: 2025-03-24 AccessKey Name: name-accesskeys, Last Used: 2025-03-24 AccessKey Name: name-accesskeys, Last Used: 2025-03-24 AccessKey Name: name-accesskeys, Last Used: 2025-03-24 AccessKey Name: name-accesskeys, Last Used: 2025-03-24 AccessKey Name: name-accesskeys, Last Used: 2025-03-24 プログラムの全体像 import requests import json import time from time import sleep from datetime import datetime, timezone, timedelta # PrismaCloudのAPIに必要なトークンを発行する def get_token(): # 発行したアクセスキーを書く(ハードコードは良くないためconfigファイル等に格納するのがベスト) username = "891a8cef-82df-434d-8b2a-e2f4145aa4b4" password = "ZJMp9W8xabxNZrwcC330kG3rTPg=" url = "https://api.anz.prismacloud.io/login" # リクエストパラメータ（username,password）の編集 payload = '{\"username\":\"' + username + \ '\",\"password\":\"' + password + '\"}' headers = { "Accept": "application/json; charset=UTF-8", "Content-Type": "application/json; charset=UTF-8" } wasResponseError = False # リクエスト実行（POST / login APIを使用してJWTをを取得） while True: # https://prisma.pan.dev/api/cloud/cspm/login#operation/app-login response = requests.request("POST", url, data=payload, headers=headers) # リクエスト実行結果の判定 if response.status_code == 200: token = json.loads(response.text)['token'] wasResponseError = False break else: print(f"You couldn't be authenticated [status_code:{response.status_code}]") # APIのベストプラクティス if wasResponseError: exit() else: sleep(32) wasResponseError = True return token # アクセスキー一覧を返すAPIを叩く def get_accesskeys(token): url = "https://api.anz.prismacloud.io/access_keys" payload = {} headers = { "Content-Type": "application/json; charset=UTF-8", "x-redlock-auth": token } wasResponseError = False while True: response = requests.request("GET", url, headers=headers, data=payload) if response.status_code == 200: access_key_data = json.loads(response.text) wasResponseError = False break else: print(f"Bad Request[status_code:{response.status_code}]") if wasResponseError: exit() else: sleep(32) wasResponseError = True return access_key_data # 一カ月前のUnix時間を返す def get_one_month_ago_unix_time(): # 現在の日付を取得 current_time = datetime.now() # 1か月前の日時を取得 one_month_ago = current_time - timedelta(days=30) # 1か月前のDatetimeオブジェクトをUnix時間に変換 one_month_ago_unix_time = int(time.mktime(one_month_ago.timetuple())) * 1000 return one_month_ago_unix_time # unixミリ秒を日本時間に変換 def convert_unix_millis_to_jst(unix_millis): # ミリ秒を秒に変換 unix_seconds = unix_millis / 1000.0 # Unix時間をUTCのdatetimeオブジェクトに変換 utc_time = datetime.fromtimestamp(unix_seconds, tz=timezone.utc) # 日本標準時（JST、UTC+9）に変換 jst_time = utc_time.astimezone(timezone(timedelta(hours=9))) return jst_time def print_list_accesskeys(access_key_data, one_month_ago_unix_time, jst_time): print("=== 長期間使用されていないアクセスキー一覧 ===") for data in access_key_data: # 最後に使用した時間が1ヵ月以上前だった場合 if data['lastUsedTime'] < one_month_ago_unix_time: print(f"AccessKey Name: {data['name']}, Last Used: {jst_time.strftime('%Y-%m-%d')}") def main(): # トークンを取得 token = get_token() # アクセスキー一覧を取得する(JSON形式) access_key_data = get_accesskeys(token) #1ヵ月前のUnixTime時間を取得 one_month_ago_unix_time = get_one_month_ago_unix_time() # UnixTime時間から日本時間に変換 jst_time = convert_unix_millis_to_jst(one_month_ago_unix_time) # アクセスキー一覧を出力する print_list_accesskeys(access_key_data, one_month_ago_unix_time, jst_time) if __name__ == "__main__": main() さいごに 今回はアクセスキーの解説とアクセスキー一覧を出すAPIで簡単なツールを作成してみました。 当社では、複数クラウド環境の設定状況を自動でチェックし、設定ミスやコンプライアンス違反、異常行動などのリスクを診断するCSPMソリューションを販売しております。 マルチクラウド設定診断サービス with CSPM｜ SCSK株式会社 ご興味のある方は是非、お気軽にお問い合わせください。

こんにちは。SCSK渡辺(大)です。 今回は、 AWS Organizationsを使用できない場合にAWS Configを全リージョンで有効化する方法 を考えてみました。 背景 AWSアカウントのセキュリティ監視をしたい AWSアカウントのセキュリティ監視をしたいとなった場合、AWS Security Hubを利用することが候補に挙がるかと思います。 AWS Security Hubを利用するための前提として、AWS Configを有効化している必要があります。 AWS Configのベストプラクティスには以下のように書かれています。 AWS Config ベストプラクティス | Amazon Web Services ブログ —抜粋————————————————————— 1.すべてのアカウントとリージョンで AWS Config を有効にします。 これは、  Center for Internet Security (CIS)  が推奨する業界のベストプラクティスです。AWS Config を使用すると、AWS リソースの設定を監査し、設定のベストプラクティスに確実に準拠することができます。  AWS CloudFormation StackSets  を使用すると、共通の CloudFormation テンプレートを使用して、複数のアカウントとリージョンで AWS Config を有効にできます。 ———————————————————————- 上記の通り、AWS CloudFormation StackSetsを使用することで複数アカウントとリージョンでAWS Configを有効にできます。 AWS CloudFormation StackSetsには2種類あります。 セルフマネージド型　：　AWS Organizationsを使えなくても問題ありません サービスマネージド型：　AWS Organizationsを使えることが前提です 今回はAWS Organizationsを使用できない場合を想定しているため、セルフマネージド型を利用します。 セルフマネージド許可を持つ CloudFormation StackSets を作成する – AWS CloudFormation 上記リンク先にAWS Configを有効化するためのAWS CloudFormationテンプレートが用意されていますが、自分が作りたい構成には過剰だったため、 オリジナルのAWS CloudFormationテンプレート（以降、Cfnテンプレート） を作ることにしました。 余談 ちなみに、「利用しないリージョンは無効化にしておけばセキュリティ監視が不要になるから、使用するリージョンだけ有効化して、AWS Management ConsoleからAWS Configを有効化するならそこまで手間ではないのでは？」と一度は考えましたが、悲しいことに、デフォルトで有効になっているリージョンは無効にすることはできません。 デフォルトで有効になっているリージョンは記事執筆時点で17個ありますので、仮に監視対象のAWSアカウントが10個あったとしたら、AWS Management Consoleでリージョン切替とAWS Config有効化を170回繰り返す必要があります…。 アーキテクチャ AWSアカウント 今回は２つのアカウントを用意しました。 AWS Configアグリゲータアカウント（以降、アグリゲータアカウント） AWS Configソースアカウント（以降、ソースアカウント） 使用するサービス 以下のサービスを使用します。 Amazon S3 AWS CloudFormation 作業内容 以下の作業を実施します。 From：アグリゲータアカウント、To：アグリゲータアカウント AWSマネジメントコンソールからAmazon S3バケットを作成し、AWS CloudFormationテンプレート（以降、Cfnテンプレート）をアップロードする AWS CloudFormationでAWS CloudFormation StackSets セルフマネージド型用のIAMロールを作成する AWS CloudFormationでAWS Configの配信先（Amazon S3バケット）を作成する AWS CloudFormationでAWS Config用のIAMロールを作成する From：ソースアカウント、To：ソースアカウント AWS CloudFormationでAWS CloudFormation StackSets セルフマネージド型用のIAMロールを作成する AWS CloudFormationでAWS Config用のIAMロール、を作成する From：アグリゲータアカウント、To：ソースアカウント AWS CloudFormation StackSets セルフマネージド型でAWS Configを有効化にする From：ソースアカウント、To：アグリゲータアカウント AWS CloudFormation StackSets セルフマネージド型でAWS Configを有効化にする 構成図 上記の設計を図にすると以下になります。   事前作業 Amazon S3バケットにCfnテンプレートをアップロードします。 ゴールは下図のようにアップロードされていることです。 Amazon S3バケット作成 作業実施アカウント アグリゲータアカウント 推奨設定 ブロックパブリックアクセスを有効化 ソースアカウントからもGetObjectできるようにバケットポリシーを設定する {   "Version": "2012-10-17",   "Statement": [       {           "Effect": "Allow",           "Principal": {               "AWS": "arn:aws:iam::${ソースアカウントのAWSID}:root"           },           "Action": "s3:GetObject",           "Resource": "arn:aws:s3:::${S3バケット名}/*"       }   ] }   配置するCfnテンプレートは次の通りです。 Cfnテンプレート: AWSCloudFormationStackSetAdministrationRole AWS CloudFormation StackSets セルフマネージド型で別アカウントにリソースを作成することが出来るようにするためのAWS IAMローカルを作成します。（AWSユーザーガイドからダウンロードできます） AWSTemplateFormatVersion: 2010-09-09 Description: Configure the AWSCloudFormationStackSetAdministrationRole to enable use of AWS CloudFormation StackSets. Parameters: AdministrationRoleName:   Type: String   Default: AWSCloudFormationStackSetAdministrationRole   Description: "The name of the administration role. Defaults to 'AWSCloudFormationStackSetAdministrationRole'." ExecutionRoleName:   Type: String   Default: AWSCloudFormationStackSetExecutionRole   Description: "The name of the execution role that can assume this role. Defaults to 'AWSCloudFormationStackSetExecutionRole'." Resources: AdministrationRole:   Type: AWS::IAM::Role   Properties:     RoleName: !Ref AdministrationRoleName     AssumeRolePolicyDocument:       Version: 2012-10-17       Statement:         - Effect: Allow           Principal:             Service: cloudformation.amazonaws.com           Action:             - sts:AssumeRole     Path: /     Policies:       - PolicyName: AssumeRole-AWSCloudFormationStackSetExecutionRole         PolicyDocument:           Version: 2012-10-17           Statement:             - Effect: Allow               Action:                 - sts:AssumeRole               Resource:                 - !Sub 'arn:*:iam::*:role/${ExecutionRoleName}' Cfnテンプレート: AWSCloudFormationStackSetExecutionRole AWS CloudFormation StackSets セルフマネージド型で別アカウントからリソースを作成することが出来るようにするためのAWS IAMロールを作成します。（AWSユーザーガイドからダウンロードできます） AWSTemplateFormatVersion: 2010-09-09 Description: Configure the AWSCloudFormationStackSetExecutionRole to enable use of your account as a target account in AWS CloudFormation StackSets. Parameters: AdministratorAccountId:   Type: String   Description: AWS Account Id of the administrator account (the account in which StackSets will be created).   MaxLength: 12   MinLength: 12 ExecutionRoleName:   Type: String   Default: AWSCloudFormationStackSetExecutionRole   Description: "The name of the execution role. Defaults to 'AWSCloudFormationStackSetExecutionRole'." Resources: ExecutionRole:   Type: AWS::IAM::Role   Properties:     RoleName: !Ref ExecutionRoleName     AssumeRolePolicyDocument:       Version: 2012-10-17       Statement:         - Effect: Allow           Principal:             AWS:               - !Ref AdministratorAccountId           Action:             - sts:AssumeRole     Path: /     ManagedPolicyArns:         - !Sub arn:${AWS::Partition}:iam::aws:policy/AdministratorAccess Cfnテンプレート: PreAWSConfigAggregator アグリゲータアカウントで集約するアグリゲータアカウント自身およびソースアカウントのAWS Configデータを集約するためのAmazon S3バケットを作成します。また、アグリゲータアカウント自身のAWS Config用のAWS IAMロールを作成します。 Q. aws:PrincipalOrgIDを使っている理由は？ A. ソースアカウントが増えるたびにAmazon S3バケットポリシーを変更したくないからです。予期せぬアカウントからアクセスされる懸念については、Amazon S3バケット名が漏洩しない限りは問題ないと考えての設計です。「危険だ！」という場合にはアカウント単位での指定方法（aws:PrincipalAccount）も用意されているので、以下リンク先の内容を参考にカスタマイズしてご利用ください。 Amazon global condition context keys AWSTemplateFormatVersion: "2010-09-09" Parameters: AdministratorAccountS3Bucket:   Description: AWS account S3Bucket of the administrator account (security monitoring administrator account)   Type: String OrganizationID:   Description: Organization ID   Type: String Resources: ConfigBucket:   DeletionPolicy: Retain   Type: AWS::S3::Bucket   Properties:     BucketName: !Ref AdministratorAccountS3Bucket     BucketEncryption:       ServerSideEncryptionConfiguration:         - ServerSideEncryptionByDefault:             SSEAlgorithm: AES256 ConfigBucketPolicy:   Type: AWS::S3::BucketPolicy   Properties:     Bucket: !Ref ConfigBucket     PolicyDocument:       Version: 2012-10-17       Statement:         - Sid: AWSConfigBucketPermissionsCheck           Effect: Allow           Principal: "*"           Action: s3:GetBucketAcl           Resource: !Sub "arn:${AWS::Partition}:s3:::${ConfigBucket}"           Condition:             StringEquals:               "aws:PrincipalOrgID": !Ref OrganizationID         - Sid: AWSConfigBucketExistenceCheck           Effect: Allow           Principal: "*"           Action: s3:ListBucket           Resource: !Sub "arn:${AWS::Partition}:s3:::${ConfigBucket}"           Condition:             StringEquals:               "aws:PrincipalOrgID": !Ref OrganizationID         - Sid: AWSConfigBucketDelivery           Effect: Allow           Principal: "*"           Action: s3:PutObject           Resource: !Sub "arn:${AWS::Partition}:s3:::${ConfigBucket}/AWSLogs/*/Config/*"           Condition:             StringEquals:               "s3:x-amz-acl": "bucket-owner-full-control"               "aws:PrincipalOrgID": !Ref OrganizationID         - Sid: AWSConfigBucketSecureTransport           Effect: Deny           Principal: "*"           Action:             - s3:*           Resource:             - !Sub "arn:${AWS::Partition}:s3:::${ConfigBucket}"             - !Sub "arn:${AWS::Partition}:s3:::${ConfigBucket}/*"           Condition:             Bool:               aws:SecureTransport: false ConfigRole:   Type: AWS::IAM::Role   Properties:     RoleName: AWSConfigCustomRole     AssumeRolePolicyDocument:       Version: "2012-10-17"       Statement:         - Effect: Allow           Principal:             Service: config.amazonaws.com           Action: "sts:AssumeRole"     ManagedPolicyArns:       - arn:aws:iam::aws:policy/service-role/AWS_ConfigRole Outputs: ConfigBucketName:   Description: Name of the S3 bucket for AWS Config data   Value: !Ref ConfigBucket ConfigRoleArn:   Description: ARN of the IAM role for AWS Config   Value: !GetAtt ConfigRole.Arn Cfnテンプレート: PreAWSConfigSource ソースアカウント自身のAWS Config用のAWS IAMロールを作成します。 AWSTemplateFormatVersion: "2010-09-09" Parameters: AdministratorAccountS3Bucket:   Description: AWS account S3Bucket of the administrator account (security monitoring administrator account)   Type: String Resources: ConfigRole:   Type: AWS::IAM::Role   Properties:     RoleName: AWSConfigCustomRole     AssumeRolePolicyDocument:       Version: "2012-10-17"       Statement:         - Effect: Allow           Principal:             Service: config.amazonaws.com           Action: "sts:AssumeRole"     ManagedPolicyArns:       - arn:aws:iam::aws:policy/service-role/AWS_ConfigRole     Policies:       - PolicyName: ConfigS3BucketAccess         PolicyDocument:           Version: "2012-10-17"           Statement:             - Effect: Allow               Action:                 - "s3:PutObject"                 - "s3:PutObjectAcl"               Resource:                 - !Sub "arn:aws:s3:::${AdministratorAccountS3Bucket}/AWSLogs/*"               Condition:                 StringLike:                   "s3:x-amz-acl": "bucket-owner-full-control"             - Effect: Allow               Action:                 - "s3:GetBucketAcl"               Resource: "arn:aws:s3:::${AdministratorAccountS3Bucket}" Outputs: ConfigRoleArn:   Description: ARN of the IAM role for AWS Config   Value: !GetAtt ConfigRole.Arn Cfnテンプレート: EnableAWSConfig アグリゲータアカウントまたはソースアカウントでAWS Configを有効化にします。 Q. IncludeGlobalResourceRegion: !Equals [!Ref AWS::Region, us-east-1]を使っている理由は？ A. ベストプラクティスに準拠するためです。 AWS Config ベストプラクティス —抜粋————————————————————— 3.1 つのリージョンでのみグローバルリソース (IAM リソースなど) を記録します。 これにより、IAM 設定アイテムの冗長コピーをすべてのリージョンで取得することがなくなります。それは費用の節約にもなります。 ———————————————————————- AWSTemplateFormatVersion: "2010-09-09" Conditions: IncludeGlobalResourceRegion: !Equals [!Ref AWS::Region, us-east-1] Parameters: AdministratorAccountS3Bucket:   Description: AWS account S3Bucket of the administrator account (security monitoring administrator account)   Type: String Resources: ConfigRecorder:   Type: AWS::Config::ConfigurationRecorder   Properties:     Name: !Sub "config-${AWS::AccountId}"     RecordingGroup:       AllSupported: true       IncludeGlobalResourceTypes:         !If [IncludeGlobalResourceRegion, true, false]     RoleARN: !Sub arn:aws:iam::${AWS::AccountId}:role/AWSConfigCustomRole ConfigDeliveryChannel:   Type: AWS::Config::DeliveryChannel   Properties:     Name: !Sub "config-${AWS::AccountId}"     S3BucketName: !Ref AdministratorAccountS3Bucket     ConfigSnapshotDeliveryProperties:       DeliveryFrequency: TwentyFour_Hours Outputs: ConfigRecorderName:   Description: Name of the AWS Config Recorder   Value: !Ref ConfigRecorder DeliveryChannelName:   Description: Name of the AWS Config Delivery Channel   Value: !Ref ConfigDeliveryChannel 余談 本記事では説明のためにCfnテンプレートを分けていますが、AWSCloudFormationStackSetAdministrationRoleとAWSCloudFormationStackSetExecutionRoleはPreAWSConfigAggregatorやPreAWSConfigSourceにまとめることが出来ると思います。   設定作業 AWS CloudFormationで設定していきます。 Cfnテンプレート: AWSCloudFormationStackSetAdministrationRole 作業実施アカウント アグリゲータアカウント ソースアカウント パラメーター 何も変更しません 確認画面 下図のようになっていればOKです Cfnテンプレート: AWSCloudFormationStackSetExecutionRole 作業実施アカウント アグリゲータアカウント ソースアカウント パラメーター AdministratorAccountIdを設定します アグリゲータアカウント側ではソースアカウントAWSIDを設定します ソースアカウント側ではアグリゲータアカウントAWSIDを設定します 確認画面 下図のようになっていればOKです Cfnテンプレート: PreAWSConfigAggregator 作業実施アカウント アグリゲータアカウント パラメーター AdministratorAccountS3Bucketを設定します 任意の名前で設定します（AWSの全てのリージョンにわたって一意である必要があります） OrganizationID（組織ID）を設定します 組織IDを設定します 組織IDの確認方法は、画面右上のログインユーザーをクリックした後に「組織」をクリックすると見れます 確認画面 下図のようになっていればOKです Cfnテンプレート: PreAWSConfigSource 作業実施アカウント ソースアカウント パラメーター AdministratorAccountS3Bucketを設定します PreAWSConfigAggregatorで設定した名前を指定します 確認画面 下図のようになっていればOKです Cfnテンプレート: EnableAWSConfig これまでのCfnテンプレートとは異なり、AWS CloudFormation StackSets セルフマネージド型で実行します。 作業実施アカウント アグリゲータアカウント ソースアカウント パラメーター アグリゲータアカウントとソースアカウントとも共通で、AdministratorAccountS3Bucketを設定します PreAWSConfigAggregatorで設定した名前を指定します 作業画面 基本的にはアグリゲータアカウントとソースアカウントとも共通です。 「StackSetを作成」をクリックします   CfnテンプレートのURLを入力して「次へ」をクリックします   StackSet名とAdministratorAccountS3Bucketを設定し、「次へ」をクリックします   StackSetオプションは何も変更せずに「次へ」をクリックします   アグリゲータアカウントの場合には、アカウント番号にはソースアカウントのAWSIDを設定します       ソースアカウントの場合には、アカウント番号にはアグリゲータアカウントのAWSIDを設定します   リージョンを指定します。 以下は有効化になっている全てのリージョンに対してAWS Configを有効化する場合の設定方法です。 まず、有効化になっているリージョンを確認します。 画面右上のログインユーザーをクリックした後に「アカウント」をクリックすると見れます。                                   AWS CloudFormation StackSets の画面に戻り、「すべてのリージョンを追加」をクリックします。      ステータスが無効になっているリージョンを削除します。   デプロイオプションでは、リージョンの同時実行で「並行」を選択して、「次へ」をクリックします。 確認画面 下図のようになっていればOKです   実行すると下図のようになります。   実行が完了すると下図のようにステータスが「SUCCEEDED」になります。   AWS Configが有効化されており、設定から配信先のAmazon S3バケット名が想定通りであることを確認します。   以上です。 ソースアカウントを追加したい時はどうしたら良いの？ 追加したいソースアカウントでPreAWSConfigAggregatorを実行した後、アグリゲータアカウントのAWS CloudFormation StackSetsからEnableAWSConfigを選択した後、アクションから「StackSetにスタックを追加」をクリックすることで、追加したいソースアカウントに対してスタックを作成することができます。   なお、aws:PrincipalOrgIDを使わずにaws:PrincipalAccountを使う場合には、配信先のAmazon S3バケットにおいて、バケットポリシーの変更が必要になります。   まとめ AWS CloudFormation StackSetセルフマネージド型はAWS Configの有効化の他にも、様々なことに活用できそうだと感じました。

はじめに Prisma Cloudでは月に一回アップデートがあります。 内容としては新機能のリリース情報やUI変更のお知らせからAPIの更新情報など多岐にわたりますが、今回は 2025年1月～4月 に新たに導入となった監視ポリシーの中から、重要度が高いものを解説したいと思います。 ちなみにPrisma Cloudのアップデート情報はPalo Alto社のこちらのサイトからご覧いただけます。 Features Introduced in 2025 解説内容 今回解説の内容としては、以下の観点で解説します。 ・ポリシー名 ・ポリシータイプ ・ポリシーの重要度 ・このポリシーがどんなクラウドリソースの状態を検知するのか ・なぜその状態の検知が大事なのか ・どのような状態になるのが望ましいのか それでは、解説していきます。 直近に新規追加となったポリシーについて 2025年1月～4月 に新たに導入となった監視ポリシーで、重要度がHighまたはCriticalのものは以下4つありました。 No. ポリシー名 1 AWS Connect instance using publicly accessible S3 bucket 2 Azure Container Registry with anonymous authentication enabled 3 AWS S3 bucket having ACL write permission to all users or allAuthenticatedUsers 4 AWS Lightsail bucket publicly readable 各ポリシーの説明は以下です。 AWS Connect instance using publicly accessible S3 bucket このポリシーは、AWS Connectインスタンスで利用されているS3バケットが公開アクセス可能であるかどうかを検出します。 公開アクセスが可能なS3バケットは、機密性の高い顧客データや内部データを一般に公開し、セキュリティリスクを招く可能性があります。 項目 内容 ポリシータイプ Config ポリシーの重要度 High 望ましい状態 報告されたS3バケットに対して、公開読み込み権限を排除し、厳格なアクセス制御を施す必要があります。 Azure Container Registry with anonymous authentication enabled このポリシーは、匿名認証が有効なAzure Container Registriesを特定します。 匿名アクセスを許可すると、不正なユーザーがコンテナイメージを取得または操作するリスクがあり、セキュリティ上の重大なリスクとなります。 項目 内容 ポリシータイプ Config ポリシーの重要度 High 望ましい状態 匿名認証を無効にし、Azure Active Directoryを介して認証を要求することで、より良い制御と責任を維持することが推奨されます。 AWS S3 bucket having ACL write permission to all users or allAuthenticatedUsers このポリシーは、ACLの書き込み権限がすべてのユーザーまたは認証済みユーザーに付与されているAWS S3バケットを特定します。 “AllUsers”または”AuthenticatedUsers”に”Write”または”FullControl”権限を与えることは、機密データが不正アクセスまたは改変されるリスクとなります。 項目 内容 ポリシータイプ Config ポリシーの重要度 High 望ましい状態 S3バケットポリシーとACLを構成し、アクセスが必要な特定のユーザーまたはグループにのみ権限を明示的に付与することでリスクを軽減することが推奨されます。 AWS Lightsail bucket publicly readable このポリシーは、AWS Lightsailバケットにおいて公開読み取り可能なオブジェクトを特定し、それにより機密データが不正アクセスのリスクにさらされる状況を示します。 公開読み取り可能な設定は、データの漏洩、知的財産の盗難、財務的損失など、データ漏洩や評判被害のリスクを増大させます。 項目 内容 ポリシータイプ Config ポリシーの重要度 High 望ましい状態 セキュリティリスクを軽減するためには、最小権限の原則に従い、バケットアクセスを権限のあるユーザーのみに制限し、バケット権限をプライベートに設定することが推奨されます。また、バケットアクセス制御を定期的にレビューし、誤設定を迅速に発見し対処することが望ましいです。 まとめ 今回はPrisma Cloudで 2025年1月～4月 に新たに導入となった監視ポリシーの中から、重要度が高いものを解説しました。 Prisma Cloudは定期的にポリシーが更新されます。どのようなポリシーで監視しているかを把握することはセキュリティ管理の観点から非常に重要だと思います。追加ポリシーについては今後も記事で紹介していく予定です。 この記事が、ご自身またはご自身の職場のクラウド環境のセキュリティリスクを見直すきっかけになれば幸いです。 また、当社では、Prisma Cloudを利用して複数クラウド環境の設定状況を自動でチェックし、設定ミスやコンプライアンス違反、異常行動などのリスクを診断するCSPMソリューションを販売しております。ご興味のある方はお気軽にお問い合わせください。リンクはこちら↓ マルチクラウド設定診断サービス with CSPM｜ SCSK株式会社 マルチクラウド環境のセキュリティ設定リスクを手軽に確認可能なスポット診断サービスです。独自の診断レポートが、運用上の設定ミスや設計不備、クラウド環境の仕様変更などで発生し得る問題を可視化し、セキュリティインシデントの早期発見に役立ちます。 www.scsk.jp

こんにちは、広野です。 大量のデータに対して、生成 AI で同じプロンプトを使用する問い合わせをしたかったので、CSV データを読み込んで結果を CSV に追記して返してくれるジョブを AWS 上に作成しました。 簡単なつくりですが、プロンプトを変えることでいろいろな処理に活用できると思います。 つくったもの 以下のフォーマットの CSV ファイルをインプットにします。サンプルデータのソースは AWS ドキュメントです。 結果の CSV ファイルです。本記事ではサンプルとして元データテキスト(英語)を翻訳してサマリーするだけとします。 CSV ファイルを AWS マネジメントコンソールで所定の Amazon S3 バケットに保存すると、自動的にジョブが実行され、結果 CSV ファイルがバケットに保存されるとともに、メールで完了通知が届く仕組みです。 アーキテクチャ Amazon S3 バケット内、input フォルダに CSV ファイルが保存されると、イベント通知が Amazon EventBridge に送信されます。 Amazon EventBridge ルールがそれを検知し、AWS Step Functions ステートマシンを開始します。その際、CSV ファイルが配置された Amazon S3 バケットとキーを渡します。 ステートマシンは該当の Amazon S3 バケットとキーを元に、CSV ファイルを取得します。CSV ファイルの中身を参照して、行単位で Map ステートによる並列処理を行います。 並列実行される各処理内では、データ 1 件ごとに Amazon Bedrock 基盤モデルに問い合わせます。すべての並列処理が完了後、各処理の結果がとりまとめられ、AWS Lambda 関数に渡します。 AWS Lambda 関数内では、結果データ (JSON) を CSV に変換し、Amazon S3 バケットに保存します。最後、Amazon SNS に完了通知をパブリッシュします。 ※本記事の構成では、生成 AI のモデルに Claude 3.7 Sonnet を使用したかったので、オレゴンリージョンにデプロイしました。執筆時点では東京リージョンで 3.7 がリリースされておらず。 設定解説 Amazon EventBridge Amazon S3 の設定は省略します。Amazon S3 バケットに Amazon EventBridge へのイベント通知が有効になっている状態で、Amazon EventBridge ルールを設定します。イベントパターンは以下のように設定しています。バケット名指定で、キーはワイルドカードで input フォルダにある .csv ファイルであれば発動する条件です。 { "source": ["aws.s3"], "detail-type": ["Object Created"], "detail": { "bucket": { "name": ["bedrockjob-test"] }, "object": { "key": [{ "wildcard": "input/*.csv" }] } } } ターゲットは AWS Step Functions ステートマシンです。開始するには ARN さえ設定できればよいのですが、ステートマシンの引数は Amazon S3 バケット名とキーなので、以下のように入力トランスフォーマーで絞り込みました。 入力パス { "bucket": "$.detail.bucket.name", "key": "$.detail.object.key" } 入力テンプレート { "bucket": <bucket>, "key": <key> } AWS Step Functions ステートマシンのタスク単位で説明します。設定の記法は JSONata を使用しています。 Map ステート ステートマシンが開始したとき、Map ステートから始まります。この時点のインプットは以下のようにデータが格納された CSV ファイルの S3 バケット名、キーになります。 { "input": { "bucket": "bedrockjob-test", "key": "input/testdata3.csv" }, "inputDetails": { "truncated": false }, "roleArn": "arn:aws:iam::xxxxxxxxxxxx:role/bedrockjob-StateMachineExecutionRole-test" } インプットにしたいデータが純粋な JSON データであれば処理モードは「インライン」で良いのですが、今回のように Amazon S3 にあるファイルがインプットの場合は「分散」を選択します。 データが CSV 形式の場合、専用の設定があります。 CSV ファイルは先頭行に項目名を入れているため、CSV ヘッダーの場所を「最初の行」に設定します。CSV なのでデリミタは Comma です。 CSV データからどのようにデータを取得するか、後工程でわかりやすくするため、ItemSelector を設定します。CSV 内には id, data の列があり、その項目名で JSON データに変換するイメージです。 Map ステートでは CSV 各行のデータは $states.context.Map.Item.Value に格納される仕様になっており、その中に id, data が格納されるので上記のような書き方になります。 同時実行数制限は 10 にしました。Amazon Bedrock の基盤モデルを呼び出す類のリクエスト数は分単位での実行数制限があります。しかし、数百から数千単位の数なので、同時実行 10 であればさほど気にすることはないだろう、と考えました。 InvokeModel Amazon Bedrock InvokeModel ランタイムを使用します。基本的には boto3 で InvokeModel するときと同じ引数 (パラメータ) を指定することになります。以下は例ですので、必要に応じてパラメータは変更しましょう。 注意点ですが、AWS Step Functions から直接 API を呼び出す場合、JSON 的に最初の階層の項目名は Pascal case、つまり先頭を大文字にしないとエラーになります。例えば modelId は ModelId にします。 { "ModelId": "us.anthropic.claude-3-7-sonnet-20250219-v1:0", "ContentType": "application/json", "Accept": "application/json", "Trace": "DISABLED", "PerformanceConfigLatency": "standard", "Body": { "anthropic_version": "bedrock-2023-05-31", "max_tokens": 2000, "top_k": 250, "stop_sequences": [], "temperature": 1, "top_p": 0.999, "messages": [ { "role": "user", "content": [ { "type": "text", "text": "{% 'Please translate the following text into Japanese and summarize it in no more than 300 characters.\n' & $states.input.data %}" } ] } ] } } プロンプトは “text”: の部分に書いてある Please translate the following text into Japanese and summarize it in no more than 300 characters. です。日本語も問題ないですが、なんとなく英語で書きました。 その続きに、& 区切りで変数を追加しています。$states.input.data が CSV ファイルから読み取った元データです。これら引数は使用する基盤モデルによって変わることがありますので、ご注意ください。 出力は、成功時、エラー時ともに同じフォーマットに統一したかったので、以下のように固定で項目名を設定しています。 { "id": "{% $states.input.id %}", "data": "{% $states.input.data %}", "result": "{% $parse($states.result.Body).content[0].text %}", "status": "succeeded" } id と data は、インプットに入っていたものをそのまま後続に渡します。 result には、Amazon Bedrock 基盤モデルが返してきたレスポンスから、メッセージ部分だけを抽出して格納します。 status には、成功時は succeeded 固定です。 エラー処理には、キャッチャーを 1 つ設定し以下のように入れています。result にエラーメッセージ ($states.errorOutput.Cause) を、status には failed が格納されるようにしました。 Success/Error これらのタスクは、ジョブフローの見た目で成功か失敗かをわかりやすくするために入れた Pass ステートです。特に何もしていません。 SendResult このタスクは AWS Lambda 関数を呼び出しています。AWS Step Functions のデフォルト設定で Lambda 関数を紐づけているだけです。ここでは Lambda 関数のコードを紹介します。 Lambda 関数へのインプットは、以下のような JSON データになります。このデータが Lambda 関数内の event 変数に格納されます。 [ { "id": "1", "data": "Amazon Bedrock is a fully managed service that makes high-performing foundation models... 以下略", "result": "# 日本語翻訳と要約\n\nAmazon Bedrockは、主要AI企業とAmazonの高性能基盤モデル(FM)を統一...以下略", "status": "succeeded" }, { "id": "2", "data": "With AWS Step Functions, you can create workflows, also called State machines, to build...以下略", "result": "# 日本語訳と要約\n\nAWS Step Functionsでは、分散アプリケーション構築、プロセス自動化...以下略", "status": "succeeded" } ] ユーザーには CSV ファイルとして結果を返したいので、この Lambda 関数内で pandas を使用して JSON を CSV に変換し、Amazon S3 バケットに保存します。 今回の仕様では、元データの CSV ファイルを保存した Amazon S3 バケットの output フォルダに結果 CSV ファイルを保存します。 Lambda 関数 import json import pandas as pd import datetime import boto3 s3 = boto3.resource('s3') client = boto3.client('s3') sns = boto3.client('sns',region_name='us-west-2') def datetimeconverter(o): if isinstance(o, datetime.datetime): return str(o) def lambda_handler(event, context): try: df = pd.DataFrame(event) jstdelta = datetime.timedelta(hours=9) JST = datetime.timezone(jstdelta, 'JST') dtnow = datetime.datetime.now(JST) fileNameDateTime = dtnow.strftime('%Y%m%d%H%M%S') tempFileName = '/tmp/result_' + fileNameDateTime + '.csv' outputBucket = 'bedrockjob-test' outputS3Key = 'output/result_' + fileNameDateTime + '.csv' # JSON to CSV df.to_csv(tempFileName, encoding='utf-8_sig', index=None) # upload CSV into S3 s3.meta.client.upload_file(tempFileName, outputBucket, outputS3Key) # publish SNS res = sns.publish(TopicArn='arn:aws:sns:us-west-2:xxxxxxxxxxxx:bedrockjob-SNSTopic-xxxxxxxxxxxx',Message='Your Bedrock job has been completed.\nS3Bucket: ' + outputBucket + '\nS3Key: ' + outputS3Key) except Exception as e: print(e) return { "result": str(e) } else: return { "result": res } 最後、Amazon SNS トピックに完了メッセージを送信しています。本記事の主要なテーマではないので詳細は割愛します。 この Lambda 関数は pandas を使用するため、以下のブログ記事で紹介しているように、Lambda レイヤーの設定が必要になります。 AWS Lambda (Python 3.12) で使用可能な pandas の Lambda Layer を準備する データ分析や加工でよく使われるライブラリに、pandas があると思います。本記事では、AWS Lambda (Python 3.12) で動作する pandas の Lambda Layer を準備する手順を紹介します。 blog.usize-tech.com 2022.06.07 ここで行っている JSON から CSV 変換ですが、他のアーキテクチャも考えました。AWS Glue や Amazon Athena を使用して簡単に (極力ノーコードで) できないかと思ったんですが、カタログやテーブル的なものを作成しなければならなかったので、このようなスポット的な変換処理、かつ所詮 CSV レベルのデータ量であれば Lambda でいいか、と落ち着きました。 参考: AWS CloudFormation テンプレート これらリソース一式を AWS CloudFormation でデプロイできるようにしてあります。詳細な設定はこちらをご確認ください。Amazon SNS トピックはトピックを作成するところまでとなっていますので、サブスクライブは手動で実施ください。 AWSTemplateFormatVersion: 2010-09-09 Description: The CloudFormation template that creates a S3 bucket, a Lambda function, a Step Functions workflow, an EventBridge rule, a SNS topic, and relevant IAM roles. # ------------------------------------------------------------# # Input Parameters # ------------------------------------------------------------# Parameters: SubName: Type: String Description: System sub name of the Bedrock job. (e.g. prod or test) Default: test MaxLength: 30 MinLength: 1 S3BucketNameSdk: Type: String Description: S3 bucket name in which you uploaded sdks for Lambda Layers. (e.g. sdkbucket) Default: sdkbucket MaxLength: 50 MinLength: 1 S3KeyPandasSdk: Type: String Description: S3 key of pandas.zip. Fill the exact key name if you renamed. (e.g. sdk/Python3.13/pandas223.zip) Default: sdk/Python3.13/pandas223.zip MaxLength: 50 MinLength: 1 BedrockClaudeModelId: Type: String Description: The Bedrock Model ID. Default: "us.anthropic.claude-3-7-sonnet-20250219-v1:0" MaxLength: 100 MinLength: 1 BedrockOptionTopK: Type: Number Description: Top K parameter. The data type is int. The range is 0 to 500. Default: 250 MaxValue: 500 MinValue: 0 BedrockOptionTopP: Type: String Description: Top P parameter. The data type is float. The range is 0 to 1. Default: 0.999 MaxLength: 5 MinLength: 1 BedrockOptionTemperature: Type: String Description: Temperature parameter. The data type is float. The range is 0 to 1. Default: 1 MaxLength: 5 MinLength: 1 BedrockOptionMaxTokens: Type: Number Description: Max Tokens parameter. The data type is int. The range is 100 to 64000. Default: 2000 MaxValue: 64000 MinValue: 100 Resources: # ------------------------------------------------------------# # S3 # ------------------------------------------------------------# S3BucketBedrockJob: Type: AWS::S3::Bucket Properties: BucketName: !Sub bedrockjob-${SubName} LifecycleConfiguration: Rules: - Id: AutoDelete Status: Enabled ExpirationInDays: 7 OwnershipControls: Rules: - ObjectOwnership: BucketOwnerEnforced PublicAccessBlockConfiguration: BlockPublicAcls: true BlockPublicPolicy: true IgnorePublicAcls: true RestrictPublicBuckets: true NotificationConfiguration: EventBridgeConfiguration: EventBridgeEnabled: true Tags: - Key: Cost Value: !Sub bedrockjob-${SubName} # ------------------------------------------------------------# # Lambda S3 and SNS Invocation Role for Sfn (IAM) # ------------------------------------------------------------# LambdaS3SnsInSfnRole: Type: AWS::IAM::Role Properties: RoleName: !Sub bedrockjob-LambdaS3SnsInSfnRole-${SubName} Description: This role allows Lambda functions to invoke S3 and SNS. AssumeRolePolicyDocument: Version: 2012-10-17 Statement: - Effect: Allow Principal: Service: - lambda.amazonaws.com Action: - sts:AssumeRole Path: / Policies: - PolicyName: !Sub bedrockjob-LambdaS3SnsInSfnPolicy-${SubName} PolicyDocument: Version: 2012-10-17 Statement: - Effect: Allow Resource: - !Ref SNSTopic Action: - sns:Publish - Effect: Allow Action: - s3:PutObject Resource: - !Sub "${S3BucketBedrockJob.Arn}/*" ManagedPolicyArns: - arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole - arn:aws:iam::aws:policy/AWSXRayDaemonWriteAccess DependsOn: - S3BucketBedrockJob - SNSTopic # ------------------------------------------------------------# # Lambda Layer # ------------------------------------------------------------# LambdaLayerPandas223: Type: AWS::Lambda::LayerVersion Properties: LayerName: !Sub bedrockjob-pandas223-${SubName} Description: !Sub Pandas 2.2.3 for Python to load in bedrockjob-${SubName} CompatibleRuntimes: - python3.13 Content: S3Bucket: !Sub ${S3BucketNameSdk} S3Key: !Sub ${S3KeyPandasSdk} LicenseInfo: BSD-3-Clause # ------------------------------------------------------------# # Lambda # ------------------------------------------------------------# LambdaSendResult: Type: AWS::Lambda::Function Properties: FunctionName: !Sub bedrockjob-SendResult-${SubName} Description: Lambda Function to send the Step Functions job result. Runtime: python3.13 Timeout: 240 MemorySize: 256 Role: !GetAtt LambdaS3SnsInSfnRole.Arn Handler: index.lambda_handler Layers: - !Ref LambdaLayerPandas223 Tags: - Key: Cost Value: !Sub bedrockjob-${SubName} Code: ZipFile: !Sub | import json import pandas as pd import datetime import boto3 s3 = boto3.resource('s3') client = boto3.client('s3') sns = boto3.client('sns',region_name='${AWS::Region}') def datetimeconverter(o): if isinstance(o, datetime.datetime): return str(o) def lambda_handler(event, context): try: df = pd.DataFrame(event) jstdelta = datetime.timedelta(hours=9) JST = datetime.timezone(jstdelta, 'JST') dtnow = datetime.datetime.now(JST) fileNameDateTime = dtnow.strftime('%Y%m%d%H%M%S') tempFileName = '/tmp/result_' + fileNameDateTime + '.csv' outputBucket = '${S3BucketBedrockJob}' outputS3Key = 'output/result_' + fileNameDateTime + '.csv' # JSON to CSV df.to_csv(tempFileName, encoding='utf-8_sig', index=None) # upload CSV into S3 s3.meta.client.upload_file(tempFileName, outputBucket, outputS3Key) # publish SNS res = sns.publish(TopicArn='${SNSTopic}',Message='Your Bedrock job has been completed.\nS3Bucket: ' + outputBucket + '\nS3Key: ' + outputS3Key) except Exception as e: print(e) return { "result": str(e) } else: return { "result": res } # ------------------------------------------------------------# # State Machine Execution LogGroup (CloudWatch Logs) # ------------------------------------------------------------# LogGroupStateMachineBedrockJob: Type: AWS::Logs::LogGroup Properties: LogGroupName: !Sub /aws/vendedlogs/states/bedrockjob-${SubName} RetentionInDays: 365 Tags: - Key: Cost Value: !Sub bedrockjob-${SubName} # ------------------------------------------------------------# # State Machine Execution Role (IAM) # ------------------------------------------------------------# StateMachineExecutionRole: Type: AWS::IAM::Role Properties: RoleName: !Sub bedrockjob-StateMachineExecutionRole-${SubName} Description: This role allows State Machines to call specified AWS resources. AssumeRolePolicyDocument: Version: 2012-10-17 Statement: - Effect: Allow Principal: Service: states.amazonaws.com Action: - sts:AssumeRole Path: / Policies: - PolicyName: !Sub bedrockjob-StateMachineExecutionPolicy-${SubName} PolicyDocument: Version: 2012-10-17 Statement: - Effect: Allow Action: - s3:GetObject - s3:PutObject Resource: - !Sub "${S3BucketBedrockJob.Arn}/*" - Effect: Allow Action: states:StartExecution Resource: "*" - Effect: Allow Action: states:DescribeExecution Resource: "*" - Effect: Allow Action: - bedrock:InvokeModel* - bedrock:CreateInferenceProfile Resource: - arn:aws:bedrock:*::foundation-model/* - arn:aws:bedrock:*:*:inference-profile/* - arn:aws:bedrock:*:*:application-inference-profile/* - Effect: Allow Action: - bedrock:GetInferenceProfile - bedrock:ListInferenceProfiles - bedrock:DeleteInferenceProfile - bedrock:TagResource - bedrock:UntagResource - bedrock:ListTagsForResource Resource: - arn:aws:bedrock:*:*:inference-profile/* - arn:aws:bedrock:*:*:application-inference-profile/* ManagedPolicyArns: - arn:aws:iam::aws:policy/service-role/AWSLambdaRole - arn:aws:iam::aws:policy/CloudWatchLogsFullAccess - arn:aws:iam::aws:policy/AWSXrayWriteOnlyAccess DependsOn: - S3BucketBedrockJob # ------------------------------------------------------------# # Step Functions # ------------------------------------------------------------# StateMachineBedrockJob: Type: AWS::StepFunctions::StateMachine Properties: StateMachineName: !Sub bedrockjob-${SubName} StateMachineType: STANDARD DefinitionSubstitutions: DSLambdaSendResultArn: !GetAtt LambdaSendResult.Arn DSBedrockClaudeModelId: !Ref BedrockClaudeModelId DSBedrockOptionTopK: !Ref BedrockOptionTopK DSBedrockOptionTopP: !Ref BedrockOptionTopP DSBedrockOptionTemperature: !Ref BedrockOptionTemperature DSBedrockOptionMaxTokens: !Ref BedrockOptionMaxTokens DefinitionString: |- { "Comment": "The state machine to invoke Bedrock job.", "QueryLanguage": "JSONata", "StartAt": "Map", "States": { "Map": { "Type": "Map", "ItemProcessor": { "ProcessorConfig": { "Mode": "DISTRIBUTED", "ExecutionType": "STANDARD" }, "StartAt": "InvokeModel", "States": { "InvokeModel": { "Type": "Task", "Resource": "arn:aws:states:::aws-sdk:bedrockruntime:invokeModel", "Next": "Success", "Output": { "id": "{% $states.input.id %}", "data": "{% $states.input.data %}", "result": "{% $parse($states.result.Body).content[0].text %}", "status": "succeeded" }, "TimeoutSeconds": 600, "Catch": [ { "ErrorEquals": [ "States.ALL" ], "Comment": "Error", "Next": "Error", "Output": { "id": "{% $states.input.id %}", "data": "{% $states.input.data %}", "result": "{% $states.errorOutput.Cause %}", "status": "failed" } } ], "QueryLanguage": "JSONata", "Arguments": { "ModelId": "${DSBedrockClaudeModelId}", "ContentType": "application/json", "Accept": "application/json", "Trace": "DISABLED", "PerformanceConfigLatency": "standard", "Body": { "anthropic_version": "bedrock-2023-05-31", "max_tokens": ${DSBedrockOptionMaxTokens}, "top_k": ${DSBedrockOptionTopK}, "stop_sequences": [], "temperature": ${DSBedrockOptionTemperature}, "top_p": ${DSBedrockOptionTopP}, "messages": [ { "role": "user", "content": [ { "type": "text", "text": "{% 'Please translate the following text into Japanese and summarize it in no more than 300 characters.\n' & $states.input.data %}" } ] } ] } } }, "Error": { "Type": "Pass", "End": true, "QueryLanguage": "JSONata" }, "Success": { "Type": "Pass", "End": true, "QueryLanguage": "JSONata" } } }, "Label": "Map", "MaxConcurrency": 10, "ItemReader": { "Resource": "arn:aws:states:::s3:getObject", "ReaderConfig": { "InputType": "CSV", "CSVHeaderLocation": "FIRST_ROW", "CSVDelimiter": "COMMA" }, "Arguments": { "Bucket": "{% $states.input.bucket %}", "Key": "{% $states.input.key %}" } }, "ItemSelector": { "id": "{% $states.context.Map.Item.Value.id %}", "data": "{% $states.context.Map.Item.Value.data %}" }, "QueryLanguage": "JSONata", "ToleratedFailureCount": 5, "Next": "SendResult" }, "SendResult": { "QueryLanguage": "JSONata", "Type": "Task", "Resource": "arn:aws:states:::lambda:invoke", "Output": "{% $states.result.Payload %}", "Arguments": { "FunctionName": "${DSLambdaSendResultArn}", "Payload": "{% $states.input %}" }, "Retry": [ { "ErrorEquals": [ "Lambda.ServiceException", "Lambda.AWSLambdaException", "Lambda.SdkClientException", "Lambda.TooManyRequestsException" ], "IntervalSeconds": 1, "MaxAttempts": 3, "BackoffRate": 2, "JitterStrategy": "FULL" } ], "End": true, "Comment": "Invoke the Lambda function to send the result of this state machine via email.", "TimeoutSeconds": 300 } }, "TimeoutSeconds": 7200 } LoggingConfiguration: Destinations: - CloudWatchLogsLogGroup: LogGroupArn: !GetAtt LogGroupStateMachineBedrockJob.Arn IncludeExecutionData: true Level: ERROR RoleArn: !GetAtt StateMachineExecutionRole.Arn TracingConfiguration: Enabled: true Tags: - Key: Cost Value: !Sub bedrockjob-${SubName} DependsOn: - LogGroupStateMachineBedrockJob - StateMachineExecutionRole # ------------------------------------------------------------# # EventBridge Role (IAM) # ------------------------------------------------------------# EventBridgeRole: Type: AWS::IAM::Role Properties: RoleName: !Sub bedrockjob-EventBridgeRole-${SubName} Description: This role allows EventBridge to call the Step Functions state machine. AssumeRolePolicyDocument: Version: "2012-10-17" Statement: - Effect: Allow Principal: Service: events.amazonaws.com Action: sts:AssumeRole Policies: - PolicyName: !Sub bedrockjob-EventBridgePolicy-${SubName} PolicyDocument: Version: "2012-10-17" Statement: - Effect: Allow Action: states:StartExecution Resource: !Ref StateMachineBedrockJob DependsOn: - StateMachineBedrockJob # ------------------------------------------------------------# # EventBridge Rule # ------------------------------------------------------------# EventBridgeRule: Type: AWS::Events::Rule Properties: Name: !Sub bedrockjob-StartStateMachine-${SubName} Description: This rule starts the Step Functions state machine when the CSV data is put in the S3 bucket. EventBusName: default State: ENABLED EventPattern: !Sub |- { "source": ["aws.s3"], "detail-type": ["Object Created"], "detail": { "bucket": { "name": ["${S3BucketBedrockJob}"] }, "object": { "key": [{ "wildcard": "input/*.csv" }] } } } Targets: - Arn: !Ref StateMachineBedrockJob RoleArn: !GetAtt EventBridgeRole.Arn Id: !Sub bedrockjob-StartStateMachine-${SubName} InputTransformer: InputPathsMap: bucket: "$.detail.bucket.name" key: "$.detail.object.key" InputTemplate: | { "bucket": , "key": } RetryPolicy: MaximumRetryAttempts: 1 MaximumEventAgeInSeconds: 3600 DependsOn: - S3BucketBedrockJob - EventBridgeRole # ------------------------------------------------------------# # SNS Topic # ------------------------------------------------------------# SNSTopic: Type: AWS::SNS::Topic Properties: TracingConfig: PassThrough DisplayName: !Sub bedrockjob-notification-${SubName} FifoTopic: false Tags: - Key: Cost Value: !Sub bedrockjob-${SubName} まとめ いかがでしたでしょうか？ プロンプトの調整、インプットデータのサニタイズ、センシティブ情報のマスキングなど課題はありますが、個人利用であれば運用でカバーできると思っています。 本記事が皆様のお役に立てれば幸いです。

こんにちは、SCSKの嶋谷です。 AWSサービスの監視は、Amazon CloudWatchアラームで監視対象のメトリクス(CPU使用率やディスク使用率等)に関するアラート条件を設定してAmazon SNS(Simple Notification Service)を用いてメール等に送信する方法が一般的ではないでしょうか。CloudWatchを用いた方法は監視対象毎にアラート条件を設定して管理する必要があり、とても大変ではないでしょうか。また、サービスを組み合わせてアラーム作成を自動化することも可能ですが、この手法を構築することも大変ではないでしょうか。今回はAWSでの通知方法を監視サービス「Mackerel」で代替したときの設定方法や通知内容が気になり、実際に検証してみました。今回の検証ではアラートの通知先をメールとしています。 AWSでのアラート通知方法 まずは、AWSでのアラート通知方法について説明します。今回はAmazon EC2のCPU使用率が80%を超えた時にアラート通知が送信されるように設定します。 (1)AWSのコンソールにログインし、左上の検索バーで「CloudWatch」と入力し、エンターを押す (2)左側タブの「すべてのアラーム」をクリックし、「アラームの作成」をクリック (3)「メトリクス選択」をクリックして監視対象EC2の「CPUUtilization」メトリクスを選択 (4)条件を設定(今回はCPU使用率の5分間の平均値が80%を超えているときにアラート通知を送信) (5)トピックの作成     通知先をメールにするため、「新しいトピックの作成」を選択して、トピック名と通知先アドレスを     入力して「トピックの作成」をクリック。この設定でSNSのトピックとサブスクリプションが自動的     に作成されます。 (6)通知先アドレスに届いたメール「Confirm subscription」をクリック (7)アラーム名を設定して作成が完了 AWSでのアラート通知が設定できたので、実際にメールが来るかを検証してみます。 下記コマンドを使用して疑似的にCPUへ負荷をかけて検証しました。 # yes > /dev/null CPUが80%を超えると下記のようなメールが届きました。メールの内容は、メールが送信された理由(CPU使用率が80%を超えた)とアラートの詳細(アラーム名やアカウント情報)について記載されています。 これにてAWSでの設定からテストまで完了しました。特に詰まることなく作業を完了することができました。 Mackerelでのアラート通知方法 次にMackerelで設定する方法について解説していきます。 Mackerelで通知するためにはまずAWSのサービスを監視対象としてMackerelに登録する必要があります。MackerelではAWSインテグレーション機能を利用することでAWSサービスを作成するだけでMackerelのコンソール上にAWSサービスがホスト名で登録されます。AWSインテグレーションについては下記をご参照ください。MackerelへのEC2登録後の作業を説明します。 Mackerel で AWS のサーバーレスサービスを監視してみた (1)サービス・ロールを作成     サービスはECサイトシステム、ロールはECサイトシステムのDB機能やWeb機能のように考えれば     イメージが湧きやすいです。サービス・ロールの詳細については下記をご参照ください。ただ、サー     ビス・ロールについてはMackerelを使用する上で肝になる部分だと思っているので、次回のブログ     で説明したいと考えています。      「サービス」「ロール」とは     Mackerelコンソールの左側タブのサービスをクリックした後、「サービスを追加する」をクリック     してサービス名を入力するとサービスが作成できます。作成したサービスを選択し、「ロールを新規     作成」をクリックしてロール名を入力するとロールが作成できます。   (2)Mackerelコンソール上に登録されている監視対象ホストにロールの割り当て     ホスト一覧画面の監視対象ホストの「サービス・ロール」欄をクリックすると下記の画面が出力され     るので、(1)の手順で作成したロールを割り当てる。 (3)監視ルール(アラートを検知する条件)を作成     今回は前章と同様に5分間のCPU使用率が80%超えるとアラートが出るように設定します。     ここで監視対象を絞り込むことが重要です。 絞り込まないとMackerelに登録されている全ホストが     監視対象になってしまいます。検証の際に1度目の設定時に絞り込みを忘れ、監視対象以外のホスト     のアラートが出てしまい、監視対象のアラートをMackerel上で発見するのに苦労しました。 (4)通知グループ(通知条件)を作成して通知チャンネル(通知先)を紐づけ     通知グループ・通知チャンネルについては下記をご参照ください。      監視・通知を設定する – Mackerel ヘルプ     まず通知チャンネルを作成します。今回はメールによる通知を行うため「メール通知」を選択して     通知先のメールアドレスを選択して作成します(Mackerelではメール以外にもTeamsやSlackなどの     さまざまなサービスを通知先として選択できます)。次に通知グループを作成します。     サービスとして(1)の手順で作成したサービスを、通知先として(4)の手順で作成した通知チャンネル     を選択します。 Mackerelでアラート通知設定ができたので、前章と同じようにCPUに負荷をかけてメールが来るかを検証してみました。 CPUが80%を超えると下記のようなメールが届きました。メールの内容は、CPU使用率のグラフとアラート発生時のCPU値とアラート条件のCPU値が記載されています。 これにてMackerelでの設定からテストまで完了です。メールにグラフが表示されるのは、使用率の推移がメールで理解できるので便利だなと思いました。 EC2を増加させたときの方法 これまではEC2を1台作成したときのAWS・Mackerelでの通知設定の方法について説明しました。システムを構築していくうえでサーバ(EC2)は1台とは限らず、2,3,4台のように複数台で構成されるのが一般的だと思います。その場合のAWSやMackerelでの設定方法について説明します。(今回は監視要件が同じ場合を対象としています。) AWSの場合 ①今回の記事内容のように1台ずつCloudWatchのアラームを作成 個々のEC2に対して手動でCloudWatchアラームを作成する方法です。この方法では、監視要件や通知先が同じ場合にアラーム名が異なる CloudWatchアラームをEC2それぞれで作成 する必要があるため、手間がかかります。私は②の方法で自動化しました。 ②他サービスを連携してアラーム作成を自動化 Amazon EventBridgeとLambdaを利用してEC2の作成をトリガーとしてCloudWatchアラームを自動で作成する方法です。構成図を以下に示しております。今回はソースコードなどの掲載は省略します。 ①の方法では、EC2を作成するたびにCloudWatchアラームを作成する必要があり手間でした。②の方法を実装することでユーザはEC2を作成するだけで通知設定が自動で完了するため、とても便利な方法です(②の手順を実装することに時間がかかりますが・・・)。サーバの台数が少ない場合は①の手順でアラームを作成する方法でも問題ないかもしれません。 Mackerelの場合 Mackerelでは、サービスやロールはEC2を1台作成した際に作成済であるため、 新しく作成する必要はありません 。そのため、2章の(2)の作業のように ロールを割り当てる だけで2台目以降は簡単に通知設定を完了させることができます。今回の検証においても時間をかけることなく2台目以降の通知設定を完了させることができました。 AWSとMackerelでの実装を終えて AWSでは複数のサービスを連携することでアラート通知の設定を自動化することができるため、作成するまでの苦労を乗り越えれば後から楽ができるなと感じました。 Mackerelでは通知設定を1つ作成してしまえば、後からは1作業(ロール割り当て)で設定が完了するためこの方法も楽だなと感じました。 AWS・Mackerelでの通知方法については両サービスそれぞれの特徴があると思うので、状況によって使い分けるべきだと思いました。 ただ、どちらの方法も容易かつ便利であることは同じだと思いました。 まとめ 今回はAWSサービスの監視をAWSサービスを使用して実装する方法とMackerelで実装する方法の2種類を検証してみました。どちらの手法も簡単な操作で実装することができました。今回はEC2を増加させた場合についての実装方法を記載しましたが、次回はサービスの増減・アラート条件の変更・通知先の変更などの実際の運用現場を想定した実装方法についてMackerelの「サービス・ロール」に絡めながら記載したいと思います。

こんにちは！佐藤です。 「あれ、昔見た映画なんだっけ…タイトルが全く思いだせない…」 こんな経験、ありませんか？ 映画の一場面やキャラクターは覚えているのに、タイトルが思い出せなくてモヤモヤする…。 友人と話していても結構こういう場面に遭遇するんですよね。 そこで今回は、Amazon Bedrockのナレッジベースとエージェント機能を使って、映画の断片的な記憶から作品を特定できるシステムを作ってみた――――というお話です。 1. Amazon Bedrockとナレッジベースとは？ Amazon Bedrockは、AWS（Amazon Web Services）が提供する生成AIサービスです。APIを通じてClaude、Stable Diffusion、Anthropicなど様々な基盤モデルを実装したサービスを構築できるのが特徴です。 その中でも今回注目したいのが「ナレッジベース」機能。 これは独自のデータをAIに学習させ、そのデータを基に回答を作成する、自分だけのAIアシスタントを作れる機能です。 映画情報をナレッジベースに登録すれば、「宇宙で女性が一人」などの断片的な情報から映画を特定できるようになります！ ナレッジベースの特徴 2. システム構築をしてみよう アクセス設定 まずはAmazon Bedrockへのアクセス設定から始めます。 AWSマネジメントコンソールにログインし、Bedrockサービスに移動しましょう。 初めて使う場合は、モデルアクセスの設定が必要です。サイドバーの「モデルアクセス」から必要なモデルへのアクセスをリクエストします。 今回は特にClaude 3.5 Sonnet v2モデルを使用するので、このモデルへのアクセスを確保しておきましょう。 アクセス権がリクエスト可能になったら、リクエストを送信し、許可を待ちます。通常数分で承認されます。 データの準備 次に、映画データの準備です。今回私は次のような情報を含むJSONファイルを作成しました： 映画のタイトル（日本語・英語） 公開年 監督名 主要キャスト あらすじ キーワード（映画の中で印象強いシーンなど） 今回は、国内最大級の映画・ドラマ・ アニメレビューサイト「Filmarks( https://filmarks.com )」さんのデータをお借りして投入データを作成してみました。 その中でも、2024年最も輝いた映画・ドラマ・アニメを表彰する「Filmarks Awards 2024」の、国内映画部門ノミネート作品から、以下の5作品のデータを投入します(詳細は、 https://filmaga.filmarks.com/articles/315003/ )。 このデータをS3バケットにアップロードします。 コンソールからS3サービスに移動し、「バケットを作成」をクリックします。 私は「movie-knowledge-base-yuutsatou」という名前でバケットを作成し、先ほど準備したJSONファイル(movie.json)をアップロードしました。 ナレッジベースの作成 データの準備ができたら、いよいよナレッジベースを作成します。 Bedrockコンソールの「オーケストレーション」から「ナレッジベース」を選択し、「作成」ボタンをクリックします。 ナレッジベースの詳細を設定します： 名前：「MovieMemoryKnowledgeBase」 説明：「曖昧な記憶から映画を特定するためのナレッジベース」 データソース：S3から先ほどアップロードしたJSONファイルを指定 ベクトルストア：OpenSearch Serverlessを使用 設定が完了したら、ナレッジベースを作成します。インデックス作成には少し時間がかかりますが、辛抱強く待ちましょう。 エージェントの作成 最後に、このナレッジベースを活用するエージェントを作成します。 「オーケストレーション」の「エージェント」から「エージェントを作成」をクリックします。 エージェントの詳細を設定します： 名前：「MovieMemoryAssistant」 説明：「曖昧な記憶から映画を特定するアシスタント」 モデル：Claude 3.5 Sonnet v2 エージェント向けの指示： あなたは映画の専門家です。ユーザーの曖昧な記憶や断片的な情報から映画を特定することを得意としています。 例えば： -「80年代の、タイムマシンの映画で、車に乗って過去に行くやつ」からは「バック・トゥ・ザ・フューチャー」を特定 -「宇宙で女性が一人取り残される映画」からは「ゼログラビティ」を特定など ユーザーの質問から映画を特定できない場合は、「他にどんな特徴があったか教えてみてよ～」と言って、ユーザーからの追加情報を引き出す質問をしてください。 映画を特定できた場合は、タイトル、監督、制作年、主演俳優、簡単なあらすじを教えてあげてください。 さらに、先ほど作成したナレッジベース「MovieMemoryKnowledgeBase」をエージェントに関連付けます。 エージェント向けのナレッジベースの指示には、以下のようにフィールドマッピングを設定しました： 以下のようにフィールドマッピングされているので、回答の参考にしてください。 {title}：日本語のタイトル {title_en}：英語のタイトル {year}：公開年 {director}：監督名 {cast}：主な出演者 {synopsis}：あらすじ {keywords}：キーワード（映画の中で印象強いシーンなど。ここが最も重要視される） すべての設定が完了したら、エージェントを作成します。   4. 実際に試してみた結果 さて、いよいよ完成したシステムを試してみましょう！ ユーザー ：昔の中国が舞台の映画って何だっけ？（キングダムを想定） MovieMemoryAssistant ：あなたが言及している映画は「キングダム 大将軍の帰還」という作品だと思われます。 この映画は古代中国を舞台にしており、秦と趙の国家間の戦いを描いています。山﨑賢人が主演を務め、吉沢亮、橋本環奈、清野菜名などの豪華キャストが出演しています。 この映画は、馬陽の戦いを中心に展開し、信（山﨑賢人）と飛信隊の仲間たちが、趙国の総大将・龐煖（吉川晃司）との激しい戦いを繰り広げる物語です。原作の漫画を実写化したアクション映画で、迫力ある戦闘シーンや演技が特徴とされています。 なんと、一発で正解しました！しかも情報もかなり詳しいです。 次に少し難しい質問を試してみます。 ユーザー ：洗濯機が印象的な映画って何だっけ？結構シリアスな映画だったと思うんだけど…（ラストマイルを想定） MovieMemoryAssistant ：ご質問の内容に直接関連する映画情報は提供された検索結果には見当たりません。しかし、「ラストマイル」という映画に関連する情報が見つかりました。 この映画では、洗濯機が重要な要素として登場するようです。 「ラストマイル」は2024年公開予定の映画で、爆弾をテーマにしたシリアスなサスペンス作品のようです。物語の中で、世界に張り巡らされた「血管」（おそらく通信網や物流網を比喩的に表現）を止めずに連続爆破を阻止するという難しい課題に直面します。  この映画は、現代社会の生命線を脅かす事件を扱っており、謎が解き明かされていく中で世界の隠された真の姿が浮かび上がるという展開が示唆されています。洗濯機が具体的にどのように物語に関わるかは明確ではありませんが、日常生活の象徴として重要な役割を果たす可能性があります。 映画は「リアル」で「テンポ」がよく、「感動」や「メッセージ性」があるとされており、印象的な作品になることが期待されます。 おお！これも正解です！映画の中のワンシーンでしかない洗濯機が出てくるシーンをよく理解できましたね… 5. まとめと今後の改善点 今回はAmazon Bedrockのナレッジベースとエージェント機能を使って、「あの映画なんだったっけ？」問題を解決するシステムを構築してみました。実際に試してみた感触は以下の通りです！ 良かった点 断片的な情報からでも映画を特定できた！ 自然な会話形式で映画について質問できる！ タイトルだけでなく、監督や出演者、あらすじも教えてくれる！ 改善したい点 より多くの映画データを追加しても回答がかぶらないのか？（現在はまだ系統の違う５作品のみ） 複数の候補がある場合の絞り込み精度を上げる（追加の質問を自主的に考えられるのか？） また、投入したデータの粒度や形式によっても回答の精度は変わりそうですね… あらすじやキーワードといった、回答にダイレクトに使えそうなデータを投入したので、これが曖昧になると回答がどうなるのかも気になります。。 映画好きの皆さん、「あの映画なんだったっけ？」でモヤモヤすることなく、スムーズに映画の会話を楽しめる日が近いかもしれません…！

今回は、Prisma Cloud環境のセキュリティログをどのように管理し、監査に備えることができるかについてお話ししていきます。 Prisma Cloud の 監査ログ 監査ログ機能 企業にとって、セキュリティは常に最重要課題です。Prisma Cloudによってマルチクラウド環境を統合的に管理・監視することでセキュリティ対策を講じることが可能ですが、Prisma Cloud環境自体のセキュリティについてもきちんと対策しておく必要があります。 Prisma Cloudの監査ログ機能を使えば、セキュリティに関する行動を実行・確認し、問題が発生した際の迅速な対応が可能となります。 監査ログは、Prisma Cloud管理者によって行われた全アクションを時系列で記録し、誰がいつ何をしたのかを簡単に把握できるようにしています。これにより、組織としてコンプライアンスを保つことができます。 監査ログの保存とアクセス Prisma Cloudでは、監査ログを最大120日間保管します。具体的なアクティビティを確認するためには、Prisma Cloudコンソールの[設定]から[監査ログ]を選び、時間範囲を選択することで詳細を確認できます。また、アクションタイプやユーザー、リソース名などでフィルタを使い、効率的に必要なデータを抽出することが可能です。 CSV出力 Prisma Cloudのコンソール上で、監査ログをCSV形式でダウンロードすることも可能です。「Load More」ボタンを使うことで、より多くの監査ログレコードを簡単に取得することができ、最大500件のレコードをリクエストできます。これにより必要な情報に迅速にアクセスでき、管理業務を円滑に進めることができます。 監査ログ転送の設定 Prisma Cloudコンソール上では、最大120日間しか監査ログを保管できません。セキュリティ監査の準備等、120日間以上ログを保管しておきたい場合は、Prisma Cloudで生成された監査ログをAmazon SQSやWebhooksといった外部システムへ転送することができます。 設定方法はとてもシンプルで、エンタープライズ設定から監査ログ送信機能を有効化し、通知先を選ぶだけです。設定後に出力された新しい監査ログが、選択した通知先チャネルへ送信されます。   監査ログをAWS環境に転送してみる 実際にPrisma Cloud監査ログの転送設定をしてみます。 今回やりたいことは、「Prisma Cloudの監査ログをAWS上のS3バケットに保管する」です。 AWS環境側の設定 まずは、監査ログの保管先となるAWS環境側の準備をしていきます。 Prisma Cloudの監査ログを外部へ送信する際の通知先として指定できるサービスは限られており、Amazon SQSまたはWebhooks通知チャネルしか通知先と指定できません。そのため、監査ログをSQSに送信⇒何らかの方法でSQSへ送信された監査ログをS3に保管、という構成にする必要があります。 今回はSQSへ送信された監査ログをS3に保管する処理をLambdaで行うため、以下のリソースを準備しました。 ・S3バケット ・SQS ・Lambda ・IAM（Lambdaに設定するIAMロール・IAMポリシー） 今回はLambdaのトリガーにSQSを設定することで、SQSに監査ログが送られてきたタイミングで自動的にLambdaが起動し、SQSに送られてきた監査ログをS3に保管する処理が行われる構成としました。S3バケット、Lambdaに関する設定や処理の起動タイミング等は、各環境の要件にあったものを選択してもらえれば問題ありませんのでここでは割愛します。 SQSはログの順序性を守りたいため「FIFO」タイプを選択しました。SQS名以外のその他の設定は今回はデフォルトのままで作成しています。 Prisma Cloudの外部統合の作成 AWS環境側の準備ができたら、Prisma Cloud監査ログの送信先となる外部統合を作成します。 Prisma Cloudコンソール > [設定] > [統合と通知] > [統合の追加] で、「Amazon SQS」を選択します。 以下の設定項目を入力して、[次へ] で進み、[統合のテスト] をクリックします。 テストが成功したら保存します。 設定項目 設定値 統合名 任意の名前 キューURL AWS環境側で準備したSQSのURL ※ 指定されたSQSへのアクセスに仕様するIAMロールを指定したい場合は、その他のオプションを有効にして値を入力してください。 デフォルトではSQSがあるクラウドアカウントの接続に利用しているIAM情報が利用されます。   Prisma Cloudのエンタープライズ設定で転送設定 監査ログの転送設定を実施します。 Prisma Cloudコンソール > [設定] > [エンタープライズ設定] > [監査ログを統合に送信] を有効化します。 有効化したら、[統合の選択] で先程作成した外部統合を選択します。 外部統合を選択したら、画面右上に表示されている「設定を保存」を忘れずにクリックしましょう。 これでPrisma Cloud監査ログの転送設定はすべて完了です。   まとめ 今回はPrisma Cloudの監査ログについて転送設定含めてまとめてみました。 Prisma Cloudの機能をフルに活用して、セキュリティの強化と効率的な監査体制の構築を目指しましょう。 今後も、Prisma Cloud の活用方法について実用的な情報をお届けできればと思います。 また、当社では、複数クラウド環境の設定状況を自動でチェックし、設定ミスやコンプライアンス違反、異常行動などのリスクを診断するCSPMソリューションを販売しております。 マルチクラウド設定診断サービス with CSPM｜ SCSK株式会社 マルチクラウド環境のセキュリティ設定リスクを手軽に確認可能なスポット診断サービスです。独自の診断レポートが、運用上の設定ミスや設計不備、クラウド環境の仕様変更などで発生し得る問題を可視化し、セキュリティインシデントの早期発見に役立ちます。 www.scsk.jp ご興味のある方は是非、お気軽にお問い合わせください。

こんにちは。SCSKの上田です。 昨年、 Zabbix Cloud というサービスがリリースされました。監視ソリューションとして実績のあるZabbixが SaaS型 になり、インフラの準備無しで監視を開始できるという点が注目を集めています。 本記事では、Zabbix Cloudを実際にセットアップし、その特徴や可能性を探っていきます。 はじめに そもそもZabbixとは？ Zabbixは、 エンタープライズ対応のオープンソース統合監視ツール です。 サービスやそれを支える ITシステム(サーバ、ネットワーク機器等)の状態を把握し、障害の予兆やサービスへ影響を及ぼす事象が発生した際に、システム管理者やオペレータに通知を行うオープンソースの統合監視ソリューションです。 数万デバイス規模のエンタープライズ環境でも多数の稼動実績を誇っています。 Zabbixの詳細情報については、以下リンクよりご確認ください。 Zabbix :: The Enterprise-Class Open Source Network Monitoring Solution ZabbixはITインフラストラクチャ・コンポーネントの可用性やパフォーマンスを監視するためのエンタープライス向けソフトウェアです。Zabbixはオープンソース・ソフトウェアとして開発されており、無料でダウンロードいただくことが可能です。 www.zabbix.com Zabbix Cloudとは？ Zabbix Cloudは、この実績あるZabbixを SaaSとして提供するサービス です。インフラのセットアップやメンテナンスを気にすることなく、Zabbixの監視機能を利用できます。 Zabbix Cloudの詳細情報については、以下リンクよりご確認ください。（まだ日本語のページがないため、英語版になります） Try Zabbix Cloud today Zabbix Cloud gives you all your favorite Zabbix monitoring features, but with easier deployment and management. www.zabbix.com   セットアップしてみた それでは、実際にセットアップする手順をご紹介します。 アカウントの作成 まず、先ほどのサイトから、【 Try Zabbix Cloud 】をクリックします。 Try Zabbix Cloudをクリック すると、ログイン画面が表示されます。 まだアカウント未作成でしたら、【 Sign up 】をクリックし、アカウントを新規作成します。 Sign upをクリック アカウントを作成したら、登録したメールアドレスとパスワードでログインしましょう。メールアドレス宛にワンタイムパスワードが届きますので、そちらを入力することでログイン可能です。 ログインすると、以下のような画面が出てくると思います。 ログイン後の画面 こちらがZabbix Cloudの管理コンソール画面となります。ここからノードの作成・管理したり、支払い情報を入力することができます。 Zabbix Cloudは 無料で5日間のトライアルが可能 なので、今回は無料で使える範囲でノードを作成してみます。 ノードの作成 必要事項を記入して、ノードを作成します。 ①Name Zabbixサーバーのホスト名です。DNSにも自動で登録されるため、このFQDNでWEB管理コンソールにアクセスすることなります。自動で割り当てられますが、自分好みに変えることも可能です。 今回は自動で割り当てられた使います。（イイ感じの名前が出るまでF5しました） ②Region 現時点では以下の5つから選べます。 分類 リージョン USA N.Virginia EU Frankfurt Ireland Asia Pacific Singapore South America São Paulo 残念ながらまだ日本リージョンは無いので、同じアジアの シンガポール を選択します。 ③Compute NVPS (New Values Per Second：1秒当たりの監視数)に応じて選択できます。 料金表 無料トライアルはNano限定 なので、今回は Nano を選択します。 ④Disk size 監視データを保管するディスクサイズを選択できます。10GB～16TBまでの間で選択できます。 無料トライアルは10GB限定 なので、今回は最小の 10GB を選択します。 Zabbix Cloudの料金は、③と④のスペックによって決まってきます。自身の監視要件に見合うスペックは、公式のツールを使って算定することができます。 Try Zabbix Cloud today Zabbixクラウドでは、Zabbix監視機能をすべて利用することができ、より簡単な導入と管理が可能です。 www.zabbix.com 監視対象ホスト数、アイテム数、監視間隔によって自動で最適なマシンスペックを算出してくれます。 ちなみに、最大のスペックである 2xLarge が10,000NVPS対応なので、それを超えるメチャクチャなスペックを入力すると怒られます。 これらの入力が終わったら、「 Create new node 」をクリックし、ノードを作成しましょう。 すると、ノードの作成が始まります。5分程度待って、Initializingが100%になると、ノードが完成します。 ステータスが Running になれば作成完了です。 作成完了！ Zabbixの設定 それでは、Zabbixにログインしてみましょう。ホスト名のリンクをクリックすると、見慣れたログイン画面が表示されます。 （DNSの反映に若干時間がかかる場合があるようです。アクセスできない場合は気長に待ちましょう。） いつものログイン画面 いつも通り、 Admin / zabbix でログインしたいところですが、、初期パスワードは別で設定されています。 ノードの右上の歯車マークをクリックし、ノードの設定画面に行きましょう。 ノードの設定画面へ ここで、初期パスワードのコピーや設定ができます。 パスワードのコピー、作成が可能 この認証情報をもとに、Zabbixにログインしてみましょう。 Zabbixログイン後の画面 見慣れたZabbixの画面が出てきました！ 初期設定は英語のUIなので、 【Administrator　＞　General　＞　GUI】 で設定を開き、【 Default Language 】を【 Japanese 】に、【 Default time zone 】を【 (UTC+09:00)Asia/Tokyo 】に変更しましょう。 これでいつものZabbixのように、監視ホストの登録やアイテム・トリガーの設定ができます。 日本語化した後の画面 Zabbix Cloudでできること、できないこと ここまでZabbix Cloudのセットアップ方法を紹介してきました。そんなZabbix Cloudの強みと、できないこと（これからに期待すること）を書いていきます。 Zabbix Cloudの強み セットアップが簡単 今までOSを用意するところから始めていたZabbixのセットアップが、SaaSになったことにより 数クリックでZabbixサーバーを構築できる ようになりました。OSの管理からも解放されます。 拡張が簡単 これもSaaSの特徴ですが、監視対象の増加に伴い、 スペックを簡単に拡張することが可能 です。そのため、初期のサイジング設計が最小限で良くなります。 バージョンアップが不要 自動でZabbixのバージョンアップが行われるため、自分で バージョンの管理をする必要がなくなりました 。 Zabbix Cloudの弱点、まだできないこと いくつかの機能が使用不可 OSレイヤが触れない関係上、監視スクリプトなどオンプレ版では使用できたいくつかの機能が使用できません。 週一回のメンテナンスでダウンタイム発生 週一回、1時間のメンテナンス時間があります。この時間帯は監視の停止が発生してしまいます。 日本語サポートしていない ドキュメントやサポートがまだ日本語対応しておらず、英語しかありません。オンプレ版ではEnterpriseサポートとして日本語でのサポートに対応していますが、Zabbix Cloudは英語でしか問合せができないようです。 またリージョンが日本にないため、レスポンスの遅延があったり、国外サーバー利用の制約もユーザーによってはあるかと思います。   まとめ まだリリースしたてのため、できないこともありますが、監視ツールとして実績のあるZabbixのSaaS化は注目すべき動向です。 今時点ですぐにZabbixの利用を始めたいという方には、 オンプレ版 をお勧めします。弊社では Zabbixの設計構築、サポート、アプライアンス機器の販売 を行っています。Zabbixの導入や運用でお困りの方は、是非弊社にお声がけください！ SCSKでは、今後もZabbix Cloudの検証を進め、機能アップデートの紹介や、オンプレ版Zabbixとの比較、他SaaS監視サービスとの比較などの記事を作成していく予定です。 ところで、SCSKは今年も Interop Tokyo 2024 のZabbixブースに出展します。今年は Zabbix Cloudに関するショートセミナー を開催する予定ですので、もしInteropにいらっしゃる方がいましたら、是非Zabbixブースにお越しください！ Interop Tokyo 2025 「Interop Tokyo」は技術動向とビジネス活用のトレンドを会場でのデモンストレーションやセッションを通じてお伝えするインターネットテクノロジーイベントです。 www.interop.jp 今後のZabbix Cloudの動きに注目しましょう！ 最後まで読んでいただき、ありがとうございました。 弊社ではZabbix関連サービスを展開しています。以下ページもご参照ください。 ★Zabbixの基礎をまとめたeBookを公開しております！★ FAQ・お問い合わせ｜SCSK Plus サポート for Zabbix 導入をご検討される際、よくあるご質問と回答についてまとめております。 www.scsk.jp ★SCSK Plus サポート for Zabbix★ SCSK Plus サポート for Zabbix 世界で最も人気のあるオープンソース統合監視ツール「Zabbix」の導入構築から運用保守までSCSKが強力にサポートします www.scsk.jp ★YouTubeに、SCSK Zabbixチャンネルを開設しました！★ SCSK Zabbixチャンネル 本チャンネルでは、SCSK株式会社でのZabbixに関するトレンド/事例紹介などを動画にまとめて取り上げております。最新のトピックについては、以下の弊社HPもしくはツイッターアカウントをぜひ参照ください。ツイッターアカウント： www.youtube.com ★X（旧Twitter）に、SCSK Zabbixアカウントを開設しました！★ x.com x.com

こんにちは、SCSKの前田です。 2回目は、LifeKeeperの内部で使われている機能についての用語を説明したいと思います。 1回目の用語説明に関しては以下のリンクからどうぞ！ HAクラスター/LifeKeeper用語説明1 – TechHarmony ハートビートとは？ 「ハートビート」（heart beat）とは、直訳すると「心臓の鼓動」になります。 ITでのハートビートとは、ネットワークで接続されたコンピューターやネットワーク機器の接続が有効であることを確認するために、定期的に送信する信号のことになります。 サーバーの障害や、通信断等により一定間隔以上のお互いの通信が出来ない場合、フェイルオーバーなどの回復処理が実行されます。 LifeKeeperでのハートビートの経路としては、業務サービスが利用する経路や、ハートビート専用の経路、またWindowsに限り共有ディスクを利用した経路が選べます。   システムの環境にあった経路でハートビートを設定することが可能なんだね。 コミュニケーションパスとは？ コミュニケーションパスとは、各クラスタノード間でお互いの状態等の情報をやり取りするための経路になります。 このコミュニケーションパスが障害等で切断された場合、ノードが停止されたものと判断されフェイルオーバーが発生します。 LifeKeeperでは、瞬断や誤検知等による不必要なフェイルオーバーを回避するため、少なくとも2本以上のコミュニケーションパスを推奨しています。 また、先に紹介した「ハートビート」は、このコミュニケーションパスを通して行われています。 共有ディスク構成とは？ 共有ディスク構成とは、HAクラスターを構築する全てのノードから接続される同一のディスクにデータを格納することで、フェールオーバー後も同じデータにアクセスできるようにする方式です。 1つのノードが共有ディスクの特定な領域を利用している場合、別のノードからはアクセスすることが出来ません。 共有ディスクは比較的高額なストレージを必要とすることがデメリットではありますが、次に説明するデータレプリケーション構成と比較してディスクへ速くアクセス出来る事がメリットとなります。 データレプリケーション構成とは？ データレプリケーション構成とは、各ノードに接続されているそれぞれのローカルディスクを利用し、ミラーリングを行う方式です。 新規構築時や障害時を除き、常にローカルディスク同士でデータの同期が行われているため、アクティブノードからスタンバイノードに処理が移動した場合でも、そのままサービスが継続出来るようになっています。 データレプリケーションは、共有ディスクを構成しづらいパブリッククラウドでは一般的な構成となりますが、ディスクの種類やネットワーク環境によってディスク間の通信速度に影響を受ける可能性があります。 高価な共用ディスクを準備することなく構築出来るのがメリットよね。 スプリットブレインとは？ スプリットブレインとは、HAクラスタ環境においてネットワーク障害等により、稼働系と待機系のノード間の通信が途絶えることで、お互いのノードが稼働系としてリソースを開始してしまう状態の事を指します。 このように複数のノードでリソースを開始してしまう事により、本来一つのノード(アプリケーション)からアクセスするはずのディスクに対し、複数のノード(アプリケーション)からアクセスすることになり、データ破損やデータロストを発生させてしまう危険性があります。 LifeKeeperでは、このスプリットブレインを発生させづらくするための機能として「 Quorum/Witness機能 」が準備されています。 スプリットブレインは困るから、Quorum/Witness機能で対応しないといけないな！ まとめ 今回はLifeKeeperの内部で使われている機能の用語について説明して来ましたが、いかがでしたでしょうか？ 少しでもLifeKeeperを身近に感じて頂けたら幸いです。 次回はLifeKeeperのリソースで使われている機能や障害について説明したいと思いますので、お楽しみに！ 詳しい内容をお知りになりたいかたは、以下のバナーからSCSK LifeKeeper公式サイトまで

こんにちは。SCSKの中山です。   1月末のアップデートで、ちょっと面白い機能が追加されました。 「 Autonomous Firewall Insights 」という機能ですが、Product Updateでは「 New AI-Driven Firewall Analysis and Insights 」として紹介されていました。この機能は、Internet Firewallルールを確認し、Catoのベストプラクティスに適合しているかどうかをチェックできるのとAIを使ってテスト用などのルールを識別し、推奨を教えてくれる機能です。 今回はこの機能について、記事を書いてみたいと思います。 確認項目について まずは実際の画面を紹介したいと思います。 Internet FWの画面を開くと、ルールの上に「Autonomous Firewall Insights」の項目があります。（↓の画像の赤枠部分） 普段は閉じた状態になっているので、展開すると以下のような画面が表示されます。 （デフォルトで展開されていないので、実装されたことに気づいていない方も多そうです。。） こんな感じで項目が並んでおります。 青枠の部分がベストプラクティスの適合状況、オレンジの枠がAIの推奨項目となっており、右側にはステータスが表示されてます。   画像だと見にくいかと思いますので、以下に項目と概要を列挙してみました。 項目 概要 Enable Internet Firewall インターネットFWが有効かされているか Block Risky Categories 危険なカテゴリーがブロックされているか Block/Prompt Suspicious Categories 疑わしいカテゴリーがブロックまたはPromptに設定されているか Block Risky Applications 危険なアプリケーションがブロックされているか Match the rule name with the rule action ルール名とアクションが合っているか Define rules with the minimum required access 必要最低限のアクセス権限でルールが記載されているか Block QUIC and GQUIC protocols to enable TLS Inspection TLS Inspectionを有効化するためにQUIC 及び GQUICプロトコルの通信がブロックされているか Cato クラウドで QUIC プロトコルをブロックすべき理由 についてはブログ記事をご確認ください。 Enable RBI traffic to uncategorized and undefined categories uncategorized と undefinedのカテゴリーに対して、Promptの設定がされているか Review Temporary Rule (Powered by AI)  一時的なルールの見直しの推奨 Review Testing Rule (Powered by AI) テスト用のルールの見直しの推奨 Review Expired Rule (Powered by AI) 有効期限切れのルールの見直しの推奨 Review Rules with Future Expiration Date (Powered by AI) 有効期限は過ぎていないものの期限があるルールの見直しの推奨   ベストプラクティスに適合しているかは、セキュリティ上重要な項目です。しかし、実運用の中ではあまり見ることがないかもしれないので、意外と初めて見る方もいるのではないかと思っています。 一番下の4つの”Powered by AI”と書いてある項目が、画像で”AI”としていた項目です。 AIで推奨されているのは、ルールの最適化のために不要なルールの見直しです。   詳細について 先程の画面では、大項目に対してのステータスが表示されていましたが、各項目を展開することができます。展開すると、実際にどのような内容が適用できているか、できていないかの詳細を確認することができます。 ↓はベストプラクティスの「Block Risky Categories」を展開した画面です。 上から3つの「Questionable」「Keyloggers」「Spyware」にはFailedがついているため、これらの3カテゴリーに分類されているサイトにはアクセスできてしまうことが確認できます。反対に、4つ目以降の「Cheating」「Porn」などはPassedとなっているため、きちんとブロックされており、ベストプラクティスに適合していることが確認できます。 何となくまとめて危ないカテゴリー一式をブロックに追加したつもりでも、意外と抜け漏れがあることがあります。本ブログをお読みになった方は、ぜひこの機会に一度確認してみてください！   AIの推奨項目について こちらの項目はAIからの推奨がある場合にFailedになります。こちらは展開すると見直しが推奨されているルール名が表示されます。   AIを使っているため、細かいロジックは分かりませんが、軽く試してみたところ、名前に「test」や「temp」が入っているものは削除推奨に上がっていました。他の項目は試した中では引っかからなかったので、条件がよく分かりませんでした。   ちなみに、推奨に上がっていたルールの設定内容は変えず、ルール名のみ修正してみましたが、推奨に表示されなくなっていました。詳細は分かりませんが、ルール名の影響が大きそうです。。 運用への活かし方 これだけだと「こんな感じで見れるんだー」で終わってしまうので、実際にこの機能を使う場合を考えてみたいと思います。 ベストプラクティスへの適用については、指摘通りに修正することでCatoの推奨に従い、セキュリティを向上させることができます。ただ難しいのは、既に許可している通信を拒否することになるため、必要な通信だった場合、通信ができなくなり業務に影響が出かねません。事前にEventsなどで該当の通信を調べておくことや、事前にテストユーザ等で個別に設定を入れテストしておくと安心かと思います。 AIによる推奨については、tempやtest等の暫定的な設定に対する推奨のため、基本的には推奨通りに改善できるかと思います。しかし、元々test用に作っていたルールが実運用するルールに途中から変わっているというパターンもあるかと思います。今回試せていないので、AIがどこまでそれを識別できるか分からないため、消す前には結局ルールの内容を確認しないといけなさそうです。 また、ベストプラクティスのところでテストした方がいいと書きましたが、テスト時のルールとして名前にtestなどを入れる運用にしておけば、AIがほぼほぼ見抜けるため、消し忘れて実運用に乗ってしまうことを避けられるかもしれません。 まとめ 今回はAutonomous Firewall Insightsという機能紹介をしてみました。 本機能を使うことで、現在運用しているInternet FWのルールがベストプラクティスに沿っているかをチェックすることが可能です。Internet FWはインターネット接続に関する設定なので、ベストプラクティスに沿ってセキュアな状態にしておくことがとても重要になります。 とりあえず、本記事を見てもらった方はCMAよりInternet FWの設定状況について確認するきっかけにしてもらいたいです。

こんにちは、広野です。 以前、以下の記事で Amazon Cognito ユーザーのインポートジョブを作成していましたが、大量のインポートではエラーが発生する問題を抱えていました。本記事では、少し改善したバージョンを紹介したいと思います。   React で Amazon Cognito ユーザインポート画面をつくる [AWS Step Functions Map ステート活用例] Amazon Cognito ユーザインポート画面を React でつくることを題材に、AWS Step Functions Map ステートを活用したユーザ登録処理を紹介します。 blog.usize-tech.com 2022.07.13 前のバージョンで抱えていた課題 AWS サービスに何か命令を実行する場合、それが AWS マネジメントコンソールからにしろ、boto3 からにしろ、必ず AWS が用意した API をコールします。AWS サービスにより、一定時間の間にどれだけの数の API コールを許容するか、制限 (クォータ) があります。 Amazon Cognito ユーザープールにも当然そのクォータがあり、ユーザーの作成は 1秒間あたり 50 回 (RPS) という制限になっています。これを、考えなしに同時に API をコールしてしまうとクォータ超過のエラーが発生します。 Amazon Cognito のクォータ - Amazon Cognito Amazon Cognito ユーザープールのリクエストとリソースのサービス制限とクォータ。 docs.aws.amazon.com 前のバージョンでは、処理が速すぎてクォータを超過してしまうほど API コールをしてしまうので、待ち時間を入れるよう改善する必要がありました。新しいバージョンでは、2024 年の re:Invent で追加された JSONata を使用する AWS Step Functions 構成に変更します。 作り直した構成 全体像は以下です。React アプリに 管理者用の Amazon Cognito ユーザーインポート画面を作成していますが、本記事で着目するのは AWS Step Functions ステートマシンの部分です。 AWS Step Functions ステートマシンを AWS AppSync から呼び出す部分は、以下の記事で紹介しています。 AWS AppSync のリゾルバから AWS Step Functions ステートマシンを呼び出す AWS AppSync のミューテーションでインポートデータを AWS Step Functions ステートマシンに渡す処理を作成しました。 blog.usize-tech.com 2025.01.15   ステートマシンの部分を拡大します。 ステップごとに順を追って解説します。 Map State (入力) インプットは、以下の例のような JSON データです。 { "data": [ { "useremail": "user01@scsktest.com" }, { "useremail": "user02@scsktest.com" }, { "useremail": "user03@scsktest.com" } ], "adminemail": "xxxxxxxx@scsktest.com" } Amazon Cognito ユーザープールに登録したいユーザーのメールアドレスが複数あり、このジョブを実行した管理者のメールアドレスが adminemail として格納されています。管理者メールアドレスはインポート完了後に結果報告メールを送信するのに使用します。 Amazon Cognito ユーザープールの設定は、ユーザー名をメールアドレスにする設定のため、ユーザー名情報はありません。 このデータが Map State に渡されます。これらデータはそのときに input という JSON 項目に格納されます。従って、input.data に格納されている配列単位で、Amazon Cognito ユーザー作成を並列処理させます。JSONata では、以下のように記述します。 Amazon Cognito ユーザー作成の API (AdminCreateUser) の RPS は 50 なのですが、本記事では、作成したユーザーを特定の Cognito グループに所属させる設定を実施します。グループに追加する API (AdminAddUserToGroup) の RPS は 25 のため、安全を取って Map による同時実行数を 20 に設定しています。 Map State 完了時の出力については、章を分離して後ほど説明します。 AdminCreateUser Amazon Cognito ユーザーを 1 件作成する API を AWS Step Functions からダイレクトにコールします。インプットは、以下のような JSON データになります。 { "input": { "useremail": "user01@scsktest.com" }, "inputDetails": { "truncated": false }, "name": "AdminCreateUser" } 作成したいユーザー名は input.useremail になります。以下のように、引数の設定に入力します。作成時のパラメータは要件に応じて適宜変更する必要があります。 エラー処理の設定を追加します。それを入れないと、何らかのエラーが発生した時点でステートマシン全体がエラーで失敗してしまいます。Map 処理が途中で終了してしまうと、どのインプットデータをどこまで処理したのかがわかりにくくなってしまうので、本記事の設計では Map State 内でエラーが発生してもすべてのインプットデータを必ず処理するようにし、それぞれの結果を集計して確認できるようにします。 キャッチャーを 1 つ作成し、Errors には States.ALL を選択します。Fallback state には Error と設定しています。これはエラー発生時に進む次のステップです。後ほど説明します。 出力は、最終的に処理が成功、失敗に関わらず同じフォーマットで集計したいので、以下の考えで統一したフォーマットにします。 useremail: 作成しようとしたユーザーのメールアドレス status: 処理結果 (エラー時は failed 固定) message: エラーメッセージ useremail にはインプットから取得した値を格納します。message には、API が返してきた結果から取得します。多くの API は、$states.errorOutput.Cause にエラーメッセージを残すので、それを取得します。API によってはデータ構造が異なるかもしれないので都度確認は必要です。   Step Functions での JSONata を使用したデータの変換 - AWS Step Functions JSONPath と JSONata では、データを状態から状態に変換します。 docs.aws.amazon.com AdminAddUserToGroup AdminAddUserToGroup は、AdminCreateUser が成功し、そのユーザーが作成された後の後続処理です。インプットは、以下のように input に AdminCreateUser の結果を無加工で受け取るようにしています。 { "input": { "User": { "Attributes": [ { "Name": "email", "Value": "user01@scsktest.com" }, { "Name": "email_verified", "Value": "true" }, { "Name": "sub", "Value": "97a4ca78-1061-70ba-1b7f-xxxxxxxxxxxx" } ], "Enabled": true, "UserCreateDate": "2025-04-14T14:54:07.135Z", "UserLastModifiedDate": "2025-04-14T14:54:07.135Z", "UserStatus": "FORCE_CHANGE_PASSWORD", "Username": "97a4ca78-1061-70ba-1b7f-xxxxxxxxxxxx" } }, "inputDetails": { "truncated": false }, "name": "AdminAddUserToGroup" } このインプットから、API の引数を以下のように指定します。グループ名、Amazon Cognito ユーザープール ID は固定で指定しています。Username は、インプットから取得していますが、ここでは自動生成された sub と呼ばれる UUID 形式のユーザー名を指定していますが、おそらくメールアドレスでも問題ないです。 成功時の出力は、前述エラー処理のところで決めたフォーマットと合わせたいので、以下のように明示的に設定します。useremail はインプットから取得するようにしようとすると、以下のような記述になります。status は、成功なので succeeded 固定にし、messege はエラーがないので “-” 固定にしました。 さて、このステップでも何らかのエラーが発生したときのためにエラー処理を入れておきます。この記述は、AdminCreateUser のときと全く同じ考え方ですが、useremail がこのステップのインプットから取得する場合はデータ構造が異なりますので、その部分だけが異なっています。 Success/Error これらのステップは、1 秒待ちのステップです。先行ステップで実行した API に RPS という秒単位の実行数制限があるため、後続ステップに待ち時間をはさんでいます。細かい話ですが、これを AWS Lambda 関数内に入れてしまうと待ち時間も課金対象になってしまうため、良くないプラクティスになります。AWS Step Functions では待ち時間には課金されません。 先行ステップの成功時の Success、失敗時の Error は設定が同じです。ただ、名前を変えてジョブフローの見た目で成功か失敗かをわかりやすくしたいために明示的に分けました。統合してもかまいません。 設定はシンプルに 1 秒待ちを入れているだけです。 Map State (出力) ここまでで、Map State の中身は説明しました。全てのインプットを処理した後、結果が集計されます。 $states.result に結果が格納されるのですが、そこには管理者のメールアドレスがありません。本記事の設計では、ステートマシンのインプットに入っていた adminemail のメールアドレスに結果通知メールを送りたいので、後続ステップにインプットから引用して adminemail が入るように設定します。また、本記事ではまったく主要な話ではないのですが jobtype というフラグをここで追加して後続に渡しています。 後続でどのようなインプットになるかは、次の章で説明します。 SendResult ここでは、先行ステップ (Map State) から受け取った結果 (JSON) を CSV に変換し、Amazon S3 バケットに保存、署名付き URL を生成して送付先管理者メールアドレスに送信します。CSV 変換をサードパーティの Python モジュール pandas を使用しているので、AWS Lambda 関数で作成しました。 インプットの例は以下のデータになります。 { "input": { "adminemail": "xxxxxxxx@scsktest.com", "result": [ { "useremail": "user01@scsktest.com", "status": "succeeded", "message": "-" }, { "useremail": "user02@scsktest.com", "status": "succeeded", "message": "-" }, { "useremail": "user03@scsktest.com", "status": "failed", "message": "User account already exists (Service: CognitoIdentityProvider, Status Code: 400, Request ID: cd112c36-4a54-4706-b2b0-ac144791c2f9) (SDK Attempt Count: 1)" } ], "jobtype": "import" }, "inputDetails": { "truncated": false }, "name": "SendResult" } AWS Lambda 関数には、input 配下のデータを渡します。以下のように引数を設定します。Lambda 関数の関連付けは ARN で行います。出力はデフォルトです。   AWS Lambda 関数は以下です。jobtype という引数が import か否かによって、メール送信文章が変わるようになっています。※本記事では重要ではありません。 import json import pandas as pd import datetime import boto3 s3 = boto3.resource('s3') client = boto3.client('s3') ses = boto3.client('ses',region_name='ap-northeast-1') def datetimeconverter(o): if isinstance(o, datetime.datetime): return str(o) def lambda_handler(event, context): try: ADMINEMAIL = event['adminemail'] jobtype = event['jobtype'] jobname = 'インポート' if event['jobtype'] == 'import' else '一括削除' df = pd.DataFrame(event['result']) # Set the duration the presigned URL is valid for expiredinsec = 129600 # 129600 seconds = 36 hours expdelta = datetime.timedelta(seconds=expiredinsec) jstdelta = datetime.timedelta(hours=9) JST = datetime.timezone(jstdelta, 'JST') dtnow = datetime.datetime.now(JST) dtexp = dtnow + expdelta nowdt = dtnow.strftime('%Y/%m/%d %H:%M - %Z') expdt = dtexp.strftime('%Y/%m/%d %H:%M - %Z') fileNameDateTime = dtnow.strftime('%Y%m%d%H%M%S') tempFileName = '/tmp/' + jobtype + '_result_' + fileNameDateTime + '.csv' outputBucket = 'output_bucket' outputS3Key = 'cognito' + jobtype + 'log/' + jobtype + '_result_' + fileNameDateTime + '.csv' # JSON to CSV df.to_csv(tempFileName) # upload CSV into S3 s3.meta.client.upload_file(tempFileName, outputBucket, outputS3Key) # generate presigned URL presigned_url = client.generate_presigned_url( ClientMethod = 'get_object', Params = { 'Bucket': outputBucket, 'Key': outputS3Key }, ExpiresIn = expiredinsec, HttpMethod = 'GET' ) # send email BODY_TEXT = ('あなたがリクエストしたユーザ' + jobname + 'ジョブが完了しました。\n' '結果は以下のURLからダウンロードできます。\n\n' 'ダウンロードURL:\n<' + presigned_url + '>\n\n' 'ダウンロード有効期限:\n' + expdt +'\n\n' ) res = ses.send_email( Destination={ 'ToAddresses': [ ADMINEMAIL ] }, Message={ 'Body': { 'Text': { 'Charset': 'UTF-8', 'Data': BODY_TEXT } }, 'Subject': { 'Charset': 'UTF-8', 'Data': 'ユーザ' + jobname + '結果 [' + nowdt + ']' } }, Source='xxxxxxx@xxxxxx.xxx' ) except Exception as e: print(e) return { "result": str(e) } else: return { "result": res } SendResult ステップから受け取ったデータは、event に格納されます。 結果を通知したい管理者のメールアドレスは、event[’adminemail’] で表現できます。 インポート結果は event[‘result’] で表現できます。 ただし、このデータは JSON 形式です。管理者が見やすい形式にしたいので、CSV に変換します。そのために pandas という外部ライブラリを使ってデータ変換しますが、前提として pandas モジュールが Lambda Layer として登録されている必要があります。 CSV 形式に変換したデータは、一旦 Lambda 関数の一時ストレージ /tmp に CSV ファイルとして保存します。それを指定した Amazon S3 バケットにアップロードします。 CSV ファイルを Amazon S3 バケットにアップロードしただけでは管理者は見ることができないので、一定期間 (36 時間) だけ見られるように Amazon S3 署名付き URL を生成します。生成した URL を通知メール本文に埋め込んで、Amazon SES 経由で管理者メールアドレスにメール送信します。 pandas を使用するための Lambda レイヤー作成は以下の記事が参考になります。 AWS Lambda (Python 3.12) で使用可能な pandas の Lambda Layer を準備する データ分析や加工でよく使われるライブラリに、pandas があると思います。本記事では、AWS Lambda (Python 3.12) で動作する pandas の Lambda Layer を準備する手順を紹介します。 blog.usize-tech.com 2022.06.07 この Lambda 関数が実行されると、以下のようなメールが送信されます。 ダウンロードした CSV ファイルは以下のようになります。   参考: AWS CloudFormation テンプレート 紹介した構成一式をデプロイする AWS CloudFormation テンプレートを貼り付けておきます。IAM ロールなど細かい設定まで説明できていないので、詳細はこちらを見て頂けたらと思います。ただし、IAM ロールは雑にマネージドのものを多用しているので、必要に応じて最小権限化する必要があります。ご注意ください。 AWSTemplateFormatVersion: 2010-09-09 Description: The CloudFormation template that creates Lambda functions, Step Functions workflows, and relevant IAM roles. # ------------------------------------------------------------# # Input Parameters # ------------------------------------------------------------# Parameters: SubName: Type: String Description: System sub name of example. (e.g. prod or test) Default: test MaxLength: 10 MinLength: 1 FeedbackSenderEmail1: Type: String Description: E-mail address that sends emails. (e.g. xxx@xxx.xx) Default: xxx@xxx.xx MaxLength: 100 MinLength: 5 AllowedPattern: "[^\\s@]+@[^\\s@]+\\.[^\\s@]+" S3BucketNameSdk: Type: String Description: S3 bucket name in which you uploaded sdks for Lambda Layers. (e.g. example-bucket) Default: example-bucket MaxLength: 50 MinLength: 1 S3KeyPandasSdk: Type: String Description: S3 key of pandas.zip. Fill the exact key name if you renamed. (e.g. sdk/Python3.13/pandas223.zip) Default: sdk/Python3.13/pandas223.zip MaxLength: 50 MinLength: 1 Resources: # ------------------------------------------------------------# # Lambda S3 and SES Invocation Role for Sfn (IAM) # ------------------------------------------------------------# LambdaS3SesInSfnRole: Type: AWS::IAM::Role Properties: RoleName: !Sub example-LambdaS3SesInSfnRole-${SubName} Description: This role allows Lambda functions to invoke S3 and SES. AssumeRolePolicyDocument: Version: 2012-10-17 Statement: - Effect: Allow Principal: Service: - lambda.amazonaws.com Action: - sts:AssumeRole Path: / Policies: - PolicyName: !Sub example-LambdaS3SesInSfnPolicy-${SubName} PolicyDocument: Version: "2012-10-17" Statement: - Effect: Allow Resource: - "*" Action: - "ses:SendEmail" ManagedPolicyArns: - arn:aws:iam::aws:policy/AmazonS3FullAccess - arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole - arn:aws:iam::aws:policy/AWSXRayDaemonWriteAccess # ------------------------------------------------------------# # State Machine Execution Role (IAM) # ------------------------------------------------------------# StateMachineExecutionRole: Type: AWS::IAM::Role Properties: RoleName: !Sub example-StateMachineExecutionRole-${SubName} Description: This role allows State Machines to call specified AWS resources. AssumeRolePolicyDocument: Version: 2012-10-17 Statement: - Effect: Allow Principal: Service: states.amazonaws.com Action: - sts:AssumeRole Path: /service-role/ ManagedPolicyArns: - arn:aws:iam::aws:policy/service-role/AWSLambdaRole - arn:aws:iam::aws:policy/AmazonCognitoPowerUser - arn:aws:iam::aws:policy/CloudWatchLogsFullAccess - arn:aws:iam::aws:policy/AWSXrayWriteOnlyAccess # ------------------------------------------------------------# # State Machine Execution LogGroup (CloudWatch Logs) # ------------------------------------------------------------# LogGroupStateMachineImportCognitoUsers: Type: AWS::Logs::LogGroup Properties: LogGroupName: !Sub /aws/vendedlogs/states/example-ImportCognitoUsers-${SubName} RetentionInDays: 365 Tags: - Key: Cost Value: !Sub example-${SubName} # ------------------------------------------------------------# # S3 # ------------------------------------------------------------# S3BucketLogs: Type: AWS::S3::Bucket Properties: BucketName: !Sub example-${SubName}-logs OwnershipControls: Rules: - ObjectOwnership: BucketOwnerPreferred PublicAccessBlockConfiguration: BlockPublicAcls: true BlockPublicPolicy: true IgnorePublicAcls: true RestrictPublicBuckets: true Tags: - Key: Cost Value: !Sub example-${SubName} # ------------------------------------------------------------# # Lambda # ------------------------------------------------------------# LambdaAdminSendResultCognitoUsersSfn: Type: AWS::Lambda::Function Properties: FunctionName: !Sub example-Admin-SendResultCognitoUsersSfn-${SubName} Description: Lambda Function to send the Step Functions job result to maintain Cognito users. Runtime: python3.13 Timeout: 180 MemorySize: 256 Role: !GetAtt LambdaS3SesInSfnRole.Arn Handler: index.lambda_handler Layers: - !Ref LambdaLayerPandas223 Tags: - Key: Cost Value: !Sub example-${SubName} Code: ZipFile: !Sub | import json import pandas as pd import datetime import boto3 s3 = boto3.resource('s3') client = boto3.client('s3') ses = boto3.client('ses',region_name='${AWS::Region}') def datetimeconverter(o): if isinstance(o, datetime.datetime): return str(o) def lambda_handler(event, context): try: ADMINEMAIL = event['adminemail'] jobtype = event['jobtype'] jobname = 'インポート' if event['jobtype'] == 'import' else '一括削除' df = pd.DataFrame(event['result']) # Set the duration the presigned URL is valid for expiredinsec = 129600 # 129600 seconds = 36 hours expdelta = datetime.timedelta(seconds=expiredinsec) jstdelta = datetime.timedelta(hours=9) JST = datetime.timezone(jstdelta, 'JST') dtnow = datetime.datetime.now(JST) dtexp = dtnow + expdelta nowdt = dtnow.strftime('%Y/%m/%d %H:%M - %Z') expdt = dtexp.strftime('%Y/%m/%d %H:%M - %Z') fileNameDateTime = dtnow.strftime('%Y%m%d%H%M%S') tempFileName = '/tmp/' + jobtype + '_result_' + fileNameDateTime + '.csv' outputBucket = 'example-${SubName}-logs' outputS3Key = 'cognito' + jobtype + 'log/' + jobtype + '_result_' + fileNameDateTime + '.csv' # JSON to CSV df.to_csv(tempFileName) # upload CSV into S3 s3.meta.client.upload_file(tempFileName, outputBucket, outputS3Key) # generate presigned URL presigned_url = client.generate_presigned_url( ClientMethod = 'get_object', Params = { 'Bucket': outputBucket, 'Key': outputS3Key }, ExpiresIn = expiredinsec, HttpMethod = 'GET' ) # send email BODY_TEXT = ('あなたがリクエストしたユーザ' + jobname + 'ジョブが完了しました。\n' '結果は以下のURLからダウンロードできます。\n\n' 'ダウンロードURL:\n<' + presigned_url + '>\n\n' 'ダウンロード有効期限:\n' + expdt +'\n\n' ) res = ses.send_email( Destination={ 'ToAddresses': [ ADMINEMAIL ] }, Message={ 'Body': { 'Text': { 'Charset': 'UTF-8', 'Data': BODY_TEXT } }, 'Subject': { 'Charset': 'UTF-8', 'Data': 'ユーザ' + jobname + '結果 [' + nowdt + ']' } }, Source='${FeedbackSenderEmail1}' ) except Exception as e: print(e) return { "result": str(e) } else: return { "result": res } # ------------------------------------------------------------# # Lambda Layer # ------------------------------------------------------------# LambdaLayerPandas223: Type: AWS::Lambda::LayerVersion Properties: LayerName: !Sub example-${SubName}-pandas223 Description: !Sub Pandas 2.2.3 for Python to load in example-${SubName} CompatibleRuntimes: - python3.13 Content: S3Bucket: !Sub ${S3BucketNameSdk} S3Key: !Sub ${S3KeyPandasSdk} LicenseInfo: BSD-3-Clause # ------------------------------------------------------------# # Step Functions # ------------------------------------------------------------# StateMachineImportCognitoUsers: Type: AWS::StepFunctions::StateMachine Properties: StateMachineName: !Sub example-ImportCognitoUsers-${SubName} StateMachineType: STANDARD DefinitionSubstitutions: DSSubName: !Sub ${SubName} DSCognitoUserPoolId: Fn::ImportValue: !Sub CognitoUserPoolID-example-${SubName} DSTemporaryPassword: Passw0rd DSLambdaAdminSendResultCognitoUsersSfnArn: !GetAtt LambdaAdminSendResultCognitoUsersSfn.Arn DefinitionString: |- { "QueryLanguage": "JSONata", "Comment": "State machine to import example users into Cognito User Pool for example-${DSSubName}", "StartAt": "Map", "States": { "Map": { "Type": "Map", "ItemProcessor": { "ProcessorConfig": { "Mode": "INLINE" }, "StartAt": "AdminCreateUser", "States": { "AdminCreateUser": { "Type": "Task", "Arguments": { "UserPoolId": "${DSCognitoUserPoolId}", "Username": "{% $states.input.useremail %}", "TemporaryPassword": "${DSTemporaryPassword}", "UserAttributes": [ { "Name": "email", "Value": "{% $states.input.useremail %}" }, { "Name": "email_verified", "Value": "true" } ], "MessageAction": "SUPPRESS", "DesiredDeliveryMediums": [ "EMAIL" ] }, "Resource": "arn:aws:states:::aws-sdk:cognitoidentityprovider:adminCreateUser", "Next": "AdminAddUserToGroup", "TimeoutSeconds": 3, "Catch": [ { "ErrorEquals": [ "States.ALL" ], "Next": "Error", "Output": { "useremail": "{% $states.input.useremail %}", "status": "failed", "message": "{% $states.errorOutput.Cause %}" } } ] }, "AdminAddUserToGroup": { "Type": "Task", "Arguments": { "GroupName": "BASIC", "UserPoolId": "${DSCognitoUserPoolId}", "Username": "{% $states.input.User.Username %}" }, "Resource": "arn:aws:states:::aws-sdk:cognitoidentityprovider:adminAddUserToGroup", "Next": "Success", "Catch": [ { "ErrorEquals": [ "States.ALL" ], "Next": "Error", "Output": { "useremail": "{% $states.input.User.Attributes[0].Value %}", "status": "failed", "message": "{% $states.errorOutput.Cause %}" } } ], "TimeoutSeconds": 3, "Output": { "useremail": "{% $states.input.User.Attributes[0].Value %}", "status": "succeeded", "message": "-" } }, "Error": { "Type": "Wait", "Seconds": 1, "End": true, "Comment": "This wait is for avoiding the Cognito API error due to exceeding the rps quota." }, "Success": { "Type": "Wait", "Seconds": 1, "End": true, "Comment": "This wait is for avoiding the Cognito API error due to exceeding the rps quota." } } }, "MaxConcurrency": 20, "Items": "{% $states.input.data %}", "Next": "SendResult", "Output": { "adminemail": "{% $states.input.adminemail %}", "result": "{% $states.result %}", "jobtype": "import" } }, "SendResult": { "Type": "Task", "Resource": "arn:aws:states:::lambda:invoke", "Output": "{% $states.result.Payload %}", "Arguments": { "FunctionName": "${DSLambdaAdminSendResultCognitoUsersSfnArn}", "Payload": "{% $states.input %}" }, "Retry": [ { "ErrorEquals": [ "Lambda.ServiceException", "Lambda.AWSLambdaException", "Lambda.SdkClientException", "Lambda.TooManyRequestsException" ], "IntervalSeconds": 1, "MaxAttempts": 3, "BackoffRate": 2, "JitterStrategy": "FULL" } ], "End": true, "Comment": "Invoke the Lambda function to send the result of this state machine via email.", "TimeoutSeconds": 210 } }, "TimeoutSeconds": 900 } LoggingConfiguration: Destinations: - CloudWatchLogsLogGroup: LogGroupArn: !GetAtt LogGroupStateMachineImportCognitoUsers.Arn IncludeExecutionData: true Level: ERROR RoleArn: !GetAtt StateMachineExecutionRole.Arn TracingConfiguration: Enabled: true Tags: - Key: Cost Value: !Sub example-${SubName} まとめ いかがでしたでしょうか？ 本記事で紹介した構成はまだまだ不完全でして、このステートマシンを複数同時実行した場合はクォータを超過してしまいます。ですので、複数呼び出す可能性があるジョブを作成するときは SQS も使用してキューイングする必要がありそうです。しかし、それを実装したところで、このステートマシンを使用せずにユーザー作成をする別の作業とタイミングが重なってしまうとキューイングでも防ぎようがありません。完全な制御は難しいのですが、それをわかった上でやるべきことは、今回のように成功、失敗の結果を把握できるようにすることや、リトライ、通知などの仕組みを活用して、完璧ではないけれどより信頼性の高い仕組みを構築することだろう、と考えております。 本記事が皆様のお役に立てれば幸いです。

みなさんこんにちは。SCSK 鎌田です。 今回は、少し前に機能追加された、Copilotを使ってみた感想と、その使い方について解説します。 リリースされたばかりのこのAIアシスタントは、クラウドセキュリティの管理を効率化してくれるツールです。 すでにPrisma Cloudを利用中の方も、これから導入を検討している方も、ぜひ参考にしてください。 Prisma Cloud Copilotとは？ Prisma Cloud Copilot は、Prisma Cloudプラットフォームに統合された生成AIベースのセキュリティアシスタントです。自然言語処理（NLP）を駆使し、ユーザーのテキスト入力を理解して以下のような機能を提供します。 自然言語クエリ : 「公開されているS3バケットを教えて」といった自然な質問で、リソースの状況を即座に把握。 RQL変換 : 自然言語をPrisma CloudのResource Query Language（RQL）に自動変換し、複雑な検索を簡単に実行。 可視化 : 検索結果を表、グラフ、テキストでわかりやすく表示。 インシデント対応支援 : 異常検出や修復手順の提案を迅速に行う。 他のPrisma Cloudモジュールとの統合 : CSPM（Cloud Security Posture Management）やCWP（Cloud Workload Protection）と連携し、包括的なセキュリティ管理を実現。 Copilotへの期待 私自身、Prisma Cloudを使ってきて、ダッシュボードやRQLの威力は実感していますが、例えばRQLで検索するにもRQLを作成するところから始めることになり、検索条件が増えると構文も複雑になり作成できないなんてことも。「もっと直感的に、もっと手軽に早く結果を得たい」ということが多々ありました。 それを可能にしてくれそうなのがCopilotで、RQLを書き慣れていない新人エンジニアでも、自然言語で質問すればCopilotが適切なクエリを生成してくれるので、技術習得のハードルもかなり下がるので、私の期待は爆上がりです。 そういった期待を持って、実際にどこまで直感的に操作できるのか試してみました。 Copilotのセットアップ CopilotはEnterprise Editionに標準搭載されており、特別なインストールや追加設定は不要でした。 Prisma Cloudのダッシュボードにログインすると、画面右上に星のような十字のような「Copilot」アイコンが表示されます。 クリックすると、ChatGPTなどを触ってる人からすると見慣れた雰囲気のチャット形式のインターフェースが現れ、すぐに利用可能です。   実際に使ってみた 試しに、サンプルとしてプリセットされている「Show me S3 Buckets exposed internet.」をクリックしてみます。 そうすると、10秒程度Copilotが思考した後に、下記画像のように外部公開されているS3バケットがグラフィカルに表示されました。この時点でなかなかよさそうな予感がします！ ※バケット名をマスクしています。   上記画像の下のほうにある「Generated RQL」をクリックすると下記画像のように展開され、そこにはRQLが記載されています。 自然言語で「Show me S3 Buckets exposed internet.」と要件を入力すると、裏でCopilotがその要件にあわせたRQLを作成し、作成したクエリの結果を画面表示するという動作をしているということですね。 つまり、 ユーザーの要件・やりたいことをいかにCopilotが齟齬なくRQLに落とせるか が重要なポイントになりそうです。この辺りは、実際にある程度触ってみて勘所をおさえる必要がありそうです。 もう１つ、「Explain this graph」ボタンが気になったのでクリックすると、下記の説明文が表示されました。 ※bucket-1~4はマスクのために私が手で修正していて、実際には具体的なバケット名が記載されます。 Summary: The risk analysis reveals that the assets “bucket-1”, “backet-2”, “backet-3”, and “backet-4”, along with 16 other unnamed assets, have a finding labeled as “AWS S3 Buckets Block public access setting disabled.” This indicates that the “Block public access” setting is not enabled on these S3 buckets, potentially exposing sensitive data to unauthorized access. Critical Risk: The critical risk is that the assets are exposed to the internet due to the disabled “Block public access” setting on their S3 buckets. This allows attackers to potentially access sensitive data stored within these buckets, leading to data breaches and potential financial or reputational damage. Exploitation Steps: The potential attack on the assets may involve an attacker scanning the internet for open S3 buckets with the “Block public access” setting disabled. Once identified, the attacker could exploit this vulnerability by directly accessing the bucket’s contents, potentially downloading sensitive data or even modifying or deleting files. 英語でしか表示できなかったのが残念ですが、以下のような説明文が表示されています。 Summary 検出されたS3バケットとそのリスク要因の概要 Critical Risk 公開設定によるデータ漏えいリスク Exploitation Steps 攻撃者がどのようにバケットを悪用するかの手順 例えば管理者向けにはレポートや報告資料の作成時にそのまま使えそうですし、システム担当者向けには対応するしないや優先度を検討する際に使える情報になりそうです。 クラウドのセキュリティ対策を行うにあたり、外部公開されたリソースを把握することは重要ですが手動での対応は手間、、、それを数分でPrisma Cloudに繋いだ全環境に対して実施できそうなのは、なかなか好印象です。 Copilotの使い勝手 こちらのやりたいことをCopilotがどこまで認識してくれるかが重要とお伝えした通り、チャット形式で何をどこまでできるかが使い勝手に大きく影響してきます。そこで、私が実際に試してみたことをいくつか共有します。 日本語のサポート このブログの読者は日本の方だと思うので、まずこれが気になると思います。結論としては、日本語はサポートされています。 さきほど英語で、「インターネット公開されているS3バケットを表示して」と命令したのを、そのまま日本語で入れてみたところ、以下のように英語で命令した場合と同じ結果になりました。 ※バケット名をマスクしています。 ただ、さすがにちょっと言い方が冷たかったかなと思い、「インターネット公開されているS3バケットを表示 してください。 」と丁寧に命令してみると、さきほどと違った結果が返ってきました。CoplilotがRQLを作成してくれて、リンクをクリックすると調査画面に飛んでそのRQLクエリで検出される結果が確認できるという動作になりました。 RQLの内容も変わっていて、さっきとはまた違う検出結果を返してきてもいるので、この辺りはまだ使い勝手が悪く注意して利用しないといけなそうです。 雑談への応対 どの範囲の話題にまで付き合ってくれるのかも気になったので、いくつか英語で問いかけてみました。 結果として、全く関係のないことには分からないと回答するよう教育されてそうですが、全てNGというわけでもなく、CNAPPのような関係のある話題には回答してくれたりします。この辺りももう少し使ってみると分かってくることがあると思いますが、一般的なことへの確認や雑談をしたい場合は、素直にChatGPTなどスタンダードなものを利用したほうがよいです。 関連するPrisma Cloudドキュメントへのガイド 個人的にかなり嬉しい結果になったのが、Prisma Cloudの仕様に関する問いに回答してくれたところです。今まで、Prisma Cloudの仕様を確認するには、公開されている大量のドキュメントから記載されている場所を探し当てる必要があり、この時間がかなり無駄になっていました。今回、ためしにユーザー作成手順やアラートルールの仕様について聞いてみたところ、簡単な説明にあわせて、関連リンクとして関連するドキュメントをガイドしてくれました。これからは、分からないことがあればとりあえずCopilotに聞いてみることになりそうです。 まとめ まだ少し触ってみた程度ですので、今後評価は変わる可能性がある前提で現時点での評価としては、CopilotはPrisma Cloudのサービス仕様に詳しいチャットボットという印象です。新しく何かやりたくなった時や、運用中に不明点が出てきた場合などに、今までは自分で調べて検証していた部分の一部をCopilotが担ってくれるのではないかと期待しています。 きちんと対話できれば、RQLの作成やリスクの修正に対する提案もしてくれそうですので、踏み込んだ利用ができるようになればまた評価は変わると思いますし、何よりこれから更に機能が追加されていくはずなので、Prisma Cloudの利用高度化が期待できる素晴らしい機能だと思います。CWPやDSPMと連動するともっと面白いこともできそうな予感もあります。 みなさんにも可能ならまずは触ってみてもらいたいですし、どんどん使って面白いアイデアを出し合っていければ、今までよりもっと楽をして高度なセキュリティ対策を実現できそうな、そういう期待が持てる楽しみな機能だと思います。   最後に、当社ではPrisma Cloudを用いたマネージドサービスを提供しているので紹介させてもらいます。 ＝＝＝ 【CSPMマネージドサービス SmartOneCloudSecurity】 SmartOneCloudSecurityは、Prisma Cloud を用いたCSPMマネージドサービスです。Prisma Cloud の導入から設定変更まで、弊社技術担当者がお客様のCSPM対策をサポートします。CSPMの導入を検討中の方はもちろん、Prisma Cloud を利用中だけど機能や運用面でもっと上手に活用したい、というような課題をお持ちな方は、お気軽に下記URLからお問い合わせください。Prisma Cloud のPoCの相談も受けています。 New!! CWPPの導入サポートも始めました！ Smart One Cloud Security® パブリッククラウドのセキュリティ設定を診断/監視するマネージドCSPMサービスです。Palo Alto Networks社Prisma Cloud（CSPM機能）を使い易く、簡単に導入いただけます。 www.scsk.jp

CIEMとは CIEM(Cloud Infrastructure Entitlement Management)とは、日本語でクラウドインフラストラクチャ権限管理を意味し、クラウド環境のIDと権限を管理するプロセスを指します。CIEMの目的はクラウド環境とマルチクラウド環境に存在するアクセス権限を把握し、 必要以上の権限がもたらすリスクを特定・軽減すること です。 例えば、クラウド環境にて検証目的でリソースを構築するときに、検証を早く完了させたいがために、リソースやユーザへ付与する権限を最小権限とせずに、ベンダー提供権限や管理者権限など、必要以上の権限を付与するケースを想定してみてください。検証完了後にその権限を削除すれば良いのですが、権限を外さずに放置してしまうとその権限を不正利用されてしまうリスクがあります。 CIEMをクラウドに適用することで、そういった必要以上に権限が付与されているリソースを特定し、リスクを軽減することでクラウドのインフラとリソースに最小権限の原則を適用できます。 本記事ではCIEMとPrisma CloudのCIEM機能であるIAMセキュリティについて解説します。 IAMセキュリティを利用することで、パブリッククラウドのインフラとリソースに最小権限の原則を適用できるようになります。   IAMセキュリティとは IAMセキュリティはPrisma CloudのCIEM機能になります。IAMセキュリティは以下3つの主要な特徴を持っています。 権限の可視性向上 ：クラウドアカウント内のリソースで利用できる権限の可視性を向上させます。 すぐに利用できるベストプラクティスポリシー ：すぐに使用できるベストプラクティスポリシーを利用して、過剰な権限や未使用の権限といった権限周りのリスク発生を監視できます。 リスクを対処するアクションの提示 ：特定した権限のリスクに対して、その権限を調整するためのアクションを提示してくれるので、リスクへ対応しやすくなります。 IAMセキュリティでは、権限の可視性向上・ベストプラクティスポリシーによる監視によって権限周りのリスクを特定し、提示されたアクションを実行することで権限を調整し、リスクを軽減していくのが大まかな使い方となります。 IAMセキュリティを有効化した後に、上記3つの特徴を実際の画面をお見せしながら説明します。   Prisma CloudでのIAMセキュリティの有効化 まず、IAMセキュリティを有効化する手順を説明します。 IAMセキュリティを有効化すると全体の消費クレジット数は1.25倍になります。 有効化に伴い、現状の購入クレジット数を超過しないようにご注意ください。        消費クレジット数の最新情報は以下でご確認ください。 Prisma Cloud Enterprise Edition Credit Guide – Palo Alto Networks Prisma Cloudログイン後のコンソール画面にて、右上の顔画像をクリックし、「View Subscriptions」をクリックします。 以下画面にて、IAM Securityの「Subscribe」をクリックします。 以下画面が表示されますので、「Agree and Submit」をクリックするとIAMセキュリティが有効化されます。 IAMセキュリティの3つの特徴について これでIAMセキュリティが有効化されたので、IAMセキュリティの3つの特徴について実際の画面をお見せしながら説明します。 権限の可視性向上 IAMセキュリティがクラウドアカウント内のリソースで利用できる権限の可視性を向上することで、必要以上に権限が付与されているリソースを 特定しやすくなります 。 それでは実際に、AWS管理ポリシーの”AdministratorAccess”(管理者権限相当）を持つリソースを可視化し、過剰な権限を持つリソースを特定してみます。 Prisma Cloudへログインし、「Investigate」をクリック、RQLというPrisma Cloud独自言語で”AdministratorAccess”を持つリソースを検索します。本記事では、以下RQL文で検索を行っています。 config from iam where source.cloud.type = ‘AWS’ and grantedby.cloud.policy.name = ‘AdministratorAccess’ 検索すると、上記のような図が表示されます。各列を左列から説明すると、以下の通りです。 Sources：「Granters」列のリソースによってアクセス許可が付与されたAWSサービス名が表示 Granters：”AdministratorAccess”のポリシーが付与されたリソースのグループ Destination：「Sources」列のリソースがアクションを起こせるAWSサービス名が表示 図を見ると、「Sources」列のEC2とLambdaが”AdministratorAccess”のポリシーを利用して、「Destination」列の392種類のAWSサービスに対して何かしら、アクションできることが分かります。EC2、Lambdaに過剰な権限が付与されてることが分かったので、このうちのLambdaをさらに分析します。 まず、「View Mode」を「Graph」から「Table」に変更し、図だった表示形式を表形式に変更します。 「Source」列がLambda functionである行を探します。 このLambdaが”AdministratorAccess”のポリシーを利用できることを意味します。さらにその行の「Granted By Entity」列に記載されているロールが”AdministratorAccess”のポリシーを持った、このLambdaに付与されているロールとなります。このロールをさらに詳しく調査するため、ロールをクリックします。 クリックすると、上記のようにロールに関する情報が表示されます。 さらに詳細な情報を調べるため、右上の「View JSON」をクリックします。 クリックすると、このロールにアタッチされているポリシーを確認することができ、実際に”AdministratorAccess”のポリシーが付与されていることが分かります。 権限の可視性向上によって、過剰な権限が付与されているリソースやロールを特定することができました。   すぐに利用できるベストプラクティスポリシー Prisma CloudのIAMセキュリティ機能では、過剰な権限や未使用の権限を監視するために、すぐに使用できるデフォルトのベストプラクティスポリシーを提供してくれます。IAMセキュリティで提供されるポリシーは2025年4月現在、約254ポリシーあります。 Prisma Cloudでは特定のポリシーを選択して、パブリッククラウドを監視し、ポリシー違反リソースがあればアラートを発砲して、メール通知を行う機能が標準で提供されています。IAMセキュリティで提供されるポリシーでパブリッククラウドを監視することで過剰な権限や未使用の権限が発生したことをスピーディーに気づくことができます。   リスクを対処するアクションの提示 Prisma CloudのIAMセキュリティ機能では、可視性やガバナンスによって特定した過剰な権限や未使用の権限に対して、権限を調整するようなアクションが提示され、そのアクションを実行することで リスクを軽減できます 。どのように権限を調整するかというと、CLIコマンドが発行されるため、そのコマンドをパブリッククラウドで手動実行して、過剰な権限を調整します。 実際に、権限を調整するためのCLIコマンドを発行してみます。 「Alerts」＞「Overview」をクリックして、アラートを表示させます。 フィルタは「Policy Type：IAM」、「Remediate：Yes」を指定して、IAMセキュリティのポリシーで検知したアラートの内、CLIコマンドを発行できるアラートを表示します。 今回は「IAM書き込み権限が付与されたLambda関数」というポリシーを例に、本ポリシーで検知しているリソースを選択し、「Remediate」をクリックします。 そうすると以下画面が表示され、CLIコマンドが提示されます。 コマンドをコピーいただき、パブリッククラウドで実行すれば書き込み権限を持ったロールのIAMポリシーを調整することができます。 コマンド実行前に、意図して過剰な権限が付与されていないこと、コマンド実行による影響が無いことを確認の上、コマンドを実行ください。   まとめ 今回はCIEMとPrisma CloudのCIEM機能であるIAMセキュリティについて解説しました。 IAMセキュリティを利用することで、必要以上に権限が付与されているリソースを特定し、リスクを軽減することができ、クラウドのインフラとリソースに最小権限の原則を適用できるようになります。 本記事でPrisma CloudのIAMセキュリティを利用することのメリットが伝わりましたら幸いです。 当社ではPrisma Cloud利用して、複数クラウド環境の設定状況を自動でチェックし、 設定ミスやコンプライアンス違反、異常行動などのリスクを診断するCSPMソリューションを販売しております。 本記事で解説させていただいたIAMセキュリティも利用いただけます。 興味のある方は是非、お気軽にお問い合わせください。            

こんにちは！SCSKの八巻です。 Google Cloud にて利用できる『Google Agentspace』についてご存知でしょうか？？ Agentspaceを利用することで、 組織全体のコンテンツを連携させ、根拠に基づいたパーソナライズされた回答を生成する。 ワークフローアクションと連携してタスクを実行することで、従業員が必要な情報を適切なタイミングで入手する。 ことが可能となります。 Google Cloud 公式サイト： Google Agentspace | Google Cloud Google Agentspace の利用に際しては 『 早期アクセス（Early Access）の申請が必要』 となります。 （執筆時 2025.4.9時点） 詳細については、以下の応募フォームをご確認ください。 Google Agentspace early access また、本ブログに添付しているコンソール画面についても執筆時時点のものとなります。 更新されている内容については、公式のドキュメントをご確認ください。 本記事では、 『 Google Agentspace 』について色々と調査し、実際に触ってみましたので、その魅力についてご紹介させていただければと思います。 また、 Agentspace について「もっと知りたい！！！」方は、 他サービスとのデータ連携やAgent関連について記載している以下「あわせて読みたい」もぜひご覧ください。 【Google Cloud】Agentspaceについてご存じですか？①「概要編」 Google Agentspace について調査し、実際に触ってみましたので、その魅力についてご紹介させていただければと思います。 blog.usize-tech.com 2025.04.10 【Google Cloud】Agentspaceについてご存じですか？⑤「ブレンドRAG編」 今回はブレンドRAGの機能を活用し、複数のデータソースを精査した上で回答を生成させるデモを紹介します。対象のデータソースを一か所に集約させることなく、データソースを複数選択することができるので、現状の業務環境にフィットさせる形で利用を開始することが可能です。 blog.usize-tech.com 2025.04.14 この記事に書いてあること 本記事では、Agentspaceの付加機能である『NoteBookLM』について紹介します。 NoteBookLMとは NoteBookLMの利用方法   NoteBookLMとは NotebookLMは、一言でいえば 資料やデータをもとに会話できるAI搭載のノートブック です。 大規模言語モデルを活用し、アップロードしたドキュメントを理解し、その内容に基づいて質問に答えたり、要約を作成したり、アイデア出しをサポートしたりできます。 研究、学習、執筆など、さまざまな知的作業を効率化するツールとして利用できます。 NotebookLMの基本機能 NotebookLMは、主に以下の機能を提供します。 NoteBook作成: 用途別に資料の保存場所を分割できます。 ソースの追加:  学習させるデータやファイルをアップロードします。 ソースの選択:  要約や回答をするためのソースを選択することができます。 チャット: 質問や要約の指示を行い、アップロードしたソースをもとに回答を生成させます。 音声概要： アップロードしたソースをもとに、2人のディスカッション形式の音声を生成します。(英語音声のみ) 文章を読むことなく、聞き流すことでアップロードしたソースの要点を理解する機能です。 メモ ：チャットにて会話した内容を保存することができます。 共有 ：NoteBookにアクセスできるユーザーを追加し、共有範囲を決定できます。   NotebookLMを利用するメリット NotebookLMを活用することで、以下のメリットがあります。 効率的な情報整理:  アップロードしたテキストの要点を要約できるため、情報整理の時間を削減できます。 共同作業の促進:  共有可能なノートブックとして、チームメンバーとの共同作業を円滑に進めることができます。 履歴・メモ機能:  検索結果をメモとして残すことができ、過去の情報を参照するのに役立ちます。   NoteBookLMのEnterprise版と無料版との比較 Agentspaceでは、NoteBookLMのEnterprise版を利用することができます。 Enterprise版と無料版の大きな違いは、セキュリティ強化やアクセス権制御の有無です。 無料版は個人利用を主としており、 VPC-SCに準拠していないため、サポートするデータが少なくなっています。 一方、Enterprise版は、コンプライアンスと企業に必要な管理機能を有しているため、無料版では利用できない Microsoft WordやPowerPointなどのデータを活用することができます。 ​ ​ NotebookLM for Enterprise ​ NotebookLM 無料版 ​ 概要 ​ 大規模言語モデル (LLM) を活用し、ド キュメントの理解、情報の抽出、コン テンツ作成を支援する。 ​ エンタープライズ向けにセキュリティ とプライバシーを強化。 ​ 機能は NotebookLM for Enterprise と同様。 ​ Google アカウントを持つユーザーが利 用できる個人利用ツール。 ​ 機能 ​ ドキュメントの要約、質問応答、アイ デア生成、 FAQ 作成、ナレッジベース 構築など。 ​ ドキュメントの要約、質問応答、アイ デア生成など。 ​ インポートデータ ​ Google ドキュメント、テキスト、 URL 、 Youtube 、 PDF 、 M365 （ Word 、 PPT 、 Excel ）、音声 (mp3) ・・・ ​ Google ドキュメント、テキスト、 URL 、 Youtube 、 PDF ​ 共有方法 ​ アクセス権限を設定して、組織内の特 定のユーザーまたはグループと共有可 能。 ​ 共有リンクを発行して、他のユーザー と共有可能。 ​ データの所在 ​ Google Cloud Platform 上で管理。 企業は データの所在地を制御可能。 ​ Google Cloud Platform 上で管理。 ​ 料金 ​ 1 ライセンス 月額 $9 （約 1400 円） ​ 基本無料 ​   NoteBookLMの利用方法 前述したNoteBookLMの基本機能をもとに、NoteBookLMの利用方法を説明します。 NoteBook作成 ①画面左にある、NoteBookLMのタブをクリックします。 ②NoteBookLMの初期画面で、新規作成をクリックします。   ソースの追加 ①NoteBookLM後にソースを追加する画面が表示されます。 読み込ませたい資料を選択し、アップロードします。 ②画面左にアップロードされた資料が表示されているか確認します。 ③追加でアップロードする場合は、画面左側の「ソースを追加」をクリックし、①と同様の手順でアップロードします。   ソースの選択 ①画面左側のソースから、読み込ませたい資料のチェックボックスにチェックを付けます。   チャット ①画面中央のチャット欄に、質問や指示を入力し、青い送信ボタンをクリックします。 ②回答を確認します。   音声概要 ①画面右上の音声概要の欄で、生成をクリックします。 ②画面右側のStudio欄に音声が生成されたことを確認し、再生ボタンをクリックして音声を聞きます。   メモ ①チャットで返ってきた回答の最後尾にある、「メモに保存」をクリックします。 ②画面左側のメモ欄にメモが保存されたことを確認します。   共有 ①画面右上の「共有」ボタンをクリックします。 ②「ユーザーを追加」の欄に、Agentspaceを利用可能なユーザーのメールアドレスを入力します。   最後に 今回は『 Google Cloud のAgentspace 』のNoteBookLMについてご紹介させていただきました。 NoteBookLMを使ってみての所感として、アップロードした資料を要約する機能を保有しているので、 資料すべてに目を通す必要がなくなり、情報収集の時間を短縮できると感じました。また、共有機能があるため、チームで共有することができ、チーム内のナレッジ共有ツールとしても非常に有用だと感じました。 本記事を見てAgentspaceに興味を持った方は、そのほかの記事を是非ご覧ください！！ 【Google Cloud】Agentspaceについてご存じですか？①「概要編」 Google Agentspace について調査し、実際に触ってみましたので、その魅力についてご紹介させていただければと思います。 blog.usize-tech.com 2025.04.10 【Google Cloud】Agentspaceについてご存じですか？②「検索（Cloud Storage）編」 本記事では、Agentspaceのアシスタント機能（検索機能）を紹介します。 blog.usize-tech.com 2025.04.10 【Google Cloud】Agentspaceについてご存じですか？④「BigQuery編」 AgentspaceのデータソースとしてBigQueryテーブルを接続し、テーブル内の情報から回答を生成させるデモをご紹介します。 blog.usize-tech.com 2025.04.14 今後とも、Agentspaceのアップデート情報を掲載していきたいと思います。 最後まで読んでいただき、ありがとうございました！！！ [共同執筆者紹介] 島村裕哉 SCSK株式会社のクラウド専門部隊に所属 Google Cloudの ・AI MLサービス選定/導入コンサルティング/導入サポート/AI 基盤・運用構築　まで多く案件を担当 Google Cloud Partner Top Engineer 2024・2025 受賞　カテゴリ：Cloud AI/ML Google Cloud Next Tokyo 出展 Google Cloud Day ’23 Tour 登壇 「AI は選んで組み込んで実装！最新 AI を道具として有効利用するためには！？」 ■好きな Google Cloud サービス：Vertex AI / Dialogflow CX / Visual Inspection AI / Cloud Run 山口翔平 Google Cloud歴3年目（社会人4年目）です。 日々捌ききれないほどのインプットを浴びているので、本ブログをアウトプットの場として活用しています。 ----- 好きな(よく触っている)サービス：BigQuery、Cloud Functions、Data Fusion 保有資格：応用情報技術者、Google Cloud 認定資格全冠（12冠） 受賞歴：Google Cloud Partner Top Engineer 2025（カテゴリ：General）受賞

こんにちは、SCSKの坂木です。 5月末に、Zabbix Japanが主催する Zabbix セミナー in 東京 2025 が開催されます！ このイベントでは、Zabbixを知らない方から既にご利用いただいている方、そしてZabbix導入を検討されている方まで、広範なユーザを対象とした オンサイト限定のイベント となっております。   イベント概要 Zabbix セミナー in 東京 2025では、 Zabbix Japan及びZabbixパートナー企業によるセミナー が行われます。（もちろん弊社も登壇します！）　Zabbixを用いた監視方法やパートナー企業のZabbixソリューション、Zabbixの最新情報について知ることができます。 開催日程 2025年5月20日(火)　13:00-17:50 開催場所 東京都港区港南２丁目３−１３ 品川フロントビル B1階 スケジュール 12:00-13:00　受付 13:00-13:10　開会のあいさつ 13:10-17:30　Zabbix Japan及びZabbixパートナー企業によるセミナー（講演内容の詳細は こちら ） 17:30-17:50　質疑応答、クロージング   SCSKのセミナーについて 弊社は Zabbix入門　監視システム構築の第一歩 と題して、Zabbixの基本機能、実践的な監視設定について講演します。 監視対象の設定から、監視項目設定、障害検知、運用担当者への通知まで、監視の基礎設定について網羅的に説明します。 そして、ここまで本ブログをご覧いただいた皆様にはセミナー資料の一部を先行公開しちゃいます！   セミナーの申し込み さてさて、ここまで読んでくださった方は本セミナーに参加したくなったのではないでしょうか？ そんなことないですかね。 筆者としては、10人に1人くらいは「参加したい」と思ってくれることを願っています。 そんな選ばれた1人へ、セミナー参加の申し込みは こちら からお願いします。   さいごに 最後まで読んでいただきありがとうございます。 ちなみにですが、ここまでZabbix セミナー in 東京 2025について熱く語ってきましたが、筆者は講演どころか参加もしません。（行きたくても行けないのです。筆者は忙しいのです。） 本ページ見てイベントに参加しようと思った方は、筆者の分も楽しんできてくださいね！   本当のさいごのさいごに、弊社のYoutubeチャンネルを紹介させてください。 今後、Zabbixに関する有益な動画が続々と投稿しますので、今のうちにチャンネル登録してやってください。 SCSK Zabbixチャンネル 本チャンネルでは、SCSK株式会社でのZabbixに関するトレンド/事例紹介などを動画にまとめて取り上げております。最新のトピックについては、以下の弊社HPもしくはツイッターアカウントをぜひ参照ください。ツイッターアカウント： www.youtube.com

こんにちは。SCSKの坂木です。 さっそくですが、某人気アニメを捩ったタイトルにつられてこのページをクリックしてくれた方へ、本ブログは一切地球の運動を感じられないバチバチの技術ブログとなっております。 ただ、せっかく開いたことですし、このまま最後までお付き合いいただけると嬉しいです。 元々、Patch Manager目的で開いた方は目的どおりの記事となっておりますので、ご安心ください！ 本ブログでは、AWS System Managerのツールである Patch Manager を用いたEC2インスタンスのスキャン及びパッチ適用の方法について説明します。 Patch Managerとは AWS Systems Manager(SSM) の Patch Manager は、Amazon EC2 インスタンスやオンプレミスサーバーを含む、SSMで管理されるインスタンスの パッチ適用を自動化するサービス です。OS の脆弱性を修正するためのセキュリティパッチ適用や、その他のソフトウェア更新を効率的に実施できます。   事前設定について 本記事では、以下の環境にてPatch Managerでスキャンおよびパッチ適用するための基本的な設定を行います。 Patch Managerの実施にあたり、いくつか押さえておきたい設定がありますので、確認していきましょう！   パッチ適用するインスタンスのOS Patch Managerでは利用できるOSに制限がありますので、対象のインスタンスがサポートされているか、 こちら よりご確認ください。   SSM Agent のバージョン 対象インスタンスのSSM Agentのバージョンが2.0.834.0以降(2025/4時点)であることを確認します。 System Manager/フリートマネージャーより対象のインスタンスを選択することで、バージョンを確認できます。本環境では3.3.1611.0でした。   パッチソースへの接続 インスタンスがインターネットへ接続して、対象OSのレポジトリが保存されているサーバへアクセスできる必要があります。 セキュリティグループやネットワークACLの設定を確認し、インターネットへのアクセスが問題ないかご確認ください。 穴あけをしていない状態でPatch Managerを実行すると、XXXX.comへのアクセスができませんという旨のエラーが返されます。その情報から、穴あけが必要な最小限のIPを特定できるため、全開放ではなく最小限の開放のみで済みます。また、ポートはアウトバウンド通信で80か443、インバウンド通信でエフェメラルポートを開ける必要があります。 ちなみにですが、AWS Network ManagerのReachable Analyzerを用いることで、対象インスタンスからIGWや外部サーバへの通信が許可されているか確認できます。パッチソースへの接続に不安のある方は利用してみてください。   S3への接続 パッチ適用オペレーションの実施にあたっては、対象インスタンスからS3への接続を確保する必要があります。 前提条件 より、S3へのアクセスにはエンドポイントを用いる必要がありそうなので、エンドポイントでの接続を設定します。 エンドポイントにはインタフェース型とゲートウェイ型がありますが、どちらのタイプでも問題はありません。本記事では無料で利用できるゲートウェイ型のインタフェースを利用します。   インスタンスのステータス Patch Managerは起動しているインスタンスに対してのみ実行できるため、スキャンまたはパッチ適用時に対象のインスタンスの状態が、「実行中」であることを確認してください。 定期実行時に、EC2の状態が停止中になっており、スキャンやパッチ適用が行われない事象。あると思います。   手動実行 AWS System manager/Patch Manager/今すぐパッチ適用から、手動実行できます。 本記事では、インストールはせずにスキャンのみ実施したいと思います。 ターゲットの選択から、対象のインスタンスを選択します。今回はインスタンス名でターゲットを選択しましたが、タグやリソースグループ単位で選択することもできます。   実行結果はAWS System manager/Patch Manager/コンプライアンスレポートより確認できます。今回の結果ではセキュリティの非準拠数は0でコンプライアンスに準拠していましたが、非準拠の場合は「欠如している数」から欠如しているパッケージを確認することができます。 「スキャンとインストール」を選択した場合、欠如しているパッケージは自動的にインストールされますが、 スキャンのみの場合はdnfコマンド等を使って手動でインストールする必要 があります。   ちなみにですが、非準拠となった場合は以下の画像のように、非準拠数と欠如したパッケージが表示されます。（Ubuntuで試してみました）   定期実行 AWS System manager/Patch Manager/パッチポリシーを作成から、定期的な実行スケジュールを作成できます。 スキャンとインストール/カスタムスケジュールより、実行時刻を設定できます。 実行頻度は、日単位(毎日hh:mmに実行)またはcron形式で指定することができます。 パッチベースラインとは、承認されたパッチの集合を定義するものです。どのパッチをインスタンスに適用するかを制御するために使用されます。今回はAWS推奨の事前定義されたパッチベースラインを利用します。パッチベースについては こちら をご確認ください。   さいごに 本記事では、AWS初心者に向けてPatch Managerの設定方法を説明しました。 Patch Managerは、 大規模な環境で効率的かつ安全にパッチを適用するための強力なツール です。手動操作の負担を軽減し、コンプライアンスを維持するのに役立ちますので、是非使ってみてください。 他の記事も読んでもらえると、著者が小躍りして喜びます。 【Amazon Bedrock】ナレッジベースを用いた社内資料管理ーめざせ生産性向上ー 社内資料の管理、効率的ですか？様々な形式の文書が散在し、必要な情報を探すのに時間を取られていませんか？ ファイルサーバーの奥底に埋もれどこにあるか分からない、バージョン管理が混乱する、などといった課題を抱えていませんか？これらの非効率は、業務の生産性低下に直結します。 今こそ、社内資料の一元管理体制を見直しましょう！ということで、AWS Bedrockのナレッジベースを用いた資料の一括管理およびその検索方法をご紹介します！ blog.usize-tech.com 2025.02.14

こんにちは！SCSKの八巻です。 Google Cloud にて利用できる『Google Agentspace』についてご存知でしょうか？？ Agentspaceを利用することで、 組織全体のコンテンツを連携させ、根拠に基づいたパーソナライズされた回答を生成する。 ワークフローアクションと連携してタスクを実行することで、従業員が必要な情報を適切なタイミングで入手する。 ことが可能となります。 Google Cloud 公式サイト： Google Agentspace | Google Cloud Google Agentspace の利用に際しては 『 早期アクセス（Early Access）の申請が必要』 となります。 （執筆時 2025.4.9時点） 詳細については、以下の応募フォームをご確認ください。 Google Agentspace early access また、本ブログに添付しているコンソール画面についても執筆時時点のものとなります。 更新されている内容については、公式のドキュメントをご確認ください。 本記事では、 『 Google Agentspace 』について色々と調査し、実際に触ってみましたので、その魅力についてご紹介させていただければと思います。 また、 Agentspace について「もっと知りたい！！！」方は、 他サービスとのデータ連携やAgent関連について記載している以下「あわせて読みたい」もぜひご覧ください。 【Google Cloud】Agentspaceについてご存じですか？①「概要編」 Google Agentspace について調査し、実際に触ってみましたので、その魅力についてご紹介させていただければと思います。 blog.usize-tech.com 2025.04.10 https://blog.usize-tech.com/agentspace-search-gcs/ 【Google Cloud】Agentspaceについてご存じですか？③「Agent呼び出し編」 Dialogflow (DFCX) エージェントをアシスタント機能としてAgentspaceから呼び出してで利用できるようにする構成を紹介します。 blog.usize-tech.com 2025.04.10 この記事に書いてあること 本記事では、Agentspaceの付加機能である『Deep Research』について紹介します。 Deep Researchとは Deep Researchの利用方法 Deep Researchとは Deep Researchは、 AIが自動で調査計画を立案し、必要な情報を収集してレポートを作成するツール です。 質問に対して、インターネット上の膨大な情報源から関連情報を収集し、分析、要約することで、ユーザーが効率的に深い洞察を得られるように設計されています。 Agentspaceのアシスタント画面に、Deep Researchが付随しており、AgentspaceのWeb画面から利用することができます。 従来の検索エンジンと比較して優れている点 従来の検索エンジンとは異なり、Deep Researchは以下の点で優れています。 文脈理解: 自然言語処理 (NLP) 技術を用いて、ユーザーの質問や意図を正確に理解できる 情報源の多様性: ウェブページ、ニュース記事、学術論文、ブログ、ソーシャルメディアなど、多様な情報源を網羅的に検索する 情報の関連性評価: 収集した情報の中から、質問やトピックとの関連性が高い情報を優先的に抽出する 情報の分析と要約: 抽出した情報を分析し、重要なポイントを抽出し、構造化された形式で要約する 継続的な学習: ユーザーのフィードバックや新しい情報に基づいて、検索精度と分析能力を継続的に向上させる   Deep Researchを利用するメリット Deep Researchを活用することで、以下のメリットがあります。 時間と労力の削減: 時間と労力がかかるリサーチタスクを自動化し、効率的な情報収集と分析を実現する 深い検索結果の取得: 情報を多角的に分析し、構造化された形式で提示することで、深い検索結果を得ることを支援する 意思決定の迅速化: 迅速かつ正確な情報に基づいて、より迅速な意思決定を支援する 競争力の強化: 市場動向、競合企業の戦略、顧客ニーズなどを把握し、競争優位性を確立するための戦略を策定する   Deep Researchの利用方法 Deep Researchは、Agentspaceのアシスタント画面（Webアプリケーション画面）から簡単に利用することができます。 Deep Researchの検索方法 ①画面左にある、エージェント配下のDeep Researchタブをクリックします。   ②画面下の検索欄に、調査したい質問を入力します。 今回は、「最近話題のAI技術について詳しく教えてください。」と聞いてみます。   ③リサーチプランが作成されますので、内容を確認し『リサーチを開始』をクリックします。 ④リサーチが開始されると、Deep Researchはウェブ検索によりレポート作成を始めます。 数分後に詳細なレポートが生成されます。 ↑（2025/4/14時点）検索結果は日本語で表示されず英語で返ってきます。 ⑤Deep Researchの検索結果は、AgentspaceのWeb画面に残ります。 画面左側の『最近』のタブから確認することができます。   リサーチプランの変更方法 Deep Researchが提示したリサーチプランが、検索したい内容と異なることもあるかと思いますので、 リサーチプランに変更を加えたい場合の手順を紹介します。 ①リサーチプランの提示後に、『リサーチプランを変更したい』と指示を与えます。   ②変更したい内容の指示を追加し、新たに提示されたリサーチプランを確認します。 最後に 今回は『 Google Cloud のAgentspace 』のDeep Researchをご紹介させていただきました。 Deep Researchを使ってみての所感としては、Webサイトの情報だけでなく、SNSや動画サイト・論文などさまざまな情報をもとにリサーチするため、情報収集の時間を大幅に短縮できると感じました。 また、今回は最新AI情報の収集をターゲットにしましたが、市場/顧客分析などのマーケットの領域にも活用できると思います。 リサーチプランを修正/改善することで、こちらが求めている情報を取得できることも便利だと感じました。 本記事を見てAgentspaceに興味を持った方は、そのほかの記事を是非ご覧ください！！ 【Google Cloud】Agentspaceについてご存じですか？①「概要編」 Google Agentspace について調査し、実際に触ってみましたので、その魅力についてご紹介させていただければと思います。 blog.usize-tech.com 2025.04.10 【Google Cloud】Agentspaceについてご存じですか？②「検索（Cloud Storage）編」 本記事では、Agentspaceのアシスタント機能（検索機能）を紹介します。 blog.usize-tech.com 2025.04.10 【Google Cloud】Agentspaceについてご存じですか？③「Agent呼び出し編」 Dialogflow (DFCX) エージェントをアシスタント機能としてAgentspaceから呼び出してで利用できるようにする構成を紹介します。 blog.usize-tech.com 2025.04.10 今後とも、Agentspaceのアップデート情報を掲載していきたいと思います。 最後まで読んでいただき、ありがとうございました！！！ [共同執筆者紹介] 島村裕哉 SCSK株式会社のクラウド専門部隊に所属 Google Cloudの ・AI MLサービス選定/導入コンサルティング/導入サポート/AI 基盤・運用構築　まで多く案件を担当 Google Cloud Partner Top Engineer 2024・2025 受賞　カテゴリ：Cloud AI/ML Google Cloud Next Tokyo 出展 Google Cloud Day ’23 Tour 登壇 「AI は選んで組み込んで実装！最新 AI を道具として有効利用するためには！？」 ■好きな Google Cloud サービス：Vertex AI / Dialogflow CX / Visual Inspection AI / Cloud Run 山口翔平 Google Cloud歴3年目（社会人4年目）です。 日々捌ききれないほどのインプットを浴びているので、本ブログをアウトプットの場として活用しています。 ----- 好きな(よく触っている)サービス：BigQuery、Cloud Functions、Data Fusion 保有資格：応用情報技術者、Google Cloud 認定資格全冠（12冠） 受賞歴：Google Cloud Partner Top Engineer 2025（カテゴリ：General）受賞