こんにちは。SCSK 青島です。 先日6月25,26日の2日間、幕張メッセで開催されたAWS Summit Japan 2025に参加しました。 私にとっては今回が初参加でした。 ▲会場の様子 AWS Summit Japan | 2025 年 6 月 25 日（水）、26 日（木） AWS Summit Japan（AWSサミット）とは、AWSのサービスに関する今を知ることができる、AWSを学ぶ日本最大のイベントです。基調講演をはじめとしたさまざまなセッション（講演）や、さまざまな企業の展示を見られるExpoエリア、そのほかにも楽しいイベントが用意されています。   参加前は「生成AI」や「DX」といったトレンドキーワードが並び、どんな難しい技術を使うんだろう、、と少し身構えていました。 しかし実際にセッションを聞いてみると、技術そのものよりも「人と組織」の課題について語られており、そこに生成AI活用やDX推進の本質があるように感じました。 そこで印象的だった3つの事例をご紹介します。   損保×デロイト 「クラウドで変える損保業界のサプライチェーン -業界共通基盤の第一歩、レンタカー手配 DX-」 概要 損保とデロイトによる業界横断DXのセッションです。 自動車事故時のレンタカー配車業務において、業界初となる共通プラットフォーム構築の挑戦について紹介されました。     課題とアプローチ 従来は、各損保会社が個別にレンタカー会社と電話やFAXでやり取りしていました。     ＜各社の課題＞       レンタカー会社：各社との個別対応が負担 損保会社：配車業務が煩雑、運用コストに課題 ⇒レンタカー手配を非競争領域として位置付け、損保ジャパン主導のもと業界共通基盤としてシステムを統一 業界全体の課題解消、価値拡大に貢献 工夫                     「直感的、シンプル」な 機能に絞り込む ことでシステム利用率向上 共通的な機能は共通部に集約し、システムの再利用性を向上 個社特有の情報を処理するワークロードは個別に構築し、共通部からも分離 塩野義製薬  「SHIONOGI における生成 AI 活用～全社的な道筋と医薬開発領域での事例紹介～」 概要 塩野義製薬の生成AI活用に関する取り組みについてです。 製薬開発における文書作成の膨大な時間と費用という課題に対し、生成AIを活用した文書作成支援の事例が挙げられました。   課題とアプローチ               臨床試験時に成果物として提出される様々な規制文書の作成には、膨大な時間（数十～数百時間/文書）を要する 製薬業界のミッションは、新薬発売までのリードタイムをいかに短く、効率的にできるか ⇒文書作成支援や文書検索・分析等様々な生成AIアプリを開発   工夫                     人間によるチェックプロセスを残し、 リスクが高いレビューは人がやる すべての工程で生成AIを使用するのではなく、 要所要所で必要な技術を掛け合わせる 例：文書生成にはLLMを、フォーマット調整などの定型作業にはPythonを組み合わせることで安定性を図る プロアクティブな運用でハルシネーションを監視 ANA 「ANA の挑戦！ AI とデータ活用を牽引するデータ基盤の拡大戦略」 概要 ANAの生成AI活用事例とデータマネジメント基盤 「BlueLake」に関するセッションです。 4 万人規模の組織におけるデータ民主化を通じた、AI やデータの活用事例が紹介されました。   課題とアプローチ 数千件/月ほどの「お客様の声」を人手で分類、担当者による主観が入り判断基準が曖昧 表やグラフ、数字の人手による更新が都度必要 手作業が多く、施策検討までたどり着けない ⇒CAがカテゴライズする際の頭の中のロジックを言語化 経験や勘に基づく「暗黙知」を引き出すことで精度を向上 工夫 「小さく始めて、大きく育てる」 アプローチ 経験や勘に基づく「暗黙知」 を引き出し、プロンプトに組み込むことで精度を向上 個人情報の有無判定にも Amazon Bedrockを活用することでフリーテキスト内に存在する個人情報の取り扱いも可能に 自社アプリ「BlueLake AiVO」によるモニタリング体制 まとめ 3社の事例を通じて、生成AI活用・DX推進における成功ポイントを考えてみました。 現場の具体的な課題が起点 技術先行ではなく、現場の身近な課題から始まることで、現場の人にも「自分事」としてとらえやすい 現実的かつ実用的なアプローチ 「小さく始めて、大きく育てる」段階的な推進 機能を絞り込んだり、適宜技術を掛け合わせたり 人間の知恵×技術の効果的な組み合わせ 暗黙知のプロンプト化 人間のチェックプロセスは残す 堅実な構築と運用 共通部分と個別部分の分離 個人情報保護のための2層構造 最後に 今回のAWS Summit では上に挙げた3社以外のセッションも拝聴しましたが、 技術そのものの活用以上に、組織全体で生成AI活用・DX推進に取り組む文化の醸成が難しく、大切なのだと気づかされました。 そしてその文化醸成は、現場の身近な課題解決から小さく始まり、その成功の積み重ねによって大きな成果が実現できると思います。結局人が主役となって進んでいくんだなあと感じました。 技術トレンドを追うだけでなく、現場に寄り添った地に足の着いた改善を意識していきたいです。 最後までお読みいただきありがとうございました。

こんにちは、SCSKの前田です。 私が携わった LifeKeeper の案件で導入を行った ARK について紹介をかねてお話したいと思います。 今回は、SQL Server 編と言うことで、マイクロソフト社が開発したリレーショナルデータベース管理システムを簡単に冗長化するための ARK の導入事例について、ご紹介していきます。 注意 マイクロソフト によると、SQL Server フェイルオーバークラスターインスタンス (FCI) では、クラスターノードがドメインに参加している必要があります。この制限により、Windows 版の LifeKeeper を使用し、ワークグループ環境で SQL Server フェイルオーバークラスターインスタンスを保護することはできません。 おさらい LifeKeeperのARKについて、おさらいしたいと思います。 ARK とは、Application Recovery Kits の略で、LifeKeeper が特定のアプリケーション（オープンソースソフトウェアや商用アプリケーション）を容易にリソースとして組み込むことが可能になる製品です。 ARK による、アプリケーションのリソースへの組み込みはウィザード形式（GUI上で設定）で作業が可能となり、ARK には、アプリケーションを操作（起動・停止・監視・再起動）するための4つのスクリプトがあらかじめ準備されているため、スクリプトを設計・作成するための開発工数の削減や人的なミスを防止することが出来ます。 概要説明 SQL Server ARK では、SQL Server 本体を保護対象リソースとして登録し、下記表にまとめたオプションサービス（必要に応じ選択が可能）を含めて保護する機能を提供します。 オプションサービス名 備考 SQL Server Agent   SQL Server Reporting Services   Distributed Transaction Coordinator   SQL Server Browser   SQL Server VSS Writer   SQL Server Integration Services SQL Server 2014 より利用可能 SQL Full-text Filter Daemon Launcher SQL Server 2016 より利用可能 SQL Server Launchpad SQL Server 2016 より利用可能 SQL Server PolyBase Data Movement SQL Server 2016 より利用可能 SQL Server PolyBase Engine SQL Server 2016 より利用可能 SQL Server CEIP service SQL Server 2016 より利用可能 注意 SQL Server ARK では、SQL Server の次の機能を利用できません ・SQLレプリケーション（スナップショット、マージ、トランザクション） ・SQL のログ配布 ・SQL データベースのミラーリング ・SQL Server AlwaysOn 可用性グループ また、分散トランザクションはサポートされません。 SQL Server ARK は、汎用アプリケーション(Generic Application)リソースの導入とは違い、起動・停止・監視・再起動を行うためのスクリプトを明示的に指定することはなく、リソースの作成に必要な項目に対するパラメータをウィザード形式で入力または、選択することでリソースを作成することが出来ます。 SQL Server ARK として SQL Server の処理内容は以下の通りとなります。 SQL Server の処理 処理名 処理内容 起動処理 ① sc query コマンドによるサービス名を取得 ② ARK の内部処理（$LKBIN/ScQueryState.exe）によってサービスの起動状態を取得 ③ サービスの状態が RUNNING 以外の場合、sc start コマンドによりサービスの開始を実施 ④ オプションサービスも保護する場合、オプションサービスに対して②と③を実施 ⑤ 起動した SQL Server 本体のサービスに対し、管理ユーザで接続出来るか確認を実施 停止処理 ① オプションサービスも保護する場合、ARK の内部処理（$LKBIN/ScQueryState.exe）によってオプションサービスの起動状況を取得 ② オプションサービスの状態が RUNNING か PAUSED の場合、sc stop コマンドによりオプションサービスの停止を実施 ③ ARK の内部処理（$LKBIN/ScQueryState.exe）によって SQL Server 本体サービスの起動状況を取得 ④ SQL Server 本体サービスの状態が RUNNING か PAUSED の場合、sc stop コマンドにより SQL Server 本体サービスの停止を実施 ⑤ ④で SQL Server 本体サービスが停止出来なかった場合、net stop コマンドにより SQL Server 本体サービスの停止を実施 ⑥ ⑤で SQL Server 本体サービスが停止出来なかった場合、もう一度④で SQL Server 本体サービスの停止を実施 監視処理 sc query コマンドにより、SQL Server 本体 及び、オプションサービスの起動状態の確認を実施 詳細監視処理 ① SQL Server 本体のサービスに対し、管理ユーザで接続出来るか確認を実施 ② マスター DB にクエリーを発行し、結果が取得できるか確認を実施 再起動処理 起動処理と同一の処理を実施 SQL Server ARK の構築例 それでは、実際に SQL Server ARK の構築についてお話していきたいと思います。 SQL Server ARK のパラメータ項目 SQL Server のリソース作成時に設定する特有のパラメータを一覧表にまとめました。 項目 説明 Microsoft SQL Server のインスタンスの選択 LifeKeeper for Windows で保護する Microsoft SQL Server のインスタンスを選択 Microsoft SQL 管理ユーザ名の入力 このサーバで Microsoft SQL の管理権限を持つユーザの名前を入力。（マスタデータベースに対する SA 権限が必要） パスワードの入力 入力したユーザアカウントの管理パスワードを入力 保護対象のオプショナルサービスの選択 この階層で保護されるオプションの SQL サービスを選択（リストには LifeKeeper の保護に適したサービスのみが表示される） 保護された IP アドレス インスタンスで保護する IP アドレスを選択（名前付きパイプだけを使用する場合、IP アドレスは不要） 名前付きパイプのエイリアス 名前付きパイプの別名を入力 SQL Server リソースの作成 SQL Server リソースを LifeKeeper の GUI によって作成する流れを例として紹介します。 注意 SQL Server で使用する共有ディスクリソースと、 IP リソース、及び、別のリソース等、それぞれの依存関係がある状態で SQL Server リソースを作成した場合、SQL Server リソース作成時の自動による依存関係の作成が失敗する可能性があるため、必要に応じて依存関係を削除する必要があります。 以降の例では、共有ディスクリソースと IP リソースの依存関係がない状態で SQL Server リソースの作成を実施しています。 処理内容 GUI画面例 リソース作成前のツリー構造 冗長化対象ノードの選択 保護アプリケーションの選択（MS SQL Server） Microsoft SQL Server のインスタンスの選択 Microsoft SQL 管理ユーザ名の入力 管理ユーザのパスワードの入力 データベースの設定の確認 保護対象のオプショナルサービスの選択 保護する IP アドレスの選択（例では「なし」を選択） 名前付きパイプのエイリアスの選択（例では「なし」を選択） Microsoft SQL Server リソースのタグ名の入力 稼働系ノードのリソース作成結果 待機系ノードのリソース作成準備の確認結果 待機系ノードの優先順位の設定 ※デフォルト：10 待機系ノードのリソース作成結果 リソース作成後のツリー構造 これで、LifeKeeper による SQL Server のリソースが完成です。 依存関係の作成 SQL Server リソースを作成した後、全リソースの起動（停止）する順序を定義するため、必要に応じてリソース間の依存関係（リソースツリーの下から起動され、上から停止される）を作成する必要があります。 例として、別で作成していた仮想 IP リソースを始めに起動させるようリソースツリーの下部に配置させ、その後に共有ディスクリソースと SQL Server が起動されるように依存関係を作成します。 処理内容 GUI画面例 依存関係作成前のツリー構造 SQL Server リソースの依存関係作成後 これで、SQL Server に関連する LifeKeeper によるリソース構成ツリーの完成です。 まとめ 今回は LifeKeeper ARK の導入事例と言うことで、SQL Server のリソース作成について紹介してみました。 SQL Server ARK は、汎用アプリケーション(Generic Application)リソースとは違い、起動・停止・監視・再起動を行うためのスクリプトを準備する必要がなく、リソースを作成することで意識することなく自動でスクリプトが導入されます。 また、SQL Server ARK では、SQL Server 本体を保護サービスとしてリソースに登録すると共に、必要なオプションサービスを保護する機能も提供しています。システムの要件に合わせ、保護対象のサービスを選択することが可能になっています。 SQL Server ARK を導入するための手順を纏めます。 ・SQL Server として保護対象とするオプションサービスを決定する ・SQL Server のリソース固有のパラメータの設定値を検討する ・LifeKeeper GUI を用いて、SQL Server のリソースを作成する ・仮想 IP リソース含め、リソースの起動順序を定義するため依存関係を作成する LifeKeeper では SQL Server 以外にも多数の ARK が用意されていますので、また次の機会に別の ARK について紹介していきたいと思います。 その他 ARK の導入事例に関しては以下のリンクからどうぞ！ LifeKeeper ARK の導入事例を紹介＜JP1/AJS3編＞ – TechHarmony LifeKeeper ARK の導入事例を紹介＜Oracle編＞ – TechHarmony 詳しい内容をお知りになりたいかたは、以下のバナーからSCSK LifeKeeper公式サイトまで

こんにちは、SCSKの齋藤です。 本記事では、 Terraform を使ってBigQueryのリソース（データセット・テーブル・スキーマ）を Infrastructure as Code（IaC） として管理する方法を解説します。   そもそもBigQueryとは？ BigQueryは、Google Cloudが提供するサーバーレスなデータウェアハウスです。 特徴は以下の通りです。 SQLで大規模データを高速分析 標準SQLでペタバイト級のデータを数秒〜数分で集計・分析。 サーバーレス インフラ管理不要。ストレージやクエリのリソースは自動でスケール。 コスト効率 ストレージとクエリ課金が分離されており、使った分だけ支払う従量課金。 GCPサービスとの連携 Cloud Storage、Dataflow、Looker Studio など、他の GCP サービスとシームレスに連携。 これにより、データの収集、処理、可視化を統合的に行うことが可能。 なぜTerraformでBigQueryを管理するのか？ BigQueryはGCPコンソールやbqコマンドで手軽にテーブル作成できますが、 TerraformでIaC化することで以下のメリット があります。 環境ごとの再現性 開発 (dev)、ステージング (stg)、本番 (prd) など、異なる環境で同じ構成をコードで再現できます。環境の違いによる「あれ？動かない…」を撲滅！ スキーマや設定のバージョン管理 テーブル定義、パーティション設定、クラスタリング設定などの変更履歴を Git で管理できます。 これにより、変更の追跡、ロールバック、監査が容易！ 自動化・レビュー Pull Request (PR) ベースでレビューを行い、CI/CD (Continuous Integration/Continuous Delivery) パイプラインによる自動反映が可能です。 これにより、変更の品質を向上させ、デプロイメントの効率アップ！ ヒューマンエラー防止 手作業による設定ミスや漏れを防ぐことができます。 コードによる定義は、人為的な誤りを減らし、一貫性を保証！ ディレクトリ構造例 本記事で紹介する構成は、 プロジェクトごと・データセットごとにモジュールを分割 し、環境（dev/stg/prd）ごとにパラメータを切り替えられるようにしています。 terraform-bigquery/ └── プロジェクト名/ ├── envs/ │ │── dev/ │ │ ├── main.tf │ │ ├── backend.tf │ │ ├── provider.tf │ │ ├── terraform.tfvars │ │ └── variables.tf │ └── stg/ │ └── prd/ └── module/ └── dataset1/ ├── table1.yaml # テーブルスキーマ（YAML） ├── dataset1.tf # データセット・テーブル定義 └── variables.tf # モジュール変数 各ファイルの役割: envs/dev/main.tf : 環境固有の設定を適用し、データセット構築に必要な各モジュールの呼び出しとその引数を定義 envs/dev/backend.tf : Terraform State を安全かつ共有可能な場所に保存するための設定（GCSバケットなど） envs/dev/provider.tf : GCP プロバイダの認証情報、対象プロジェクト、リージョンなどを設定 envs/dev/terraform.tfvars : プロジェクトID、リージョン、サービスアカウントメールアドレスなど、環境によって異なる変数値の定義 envs/dev/variables.tf : main.tf で使用する変数の型、デフォルト値、説明などを定義し、外部からの入力インターフェースを提供 module/dataset1/table1.yaml : テーブルのカラム名、データ型、nullable 属性、説明などを記述した YAML 形式のスキーマ定義ファイル module/dataset1/dataset1.tf : データセット自体の定義、および table1.yaml からスキーマを読み込んでテーブルを定義するTerraformリソース定義 module/dataset1/variables.tf : モジュール内で使用する変数（プロジェクトID、データセット名など）の型、デフォルト値、説明などを定義 実装例 envs/dev/main.tf このファイルは、各データセットに対応するモジュールを呼び出す役割を担います。 source パラメータでモジュールの場所を指定し、 project_name と region 変数を渡します。 環境ごとに異なる terraform.tfvars ファイルを使用することで、 同じコードで異なる環境 をデプロイできます。 module "table1" { source = "../../module/table1" project_name = var.project_name region = var.region } module "table2" { source = "../../module/table2" project_name = var.project_name region = var.region } module/dataset1/table1.yaml このファイルは、テーブルのスキーマを YAML 形式で定義します。 name 、 type 、 mode 、 description などの属性を定義することで、テーブルのカラム構造を明確に記述できます。 YAML 形式を使用 することで、可読性が向上し、メンテナンスが容易になります。 - name: extraction_time type: DATETIME mode: NULLABLE description: "データ抽出日時" - name: value type: STRING mode: NULLABLE description: "値" # ...（以下略） module/dataset1/dataset.tf このファイルは、データセットとテーブルのリソースを定義します。 google_bigquery_dataset  リソース: project 、 location 、 dataset_id などの属性を定義して、 データセットを作成 します。  google_bigquery_table  リソース: project 、 dataset_id 、 table_id 、 description  などを定義して、 テーブルを作成 します。 。 schema  属性:  YAML ファイルからテーブルスキーマを読み込み、 yamldecode  関数で YAML 形式 から Terraform で使用できる形式に変換し、さらに jsonencode 関数でJSON形式にエンコードします。 time_partitioning  ブロック: クエリのパフォーマンスを向上 させるために、時間ベースのパーティショニングを設定します。  type  (この例では “MONTH”) と  field (パーティションキーとなるカラム名)  clustering  属性: クエリのパフォーマンスを向上 させるために、クラスタリングキーとなるカラム名を指定して、クラスタリングを設定します。 deletion_protection  属性:  テーブルの削除保護を有効にします。  true に設定することで、 誤ってテーブルを削除するのを防止 。 resource "google_bigquery_dataset" "dataset1" { project = var.project_name location = var.region dataset_id = "dataset1" } resource "google_bigquery_table" "table1" { project = google_bigquery_dataset.dataset1.project dataset_id = google_bigquery_dataset.dataset1.dataset_id table_id = "table1" description = "情報を取得" schema = jsonencode(yamldecode(file("${path.module}/table1.yaml"))) time_partitioning { type = "MONTH" field = "extraction_time" } clustering = ["value"] deletion_protection = true } envs/dev/variables.tf このファイルは、 main.tf やモジュールで使用する変数を定義します。以下の変数は、GCP プロジェクト ID とリージョンを指定するために使用されます。 variable "project_name" { type = string } variable "region" { type = string } envs/dev/terraform.tfvars このファイルは、環境固有の変数の値を定義します。以下の変数に、それぞれ GCP プロジェクト ID とリージョンの値を設定します。 project_name = "project1" region = "asia-northeast1" envs/dev/provider.tf このファイルは、GCP プロバイダを設定します。 以下の属性に、それぞれ project_name と region 変数を設定します。 provider "google" {   project = var.project_name   region  = var.region }    工夫ポイント スキーマをYAMLで管理 テーブルのカラム定義を YAML で記述し、Terraform で  yamldecode  →  jsonencode  して渡すことで、スキーマの可読性・メンテナンス性が大幅に向上します。 YAML は、構造化されたデータを記述するための人間にとって読みやすい形式であり、複雑なスキーマを管理するのに適しています。 パーティション・クラスタリングもIaCで管理 time_partitioning  や  clustering もコードで明示することで、クエリコスト最適化や運用ルールの徹底ができます。  time_partitioning { type = "MONTH" field = "extraction_time" } clustering = ["value"] deletion_protection = true   部分的なplan/applyで安全に反映 以下のように、特定のデータセットやテーブルだけを対象に plan/apply できます。他のリソースに影響を与えないので安心です。 bash terraform plan -target=module.dataset1 terraform apply -target=module.dataset1 テーブルの削除保護 deletion_protection = true   を設定しておけば、間違ってテーブルを削除してしまうのを防げます。本番環境では必須の設定です。    運用・変更の流れ スキーマ追加・変更: 該当する YAML ファイルにカラムを追加・修正。 テーブル追加: module/dataset名/  に新たな YAML ファイルとリソース定義 ( .tf ファイル) を追加。 環境ごとに反映: dev/stg/prd  の  main.tf  で必要なモジュールを呼び出し、 terraform apply を実行。 バージョン管理: すべての変更を Git で管理。 Pull Request ベースでレビューを行い、CI/CD パイプラインを使用して自動的にデプロイ。 まとめ BigQueryのテーブルやスキーマ、パーティション設定を TerraformでIaC化 することで、 再現性・自動化・レビュー性・ヒューマンエラー防止 など多くのメリットが得られます。 スキーマはYAMLで管理し、Terraformで読み込むと可読性・保守性が高まる パーティションやクラスタリングもコードで明示し、運用ルールを徹底 dev/stg/prdなど複数環境も同じ構成を再現できる すべてgitでバージョン管理し、Pull Requestベースで安全に運用 BigQueryの運用に課題を感じている方、これからIaCに取り組みたい方は、ぜひTerraformによるBigQuery管理を試してみてください！   参考リンク   Google BigQuery 公式ドキュメント Terraform Google Provider BigQuery Table TerraformでBigQueryを管理するベストプラクティス YAMLスキーマ管理のアイデア

こんにちは、SCSKの齋藤です。 Google Cloud Platform (GCP) の Identity and Access Management (IAM) は、クラウドリソースへのアクセス制御を行う重要な機能です。しかし、組織が大きくなり、複数のフォルダとプロジェクトを管理するようになると、IAMの管理は複雑化し、手動での運用では限界が見えてきます。 本記事では、実際にGoogle Cloud組織全体のIAMをTerraformで自動化し、組織レベルからフォルダ、プロジェクトまでを一元管理できるシステムを構築した経験を紹介します。 なぜIAMのTerraform化が必要なのか？ GCPをはじめとするクラウド環境では、リソースのデプロイや設定変更の速度が非常に速く、手動での変更管理では追いつかないのが現状です。これはIAM権限についても同様で、特に大規模な組織や多くのプロジェクトが稼働している環境では、権限管理の複雑性が増大し、以下のような課題に直面しがちです。 手動でのIAM管理が抱える課題 可視性の欠如 : 誰が、いつ、どのような権限を、どのリソースに対して付与したのかが、コンソールや監査ログを手動で確認するだけでは把握しにくい。 複数のプロジェクトやフォルダにまたがる権限の全体像を俯瞰することが困難。 一貫性の欠如と設定ミス : 手動での権限付与は、ヒューマンエラーを誘発しやすく、意図しない権限の付与や、必要な権限の漏れが発生しやすい。 プロジェクトや環境ごとに同様の権限設定が必要な場合でも、手動では一貫性を保つのが難しい。 レビュープロセスの困難さ : 変更内容を第三者がレビューする仕組みがない、あるいは機能しにくい。 権限変更が組織のセキュリティポリシーに準拠しているかを確認するのに時間がかかる。 変更履歴の追跡とロールバックの難しさ : 特定の変更がいつ、誰によって行われたのかを追跡するのが難しい。 誤った変更があった場合に、迅速かつ安全に元の状態に戻す（ロールバックする）ことが困難。 セキュリティドリフトの発生 : コードで管理されていない場合、一時的な手動変更が恒久化し、定義されたセキュリティポリシーと実際の環境との間に乖離（ドリフト）が生じやすい。これにより、意図せず広範な権限が付与されたままになる「過剰な権限」が発生する可能性があります。 これらの課題は、セキュリティリスクの増大だけでなく、運用の非効率性、コンプライアンス違反のリスク、そして監査対応時の大きな負担へと繋がります。 TerraformによるIAM管理のアーキテクチャと実装 ここでは、TerraformでIAMを管理するための推奨されるディレクトリ構造、GCPリソースの動的な取得、そしてYAMLファイルによる設定管理の具体例を紹介します。 ディレクトリ構造 TerraformでIAMを効果的に管理するためには、明確でスケーラブルなディレクトリ構造が重要です。以下にその一例を示します。 terraform-iam/ ├── main.tf # メイン設定ファイル (モジュールの呼び出しなど) ├── variables.tf # 変数定義ファイル ├── outputs.tf # 出力値定義ファイル ├── backend.tf # Terraform Stateのバックエンド設定 ├── provider.tf # GCPプロバイダー設定 ├── terraform.tfvars # 変数のデフォルト値または環境固有の値 ├── modules/ │ └── folder_hierarchy/ # フォルダ・プロジェクト階層のIAM管理用モジュール │ ├── main.tf # モジュール本体 │ ├── variables.tf # モジュール変数定義 │ └── outputs.tf # モジュール出力値 └── iam_configs/ # IAM設定を記述するYAMLファイル群 ├── organization/ # 組織レベルのIAM設定 │ └── organization.yaml ├── folders/ # フォルダレベルのIAM設定（フォルダごとにファイル分割） │ ├── production.yaml │ ├── analytics.yaml │ └── development.yaml └── projects/ # プロジェクトレベルのIAM設定（特定のプロジェクト用） ├── project_alpha.yaml └── project_beta.yaml この構造により、IAM設定の責任範囲を明確にし、再利用性を高め、管理の複雑性を低減できます。 GCP IAMとTerraformリソースの対応 GCP IAMは階層的な構造（組織 > フォルダ > プロジェクト > リソース）を持っています。Terraformでは、この階層に応じて異なるリソースタイプが提供されます。 組織 (Organization) レベル :  google_organization_iam_member ,  google_organization_iam_policy フォルダ (Folder) レベル :  google_folder_iam_member ,  google_folder_iam_policy プロジェクト (Project) レベル :  google_project_iam_member ,  google_project_iam_policy 特定リソース (Resource) レベル :  google_storage_bucket_iam_member ,  google_bigquery_dataset_iam_member  など、各サービス固有のリソース。 サービスアカウント (Service Account) レベル :  google_service_account_iam_member ,  google_service_account_iam_policy  (サービスアカウント自身への権限) 承知いたしました。ご提供いただいた詳細なコードとディレクトリ構成、運用面の考慮事項などを盛り込み、「IAMをTerraform化してみた」の記事を再構築します。前回の記事との依存関係をなくし、TerraformによるIAM管理に特化した内容とします。 IAMをTerraform化してみた こんにちは、SCSKの齋藤です。 クラウド環境、特にGoogle Cloud (GCP) におけるIdentity and Access Management (IAM) の管理は、組織のセキュリティと運用効率の要となります。しかし、多くの企業でIAM権限の管理は複雑化し、セキュリティリスクや運用上の課題を抱えがちです。手動での権限付与は、ヒューマンエラー、変更履歴の追跡困難、コンプライアンス遵守の課題など、様々な問題を引き起こす可能性があります。 本記事では、GCP環境におけるIAM権限の管理をより効率的かつ安全に行うため、 TerraformによるInfrastructure as Code (IaC) を導入する具体的なアプローチについて解説します。IAM設定をコードとして管理することで、手動運用が抱える様々な課題を解決し、堅牢でスケーラブルなセキュリティ基盤を構築できます。 第1章：はじめに – なぜ今、IAMのTerraform化が必要なのか？ GCPをはじめとするクラウド環境では、リソースのデプロイや設定変更の速度が非常に速く、手動での変更管理では追いつかないのが現状です。これはIAM権限についても同様で、特に大規模な組織や多くのプロジェクトが稼働している環境では、権限管理の複雑性が増大し、以下のような課題に直面しがちです。 1.1. 手動でのIAM管理が抱える課題 可視性の欠如 : 誰が、いつ、どのような権限を、どのリソースに対して付与したのかが、コンソールや監査ログを手動で確認するだけでは把握しにくい。 複数のプロジェクトやフォルダにまたがる権限の全体像を俯瞰することが困難。 一貫性の欠如と設定ミス : 手動での権限付与は、ヒューマンエラーを誘発しやすく、意図しない権限の付与や、必要な権限の漏れが発生しやすい。 プロジェクトや環境ごとに同様の権限設定が必要な場合でも、手動では一貫性を保つのが難しい。 レビュープロセスの困難さ : 変更内容を第三者がレビューする仕組みがない、あるいは機能しにくい。 権限変更が組織のセキュリティポリシーに準拠しているかを確認するのに時間がかかる。 変更履歴の追跡とロールバックの難しさ : 特定の変更がいつ、誰によって行われたのかを追跡するのが難しい。 誤った変更があった場合に、迅速かつ安全に元の状態に戻す（ロールバックする）ことが困難。 セキュリティドリフトの発生 : コードで管理されていない場合、一時的な手動変更が恒久化し、定義されたセキュリティポリシーと実際の環境との間に乖離（ドリフト）が生じやすい。これにより、意図せず広範な権限が付与されたままになる「過剰な権限」が発生する可能性があります。 これらの課題は、セキュリティリスクの増大だけでなく、運用の非効率性、コンプライアンス違反のリスク、そして監査対応時の大きな負担へと繋がります。 1.2. IAMをTerraformで管理するメリット Infrastructure as Code (IaC) ツールであるTerraformを利用してIAMを管理することで、上記の手動管理の課題を解決し、以下のようなメリットを享受できます。 可視性と一元管理 : IAMポリシーがコードとしてTerraformファイルに明示的に記述されるため、権限の付与状況が一目で把握できます。 組織、フォルダ、プロジェクト、リソースレベルなど、すべてのIAM設定を一元的に管理できます。 バージョン管理と変更履歴 : Gitなどのバージョン管理システムと連携することで、IAMポリシーのすべての変更が履歴として残り、誰が、いつ、何を、なぜ変更したのかを追跡できます。 必要であれば、特定の時点の構成に迅速にロールバックすることも可能です。 レビューと承認プロセス : 権限の変更は、コードとしてプルリクエスト（Pull Request）を通じて提出され、チームメンバーやセキュリティ担当者によるコードレビューを受けることができます。 これにより、変更内容の妥当性、セキュリティポリシーへの準拠、ベストプラクティスとの整合性を確保できます。 自動化と再現性 : Terraformによって、IAMポリシーのデプロイや更新を自動化できます。 これにより、同じポリシーを複数の環境（開発、ステージング、本番）に一貫して適用し、環境間の差異をなくすことが容易になります。 セキュリティドリフトの検出と修正 : Terraform Stateファイルと実際のクラウド環境の状態を比較することで、手動で行われた変更（ドリフト）を検出し、コードに定義された状態に戻すことが可能です。 これにより、常にコードが「真実の源 (Source of Truth)」となり、セキュリティポリシーが強制されます。 コンプライアンスと監査対応の簡素化 : コード化されたポリシーは、監査証跡として機能し、特定の規制（GDPR、PCI DSSなど）への準拠状況を証明しやすくなります。 監査担当者は、コードリポジトリを参照することで、権限設定の詳細を容易に確認できます。 第2章：TerraformによるIAM管理のアーキテクチャと実装 ここでは、TerraformでIAMを管理するための推奨されるディレクトリ構造、GCPリソースの動的な取得、そしてYAMLファイルによる設定管理の具体例を紹介します。 2.1. 推奨されるディレクトリ構造 TerraformでIAMを効果的に管理するためには、明確でスケーラブルなディレクトリ構造が重要です。以下にその一例を示します。 python コードを実行 コードをコピーする terraform-iam/ ├── main.tf # メイン設定ファイル (モジュールの呼び出しなど) ├── variables.tf # 変数定義ファイル ├── outputs.tf # 出力値定義ファイル ├── backend.tf # Terraform Stateのバックエンド設定 ├── provider.tf # GCPプロバイダー設定 ├── terraform.tfvars # 変数のデフォルト値または環境固有の値 ├── modules/ │ └── folder_hierarchy/ # フォルダ・プロジェクト階層のIAM管理用モジュール │ ├── main.tf # モジュール本体 │ ├── variables.tf # モジュール変数定義 │ └── outputs.tf # モジュール出力値 └── iam_configs/ # IAM設定を記述するYAMLファイル群 ├── organization/ # 組織レベルのIAM設定 │ └── organization.yaml ├── folders/ # フォルダレベルのIAM設定（フォルダごとにファイル分割） │ ├── production.yaml │ ├── analytics.yaml │ └── development.yaml └── projects/ # プロジェクトレベルのIAM設定（特定のプロジェクト用） ├── project_alpha.yaml └── project_beta.yaml この構造により、IAM設定の責任範囲を明確にし、再利用性を高め、管理の複雑性を低減できます。 2.2. GCP IAMとTerraformリソースの対応 GCP IAMは階層的な構造（組織 > フォルダ > プロジェクト > リソース）を持っています。Terraformでは、この階層に応じて異なるリソースタイプが提供されます。 組織 (Organization) レベル :  google_organization_iam_member ,  google_organization_iam_policy フォルダ (Folder) レベル :  google_folder_iam_member ,  google_folder_iam_policy プロジェクト (Project) レベル :  google_project_iam_member ,  google_project_iam_policy 特定リソース (Resource) レベル :  google_storage_bucket_iam_member ,  google_bigquery_dataset_iam_member  など、各サービス固有のリソース。 サービスアカウント (Service Account) レベル :  google_service_account_iam_member ,  google_service_account_iam_policy  (サービスアカウント自身への権限) 特に、 _iam_member リソースは既存ポリシーに影響を与えず追記・削除を行うため推奨されますが、 _iam_policy は既存ポリシーを上書きするため注意が必要です。 組織配下のすべてのリソースを動的に取得する仕組み 大規模なGCP環境では、個々のフォルダやプロジェクトを手動で指定するのではなく、組織内の既存リソースをTerraformで動的に取得し、IAM管理の対象とすることが効率的です。 data ブロックを利用してこれを実現します。 # main.tf (または適切な場所に配置) # 組織配下の直属のフォルダを動的に取得 data "google_folders" "organization_folders" { parent_id = "organizations/${var.organization_id}" } # 組織配下のすべてのサブフォルダを再帰的に取得（各直属フォルダの子フォルダを対象） # mapのkeyは直属フォルダのIDになります data "google_folders" "all_subfolders" { for_each = toset([for folder in data.google_folders.organization_folders.folders : folder.folder_id]) parent_id = "folders/${each.key}" # 'each.key' は親フォルダのID } # 組織配下のすべてのプロジェクトを取得 data "google_projects" "organization_projects" { # フィルタで組織IDを直接の親、または祖先に持つプロジェクトを指定 filter = "parent.id:${var.organization_id} OR ancestors.id:${var.organization_id}" } この設定により、TerraformはGCP環境から最新の組織、フォルダ、プロジェクトの情報を取得し、IAM設定の基盤として利用できるようになります。 ローカル値による論理構造の構築 取得した動的なデータを、Terraformの locals ブロックを使って管理しやすい論理構造に変換します。これにより、YAMLファイルで定義するIAM設定と、Terraformリソースを柔軟に連携させることができます。 # main.tf (localsブロックの例) locals { # 組織直下のフォルダ（IAM設定のターゲット指定用） root_folders = { for folder in data.google_folders.organization_folders.folders : folder.display_name => folder.folder_id if !contains(var.excluded_folders, folder.folder_id) # 除外対象フォルダは含めない } # 各ルートフォルダ配下のすべてのサブフォルダ（再帰的に取得した情報を統合） # root_name (例: "production") をキーに、その配下の全フォルダID (root自身含む) のリスト all_subfolders_by_root = { for root_name, root_id in local.root_folders : root_name => concat( [root_id], # ルートフォルダ自身もリストに含める flatten([ # data.google_folders.all_subfolders[root_id].folders は map(object) # その中の各folderオブジェクトからfolder_idを取得しflatten for subfolder in try(data.google_folders.all_subfolders[root_id].folders, []) : [ subfolder.folder_id, ] ]) ) } # 各ルートフォルダ配下のすべてのプロジェクト # root_name (例: "production") をキーに、その配下の全プロジェクトIDのリスト projects_by_root_folder = { for root_name, root_id in local.root_folders : root_name => [ for project in data.google_projects.organization_projects.projects : project.project_id # プロジェクトのancestorsにルートフォルダIDが含まれ、かつ除外対象でないものを抽出 if contains(project.ancestors, root_id) && !contains(var.excluded_projects, project.project_id) ] } # IAM設定ファイルを読み込み、localsに統合 # ここでiam_configs/folders/以下のYAMLファイルを動的に読み込みます。 # 各ルートフォルダ名（例: "production"）に対応するYAMLファイルを検索し、 # 存在すればその内容をyamldecodeでパースし、Terraformで扱いやすいマップ構造に変換します。 folder_iam_configs = { for root_name, _ in local.root_folders : root_name => { # フォルダごとのIAMバインディング folder_bindings = fileexists("${path.module}/iam_configs/folders/${lower(root_name)}.yaml") ? { for binding in flatten([ for iam_entry in yamldecode(file("${path.module}/iam_configs/folders/${lower(root_name)}.yaml")).folder_bindings : [ # YAML内の'folder_bindings'キーを想定 for role in iam_entry.roles : { principal = "${iam_entry.principal_type}:${iam_entry.email}" role = role condition = lookup(iam_entry, "condition", null) # Conditionもサポート } ] ]) : "${binding.role}_${binding.principal}" => binding # Keyとしてroleとprincipalを連結しユニーク化 } : {} # プロジェクトごとのIAMバインディング (フォルダ配下のプロジェクトに適用したい場合) project_bindings = fileexists("${path.module}/iam_configs/folders/${lower(root_name)}.yaml") ? { for binding in flatten([ for iam_entry in yamldecode(file("${path.module}/iam_configs/folders/${lower(root_name)}.yaml")).project_bindings : [ # YAML内の'project_bindings'キーを想定 for role in iam_entry.roles : { principal = "${iam_entry.principal_type}:${iam_entry.email}" role = role condition = lookup(iam_entry, "condition", null) } ] ]) : "${binding.role}_${binding.principal}" => binding } : {} folder_ids = local.all_subfolders_by_root[root_name] # そのルートフォルダ配下の全フォルダID project_ids = local.projects_by_root_folder[root_name] # そのルートフォルダ配下の全プロジェクトID } } } この locals ブロックは、動的に取得したGCPの階層情報と、YAMLファイルで定義されたIAM設定を組み合わせ、 folder_iam_configs というマップ構造に変換します。これにより、後続のモジュール呼び出しで、各フォルダセット（例: productionフォルダとその配下のすべてのフォルダ・プロジェクト）に適用すべきIAMポリシーを動的に渡すことが可能になります。 YAML設定ファイルの読み込みと構造 IAM設定は、 iam_configs/ ディレクトリ配下にYAMLファイルとして定義します。これにより、HCL（HashiCorp Configuration Language）に不慣れなチームメンバーでもIAM設定を記述しやすくなり、Terraformコード本体と設定データを分離できます。 YAML設定ファイルの例 ( iam_configs/folders/production.yaml ) : # production.yaml folder_bindings: - principal_type: "user" email: "admin@example.com" roles: - "roles/resourcemanager.folderViewer" - "roles/resourcemanager.folderEditor" - principal_type: "group" email: "production-team@example.com" roles: - "roles/resourcemanager.folderViewer" - principal_type: "serviceAccount" email: "terraform@your-project.iam.gserviceaccount.com" roles: - "roles/resourcemanager.folderAdmin" project_bindings: - principal_type: "group" email: "production-team@example.com" roles: - "roles/viewer" - "roles/container.developer" # 例えばGKE開発者ロール YAMLファイルでは、 folder_bindings と project_bindings をキーとして、それぞれのレベルで付与したいプリンシパル、そのタイプ、メールアドレス、そしてロールのリストを定義します。これにより、特定のフォルダやその配下のプロジェクトに対して、一貫したIAMポリシーを適用できます。 TerraformによるIAM運用ワークフロー IAMをTerraformで管理することは、単にコードを書くだけでなく、そのコードをセキュアに運用するためのワークフローを確立することが重要です。 コードレビューの導入 IAMポリシーの変更は、セキュリティに直接影響を与えるため、厳格なコードレビュープロセスが不可欠です。 プルリクエスト (Pull Request) ベースの開発 : Terraformコードの変更はすべて、Gitリポジトリのプルリクエストとして提出します。 セキュリティチーム、アーキテクト、または経験豊富なチームメンバーがレビュー担当者となり、変更内容の妥当性、最小権限原則への準拠、セキュリティベストプラクティスとの整合性を確認します。 terraform plan  の活用 : レビューの際には、必ず terraform plan コマンドの出力を共有します。 terraform plan は、Terraformが実行しようとしている変更の差分を詳細に表示するため、意図しない権限の追加や削除がないかを確認する上で極めて重要です。 CI/CDパイプラインとの連携と実行コマンド TerraformによるIAMのデプロイは、CI/CDパイプラインに組み込むことで自動化と信頼性を向上させます。 自動テストとポリシーチェック : Terraformコードの変更がプルリクエストとして提出された際、自動的に terraform validate を実行し、構文エラーがないかを確認します。 さらに、 terraform fmt でコードのフォーマットを統一します。 OPA (Open Policy Agent) や terraform-compliance などのポリシーチェックツールを導入し、セキュリティポリシーやコンプライアンス要件に違反していないかを自動的に検証します。 自動 terraform plan 実行 : プルリクエストが作成されるたびに、CIパイプラインで自動的に terraform plan を実行し、その出力をプルリクエストコメントとして自動投稿します。これにより、レビュー担当者は変更のプレビューを容易に確認できます。 自動デプロイとロールバック戦略 : レビューと承認が完了したプルリクエストは、自動的に本番環境に terraform apply を実行する設定を検討します。 自動デプロイは強力ですが、万が一の事態に備え、迅速なロールバック戦略を準備しておくことが重要です。Gitリポジトリの過去のコミットに git revert で戻し、再度 terraform apply を実行するなどの手順を確立します。 実行コマンド例 : Terraformの実行は、対象スコープを限定することで、影響範囲を制御しながら段階的に適用することができます。 # 全体実行（組織 + 全フォルダ + 全プロジェクトのIAMを適用） terraform plan terraform apply # 組織レベルのみのIAMを適用（特定のモジュールをターゲット指定） terraform plan -target=module.organization_iam terraform apply -target=module.organization_iam # 特定フォルダ配下全体（フォルダ + サブフォルダ + プロジェクト）のIAMを適用 # local.folder_iam_configsをfor_eachで展開しているモジュール（例: module.iam_for_root_folder）に対してターゲットを指定 terraform plan -target=module.iam_for_root_folder["production"] terraform apply -target=module.iam_for_root_folder["production"] # 複数フォルダのIAMを同時に指定して適用 terraform plan -target=module.iam_for_root_folder["production"] -target=module.iam_for_root_folder["analytics"] terraform apply -target=module.iam_for_root_folder["production"] -target=module.iam_for_root_folder["analytics"] -target オプションは、特定の変更を検証・適用する際に非常に有用です。 まとめ 本記事では、GCP環境におけるIAM管理をTerraformでコード化する具体的な方法と、そのメリット、考慮すべき点について解説しました。 IAMをTerraform化することは、手動管理の限界を乗り越え、GCP環境におけるセキュリティと運用ガバナンスを大きく向上させる強力な手段です。ヒューマンエラーのリスクを低減し、透明性のあるレビュープロセスを導入し、変更履歴を完全に追跡できるようになります。さらに、最小権限の原則をコードとして強制することで、セキュリティリスクを大幅に削減することが可能です。 初期の導入には手間と学習コストがかかるかもしれませんが、その投資は長期的なセキュリティ体制の強化と運用効率の向上として必ず報われます。Infrastructure as CodeによるIAM管理は、現代のクラウド運用において不可欠なアプローチです。 継続的な改善と、セキュリティベストプラクティスの適用を通じて、より堅牢で効率的なクラウドインフラを目指していきましょう。 参考 Google Cloud IAM の概要  – Google Cloud 公式ドキュメント https://cloud.google.com/iam/docs/overview?hl=ja

こんにちは、SCSKの齋藤です。 Google Cloudでは、このシークレット管理の課題を解決するために「 Secret Manager 」というサービスを提供しています。Secret Managerは、機密情報を安全に保存、管理、アクセス制御するためのフルマネージドサービスであり、バージョン管理や監査ログ機能も備えています。 本稿では、Cloud RunアプリケーションでSecret Managerを活用する際に検討すべき3つの連携方法を比較し、特に 「Cloud Runのボリュームとしてシークレットをマウントする」 方法の具体的な設定方法と、そのメリットについて深く掘り下げて解説します。 Cloud RunとSecret Managerの基本 まずはCloud RunとSecret Managerそれぞれの基本的な役割を確認しておきましょう。 Google Cloud Run：サーバーレスコンテナプラットフォーム Cloud Runは、コンテナイメージからWebサービスやバッチジョブを実行するためのフルマネージドなサーバーレスプラットフォームです。トラフィックに応じて自動的にスケーリングし、リクエストがない場合は0にスケールダウンするため、コスト効率に優れています。開発者はコンテナイメージを用意するだけで、インフラのプロビジョニングや管理を意識することなくアプリケーションを展開できます。 Google Cloud Secret Manager：シークレットの一元管理サービス Secret Managerは、各種認証情報やAPIキー、証明書といった機密情報を安全に保存・管理するためのサービスです。主な特徴は以下の通りです。 集中管理:  アプリケーションごとに分散しがちなシークレットを一元的に管理できます。 バージョン管理:  シークレットの変更履歴を自動的に管理し、必要に応じて特定のバージョンにロールバックできます。 アクセス制御:  IAM（Identity and Access Management）と連携し、誰がどのシークレットにアクセスできるかを厳密に制御できます。 監査ログ:  シークレットへのアクセスや変更履歴を詳細に記録し、コンプライアンス要件への対応を支援します。 自動ローテーション（一部対応）:  シークレットの自動的な更新をサポートし、セキュリティ強化に貢献します。 Cloud RunでSecret Managerを使用することは、アプリケーションのセキュリティを確保し、運用の手間を削減するための不可欠なステップとなります。 Cloud RunにおけるSecret Managerの連携方法：3つの選択肢 Cloud RunアプリケーションがSecret Managerからシークレット情報を取得する方法は、主に以下の3種類があります。   Secret Managerを読み込む方法 方法 特徴（メリット/デメリット） 1 Cloud Runのボリュームとしてマウント gcloud run jobs create JOB_NAME --image IMAGE_URL --set-secrets=PATH=SECRET_NAME:VERSION 【メリット】 コンフィグでの依存関係が明確。アプリケーションコードはファイル読み込みのみでポータビリティが高い。環境変数よりもセキュアな提供方法。シークレット変更時の挙動が明確化される。 【デメリット】 インスタンス起動時のシークレットアクセス失敗は実行時エラーとなる。シークレットの自動更新には対応しない場合が多い。 2 Cloud Runの環境変数として読み込み gcloud run jobs update JOB_NAME --set-secrets ENV_VAR_NAME=SECRET_NAME:VERSION 【メリット】 アプリケーションコードからシンプルに環境変数としてアクセスできる。インスタンス開始前にシークレット取得が行われるため、失敗した場合はインスタンスが起動しない（早期発見）。 【デメリット】 環境変数はプロセスダンプやログから漏洩するリスクがある。コンフィグでの依存関係がやや見えにくい。シークレットが変更されても、インスタンスが再起動されない限りアプリケーションに反映されない。 3 プログラムからSecret Manager APIを直接読み込み SecretManagerServiceClient()を使用 【メリット】 Cloud Runというサービスに直接依存しない実装となり、ポータビリティが最も高い。シークレットの動的な取得や、特定のタイミングでの取得が可能。 【デメリット】 アプリケーションコードがSecret Manager APIへの依存性を持つ。権限管理が複雑化する可能性。シークレットへのアクセス回数が増え、運用が複雑になる。どのタイミングでシークレットが参照されるか不透明になる。 本稿では、特に 「Cloud Runのボリュームとしてシークレットをマウントする」 方法に焦点を当て、その具体的な設定とメリットを詳細に解説します。 ボリュームマウントでシークレットをファイルとして利用する方法 Cloud RunでSecret Managerのシークレットをボリュームとしてマウントする方法は、コンテナがファイルシステムからシークレットを読み込めるようにするものです。この方法を設定する具体的なコマンドと、それに伴うメリットを見ていきましょう。 設定方法：–set-secretsオプションの使用 シークレットをボリュームとしてマウントするには、 gcloud run jobs create コマンドまたは gcloud run services update コマンド（Cloud Runサービスの場合）で --set-secrets オプションを使用します。 ジョブの場合の例： gcloud run jobs create MY-BATCH-JOB \ --image gcr.io/my-project/my-batch-app \ --set-secrets=/secrets/db_password=my-database-password:latest \ --region us-central1 このコマンドは、 my-database-password というSecret Managerのシークレットの最新バージョンを、コンテナ内の /secrets/db_password というパスにファイルとしてマウントします。アプリケーションは、このパスのファイルを読み込むことでシークレットにアクセスできます。 ボリュームマウント方式のメリット シークレットをボリュームとしてマウントする方式には、複数のメリットがあります。 コンフィグでの依存関係が明確: Cloud Runのデプロイ設定（コマンドラインオプションやYAMLコンフィグレーション）において、どのSecret Managerのシークレットが、どのパスにマウントされるかが明示的に定義されます。これにより、デプロイ設定をレビューするだけで、アプリケーションがどのシークレットに依存しているか、そしてどのバージョンのシークレットを使用しているかが一目で分かり、CI/CDパイプラインの管理やセキュリティ監査の際に可視性が向上します。 アプリケーションコードのポータビリティが高い: シークレットをボリュームとしてマウントする方式では、アプリケーションコード自体はファイルシステムからデータを読み込むだけであり、Secret Manager APIへの直接的な依存性を持ちません。これにより、コンテナイメージのポータビリティを高く保つことができます。例えば、開発環境、ステージング環境、本番環境で異なるSecret Managerのシークレットを使用したい場合でも、同じコンテナイメージを使い回し、各環境のデプロイ設定で適切なシークレットをマウントするだけで対応が完結します。 よりセキュアな方法でアプリケーションにデータを提供: シークレットをアプリケーションに提供する際、セキュリティは最優先事項です。ボリュームとしてマウントされたシークレットは、コンテナ内のファイルシステムにファイルとして配置されます。これにより、ファイルシステムアクセス権限によって読み取りが制御され、意図しないアクセスを防ぎやすくなります。Kubernetesのセキュリティベストプラクティスにおいても、シークレットを環境変数として直接指定するよりも、ボリュームとしてマウントする方が、プロセスダンプなどからの漏洩リスクが低減されるため、よりセキュアであると推奨されています。 シークレット変更時の影響を明確化できる: ボリュームマウント方式の場合、Cloud Runインスタンスの起動時に一度だけシークレットがボリュームに注入されます。これにより、シークレットが変更された際にアプリケーションに新しい値を反映させるには、Cloud Runサービス（またはジョブ）の再デプロイ（または更新）が必要であることが明確になります。この予測可能な挙動は、シークレット変更時の運用計画を立てやすくし、予期せぬ動作を回避する上で有効です。インスタンスの起動時にシークレットへのアクセスが失敗した場合、ボリュームマウントされたシークレットの読み取りも失敗するため、アプリケーションの起動に影響が出ます。これは、シークレットが正しく提供されていないことを早期に検知できるというメリットでもあります。 ローカル開発環境でのシークレット管理 本番環境でSecret Managerをボリュームとしてマウントする方法を用いる一方で、ローカル開発環境でのシークレット管理も考慮する必要があります。開発中にCloud Run環境を完全に再現し、シークレットをマウントすることは非効率的です。 ローカルでの実行時には、以下の手順でシークレットを管理する方法も検討することをお勧めします。 Secret Managerからのシークレット取得:   gcloud secrets versions access latest --secret=SECRET_NAME  コマンドを使用して、Secret Managerから対象のシークレットの最新バージョンを一時的に取得します。必要に応じて特定のバージョンを指定することも可能です。 環境変数への設定:  取得したシークレットの値を、ローカル環境の環境変数として設定します。例えば、Bashでは  export MY_API_KEY="取得したシークレットの値"  のように設定します。 アプリケーションの実行:  設定した環境変数を使用して、アプリケーションをローカルで実行します。 このアプローチにより、本番環境ではファイルシステムからシークレットを読み込むアプリケーションが、ローカルでは環境変数からシークレットを読み込む形となり、開発と本番の間のシークレット取得方法の差異を吸収しつつ、安全な開発環境を維持できます。アプリケーションコードは、単に「 MY_API_KEY という値（ファイルまたは環境変数）を読み込む」という抽象化されたロジックに留めることが可能です。 まとめ クラウドネイティブな環境におけるシークレット管理は、アプリケーションのセキュリティと運用効率の根幹をなす要素です。Google Cloud Secret Managerは、その強力な機能によってこの課題を解決する重要なサービスであり、Cloud Runとの連携はサーバーレスアプリケーションの安全な運用に不可欠です。 本稿で解説したように、Cloud RunでSecret Managerを活用する方法は複数存在します。その中でも、 「Cloud Runのボリュームとしてシークレットをマウントする」 方法は、以下の点で注目すべき特徴とメリットを提供します。 設定の可視性が高く、運用管理が容易である点。 アプリケーションコードのポータビリティを維持し、環境間で同じコンテナイメージを再利用しやすい点。 環境変数に比べてシークレットの露出リスクが低く、Kubernetesのセキュリティベストプラクティスにも合致する、よりセキュアな提供方法である点。 シークレット変更時のアプリケーションの挙動が予測しやすく、運用計画やトラブルシューティングが容易である点。 どの方法を選択するかは、アプリケーションの特性、チームのスキルセット、組織のセキュリティポリシーによって最適な判断が異なります。しかし、上記で述べたボリュームマウント方式のメリットは、Cloud Runでのシークレット管理戦略を検討する上で重要な考慮点となるでしょう。 安全で効率的なクラウドネイティブ開発を目指す上で、Google Cloud RunとSecret Managerを組み合わせたセキュアなシークレット管理は不可欠な要素です。本稿が、貴社のクラウド環境におけるシークレット管理戦略の策定に役立ち、より堅牢なシステム構築の一助となれば幸いです。 参考資料 Cloud Run にシークレットを構成する  – Google Cloud 公式ドキュメント https://cloud.google.com/run/docs/configuring/secrets?hl=ja Secret Manager の概要  – Google Cloud 公式ドキュメント https://cloud.google.com/secret-manager/docs/overview?hl=ja

こんにちは、SCSKの齋藤です。 皆さん、日々のクラウドセキュリティ運用で、こんな課題に直面していませんか？ 「あれ、このVMのポート、外部に開けっ放しじゃないか？」 「新しいストレージバケットが作られたけど、パブリック公開の設定になってないか心配だ…」 「不審なアクセスアラートが多すぎて、どれから対応すべきか分からない…」 クラウド環境は、その柔軟性とスケーラビリティでビジネスに多大な恩恵をもたらしますが、同時にセキュリティ管理の複雑性を増大させます。複数のプロジェクト、多種多様なサービス、日々刻々と変化するリソース群…これらのセキュリティ状態を常に正確に把握し、潜在的なリスクに迅速に対応することは、決して容易ではありません。 こうした状況を打開し、クラウドセキュリティの「見える化」と「運用効率化」を加速させるべく、私たちはGoogle Cloudが提供する統合セキュリティ管理プラットフォーム、「 Security Command Center（SCC） 」の導入に踏み切りました。 本記事では、SCCを実際に有効化し、利用してみた経験に基づき、SCCが提供する主要な機能、多くの企業が検討時に気になるであろう「 スタンダードティアとプレミアムティアの比較 」、そして「 料金設定 」について、実践的な視点から解説していきます。クラウド環境のセキュリティ管理にお悩みの皆様にとって、本記事が具体的な解決策を見つけるための一助となれば幸いです。 クラウドセキュリティにおける現在の課題とSCCの必要性 現代の企業がクラウド環境において直面するセキュリティ課題は多岐にわたります。これらの課題が、従来のセキュリティ運用手法では対応しきれないレベルに達していることが、SCCのような統合プラットフォームの必要性を高めています。 リソースの膨大化と可視性の欠如 GCP環境では、仮想マシン（VM）、データベース、ストレージ、ネットワーク設定など、多種多様なリソースが瞬時にデプロイされ、変更されます。大規模な組織では、これらのリソースが数千、数万に上ることも珍しくありません。個々のリソースに対するセキュリティ設定の確認や、全体像の把握は極めて困難であり、設定ミスやポリシー違反が潜在的な脆弱性として放置されるリスクが高まります。特に、シャドーITや非公式なリソース展開が発生した場合、それらのセキュリティ状態を把握することはほぼ不可能です。 セキュリティ情報のサイロ化と統合の困難さ 従来のセキュリティ運用では、脆弱性スキャナー、脅威検出システム、アクセスログ監視ツールなど、複数のセキュリティツールを個別に導入・運用することが一般的でした。これらのツールはそれぞれ特定の領域に特化した情報を提供しますが、その情報がバラバラに管理されるため、全体的なセキュリティ状態を把握し、優先順位を付けて対応することが困難になります。結果として、重要なアラートが見過ごされたり、インシデント対応の初動が遅れたりするリスクが増大します。 手作業による運用限界とアラート疲労 クラウド環境は常に変化しており、新しいリソースのデプロイ、設定変更、脅威の発生などが日常的に発生します。これらすべてを手作業で監視し、アラートに対応するには膨大な時間と人的リソースを要し、ヒューマンエラーのリスクも高まります。また、各ツールから大量に発報されるアラートの中から、本当に対応すべき「重要」なアラートを特定することが難しく、セキュリティ担当者が「アラート疲労」に陥り、重要なアラートを誤って見過ごしてしまう状況も頻繁に発生します。 コンプライアンス要件への継続的な対応 GDPR、HIPAA、PCI DSS、日本の個人情報保護法など、業界や地域ごとに多様なコンプライアンス要件が存在します。これらの要件に継続的に準拠していることを証明するためには、定期的な監査と継続的なセキュリティ状態の確認が不可欠です。手作業によるコンプライアンスチェックは非常に負担が大きく、またリアルタイムでの準拠状況の把握が困難です。 これらの課題を解決し、クラウド環境におけるセキュリティの可視性、効率性、対応能力を飛躍的に向上させるプラットフォームとして、Google Cloud Security Command Centerが位置づけられます。SCCは、GCP環境全体のセキュリティリスクを「発見」「調査」「対応」するための一元化されたプラットフォームであり、クラウドセキュリティの「司令塔」としての役割を担います。 Security Command Center（SCC）とは？ Google Cloud Security Command Center（SCC）は、GCP環境全体におけるセキュリティの状態を包括的に把握し、潜在的な脅威や脆弱性をプロアクティブに管理するための統合プラットフォームです。SCCを導入することで、以下の主要な課題を解決し、セキュリティ運用に新たな価値をもたらします。 SCCが提供する主要な価値 SCCは、主に以下の3つの主要な価値を提供することで、クラウドセキュリティ運用の変革を促進します。 1. 包括的な可視性（Visibility）： GCP環境内に存在するすべてのアセット（リソース）を自動的に検出・インベントリ化し、常に最新の状態を把握できるようにします。これにより、どのプロジェクトにどのようなリソースが存在し、それらがどのような設定になっているかを一元的に確認できます。さらに、既知の脆弱性、設定ミス、コンプライアンス違反、不審な活動などを自動で検出し、それらを「発見事項（Findings）」として集約します。これにより、「何がどこにあるか」「どこに脆弱性があるか」「何が起きているか」という基本的な問いに対する答えが明確になります。 2. 優先順位付けと調査の効率化（Prioritization & Investigation）： 検出された膨大な数の発見事項に対し、その深刻度や影響度に基づいて優先順位を自動的に付与します。これにより、セキュリティチームは、対応すべき最も重要なリスクに集中し、限られたリソースを最適に配分できます。各発見事項には詳細な情報（関連するアセット、影響範囲、推奨される是正措置など）が付与されており、セキュリティアナリストによる調査を効率化し、迅速な意思決定を支援します。 3. 対応と自動化の促進（Response & Automation）： SCCが検出した発見事項は、APIを通じて外部のセキュリティ運用ツール（SIEM、SOARなど）と連携することが可能です。これにより、検出された脅威や脆弱性に対する自動的な対応ワークフローを構築し、手動での介入を最小限に抑えながら、迅速かつ効果的なインシデントレスポンスを実現します。また、コンプライアンス監査への継続的な準拠状況を可視化し、レポート生成を支援することで、監査対応の効率化にも貢献します。   SCCを有効化してみた！ 複数のプロジェクトを横断して包括的な監視を行いたかったため、組織レベルでのSCC有効化を選択しました。 有効化プロセスは想像以上にスムーズ SCCの有効化プロセスは、驚くほど簡単でした。 GCP Consoleにログインし、SCCダッシュボードへ移動。 「Security Command Centerを有効にする」ボタンをクリック。 組織レベルでの有効化を選択し、組織IDを確認。 必要なサービスアカウントの作成と権限付与は自動で行われます。 数クリックで有効化完了！ 正直なところ、設定に悩む時間はほとんどありませんでした。有効化後、すぐにデータが収集され始めるわけではありませんが、最初の完全なアセットインベントリの収集には数時間から最大24時間程度かかる旨のメッセージが表示されました。   SCCの核心機能深掘り SCCはクラウド環境のセキュリティライフサイクル全体を支援するための、多岐にわたる機能を提供します。 アセットインベントリ SCCの基盤となるのは「アセットインベントリ」機能です。GCP環境内に存在するすべてのリソースを自動的に検出し、体系的にカタログ化します。これにより、セキュリティ担当者は以下のことを実現できます。 リソースの網羅的な把握:  どのプロジェクトに、どのような種類のVM、ストレージ、データベース、ネットワークが存在するのかを常に最新の状態で把握できます。シャドーITや意図しないリソース展開のリスクを低減します。 設定情報の詳細化:  各アセットのIAMポリシー、ネットワーク設定、公開設定などの詳細情報を確認できます。これにより、「このバケットは本当にパブリック公開が必要なのか？」といった疑問に迅速に答えることができます。 脆弱性検出 SCCは、Googleが提供する様々なセキュリティ検出サービスと連携し、GCP環境内の脆弱性や設定ミスを自動的に検出します。 Security Health Analytics (SHA):  GCPリソースの設定ミスや構成上の脆弱性を継続的にスキャンします。広範なIPアドレスからのSSHアクセス許可、公開設定になっているCloud Storageバケット、過剰な権限を持つIAMロールなどを検出します。また、CISベンチマーク（Center for Internet Security）などの業界標準セキュリティベンチマークへの準拠状況を評価し、具体的な改善推奨事項を提供します。 Web Security Scanner (WSS):  GCP上で稼働するWebアプリケーションの一般的な脆弱性（XSS、SQLインジェクションなど）を検出します。定期的なスキャンを設定することで、新たな脆弱性が生まれていないかを継続的に監視できます。 Container Threat Detection (CTD):  GKE（Google Kubernetes Engine）環境のランタイム動作を監視し、コンテナ内での不審なアクティビティ（特権昇格、マルウェア実行、不審なバイナリ実行など）を検出します。 脅威検出 脆弱性の検出だけでなく、実際に発生している、あるいは発生しようとしている脅威をリアルタイムで検出することも、SCCの重要な役割です。 Event Threat Detection (ETD):  Cloud Audit Logs、VPC Flow Logs、DNS logsなど、GCPの様々なログデータを継続的に監視し、機械学習と脅威インテリジェンスを活用して不審な活動を検出します。ブルートフォース攻撃、認証情報の不正使用、マルウェア感染の兆候、データ流出の試み、サービスアカウントの異常な動作などを検出します。 Cloud DLP (Data Loss Prevention) 連携:  Cloud StorageバケットやBigQueryデータセットなどに保存されている機密データをスキャンし、発見された機密データに基づいてリスク（例：不適切な公開設定のバケットに機密データが存在する）をSCCに報告します。 スタンダードティア vs プレミアムティア SCCには、「スタンダードティア」と「プレミアムティア」の2つのサービスティアが存在します。それぞれ提供される機能の範囲と料金体系が大きく異なるため、組織の規模、セキュリティ要件、予算に応じて最適なティアを選択することが非常に重要です。 スタンダードティア スタンダードティアは、SCCの基本的な機能を提供し、 無料 で利用できます。クラウドセキュリティの「見える化」をこれから始める組織や、コストを抑えたい場合に適しています。 スタンダードティアで利用できる主な機能： アセットインベントリ:  GCP環境内のすべてのリソースを自動的に発見し、インベントリ化します。 Web Security Scanner (WSS):  GCP上でホストされているWebアプリケーションの一般的な脆弱性をスキャンし、検出結果をSCCに集約します。 Google Cloud Armor との統合:  Google Cloud ArmorのDDoS保護やWAFに関する情報がSCCに表示されます。 基本的な脅威検出:  Google Cloudの脅威インテリジェンスを活用した基本的な脅威情報が提供されます。 スタンダードティアのメリット： 無料:  コストをかけずにクラウド環境の基本的なセキュリティ状況を把握できます。 手軽に導入可能:  複雑な設定は不要で、すぐに使い始められます。 基本的な可視性の確保:  リソース把握やWebアプリケーションの初期脆弱性検出の第一歩として最適です。 プレミアムティア プレミアムティアは、スタンダードティアのすべての機能に加えて、より高度な検出機能、自動化、コンプライアンス管理、調査ツールを提供します。 有料 サービスですが、その分、強固なセキュリティ体制を構築するための強力なツールとなります。 プレミアムティアで利用できる主な追加機能： Security Health Analytics (SHA) の高度な検出:  スタンダードティアのWSSよりもはるかに広範なGCPリソースの設定ミス、不適切なIAMポリシー、ネットワーク構成の脆弱性などを継続的にスキャンします。CISベンチマークなどの業界標準セキュリティベンチマークへの準拠状況を自動評価し、具体的な改善推奨事項を提供します。 Event Threat Detection (ETD):  GCPの各種ログデータ（Cloud Audit Logs, VPC Flow Logs, DNS logsなど）をリアルタイムで分析し、機械学習とGoogleの脅威インテリジェンスを活用して、高度な脅威（認証情報の不正使用、マルウェア実行、異常なデータ抽出など）を検出します。 Container Threat Detection (CTD):  GKE環境でのコンテナランタイムにおける不審な活動を検出します。 Rapid Vulnerability Detection (RVD):  特定の重大な脆弱性（例：Log4jの脆弱性）が存在しないかを迅速にスキャンし、影響を受けるリソースを特定します。 Findings APIと高度なエクスポート機能:  SCCが検出したすべての「発見事項（Findings）」にプログラムでアクセスできるAPIを提供します。これにより、検出結果をSIEMやSOARツールと連携させ、自動化された対応ワークフローを構築できます。BigQueryへのエクスポート機能により、長期的な分析やカスタムレポート作成も可能です。 脅威の優先順位付けと調査機能の強化:  検出された Findingsの中から、最も重大な脅威や脆弱性を自動的に優先順位付けし、対応すべき事項を明確にします。 プレミアムティアのメリット： 包括的なセキュリティ可視化:  アセットから脆弱性、脅威、コンプライアンスまで、GCP環境全体のセキュリティ状況を深く掘り下げて可視化します。 高度な脅威検出:  機械学習とGoogleの脅威インテリジェンスにより、洗練された攻撃や異常な行動を早期に発見できます。 コンプライアンス管理の効率化:  CISベンチマーク対応などにより、規制要件への準拠状況を継続的に評価・報告できます。 自動化と連携:  APIを通じて、既存のセキュリティツールやワークフローとの連携が容易になり、自動化された対応が可能になります。 どちらを選ぶべきか？判断基準 比較項目 スタンダードティア プレミアムティア 料金 無料 有料（アクティブなアセット数に応じた従量課金） アセットインベントリ ○ (基本的) ○ (詳細、長期履歴保持) 脆弱性検出 Web Security Scanner (WSS) のみ SHA, ETD, CTD, RVD, VMM連携など、広範かつ高度な検出 脅威検出 基本的な脅威情報 高度な機械学習ベースのリアルタイム脅威検出 (ETD, CTD) コンプライアンス 制限的 CISベンチマーク評価など、体系的なコンプライアンス管理 自動化/連携 制限的 高度なAPI連携 (Findings API)、SIEM/SOAR統合 データ保持期間 短い（数日～数週間） 長い（数カ月） 推奨組織 小規模、セキュリティ初心者、コスト重視、まず可視化したい 大規模、高セキュリティ要件、専門チームあり、包括的管理志向 クラウドセキュリティへの取り組みをこれから始める方や、GCP環境が比較的小規模な場合は、まず スタンダードティアでSCCの基本的な可視化能力を体験することをお勧めします。 その後、GCP環境の拡大やセキュリティ要件の高まりに応じて、プレミアムティアへのアップグレードを検討するのが賢明なアプローチと言えます。 気になる料金設定 SCCプレミアムティアの導入を検討する際、多くの方が気になるのが料金体系だと思います。SCCプレミアムティアの料金モデルは、主に「 組織内のアクティブなアセット数 」に基づいて計算されます。 基本的な料金モデルの概要 SCCプレミアムティアの料金は、 組織内のアクティブなアセット（リソース）の数 によって決まります。具体的には、主要なGCPアセットタイプ（Compute Engine VMインスタンス、Cloud SQLインスタンス、Cloud Storageバケット、BigQueryデータセット、GKEクラスターなど）がカウント対象となります。 料金は、これらのアクティブなアセットタイプごとに設定された単価（例：「VMインスタンス1台あたり月額Xドル」）に基づき、合計で算出されます。最新かつ正確な料金情報は、常に Google Cloudの公式料金ページ で確認するようにしてください。 コスト最適化のためのヒント SCCプレミアムティアの利用料金を最適化するために、いくつかの重要なポイントがあります。 不要なアセットの定期的なクリーンアップ:  SCCはアクティブなすべてのアセットをカウントします。開発やテストで一時的に作成され、その後放置されているVMやストレージバケットなどがないか定期的に確認し、不要なものは削除しましょう。これはコスト削減だけでなく、セキュリティリスク（未管理のリソースに脆弱性が放置されるなど）の低減にも繋がります。 監視対象のスコープを最適化:  組織内の全てのプロジェクトやフォルダをSCCの監視対象にする必要があるか再検討します。非常に機密性の低い、あるいはセキュリティリスクが極めて低いと判断されるプロジェクトであれば、監視対象から除外することでコストを抑えられる可能性もあります。ただし、これにはセキュリティカバレッジの低下というトレードオフが伴うため、慎重な検討が必要です。 無料ティアの有効活用:  もしプレミアムティアのコストが見合わないと感じる場合でも、スタンダードティアは無料で利用できます。基本的な可視性を確保するだけでも、セキュリティ体制は大きく改善されます。 無料トライアルと見積もり:  Google Cloudは新規ユーザー向けに無料トライアルクレジットを提供しており、これを使ってSCCプレミアムティアを試すことができます。また、GCPコンソールの「料金」セクションや、Googleの営業担当者に問い合わせることで、具体的な見積もりを取得することも可能です。 SCCプレミアムティアは決して安価なサービスではありませんが、そのコストは重大なセキュリティインシデントが発生した場合の損害（データ漏洩による罰金、ブランドイメージの失墜、事業停止など）と比較すれば、はるかに低い投資となるでしょう。重要なのは、その価値とコストのバランスを理解し、組織のニーズに合ったプランを選択することです。 まとめ SCCがもたらす主要な成果は以下の通りです。 セキュリティ状況の「見える化」とリスクの事前特定: 組織内のすべてのアセットが網羅的に可視化され、それに紐づく脆弱性や脅威が明確になりました。これにより、漠然とした「何か起こるかもしれない」という不安が、「この脆弱性を優先的に修正しよう」「この脅威アラートには直ちに対応しよう」という具体的なアクションプランへと変わりました。 セキュリティ運用の「効率化」と「自動化」への道筋: 手動での確認作業が大幅に削減され、セキュリティチームの負担が軽減されました。また、Findings APIを活用することで、検出から是正までのワークフローを自動化する道筋が見え、インシデント対応の迅速化と人的ミスの削減が期待できます。 コンプライアンスへの「自信」と信頼性の向上: CISベンチマークへの準拠状況が継続的に評価されることで、監査対応の準備が格段に楽になり、GCP環境が常にセキュリティベストプラクティスに則っているという確信を持てるようになりました。これは、企業としての信頼性向上にも直結します。 もちろん、プレミアムティアの料金は安価ではありません。しかし、今日のサイバー脅威の高度化と、データ漏洩やシステム停止がビジネスにもたらす壊滅的な影響を考えれば、SCCへの投資は、企業を守るための必要不可欠なコストであると考えます。 もし今、あなたがクラウドセキュリティの課題に直面し、情報のサイロ化や対応の遅延に悩んでいるのであれば、ぜひ一度、Google Cloud Security Command Centerを有効化してみてください。 参考 Security Command Center の概要  – Google Cloud 公式ドキュメント https://cloud.google.com/security-command-center/docs/concepts-security-command-center-overview?hl=jahttps://cloud.google.com/security-command-center/docs/overview?hl=ja Security Command Center の料金  – Google Cloud 公式ドキュメント https://cloud.google.com/security-command-center/pricing?hl=ja

こんにちは、SCSKの齋藤です。 本記事では、IAMのセキュリティ分析情報を用いて、権限整理を行った事例について紹介します。   はじめに、なぜIAMの権限整理が必要なのか？ クラウドサービスの普及により、企業は以前にも増して迅速にアプリケーションを開発し、多様なサービスを展開できるようになりました。その一方で、クラウド環境におけるセキュリティの重要性も飛躍的に高まっています。特に、Google Cloud (GCP) におけるIdentity and Access Management (IAM) は、リソースへのアクセスを制御するまさに「要」となる機能であり、その適切な管理はセキュリティ確保の最優先事項と言えるでしょう。 しかし、実際の運用現場では、IAM権限の管理はしばしば複雑化し、気付かないうちに「過剰な権限」が付与されているケースが散見されます。なぜこのような状況が生まれるのでしょうか？ 緊急の対応で一時的に広い権限を付与したままにしてしまう、権限付与の基準が曖昧なままプロジェクトが進む、担当者の異動や役割変更に合わせて権限が見直されない、といった要因が挙げられます。 過剰なIAM権限がもたらすリスク 過剰なIAM権限は、想像以上に深刻なリスクをもたらします。 セキュリティ侵害のリスク増大 : 最も重大なリスクです。悪意のある攻撃者や、内部の不正行為者が、必要以上の権限を利用して機密情報にアクセスしたり、システム設定を改ざんしたりする可能性があります。例えば、本番データベースの削除権限を持つ開発者アカウントが乗っ取られた場合、サービス停止やデータ消失といった壊滅的な被害につながる恐れがあります。 誤操作による影響の拡大 : 意図せずして、重要なリソースを削除したり、設定を変更したりする「ヒューマンエラー」のリスクが高まります。例えば、開発環境だと思って操作していたつもりが、本番環境のデータを誤って消去してしまった、といった事態は避けたいものです。最小権限の原則を守ることで、このような事故発生時の影響範囲を限定できます。 コンプライアンス違反 : GDPR、HIPAA、PCI DSS、日本の個人情報保護法など、多くの規制や業界標準では、データへのアクセス制御に関する厳格な要件が定められています。過剰な権限は、これらのコンプライアンス要件を満たさない状態を生み出し、監査での指摘や法的な問題に発展する可能性があります。 監査対応の複雑化と負担増 : 誰が、いつ、どこに、どのようなアクセス権を持っているかを正確に把握できないと、監査対応時に膨大な時間と労力を要します。透明性の低い権限管理は、企業全体のガバナンス低下にも繋がります。 IAMの重要性 – クラウドセキュリティの要 クラウド環境におけるセキュリティは、「責任共有モデル」に基づいて構築されています。クラウドプロバイダ（Google Cloud）はインフラストラクチャやプラットフォームのセキュリティを担当しますが、ユーザーは自身のデータ、アプリケーション、そして「IAM設定」に関するセキュリティに責任を持ちます。IAMは、このユーザー側の責任範囲において、最も基本的ながら最も重要なセキュリティ制御点なのです。 ここで不可欠なのが「 最小権限の原則 (Principle of Least Privilege) 」です。これは、ユーザーやサービスがその職務を遂行するために必要な最小限の権限のみを付与すべきである、というセキュリティの基本原則です。この原則を徹底することで、万が一アカウントが侵害された場合でも、その被害を最小限に抑えることができます。 本記事で扱う課題と解決策の概要 本記事では、GCP環境における過剰なIAM権限という課題に対し、Security Command Center (SCC) の先進的なセキュリティ分析機能を活用した具体的な解決策を提示します。 SCCは、GCP環境全体にわたる脅威、脆弱性、設定ミスを検出・管理するための統合プラットフォームです。その中でも、特にPremiumプランで利用可能な「IAMセキュリティ分析（Policy Intelligence）」は、IAMポリシーの構成を詳細に分析し、過剰な権限や未使用の権限といった「洞察（Insights）」を提供してくれます。   Google CloudのIAMとその複雑性 Google Cloud IAMは、GCPリソースへのアクセスをきめ細かく制御するための強力なフレームワークです。しかし、その強力さゆえに、適切に理解し管理しなければ、あっという間に複雑化し、手に負えない状況に陥る可能性があります。 IAMの基本概念 GCP IAMは、「誰が」「何をできるか」「どのリソースに対して」という3つの主要な要素で構成されます。これらが組み合わさって「ポリシー」を形成します。 プリンシパル (Principal) ： 誰が アクセスを許可されるかを示すエンティティです。 種類としては、Googleアカウント（個々のユーザー）、サービスアカウント（アプリケーションやVMインスタンス）、Googleグループ（複数のGoogleアカウントの集合）、G Suiteドメイン、またはCloud Identityドメイン全体があります。 例:  user:alice@example.com ,  serviceAccount:my-app@my-project.iam.gserviceaccount.com ,  group:devs@example.com ロール (Role) ： 何をできるか 、つまりプリンシパルに付与される権限の集合です。 ロールは、一つ以上の「権限 (Permission)」を含みます。権限は、特定のアクション（例:  compute.instances.start 、 storage.objects.get ）を実行する能力を定義します。 例:  roles/compute.viewer  (VMインスタンスを見る権限),  roles/storage.objectAdmin  (Cloud Storageオブジェクトを管理する権限) リソース (Resource) ： 権限が適用される対象となるGCPリソースです。 プロジェクト、フォルダ、組織といった階層的なリソースから、Compute EngineのVMインスタンス、Cloud Storageのバケット、BigQueryのデータセットといった具体的なサービスリソースまで多岐にわたります。 IAMポリシーは、このリソース階層のいずれかのレベルで設定されます。下位のリソースは上位のリソースからポリシーを継承します。 ポリシー (Policy) ： 上記3つの要素を組み合わせたものです。特定のプリンシパルに、特定のロールを、特定のリソースに対して付与します。 技術的にはJSON形式で表現され、以下のような構造を持ちます。 { "bindings": [ { "role": "roles/viewer", "members": [ "user:alice@example.com", "serviceAccount:my-app@my-project.iam.gserviceaccount.com" ] }, { "role": "roles/editor", "members": [ "group:developers@example.com" ], "condition": { "title": "Access only from trusted IPs", "expression": "request.time < timestamp(\"2024-12-31T23:59:59Z\") && caller.ip == \"203.0.113.0/24\"" } } ], "etag": "...", "version": 3 } 上記の例では、 roles/viewer がAliceとサービスアカウントに、 roles/editor がdevelopersグループに付与されており、後者にはさらに条件が指定されています。 ロールの種類と役割 GCP IAMには、主に以下の2種類のロールがあります。 プリセットロール (Predefined Roles) ： Googleが事前に定義しているロールで、一般的なユースケースに合わせて最適化されています。例:  roles/viewer  (閲覧者),  roles/editor  (編集者),  roles/owner (オーナー) などが存在します。 利便性が高く、多くのシナリオで利用できますが、含まれる権限が多すぎることが過剰な権限付与の原因となることがあります。 カスタムロール (Custom Roles) ： ユーザーが特定の要件に合わせて、必要な権限のみを厳選して作成できるロールです。 最小権限の原則を徹底するために非常に有効です。例えば、特定のAPIの読み取り権限と、特定のファイルへの書き込み権限だけを組み合わせたカスタムロールを作成できます。 手間はかかりますが、セキュリティを強化し、誤操作のリスクを減らす上で推奨されるアプローチです。   Security Command Center (SCC) とは Security Command Center (SCC) は、Google Cloud環境全体のセキュリティ状態を包括的に可視化し、リスクを特定・管理するための統合プラットフォームです。脆弱性、設定ミス、脅威、コンプライアンス違反など、多岐にわたるセキュリティ上の問題を発見し、優先順位を付けて対応を促すことで、組織のセキュリティ体制を強化します。 Security Command Centerの概要 SCCは、以下のような広範なセキュリティ情報を集約し、一元的に管理します。 アセットの可視化 : GCP環境内のすべてのリソース（VM、ストレージバケット、データベース、ネットワーク設定など）を自動的に検出し、インベントリとして表示します。 検出結果の管理 : さまざまなセキュリティ検出サービス（VMの脆弱性スキャン、ストレージの設定ミス、ネットワーク設定の異常、悪意のあるアクティビティなど）からの検出結果を一箇所に集約し、分析・管理できます。 脅威の特定 : Cloud LoggingやCloud DNSなどから収集したログデータを分析し、マルウェア、不正アクセス、データ流出などの脅威を検出します。 コンプライアンス状況のモニタリング : CISベンチマークやPCI DSSなど、業界標準のセキュリティ要件に対する準拠状況を評価します。 IAMセキュリティ分析 : 本記事の主題である、IAM権限に関する過剰な付与や未使用の権限などを検出します。 SCCは、これらの情報を使いやすいダッシュボードに統合し、セキュリティチームが効率的にリスクを把握し、対策を講じることを可能にします。 SCCのプランと機能 SCCには、大きく分けて「Standardプラン」と「Premiumプラン」の2つのサービスティアがあります。 Standardプラン : 基本的なセキュリティ評価と脅威検出機能を提供します。 Cloud Security Health Analytics (設定ミス検出)、Cloud DLP (機密データ検出)、Web Security Scanner (Webアプリ脆弱性スキャン)、Security Health Analytics for Kubernetes (Kubernetesセキュリティ評価) など、一部のサービスが利用可能です。 重要なのは、 IAMセキュリティ分析機能はStandardプランでは利用できない という点です。 Premiumプラン : Standardプランの全機能に加え、より高度なセキュリティ分析と脅威インテリジェンスを提供します。 IAMセキュリティ分析（Policy Intelligence） は、このPremiumプランでのみ利用可能です。 これ以外にも、脅威の優先順位付け、セキュリティ調査ワークベンチ、コンプライアンスダッシュボード、高度な侵入検知（Event Threat Detection）など、エンタープライズレベルのセキュリティ運用に不可欠な機能が多数含まれています。 過剰なIAM権限を自動的に洗い出すためには、 SCC Premiumプランの有効化が必須 となります。 IAMセキュリティ分析（Policy Intelligence/Policy Insights） SCC Premiumプランが提供するIAMセキュリティ分析は、Google Cloudの「Policy Intelligence」機能群の一部です。Policy Intelligenceは、IAMポリシーの構成を分析し、より安全で効率的なポリシー管理を支援するAIベースのツールセットです。主なコンポーネントは以下の通りです。 Policy Analyzer (Policy Insights) ： 「誰が、どのリソースに対して、どのようなアクセス権を持っているか」を分析し、 過剰な権限 や 未使用の権限 などの「洞察（Insights）」を提供します。 例えば、「このサービスアカウントは過去90日間、付与された権限の一部しか使用していない」といった情報や、「このユーザーは、必要以上の広範な管理者権限を持っている」といった具体的な推奨事項を提示します。 SCCは、このPolicy Analyzerが生成する「Policy Insights」を、検出結果としてダッシュボードに表示します。これが、本記事の主題である「過剰な権限の洗い出し」の核となります。 Policy Simulator ： IAMポリシーを変更した場合に、その変更が既存のアクセスにどのような影響を与えるかを シミュレーション できます。 実際にポリシーをデプロイする前に、意図しないアクセス拒否や、予期せぬアクセス許可が発生しないかを確認できるため、安心して変更作業を進めることができます。 Policy Troubleshooter ： 特定のプリンシパルが特定のリソースにアクセスできない、またはアクセスできるべきではないのにアクセスできてしまう、といったトラブルシューティングを支援します。 与えられたプリンシパル、リソース、権限に基づいて、アクセスが許可された理由、または拒否された理由を詳細に分析してくれます。 SCC Premiumプランでは、これらのPolicy Intelligence機能、特にPolicy Analyzerの洞察を「検出結果」として一元的に可視化し、セキュリティ運用のワークフローに統合します。これにより、これまで手動では困難だった、大規模な環境におけるIAM権限の健全性チェックと改善が、はるかに効率的に行えるようになります。 実践！SCCで過剰なIAM権限を洗い出す それでは実際に、Security Command Center Premiumプランを使用して、GCP環境における過剰なIAM権限を洗い出す手順を見ていきましょう。 SCC Premiumプランの有効化と設定 過剰なIAM権限の分析には、まずSCC Premiumプランを有効化する必要があります。 組織レベルでの有効化 : SCCは組織レベルで有効化するのが一般的です。これにより、組織内のすべてのフォルダとプロジェクトがSCCの監視対象となります。 Google Cloud Consoleで、組織リソースを選択し、ナビゲーションメニューから「Security Command Center」を選択します。 初回アクセスの場合、「概要」ページで「有効化」ボタンが表示されます。StandardプランかPremiumプランかを選択する画面が表示されたら、「Premium」を選択して有効化を進めます。 有効化には、 roles/securitycenter.admin  などの適切なIAM権限が必要です。通常は組織の管理者アカウントで行います。 有効化後、SCCが組織内のアセットをスキャンし、検出結果を収集するまでに時間がかかる場合があります（数時間から24時間程度）。 必要なIAM権限の確認 : SCCのダッシュボードを閲覧し、検出結果を管理するためには、適切なIAM権限が必要です。 一般的に、以下のロールが付与されたユーザーアカウントまたはサービスアカウントが必要です。 roles/securitycenter.admin  (管理者の場合) roles/securitycenter.viewer  (検出結果を閲覧するのみの場合) roles/securitycenter.findingsEditor  (検出結果のステータス変更などを行う場合) IAMセキュリティ分析（Policy Intelligence）に関する洞察を表示するためには、これらのSCCロールに加え、関連するリソースのIAMポリシーを参照する権限も間接的に必要となりますが、SCC Premiumが有効であれば、通常は自動的に権限が補完されます。 ポリシーの分析情報を管理するために必要な権限を取得するには、分析情報を管理するプロジェクト、フォルダ、または組織に対して次の IAM ロールを付与する必要があります。 roles/recommender.iamViewer （ポリシーの分析情報を表示する場合） roles/recommender.iamAdmin （ポリシーの分析情報を変更する場合） 有効化後の分析情報例 SCC Premiumプランを有効化し、しばらく時間が経つと、Policy Intelligence (Policy Analyzer) が収集したIAMに関する分析情報が「検出結果 (Findings)」タブに表示され始めます。これらの分析情報は「洞察 (Insights)」として提供され、過剰な権限や未使用の権限が具体的に指摘されます。 この画像は、あるプリンシパルに付与された「 Storage オブジェクト管理者 」ロールが過剰な権限を持っていることを示しています。 概要 : 上部に表示されるメッセージ「 Storage オブジェクト管理者 ロールを Storage オブジェクト閲覧者 ロールに置き換えると、プリンシパルの権限数が 28 から 8 に減少します。分析は過去 90 日間を基にしています。 」が、この洞察の要点をまとめています。 特定のプリンシパルに付与された「 Storage オブジェクト管理者 」ロールが、実際の使用状況と比較して広範すぎることを指摘。 より制限された「 Storage オブジェクト閲覧者 」ロールへの置き換えを推奨。 その結果、付与される権限の総数が28から8に大幅に削減されることを明示。 この分析が、過去90日間の権限使用履歴に基づいて行われたことを示しています。 現在の権限 (左側) : 「 Storage オブジェクト管理者 ロールの現在の権限 」として、このロールが持つ広範な権限がリストアップされています。 例として、 storage.objects.get （オブジェクトの取得）のような読み取り権限に加え、 monitoring.timeSeries.create 、 orgpolicy.policy.get 、 resourcemanager.projects.get / list 、さらには storage.folders.create / delete / rename などの ストレージの管理・削除に関する権限 や、 storage.managedFolders （マネージドフォルダ）に関する権限など、多岐にわたる権限が含まれていることが分かります。 これらのうち、 storage.objects.get  以外は、過去90日間で実際に使用されていない「過剰な権限」として青字の「過剰な権限」ラベルとともに表示されています。 置き換え推奨のロール (右側) : 「 Storage オブジェクト閲覧者 のロールの置き換えを推奨 」セクションでは、提案されるロール（この場合は Storage オブジェクト閲覧者 ）に含まれる権限と、現在のロールとの差分が表示されます。 赤いハイライトで示されているのは、現在のロール（ Storage オブジェクト管理者 ）には含まれるが、推奨されるロール（ Storage オブジェクト閲覧者 ）には含まれない、つまり 削除されるべき権限 です。これにより、一目でどの権限が不要と判断されたかを確認できます。 ここでは、 storage.objects.get  のみが必要な権限として残り、その他の監視、組織ポリシー、リソースマネージャー、およびストレージ管理に関する多くの権限が削除対象となっていることが明確に示されています。 この具体的な洞察は、権限整理の具体的なアクションに直結します。この情報に基づいて、対象のプリンシパルから Storage オブジェクト管理者 ロールを削除し、代わりに Storage オブジェクト閲覧者 ロール、またはより細かく制御されたカスタムロールを付与することで、最小権限の原則を適用し、セキュリティリスクを大幅に低減することができます。 まとめ 本記事では、GCP環境における過剰なIAM権限の危険性とその解決策として、Security Command Center Premiumの強力なIAMセキュリティ分析機能（Policy Intelligence）を解説しました。 IAMはクラウドセキュリティの基盤であり、その適切な管理は組織のデータとシステムを保護する上で不可欠です。SCC Premiumを導入し、本記事で紹介した手順とベストプラクティスを実践することで、これまで見過ごされがちだったIAMの「死角」を解消し、より堅牢で効率的なGCP運用を実現できるはずです。 本記事がGCP環境のセキュリティ強化の一助となれば幸いです。 参考 Google Cloud IAM の概要  – Google Cloud 公式ドキュメント https://cloud.google.com/iam/docs/overview?hl=ja Security Command Center の概要  – Google Cloud 公式ドキュメント https://cloud.google.com/security-command-center/docs/overview?hl=ja Security Command Center の料金  – Google Cloud 公式ドキュメント https://cloud.google.com/security-command-center/pricing?hl=ja

更新必要な資格の中でも、私が初めて取得したAZ-104の更新時期がついにやってきました。 取得した当時は実務経験もそれほど多くなかったため、実務想定の長文ケーススタディ問題には相当苦戦した記憶があります。 一年足らずで更新のタイミングが来て、「もう更新か…」と正直驚きました。 これからも資格の更新あるので備忘も兼ねて記事に残しておきます。   AZ-104の概要 AZ-104（マイクロソフト認定: Azure管理者アソシエイト）とは、Azureの管理・設計・運用に必要な知識とスキルを証明する資格です。リソースグループ、仮想マシン、ストレージ、Vnet、Entra ID、セキュリティなど業務と密接にかかわる内容で構成されているのが特徴です。 インフラ関連のエンジニアとして中級者レベルの実力を持つことを証明できます。 Azure資格は有効期限が「12ヵ月」と設定されている点も独特です。 他のクラウドベンダーの資格は有効期限が2〜3年というパターンも多い中で、マイクロソフトのAzure系資格は、年次更新が求められます。これによって常に最新のクラウド技術にキャッチアップし続ける意識が自然と身につくという意味では、良い仕組みなのかもしれません。   テストの受け方 AZ-104の更新テストは本番のように試験センターまで赴く必要はありません。自宅や職場など、インターネット接続環境があればどこからでも受験可能なWebテスト形式です。 Microsoft Learn: キャリアの扉を開くスキルを身につける このサイトにアクセスして自分のプロファイルに飛んでください。 資格証明タブから更新したい資格を選んで、更新ボタン押します。             更新費用 費用はかかりません。更新は何度受験しても無料で受験できます。   試験内容と結果 全部で26問、制限時間は45分のテストです。 残り時間の表示は無いので注意して下さい。本試験のときは残り時間が表示されていた記憶があります。 長文のケーススタディ問題は出題されず、リソース設定の知識問題と目的のために何をする必要があるかを選ぶ問題でした。 結果は、、           落ちました。         正答率34%で不合格。 一度取得したし、大丈夫だろうと油断していたら普通に落ちました。 細かい設定の知識が抜けていることを痛感しました。 忘れていることが多く反省してます。教材引っ張り出して、猛勉強して再チャレンジします。 余談ですが、SCSKにはhirodemyという学習サイトがあります。 AWSとGoogle Cloudの問題が多数収録されていて、私もAWS SAAの受験時には大変お世話になりました。 しかし、Azureだけ無いんですよね、、昔はあったと先輩から聞いたことありますが2年目の私には幻の存在です。 しかたがないので、昔に購入したudemyの問題集で勉強し直しました。 hirodemyに関して、以下に参考リンク貼りますので見てください。 セッション資料・動画一覧 – AWS Summit Online 2021 | AWS PAR-15_AWS_Summit_Japan_2021_SCSK.pdf   再受験まで24時間の間隔をあける必要があります。私の場合、期限の2025年12月18日まで何度でも再受験が可能です。 Microsoft 認定: Azure 管理者アソシエイトの更新 – Certifications | Microsoft Learn   ～24時間後～ 満を持して、2度目の挑戦。   結果は、、     合格。           合格ボーダー57%で、結果は65%でした。危なかった。 情けなくもギリギリですが、何とか更新を完了できてホッとしています。             感想 今回AZ-104の資格更新しましたが、次はより上位の資格であるAZ-305：Azure ソリューション アーキテクト エキスパートにチャレンジする予定です。同じ傾向で知識重点的に問われるのであれば、改めて復習しておかないとなぁと思います。 勉強頑張ります。

本記事は 夏休みクラウド自由研究2025 8/8付の記事です 。 Catoクラウドのセキュリティ機能のうち、Threat Preventionオプションにて提供される Anti-MalwareとIPSについて詳しく紹介いたします。 はじめに：Threat Prevention機能について Catoクラウドが提供する数多くのオプションの中で、最も基本的なセキュリティ機能を提供するのが 「Threat Prevention」オプションです。 本オプションには、大きく分けて「Anti-Malware」「次世代Anti-Malware（NGAM）」「IPS」 の3機能が含まれております。オプションとして追加することで 高性能なウィルス対策ソフトウェアや次世代セキュリティソフトウェアを導入するのに相当する セキュリティが提供されるようになります。 本記事では、これらの記事について紹介すると共に、 少し深堀りして具体的な挙動も含めて説明していきます。 CatoのAnti-Malware機能 まずはAnti-Malware機能の概要と挙動について紹介していきます。 2つのAnti-Malwareとその関係性 先述の通り、Catoの提供するAnti-Malware機能は2種類存在します。 どちらも HTTP、HTTPS、FTPの3種のプロトコルによる通信が対象 となっています。 名称 役割 Anti-Malware いわゆる一般的なウィルス対策ソフトウェアに近い、シグネチャベースおよび挙動検知型の アンチマルウェアです。 Catoネットワークを経由してやり取りされるファイルを自動でスキャンします。 NG Anti-Malware 膨大な量のマルウェアの機能を学習したAIによって、特徴を検知するアンチマルウェアです。 未知のマルウェアやゼロデイのマルウェアにも対応することが可能です。 Catoネットワークを経由してやり取りされるファイルを自動でスキャンします。 これらの機能は同時に稼働しているわけではなく、下記のように順番に適用されます。 １．対象となるファイルが除外対象でなければ、「Anti-Malware」によるスキャンを実施 ２．「Anti-Malware」の結果に問題が無い場合、「NG Anti-Malware」によるスキャンを実施 ３．結果に応じてAllow / Blockを決定 NG Anti-Malwareは、必ずAnti-Malwareの後で動作します。この挙動を考慮してか、 NG Anti-Malwareは前提としてAnti-Malwareの有効化が必須 となっております。 普段意識する必要はありませんが、念のため気を付けておきましょう。 Anti-Malwareの有効化 CatoのAnti-Malware機能は、[Security] > [Anti-Malware]から 簡単に有効化 / 無効化を設定できます。 デフォルトで両方有効化されているため、特に無効化する理由が無ければそのままで問題ありません。 なお、先述の通りNG Anti-MalwareはAnti-Malwareの稼働を前提としているため、 Anti-Malwareを無効化するとNG Anti-Malwareも同時に無効化されるようになっています。 Anti-Malwareの除外設定（Bypass List） Catoクラウドに限らず、ウィルス対策ソリューションは本来必要なファイルを ウィルスとして誤検知してしまう恐れがあります。 こうしたケースの対策として、スキャン対象から除外する機能が存在します。 Catoクラウドの場合、[Security] > [Anti-Malware] の [Bypass List]タブから設定を行います。 こちらの機能では、ファイル単位ではなく 宛先や通信を行うアプリで除外する 形となります。 設定項目は下記のとおりです。 名称 役割 General ルールの名称と基本的な設定を決定します。 「Rule Order」はルールの配置位置です。 「Scope」によって、WAN通信、Internet通信のどちらかだけを対象とすることも可能です。 Source 特定のユーザやグループ、Site等、接続元を指定することができます。 例えば、「システム部門のユーザのみ許可」「特定IPセグメントの機器に限り許可」 といった制御が可能です。 What 除外対象を指定します。 IPアドレスやドメインでの指定の他、「Sharepointでのファイル連携はバイパス」といった アプリケーションでの除外も可能です。  以下のように、ルールが追加されたことを確認できます。 ルール右側の「…」より、ルールの無効化や削除といった操作を実施可能です。 設定変更後、反映のために「Save」を実行することを忘れないようにしましょう。 Anti-Malwareの除外設定（File Exception） Catoは誤検知の対応方法として、個別ファイル単位での除外設定にも対応しています。 SHA-256のハッシュ値により識別 しているため、同一のファイルであれば どこを経由したものであっても除外の対象となります。 ハッシュ値を参照する都合上、対象ファイルに更新や修正が入ると 除外の対象から外れてしまいます。 改ざん対策としてセキュリティ上意味のある仕様ですが、 実運用上で引っかかる場合もあるため注意しましょう。 本設定については、実際にイベントとして検知して初めて設定できるようになっています。 [Home] > [Events]にて、以下のようなフィルタリングを行うことで、Anti-Malware機能によって出力されたイベントが一覧表示されます。 ・Sub Type In “Anti Malware”, “NG Anti Malware” 表示されたイベントを確認すると、「File Hash」という属性が存在することを確認できます。 （値が青色の文字で表示されています。） 青色で表示されている値をクリックすることで、「File Exception」の設定ウィンドウが開きます。 除外の期間とコメント（任意）を設定して「Apply」をクリックしましょう。 [Security] > [Anti-Malware]にて、追加されたルールを確認できます。 有効期間が過ぎた時点で無効化されるほか、手動での削除も可能です。 Anti-Malwareの個別設定追加 Anti-Malware機能は、デフォルトで「Malicious (virus_found)」または「Suspicious」 と判定したファイルを全てブロックするように設定されています。 上記と異なる挙動を適用したい場合、[Protection Policy]タブでポリシーを作成します。   設定項目は下記のとおりです。 名称 役割 General ルールの名称と基本的な設定を決定します。 「Rule Order」はルールの配置位置です。 「Scope」によって、WAN通信、Internet通信のどちらかだけを対象とすることも可能です。 Rule Orderが小さい（上に表示される）ルールが優先的に適用される ため、 条件の広いルールはなるべく下に配置しましょう。 Source 特定のユーザやグループ、Site等、接続元を指定することができます。 例えば、「システム部門のユーザのみ許可」「特定IPセグメントの機器は禁止」 といった制御が可能です。 What 除外対象を指定します。 IPアドレスやドメインでの指定の他、「Sharepointでのファイル連携は許可」といった アプリケーションでの除外も可能です。  Verdict 検知結果を指定します。 All Files：その名の通り、すべてのファイルです。 Suspicious：Anti-Malwareは通過、NG Anti-Malwareが「疑わしい」と判断したファイルです。 Malicious：Anti-MalwareまたはNG Anti-Malwareがマルウェアと判断したファイルです。 Encrypted：パスワード付きZipファイルなど、中身のチェックに制限がかかったファイルです。 Action Allow / Blockを指定します。 また、Eventsへのログの出力有無、メール通知の送付有無を設定します。 Eventsへの出力は、原則として有効化することを推奨します。 作成後、一覧に想定通りのルールが存在することを確認してから「Save」を実行しましょう。 BypassとAll Allowの違い 「Verdict」で「All Files」を指定して「Action」で「Allow」とした場合、 エンドユーザからの見かけ上の動作はBypassしているのと同様の結果となります。 両者の違いは下記のとおりです。          Bypass：Anti-Malwareによるチェック自体を行わない。 PolicyによるAllow：Anti-Malwareによる一通りのチェックを行った後「許可」とする。 PolicyによってAllowとしていた場合、Eventsにて後から判定を確認することも可能です。 （そもそもあまり推奨はしませんが）広い範囲で許可設定を行う場合は、 万一の確認のためにBypassではなくProtection Policyにて設定するのも一つの手です。 （参考）ウィルス対策ソフトウェアと比較してのPros & Cons これまで述べてきたように、CatoのAnti-Malware機能は 通常のアンチマルウェアや次世代アンチマルウェアソフトに匹敵する防御機能を有しています。 一方で、仕様上どうしても対処が難しい点もあります。これらについてざっと記載します。 CatoのAnti-Malwareの強み 定義ファイルの更新頻度 CatoのAnti-Malwareは、 30分毎に定義ファイルを更新 しています。 特にレガシーなタイプのシステム構成をとっている場合、 従来型のエンタープライズ向けウィルス対策ソフトウェアの端末上の定義ファイル更新頻度は 1日1回、またはそれ未満というケースも少なくありません。 Catoのバックボーン上で機能する CatoのAnti-Malware機能は、すべてバックボーンの通信上で動作します。 このため、 動作が端末自体のリソースを消費することはありません 。 定義ファイルのダウンロードにより通信帯域が圧迫される……といったこともありません。 ※前述の従来型システムでの実端末に対する更新頻度の低さは、 こういった影響を回避するため止む無く、ということも多いと思います…… 端末上で動作するものではないため、（特にSocket配下の機器について） 端末からは直接動作を無効化することができません 。 万が一端末がマルウェアに感染してしまったとして、外部への情報送信や他の機器への拡大は 相変わらずCatoのセキュリティ機能による監視の対象となります。 CatoのAnti-Malwareの弱み ネットワーク外の感染は回避不能 あくまでもCatoを介した通信を監視するものであるため、 Bypass機能などを用いてCatoのネットワークを迂回している場合は検知できません 。 当然ながら、「マルウェア入りのUSBメモリを挿入した」といったケースも検知できません。 実行そのものを止める機能は無い 上記と同様の理由で、仮に端末上に既にマルウェアが存在した場合に、 それを実行すること自体を検知、ブロックすることはできません。 ただし、強みとして記載した通り、この場合でも外部サーバへの情報送信などは Catoの機能によって阻止できる可能性があります。 対象とする形式の制約 前述の通り、本機能が対象とする通信はHTTP、HTTPS、FTPです。 外部との通信であれば概ねカバーできますが、 SMBによるファイル授受が対象外 であるため、社内ファイル共有での拡散に注意が必要です。   上述の弱みについては、CatoのAnti-Malwareの動作仕様上の制約というべきものです。 エンドポイント型のセキュリティ対策を併用する ことで、より強固なセキュリティを構築可能です。 なお、Catoにはエンドポイント型のセキュリティを提供する 「Endpoint Security（EPP）」オプションもございます。 セキュリティ機能の一括管理を希望する場合、検討するのも一つの手です。 CatoのIPS機能 IPSはAnti-Malwareとは異なり、ファイルではなく通信自体を対象とした検知、防御を行います。 一例としては、以下のような挙動を行います。 C&Cサーバやフィッシングサイトといった、攻撃用のサイト・サーバへの通信をブロックする CVEとして公開された、既知の脆弱性を突くための通信を検出、ブロックする 攻撃の前段階にあたるネットワークスキャンをブロックする Anti-Malware機能と同様に、Catoは（除外設定が無い限り）経由する通信全てに対して上記の処理を実施することが可能です。 通信の内容を解析して防御するという挙動の関係上、 Catoの TLSインスペクションが無効である場合は暗号化通信に対する検知性能が大きく低下 します。 IPSを使用する場合、可能な限りTLSインスペクションも有効としましょう。 IPSの有効化 IPS機能は、[Security] > [IPS]のトグルスイッチで有効化 / 無効化します。 下部のトグルスイッチを利用することでインターネットの通信のみを対象にするといった設定も可能ですが、基本的には全て対象とすることを推奨します。 設定変更後は、ウィンドウ右上にある「Save」の実行を忘れないようにしましょう。 IPSの除外設定 IPS機能についても、Anti-Malware機能と同様に誤検知を防ぐための除外設定を行うことが可能です。 設定方法には、大きく2つのパターンが存在します。 パターン1：設定をマニュアル作成 [Security] > [IPS] の [Allow List] タブから、除外設定を管理することが可能です。 「New」をクリックすることで、設定画面が表示されます。 名称 役割 General ルールの名称と基本的な設定を決定します。 Name：ルール名です。 Description：ルールについての説明を、任意で追記できます。 Scope：下記の通り、適用対象の通信を絞り込むことが可能です。 All：全て Inbound：外部から入ってくる通信 Outbound：外部へ出る通信 WAN：拠点間通信 Signiture ID：IPSは、疑わしい通信と判断する理由にあたる「Signature」に   合致した通信をブロックします。   この項目で、特定のSignatureに合致した場合に限って除外することも可能です。 Source 特定のユーザやグループ、IPレンジ、Site等、接続元を指定することができます。 Destination 除外対象の宛先を指定します。 IPアドレスやサブネット単位での指定、拠点間通信向けにSite単位の指定も可能です。 実は「General > Scope」に応じて設定可能項目が変更されており、 ドメイン指定は「Outbound」「WAN」のどちらかでないと設定できない （「All」では設定できない） ため注意しましょう。 Protocol/Port 対象ポートを指定します。 例えば、DNS通信を除外するのであれば「TCP_UDP/53」を指定することとなるでしょう。 Track この除外設定が適用された場合の、 Eventsへのログの出力有無、メール通知の送付有無を設定します。 設定後「Apply」を押下して、一覧に設定が追加されたことを確認します。 設定の変更、内容の確認後に、ウィンドウ右上の「Save」を実行しましょう。 パターン2：イベントログから除外設定を作成 「業務通信が上手くいかず、調査した結果IPSのブロックが原因だった」といったケースでは、 対策として該当する通信の除外設定を追加する必要が生じます。 Catoには、ブロックされた通信のイベントログから除外設定を生成する機能が存在します。 [Home] > [Events]にて、以下のようなフィルタリングを行うことで、IPSによってブロックされたイベントのログを確認することができます。 ・Sub-Type Is IPS ・Action Is Block イベントの一覧で目的のログを見つけたら、詳細を確認します。 中に「Signature ID」という属性があり、値が青色で記されていることを確認できます。 このIDの値（青色部分）をクリックすることで、即座に除外設定の作成画面が開きます。 対象の通信を絞り込むための設定がすべて入力済みとなっているので、 「Apply」を押すだけで設定が完了します。 ※接続元IPまで固定されているため、必要に応じ変更しましょう。 極めて簡単に設定できるうえ、適用範囲を最低限に絞ったルールが作成されるため セキュリティ上も利点のある方法です。ぜひ活用していきましょう！ IPSのオプション機能 IPSには、メインとなる機能を補完するオプションがいくつか存在します。 それぞれ別のタブにて設定が可能です。 [Enforcement Option]タブ Outbound Traffic – Block newly registered domains 作成が確認されてから14日以内のドメインを宛先とした通信を、一律でブロックします。 攻撃者が使い捨てのような新規ドメインを用意するケースは少なからず存在しますが、 そうした場合はこのオプションで無条件にブロックできることになります。 Inbound Traffic – Suspicious IP quarantine 短期間で高頻度にIPスキャンを行っているアドレスが確認された場合に、 当該IPアドレスの通信を5分程度遮断する機能です。 [Geo Restriction] タブ IPアドレスベースで、特定の国との通信を一律ブロックとすることが可能です。 インバウンド通信のみ、アウトバウンド通信のみといった設定も可能です。 [Suspicious Activity] タブ IPSでブロックするには至らない、疑わしい通信を識別してログに残す機能です。 あくまでもモニタリングだけで、ブロックすることはありません。 [Home] > [Events]上では、Sub-Typeは「IPS」ではなく、 「Suspicious Activity」という固有のSub-Typeで記録されています。 （参考）IPSはどんな通信を検知している？ IPSがどのような通信をブロックしたか、大まかな傾向は [Security] > [IPS] 下部の「IPS Categories」にて確認可能です。 この項目には、各カテゴリごとの直近7日間での検知回数が表示されます。 また、1件以上存在する場合は、回数部分をクリックすることで 当該の条件に合うフィルタ設定が施された状態で[Home] > [Events]に遷移します。 どのカテゴリが多く検知されるかは、それぞれの環境によって大きく異なります。 ここでは、あくまで参考として、比較的多く検知が見られたカテゴリと ブロックされる通信の例を紹介いたします。 Policy Violation Catoが「セキュリティ上望ましくない」と判断したアプリケーションによる通信をブロックする カテゴリです。 具体例としては、BitTorrent系のアプリケーションによる通信のブロック等を確認しました。 このタイプの場合、ログからアプリケーションを確認し、 業務上問題のないものかどうかを検証するのが望ましいでしょう。 Reputation 「信頼できる」と判断するには不十分な程度の情報しか存在しないIPやドメインにまつわる接続をブロックするカテゴリです。 作成されて日が浅いドメインへの接続は、このカテゴリでブロックされることが多いです。 日本ローカルのサービスなど、世界的にみると利用者の少ないサービスがこのカテゴリでブロックされてしまうケースも存在するため、同じドメインのブロックを大量に検知する場合は確認しておくことが望ましいです。 Web Application Attack その名の通り、訪問したウェブアプリケーションに有害な動作が存在した場合に ブロックするカテゴリです。 このカテゴリについて、圧倒的に検知数が多いのは「adnxs.com」のCookieでした。 Microsoftがターゲッティング広告用に用いているCookieのようで、 基本的には無害なものと考えてよさそうです。 逆に、上記以外を検知している場合は内容を精査する必要があるかもしれません。 終わりに 本記事では、Threat Preventionの機能について紹介しました。 本機能は重要な一方、普段は誤検知かトラブルが起きない限り、あまり参照しない機能です。 もしもの時のために、一度操作を確認しておくのも良いかもしれません。

こんにちは、SCSK株式会社3年目の愛甲です。 前回、私たちの部署の嶋谷さんが、 MackerelでOracle Databaseを監視してみた という記事を掲載しました。 MackerelでOracle Databaseを監視してみた – TechHarmony 今回は、AWSの通話サービスであるAmazon Connectを Mackerelで監視し可視化しましたので、ご紹介いたします。 MackerelでのAWSリソースの監視 Mackerelでは、AWSインテグレーションというものを使い、MackerelとAWSのサービスを接続し、とても簡単にAWS環境を監視することができます。 AWSインテグレーションについては、以下のMackerelの公式ドキュメントに詳細が記載されています。 AWSインテグレーション – Mackerel ヘルプ AWS環境の監視については、以下の記事でもご紹介していますので、興味がある方は是非ご覧ください。 Mackerel で AWS のサーバーレスサービスを監視してみた – TechHarmony 監視対象について はじめに、監視対象についての情報を軽く説明します。 今回の検証では、Amazon Connectで電話接続し、その電話の録音データをAmazon S3に保存されるサービスを構築しました。 システム構成は以下の図になります。 Amazon Connect 　　クラウド型コンタクトセンターサービス AWS Lambda　　　  時間帯での転送先判定 Amazon S3 　　　  　録音データの保存先 構成しているサービスの中でAmazon Connectを監視対象として検証しました。 上記の環境の構築手順については、少し長くなってしまうため、この記事では説明を省かせていただきます。 Mackerelでの監視設定手順 では、ここからはMackerelでAmazon Connectを監視するための、設定手順について記載していきます。 設定手順に興味ない方は、このパートはスキップして、「監視データ」のパートに飛んでください。 インテグレーション用のIAMロールの作成 (1) Mackerelの管理画面で「オーガニゼーション名」＞「AWSインテグレーション」をクリックする。 (2) 「新しいAWSインテグレーションを登録」というボタンが表示されるため、それをクリックする。 (3) 基本設定＞AWSアカウント　外部IDをコピーする。 (4) AWSのコンソールにログインし、左上の検索バーで「IAM」と入力し、エンターを押す。 (5) 左側のタブからロールを選択し、「ロールを作成」をクリックする。 (6) 以下に沿って入力し、すべて入力後、「次へ」をクリックする。 信頼されたエンティティタイプ：AWSアカウント AWSアカウント：別のAWSアカウント ・アカウントID：217452466226（共通） オプション：外部IDを要求する (7) Amazon Connectを監視したいため、それらに関するReadOnlyロールを選択し、「次へ」をクリックする。 (8) ロール名と説明を適宜入力し、「ロールを作成」をクリックする。 注意点：Amazon Connectを連携対象にする場合、連携に使用するIAMロールにはAmazonConnectReadOnlyAccessに加えて、CloudWatchReadOnlyAccessの権限が必要となります。 Amazon ConnectのようにCloudWatchReadOnlyAccessの権限が必要になるものがあります。詳細は冒頭にあるAWSインテグレーションヘルプをご確認ください。 ⑨作成したロールの詳細画面で表示される、ARNをコピーする。 AWSインテグレーションの作成 (1) Mackerelの管理画面に戻り、先ほど開いた「新しいAWSインテグレーションを登録」画面を開く。 そこで、名前の入力とリージョンの選択を行い、ロールARNの欄に先ほどコピーしたARNを貼り付ける。 (2) メトリックを収集するサービスで、Amazon Connectを選択し、「作成」をクリックする。 (3) 「タグを指定して登録するホストを絞り込む」にて連携したいリソースのタグ、除外したいタグを入力する。 これで、インテグレーションが作成できました！ 連携確認 以上で設定は完了です。 ここからは、監視設定を入れたサービスの状態を見てみましょう。 ここまでの手順が完了すると、Mackerelの管理画面の「ホスト」のところですぐに確認することができます。 このように、Amazon Connectのデータが取れていることがわかります。 監視データの確認 監視手順としては以上になります。 AWSインテグレーションを使うと、面倒なエージェントのインストールや、接続用のアカウントの作成などがないため、とても簡単に監視ができます。 私はAWSインテグレーションの設定はまだ2回目ですが、もうおちゃのこさいさいです！ では、ここからはAWSから連携された監視データがどのように見えているかを、 一部抜粋してお見せしたいと思います。 Amazon Connectの監視データ Amazon Connectは基本的に以下のメトリックを取得できます。 グラフ名 メトリック 説明 Concurrent Calls Service Quota ConcurrentCallsPercentage 同時に処理可能な通話数のサービスクォータがどの程度使われているか（%） To Instance Packet Loss Rate ToInstancePacketLossRate インスタンスに送信されるパケットの損失率 Voice Calls CallsBreachingConcurrencyQuota クォータ超過で処理できなかった通話数（合計値） CallsPerInterval 一定間隔内での通話数（合計値） ConcurrentCalls 同時に存在した通話数（最大値） ThrottledCalls 制限でスロットリングされた通話数（合計値） MissedCalls 取りこぼした通話数（合計値） MisconfiguredPhoneNumbers 誤設定の電話番号への通話数（合計値） Call Recording Upload CallRecordingUploadError 通話録音ファイルのアップロードエラー件数（合計値） Contact Flows ContactFlowErrors コンタクトフローで発生したエラー（合計値） ContactFlowFatalErrors 致命的エラー（合計値） CallBackNotDialableNumber コールバックできなかった番号（合計値） Queues QueueSize キュー内に滞留している件数（最大値） QueueCapacityExceededError キュー容量超過によるエラー件数（合計値） Queue Wait Time LongestQueueWaitTime 最長待機時間 Public Signing Key PublicSigningKeyUsage 公開署名鍵の利用回数（合計値） 今回は、この中のVoice Callsのグラフをお見せします。 グラフを表示させるにあたって、私はAmazon Connect上に登録した番号に繰り返し電話をかけました。 その結果、以下のようなグラフが表示されました。 こちらは、通話をした数や受電できなかった数を表したグラフになります。 （メトリックはConcurrentCallsとMissedCallsに絞って表示しています） 黄緑線　 　：繋がった通話の数 オレンジ線 ：受電したが、電話に出れなかった数 このように、CloudwtchでとれるメトリックをMackerelでも確認することができます！ このデータのほかにContact FlowsやQueuesを組み合わせて監視をすれば、Amazon Connectを使った番号への電話がつながらなくなった場合などに、何が原因で、どの時間帯につながらなくなったのかを即座に認識することができます。 興味がある方はぜひ調べて試してみてください。 おわりに 記事の内容は以上になります。いかがでしたでしょうか。 Amazon Connectを使っている方でしたら、1度は電話がつながらなくなって焦った人もいるかと思います。そんな時、Mackerelの監視をしておけば、すばやい原因特定も可能になります！ また、Mackerelを使って今まで見えていなかった情報を見える化することで、電話の多い時間帯や、電話の対応時間などを確認できるようになるため、人員最適化や業務の品質向上などの業務効率化に役立てることもできます！ ぜひ、活用してみてはいかがでしょうか。 もう少しMackerelを触ってAmazon Connectを監視してみようと思いますので、また何か気づきがありましたら記事を掲載します。 最後までお付き合いいただき、ありがとうございました。

はじめまして。吉越です。 今回、6月25日に開催されていたAWS Summit2025へ参加して持ち帰ってきた話をブログにまとめようと思います。 はじめに 早速ですが、みなさんにSNSで話題となったラーメン山岡家のブースの「ゆで麺タイマー」のアーキテクチャをお見せします！ AWS Summitの企業ブースに山岡家がある～と思って近づいたところ、ゆで麺タイマー（？）というものがAWSで構築されているのかぁと面白くて気づいたら資料くださいって声かけてました。 色々なセッションを聞いてから家に帰り、山岡家の資料をもう一度読み返してみました。 すると、ここにも「SnowFlake」があるなぁ、という感想でした。 なぜなら同日に聴講したパートナーセッション「PayPayのAI DataCloudが目指す最先端アーキテクチャ」でもSCSKブースのミニセッションでも「Snowflake」を扱っていたからです。もしかして今アツいサービスなのかもしれないという予感がしてきました。 また、私はお客様のインフラ基盤の保守運用を行っているので、サービスの提案や導入をする立場にあるということで、 AWSパートナーセッションで聞いた内容をもとに、お客様の環境へ導入検討できないかという視点で記事を書こうと思います。 ※今回はSnowFlakeがどういった製品かという内容を詳細に記事に記載いたしません。詳しくはSnowFlakeの 公式ページ を参照ください。 セッションから考えるSnowFlakeの導入検討 パートナーセッション「PayPayのAI Data Cloudが目指す最先端アーキテクチャの実装」を聴講して このセッションで伝えたかったことは 「Snowflakeによるデータ基盤構築のメリット」と「3か月でデータ基盤環境を構築し社内公開の達成」 ということでした。そのため、今回はこの2点について書きます。 まずなぜPayPayがこのデータ基盤を必要としたのかというと、それはユーザ増加に伴うデータ基盤の拡張性と柔軟性を求めていたからです。 上記のとおり、コード決済は2023年に比べても2024年では23％増えており、ここ数年でも大きく成長しています。 そのような中でデータ基盤の構築することにより、データをより効果的に活用し今後の更なるビジネス成長や拡大に狙いがありました。 このようなメリットがあるわけでデータ基盤を構築するわけですが、まず事前に知っておきたいPayPayのデータ基盤のアーキテクチャです。 このように支払いデータは、インフラ基盤→Data Lake（S3）→Data Warehouse（Snowflake）→Data Analytics ML/AI（SnowFlake等） の流れで格納、加工、分析され活用されています。 PayPayはデータ基盤の構築のためにSnowFlakeを導入しますが、ではなぜSnowflakeだったのでしょうか。 以下、PayPayがもっていた課題とその解決策、そこから見たSnowflakeのメリットをまとめて表にします。 課題 解決 Snowflakeのメリット ・短期間かつ少人数で迅速に構築する必要があった ・インフラ運用工数を削減し、データ基盤開発に集中したい ◎短期間かつ少人数で迅速にデータ基盤の構築ができた ◎マネージド型サービスとニアゼロメンテナンスで開発に集中 マネージドサービス型で迅速なデータ基盤を構築 ・急速な事業成長に比例して柔軟にスケールしたい ・状況に応じて迅速に対応できる機敏性 ◎Multi-clusterのスケーラビリティは十分/使用感は控えめに言っても最高 ◎必要なときに、必要な量を、利用できる柔軟性を確認 高いスケーラビリティ・アジリティ ・特にコンピュートリソースの統制が課題 ・誰がどれくらい使っているか可視化したい ◎シンプルかつ透明性の高いコスト統制が可能に 透明性の高いコスト統制 つまり、Snowflakeの強みは、スモールスタートでスピード感をもって導入できることと、大量の処理を高速にかつ柔軟にスケールすることができる拡張性もつ製品であることが分かります。 もちろん、この他にもデータウェアハウスサービスにはGoogle CloudのBigQueryやAWSのRedshiftなどがありますが、PayPayはこの中でもスモールスタートでコスト効率が高くデータ基盤を構築でき、かつ、S3に格納しているデータとの互換性が高いということでSnowflakeを選んでいるわけです。 次にどのようしてデータ基盤構築プロジェクトを３か月で達成したのかについて以下を実装したとのことでした。 ■インフラリソースはTerraformで構成管理 ■Data Pipelineの実装 ■AWS GlueによるサーバレスなApache Sparkの実行環境として利用 特に私がこの中で興味深かったのは「Data Pipelineの実装」でした。 上記添付のようにAmazon MWAA（Airflow DAG）を使ってデータを加工し、SnowflakeでDDL/DMLを実行を行うことでスキーマの作成・変更やデータの投入・更新処理が自動化されます。これにより人的な作業を減らすことができ、迅速なデータ基盤の構築ができたということでした。MWAAとは他のAWSサービス（Glue、Fivetranなど）と連携できるため、ETL処理とDDL/DMLの実行を統合し、一連のフローとして管理できます。これによって処理の一貫性と再現性が向上します。 また、Snowflakeは大量データの処理を高速かつ柔軟に行うことができます。MWAAからDMLの実行によって、必要なタイミングで必要なデータを投入できる仕組みを整えることを実現したとのことでした。 実装したこと全ては記載できていないですが、これらを使ってPayPayは3か月でデータ基盤環境を構築、社内公開を達成することができたのでした。。！ この項目の最後に、私はパートナーセッションでSnowflakeの存在を知りましたが、AWS Summitに行っていなければ、まだSnowflakeを知らずにいたと思います。SnowflakeはPayPayという大手決済システム企業で導入されている実績もあり信頼と実績のある製品だと感じました。 導入検討に向けて考えたこと それでは、PayPayのパートナーセッションを聞いてみて、実際にSnowflakeを導入しようとなった場合の検討事項を ３つ 考えてみました。 さっそく挙げていきたいと思います！ 検討事項１．データ基盤がクラウド上に構築されていること まず、PayPayではインフラ環境がAWSで構築されています。（以下添付参照） 資料： AWS Summitに出展・登壇しました！ | PayPay Inside-Out SnowflakeはAWSやAzure、Google Cloudのクラウドプラットフォーム上で動作します。ユーザーはSnowflakeでアカウントを作成し、これらいづれかのクラウドプロバイダーの基盤を選択し、ブラウザやSQLクライアントなどからデータベースにアクセスして利用します。 そのため、もし担当しているお客様環境でクラウドプラットフォームが整備されていない場合には導入の実現はできません。 PayPayが迅速にデータ基盤構築のためにSnowflakeを導入できたのは、そもそもAWS環境でプラットフォームが整っていたことも起因しています。 検討事項２．DataLake環境が必要となる もう一度、↑の画像をみてもらうと分かりますが、PayPayのインフラ環境では、そもそもクラウドプラットフォーム上にData Lake環境があります。 Snowflakeはデータを取り込む際、まずはクラウドストレージ（S3, GCS, Azure Blob Storageなど）を経由する必要があります。これらのクラウドストレージを利用できないと、データの取り込みができません。また、クラウドストレージに格納された後、データでETL（抽出、変換、ロード）処理のジョブを作成をする必要があります。これはGlue ETL、Cloud Data Fusion, Azure Data Factory (ADF)などでサービスを活用する必要があります。 加えて、Snowflakeへデータを連携するためにデータカタログが必要となる場合もあります。 このようなData Lake環境がSnowflake導入に必要であるため、それなりに新しい技術への知見が必要になることが分かります。   検討事項３．導入で得られるメリット 上記２つの課題は技術的な観点での課題でしたが、最後はビジネスメリットについてです。 PayPayでは急速な事業成長に比例して迅速に、かつ柔軟にスケールできるデータ基盤を構築することを求めていました。 パートナーセッションではSnowflakeはこのような状況で非常に高い効果を出すことができることができるように見受けられました。 このような状況化での導入によるメリットは検討できますが、データ活用によるメリットが薄い場合には検討することすら難しいかもしれません。 もちろんPayPayは１つの事例であり、Snowflakeの導入事例は多くあるため、お客様の状況に応じて検討するのが最適です。 参考までに導入事例に関するサイトです。 サイトURL： Snowflake：全てのお客様事例 Snowflakeの事例一覧 | クラスメソッド株式会社 お客様環境で実装はできるのか 結論、 上記課題を乗り越えて実装することは可能だが、お客様の環境でビジネスメリットを検討した上で導入ができる、 です。 課題を乗り越えて実装する場合、例えば今すぐには技術的に難しいもののお様側で環境が整えば活用したい場合、 SCSKで提供しているサービス を提案したり、その他代理店で販売しているベンダーに声をかけることもできます。 ※SCSKではSnowflake社と販売代理店契約を締結し、国内におけるSnowflakeの販売が可能となりました。また、​SnowFlakeを 最短 5 日で使い始められるサービス を提供しています。このサービスを上手く活用しつつ導入することを検討できるかもしれません。 サイトURL： Snowflakeソリューション│SCSK株式会社｜サービス｜企業のDX戦略を加速するハイブリッドクラウドソリューション また、そもそもビジネスメリットがあるか分からず検討している場合には、まずはSnowflakeにて公式の 導入事例 などをみてイメージしてみることもできます。例えば金融業界においては金融資産に関する最適な提案に活用することや、審査の迅速化による業務効率化を図ることもできるようになります。他にもメーカーなどでは様々なデータやデバイスからデータが生成されサイロ化しています。そのデータを統一化することで、IoTデータ活用によるリアルタイムモニタリング、予知保全などにも有用です。 このようなメリットをお客様と一緒に検討し、さらには新しい顧客体験を一緒に考えていくことができるかもしれません。 おわりに そんなわけで、Snowflakeって名前は寒そうだけど、サービスとしてはアツかったです。 データ活用における最先端技術が利用できる製品である一方で、お客様の環境で実装可能なのか、利用するシチュエーションでメリットがどのくらいあるか等、検討する上での課題や弊害も多く存在すると感じました。 ただ今後も、PayPayのようなデータ活用を行う企業は増えていく考えられ、そのような状況でお客様に提案するためには一緒にデータ活用の目的やメリットを考え、共創していくことが必要なのだと思いました。 それでは、ここまで読んでいただきありがとうございました！

本記事は 夏休みクラウド自由研究2025 8/7付の記事です 。 2025年6月、Cato クラウドを AI を通じて操作するための MCP サーバの提供が開始されました！ Meet Cato’s MCP Server: A Smarter Way to Integrate AI Into Your IT & Security Processes  Cato’s Model Context Protocol (MCP) is now available. It lets AI agents query your Cato environment using natural langua... www.catonetworks.com 本ブログ記事では、Cato の MCP サーバが一体どういうものなのか、現時点で何ができるのかについて、詳しく見て行こうと思います。 そもそも MCP とは 生成 AI や LLM (大規模言語モデル) の技術開発の進展が非常に早い昨今、AI エージェントという文脈の中で MCP (Model Context Protocol) というものが賑わっています。 MCP は、2024年11月に Anthropic 社 (Claude という LLM の開発・提供を行っている会社) が発表したアプリケーションプロトコルです。 Model Context Protocol - Model Context Protocol The open protocol that connects AI applications to the systems where context lives modelcontextprotocol.io 様々なシステムや機能を AI に組み込むための標準的な仕組み、といった感じでイメージすると良いと思います。MCP について解説した記事は既に世の中で多く書かれていますので、本ブログ記事ではこの程度の説明に留めることとします。 以降では、本ブログ記事のテーマである Cato の MCP について解説していきます。 Cato MCP の利用イメージ まず、Cato の MCP のイメージを掴むために次の画像をご覧ください。 Cato の MCP サーバ実装を LibreChat という AI チャットソフトウェアに組み込んで実際に利用してみた例です。         ご覧のように、AI との会話を通じて Cato のサイトの情報を確認したり、ネットワーク品質の状況を確認したりできます。他にも最後の画像で AI が言っている通り、リモート接続ユーザの情報を確認することもできます。 Cato に関する管理・運用は通常は CMA (Cato Management Application) の Web 画面を通じて行いますが、任意の AI と組み合わせて会話ベースで行えるようになったというのが Cato の MCP の登場による変化です。 Cato MCP の機能 Cato の MCP サーバは、ソースコードとして次の GitHub リポジトリで公開されています。 GitHub - catonetworks/cato-mcp-server: This repository provides a local mcp-server for Cato Network's public GraphQL API This repository provides a local mcp-server for Cato Network's public GraphQL API - catonetworks/cato-mcp-server github.com 本ブログ記事執筆時点の最新版である v0.9.0 では、以下の14個の機能 (Tool) が提供されています。（ソースコードも確認しました。） 機能 (Tool) 概要 entity_lookup サイト、VPN ユーザ、管理者ユーザなどの一覧を取得する。 取得できる対象は EntityType に記載されているもの。 sites_by_location サイトの地理情報や PoP 接続情報を取得する。 site_details サイトの詳細情報や各種ステータスを取得する。 site_types サイトの接続タイプ (Socket, IPsec, vSocket など) を取得する。 socket_versions 各サイトの Socket のバージョンを取得する。 wan_connectivity サイトの WAN 側のステータスや PoP との間のトンネルのステータスを取得する。 user_details リモート接続中のユーザの接続状態、デバイス名、OS名などを取得する。 user_connection_details リモート接続中のユーザの PoP との接続に関する詳細情報を取得する。 user_software_versions リモート接続中のユーザの Cato Client のバージョン情報を取得する。 site_network_health ネットワーク品質の悪いサイトを抽出し、その RTT、ジッタ、パケットロス率を取得する。 top_bandwidth_consumers トラフィックの多いサイトやリモート接続ユーザを抽出し、その通信量を取得する。 metrics_timeseries_query サイトやリモート接続ユーザのネットワークに関する時系列データを取得する。 取得できるメトリクスは TimeseriesMetricType に記載されているもの。 metrics_site_summary サイトのネットワークに関する全てのメトリクスの集計データを取得する。 annotation_event_counter サイトのネットワークインターフェースで発生した変更イベントの回数を取得する。 取得できるイベントは AnnotationType  に記載されているもの これら機能を、AI との会話の中で利用できます。 先ほどの画面スナップショットの場合、私が AI に依頼したチャットの内容をもとに site_details や site_network_health の機能 (Tool) が実行され、その実行結果に応じて AI がわかりやすく回答してくれていました。 少しだけ内部の仕組みの話をすると、次のような流れで AI は動作しています。 AI チャットソフトは、ユーザが入力した内容と Cato の MCP で提供されている機能 (Tool) の情報を LLM に渡す LLM は、渡された情報を解釈し、どの機能 (Tool) をどのようなパラメータで実行するか決定し、AI チャットソフトに実行を指示する AI チャットソフトは、LLM の指示に従い Cato の MCP の機能 (Tool) を実行する Cato の MCP は、渡されたパラメータをもとに何らかの処理 (Cato の API の実行) を行い、結果を AI チャットソフトに返す AI チャットソフトは、MCP の実行結果を LLM に渡す LLM は、MCP の実行結果や初めに渡された情報をもとに文章を生成し、AI チャットソフトに返す AI チャットソフト (MCP クライアントとして振る舞う) や Cato の MCP サーバを介して、Cato と LLM を連携できたということですね。 Cato MCP で何ができるか 残念ながら現時点ではサイトやユーザに関する限られた情報の取得しか行えませんが、次のようなことであれば AI との会話を通じて行えるのではないでしょうか。 日常的な健全性チェックに関する運用 例）毎朝9時に、全サイトのステータス、接続先 PoP 変更イベントの発生有無、品質の悪いサイトの有無などを確認する。 障害・異常発生時のトラブルシューティング 例）特定のサイトで通信が遅いという報告があったとき、そのサイトの直近のステータス、トラフィック、RTTやパケットロスなどの指標を取得し、どのような状況がいつから発生しているか確認する。 リモート接続ユーザのサポート 例）リモート接続中のユーザからネットワークの不調に関する問い合わせがあったとき、ユーザのOS、クライアントバージョン、トラフィックの各種指標を取得して状況を把握する。 ソフトウェアバージョンアップに関する運用 例）新しいバージョンの Cato クライアントが提供されたとき、古いバージョンを利用しているユーザを抽出する。 さらに、インシデント管理システムや各種コミュニケーションツールなどが提供する MCP サーバも AI に統合すれば、AI との会話ベースで Cato の管理情報と様々なシステムを連携させることも可能になるはずです。 従来こういったことを行おうとすると、各システムの API を活用して連携させる仕組みを頑張って開発する必要がありましたが、MCP という標準化されたインターフェースが登場したことで AI を通じて容易にファジーに連携できるようになってきました。Cato の MCP により連携できるようになったのは、非常に喜ばしいことです。   今はまだサイトやユーザの設定変更を行えず、セキュリティ設定や各種イベント情報の取得もできませんが、将来的に MCP サーバの機能が追加されて様々な操作が行えるようになっていくことを期待しています。 特に、各種イベント情報の取得ができるようになれば、AI を SOC (Security Operation Center) チームの専門家と見立てて、会話ベースでのセキュリティ運用といったことも実現できるようになるのではと妄想しています。 参考：LibreChat を用いた Cato MCP 利用環境の構築 Cato の MCP サーバは任意の MCP クライアント環境で利用でき、公式のドキュメントには Claude Desktop を利用する方法が記載されています。ただ、今回は MCP クライアントとして LibreChat という AI チャットソフトウェアを利用しましたので、参考としてその環境構築方法について記載します。 今回の環境は、Amazon EC2 で起動した Amazon Linux 2023 のインスタンス上に構築し、LLM として Amazon Bedrock で提供される Claude を利用しました。 自マシンからのみアクセスすることを想定した最小限の構成であり、この環境を他の人に公開する際は他にも考慮すべきことが多々あるという点はご了承ください。 Bedrock の基盤モデルの有効化 Amazon Bedrock にて LLM の基盤モデルを利用できるようにする必要があり、その手順は こちらのページ  に記載されています。 今回は Anthropic 社の Claude 3.7 Sonnet を利用しました。 EC2 インスタンスの作成 Amazon EC2 で Amazon Linux 2023 のインスタンスを作成しました。 メモリは最低でも4GB以上のものにする必要がありました。（メモリが2GBだと、後述の LibreChat のセットアップの中でメモリ不足が発生しました…。） この EC2 インスタンスの中から Bedrock のモデルを実行することになるので、インスタンスのロールにて “AmazonBedrockLimitedAccess” ポリシーをアタッチする必要もあります。 以降、EC2 インスタンスに SSH 接続して作業していきます。 MongoDB のセットアップ LibreChat で必要となる MongoDB をセットアップします。 MongoDB のセットアップ手順は こちらのページ に記載されており、概ねその手順に従いました。 sudo vim /etc/yum.repos.d/mongodb-org-8.0.repo (※以下の内容でファイルを作成する) --- [mongodb-org-8.0] name=MongoDB Repository baseurl=https://repo.mongodb.org/yum/amazon/2023/mongodb-org/8.0/x86_64/ gpgcheck=1 enabled=1 gpgkey=https://pgp.mongodb.com/server-8.0.asc --- sudo dnf install -y mongodb-org sudo systemctl start mongod LibreChat のセットアップ LibreChat のセットアップまで行います。 セットアップ手順は こちらのページ に記載されており、概ねその手順に従ってセットアップしました。 sudo dnf install git git clone https://github.com/danny-avila/LibreChat.git -b v0.7.8 cd LibreChat cp .env.example .env sudo dnf install nodejs npm npm ci npm run frontend 上記により、LibreChat のビルドまで完了します。 手順のページでは npm run backend というコマンドの実行が書かれていますが、これを実行すると LibreChat のサーバアプリケーションが起動します。ただ、Cato の MCP を利用するための設定がまだなので、起動はその設定後に行います。 Cato MCP サーバのセットアップ Cato MCP サーバの実装はローカルで実行する形式で用意されていますので、これをセットアップします。 sudo dnf install git git clone https://github.com/catonetworks/cato-mcp-server.git -b v0.9.0 cd cato-mcp-server npm install npm run build この MCP サーバは何かが常時起動しているわけではありませんので、ビルドまで完了すればOKです。 LibreChat の設定と起動 LibreChat のディレクトリにて、設定ファイルの変更・作成を行います。 vim .env (※以下の設定を追加・変更する) --- HOST=0.0.0.0 ENDPOINTS=bedrock,agents BEDROCK_AWS_DEFAULT_REGION=ap-northeast-1 BEDROCK_AWS_MODELS=apac.anthropic.claude-3-7-sonnet-20250219-v1:0 SEARCH=false --- vim librechat.yaml (※以下の内容でファイルを作成する) --- version: 1.2.1 mcpServers: cato: type: stdio command: node args: ["/home/ec2-user/cato-mcp-server/build/index.js"] env: CATO_API_HOST: api.catonetworks.com CATO_ACCOUNT_ID: "アカウントID(4桁または5桁の数字)" CATO_API_KEY: "APIキー" --- 設定したら、次のコマンドを実行して LibreChat の Web アプリケーションを起動します。 npm run backend 3080 番ポートで Web アプリケーションが起動しますので、あとはブラウザからアクセスしてユーザを作成すれば、AI チャットで Cato MCP を利用できるようになります。

こんにちは、SCSK株式会社の小寺崇仁です。 Zabbixの7.2から実装されたNETCONFについて検証したいと思います。 7.2の新機能につきましては、公式HPに記載がございます。 Zabbix 7.2の新機能 Zabbix 7.2 introduces new ways to visualize your data and host information, and improves upon various existing monitorin... www.zabbix.com Zabbix7.2はポイントリリースのため、サポート期間が短くなっています。 本番利用する場合は8.0LTSがリリースされるまでお待ちいただく事をお勧めします。 NETCONFとは NETCONFは、ネットワーク機器の管理・設定を行うための標準プロトコルです。 XML形式のデータとYANGデータモデルを使い、機器の設定や状態取得をプログラム的に実行します。 CLI操作に比べ、自動化、確実な設定、エラーチェックが容易で、セキュアな通信を提供。大規模ネットワーク運用における自動化基盤として利用されます。 ZabbixとNETCONF ZabbixからNETCONFを使って監視すると以下のメリットがあると考えられます。 確実なデータ取得: XML/YANGモデルによりデータ構造が明確なため、CLIスクレイピングと異なりフォーマット変更による監視破損リスクが低く、安定して正確な情報が得られます。 詳細な情報取得: SNMPでは難しい機器のより詳細な設定や運用状態を正確に監視できます。 セキュリティ強化: SSHベースで通信が暗号化され、セキュアな監視が実現します。 ベンダー依存低減: YANGモデルの標準化により、異なるベンダーの機器でも共通の監視ロジックを適用しやすくなります。   設定方法 Zabbix7.2とjuniperを使った設定内容をご紹介いたします。 juniperの設定 環境に合わせてサービスの起動、FWの穴あけを行います。 #サービスの有効化 set system services netconf ssh #FWの穴あけ set security zones security-zone untrust interfaces ge-0/0/0.0 host-inbound-traffic system-services netconf アイテムの作成 以下の設定でアイテムを作成します。Juniperでインタフェースの情報を取得するサンプルです。 名前 任意 タイプ SSHエージェント キー ssh.run[,,830,,,netconf] ※ポートとNETCONFであることを指定します。 データ型 テキスト 認証方式 パスワード（環境に合わせて） ユーザー名 （環境に合わせて） パスワード （環境に合わせて） 実行するスクリプト （XML RPCタグ） <rpc> <get-interface-information> <detail/> </get-interface-information> </rpc> ]]>]]> <rpc> <close-session/> </rpc> ]]>]]> 上記アイテムを作成いただく事で、NETCONFを使用してXML形式のデータの取得ができます。 しかしXMLの生データだけでは、監視ができないので、環境に合わせてデータの加工の設定を行う必要があります。 次に、データ加工に必要なスキルを紹介します。   必要スキル XML RPCタグの作成 データ取得の際にXML RPCタグを使って、取得するデータを指定しています。 各機器ごとにタグが違うと思うので、注意が必要です。 juniperであれば、パイプで「display xml rpc」をつなげれば作成できるようです。 user@host> show interfaces t3-5/1/0:0 | display xml rpc <rpc-reply xmlns:junos="http://xml.juniper.net/junos/16.1R1/junos"> <rpc> <get-interface-information> <interface-name>t3-5/1/0:0</interface-name> </get-interface-information> </rpc> <cli> <banner></banner> </cli> </rpc-reply> 引用： https://www.juniper.net/documentation/us/en/software/junos/junos-xml-protocol/topics/task/junos-xml-protocol-rpcs-and-xml-mapping.html 保存前処理(javascript)でデータの加工 取得したXMLデータを加工、成形する際に保存前処理でJavascriptを書く必要があります。 加工、成形する目的としては、以下2点のためです。 ・XMLから所定の値(文字列)を抽出する ・後工程（依存アイテム、LLD）で使用しやすいように、データの加工（成形）する 依存アイテム、ローレベルディスカバリ(LLD)でアイテム分割 NETCONFで監視するアイテムを大量に作成すると、NW機器側に負荷がかかるため、まとめて取得して分割する必要があります。 その際に、依存アイテム、ローレベルディスカバリを使用すると分割することができます。 依存アイテム 依存アイテムは、まとめて取得したデータを分割保存するアイテムタイプです。 例えば、1回のNETCONFアイテムで「show version」の結果を取得したとします。 コマンド結果にある、「OSの種類」と「バージョン」を別々のアイテムとして保存する場合に使用します。 ローレベルディスカバリ インタフェースごとにアイテムを作成する場合に使用します。 機器ごとにインタフェースの数、名前が違うと思います。 ローレベルディスカバリでは、機器に合わせて自動的にアイテムを作成する事ができます。   監視設定が難しい場合 ZabbixインテグレーションにJuniperのNETCONF用テンプレートが公開されております。 その他の機器についてもリリースされることを期待して待つのもよいかと思います。 https://www.zabbix.com/jp/integration_search?search=netconf SCSK Plus サポート for Zabbix SCSK Plus サポート for Zabbix 世界で最も人気のあるオープンソース統合監視ツール「Zabbix」の導入構築から運用保守までSCSKが強力にサポートします。 www.scsk.jp ★YouTubeに、SCSK Zabbixチャンネルを開設しました！★ SCSK Zabbixチャンネル SCSK Zabbixチャンネルでは、Zabbixのトレンドや実際の導入事例を動画で解説。明日から使える実践的な操作ナレッジも提供しており、監視業務の効率化に役立つヒントが満載です。 最新のトピックについては、リンクの弊社HPもしくはXアカ... www.youtube.com ★X（旧Twitter）に、SCSK Zabbixアカウントを開設しました！★ https://x.com/SCSK_Zabbix x.com

はじめに 当記事は、 日常の運用業務（NW機器設定）の自動化 により、 運用コストの削減　および　運用品質の向上 　を目標に 「Ansible」 を使用し、様々なNW機器設定を自動化してみようと　試みた記事です。 Ansibleは、OSS版（AWX）＋OSS版（Ansible）を使用しております。   PaloAltoの「Objects-サービスグループ」の登録／変更／削除を実施してみた 事前設定 Templateを作成し、インベントリーと認証情報を設定する。 インベントリー：対象機器（ホスト）の接続先を設定。　※ホストには以下変数で接続先IPを指定 ansible_host: xxx.xxx.xxx.xxx 認証情報：対象機器へのログイン情報（ユーザ名／パスワード）を設定。 ユーザ名は　　変数：ansible_user　　　に保持される パスワードは　変数：ansible_password　に保持される   Playbook作成（YAML） 使用モジュール paloaltonetworks.panos.panos_service_group 　を使用。 ※参考ページ： Ansible Galaxy galaxy.ansible.com   接続情報（provider）の設定 providerには、ip_address／username／password　の指定が必要。 vars: provider:   ip_address: '{{ ansible_host }}'　　　←　インベントリーのホストで設定   username: '{{ ansible_user }}'　　　　←　認証情報で設定   password: '{{ ansible_password }}'　　←　認証情報で設定   Objects-サービスグループの登録　※サービスグループの新規作成の場合 接続情報と　サービスグループとサービスの関連付け　を指定して登録（ state: ‘present’ ）を行う。 - name: Present ServiceGroup1 paloaltonetworks.panos.panos_service_group: provider: '{{ provider }}' name: 'test_servicegroup001'　　　←　サービスグループ value: 'test_service001'　　←　サービスグループに関連付けするサービス state: 'present' register: wk_result 実行結果：対象のサービスグループが登録された。　※Ansibleの実行結果（diff）を抜粋 "before": "", "after" : "<?xml version=\"1.0\" encoding=\"utf-8\"?>\n<entry name=\"test_servicegroup001\">\n\t<members>\n\t\t<member>test_service001</member>\n\t</members>\n</entry>\n"   Objects-サービスグループの登録　※サービスグループが既に存在する場合 接続情報と　サービスグループとサービスの関連付け　を指定して登録（ state: ‘present’ ）を行う。　 ※サービスグループが既に存在する場合は、既存設定の置き換えとなる（state: ‘replaced’と同様）   - name: Present AddressGroup1 paloaltonetworks.panos.panos_service_group: provider: '{{ provider }}' name: 'test_servicegroup001'　　　←　サービスグループ value: 'test_service002'　　←　サービスグループに関連付けするサービス state: 'present' register: wk_result 実行結果：既存のサービスグループが 上書き更新 された。　※Ansibleの実行結果（diff）を抜粋 "before": "<?xml version=\"1.0\" encoding=\"utf-8\"?>\n<entry name=\"test_servicegroup001\">\n\t<members>\n\t\t<member>test_service001</member>\n\t</members>\n</entry>\n", "after" : "<?xml version=\"1.0\" encoding=\"utf-8\"?>\n<entry name=\"test_servicegroup001\">\n\t<members>\n\t\t<member>test_service002</member>\n\t</members>\n</entry>\n"   Objects-サービスグループの変更　※登録のつづき（新たなサービスを関連付けする） 接続情報と　サービスグループとサービスの関連付け　を指定して、サービスグループの変更（ state: ‘replaced’ ）を行う。　 ※replacedの場合は、既存設定の置き換えとなる　（注意：関連付け後の状態を指定すること！！） - name: Replaced AddressGroup1 paloaltonetworks.panos.panos_service_group: provider: '{{ provider }}' name: 'test_servicegroup001' value: ['test_service001','test_service003']　←　関連付け後の状態を指定すること！！ state: 'replaced' register: wk_result 実行結果：既存のサービスグループが 上書き更新 された。　※Ansibleの実行結果（diff）を抜粋 "before": "<?xml version=\"1.0\" encoding=\"utf-8\"?>\n<entry name=\"test_servicegroup001\">\n\t<members>\n\t\t<member>test_service002</member>\n\t</members>\n</entry>\n", "after" : "<?xml version=\"1.0\" encoding=\"utf-8\"?>\n<entry name=\"test_servicegroup001\">\n\t<members>\n\t\t<member>test_service001</member>\n\t\t<member>test_service003</member>\n\t</members>\n</entry>\n"   接続情報と　サービスグループとサービスの関連付け　を指定して、サービスグループの変更（ state: ‘merged’ ）を行う。　 ※mergedの場合は、既存設定を維持した更新（Append）となる。 その為、特定サービスの関連付け解除はできない　（注意：サービス の関連付け解除をしたい場合は　state: ‘replaced’　を使用する必要がある！！）   - name: Merged AddressGroup1 paloaltonetworks.panos.panos_service_group: provider: '{{ provider }}' name: 'test_servicegroup001' value: 'test_service003'　←　関連付けしたいサービスのみ指定すること！！ state: 'merged' register: wk_result 実行結果：既存のサービスグループが 更新（Append） された。 既存設定が維持されていることを確認 。　※Ansibleの実行結果（diff）を抜粋 "before": "<?xml version=\"1.0\" encoding=\"utf-8\"?>\n<entry name=\"test_servicegroup001\">\n\t<members>\n\t\t<member>test_service002</member>\n\t</members>\n</entry>\n", "after" : "<?xml version=\"1.0\" encoding=\"utf-8\"?>\n<entry name=\"test_servicegroup001\">\n\t<members>\n\t\t<member>test_service002</member>\n\t\t<member>test_service003</member>\n\t</members>\n</entry>\n"   Objects-サービスグループの情報収集　※変更のつづき 接続情報と　サービスグループ　を指定して情報収集（ state: ‘gathered’ ）を行う。 - name: gathered AddressGroup1 paloaltonetworks.panos.panos_service_group: provider: '{{ provider }}' name: 'test_servicegroup001' state: 'gathered' register: wk_result 実行結果：対象サービスグループの 情報が取得 できた。　※Ansibleの実行結果（gathered_xml）を抜粋 "gathered_xml": "<?xml version=\"1.0\" encoding=\"utf-8\"?>\n<entry name=\"test_servicegroup001\">\n\t<members>\n\t\t<member>test_service001</member>\n\t\t<member>test_service003</member>\n\t</members>\n</entry>\n"   Objects-サービスグループの削除　※変更のつづき 接続情報と　サービスグループと関連付いているサービス　を指定して、削除（state: ‘absent’）を行う。　（ 注意：関連付いているサービスが削除されるのではなく、サービスグループが削除される！！）   - name: Absent AddressGroup1 paloaltonetworks.panos.panos_service_group: provider: '{{ provider }}' name: 'test_servicegroup001'　　　←　サービスグループ　※サービスグループが削除される value: 'test_service003'　　←　サービスグループに関連付いているサービス　※指定の必要なし state: 'absent' register: wk_result 実行結果：対象のサービスグループが 削除 された。　※Ansibleの実行結果（diff）を抜粋 "before": "<?xml version=\"1.0\" encoding=\"utf-8\"?>\n<entry name=\"test_servicegroup001\">\n\t<members>\n\t\t<member>test_service001</member>\n\t\t<member>test_service003</member>\n\t</members>\n</entry>\n", "after" : ""   最後に 「Ansible」の「paloaltonetworks.panos.panos_service_group」を使用し、「Objects-サービスグループ」の登録／変更／削除　および　情報収集ができたことは良かった。何らかの変更申請の仕組みと連携することで、より　設定変更の自動化　が活用できるようになると考える。 現状　設定情報がベタ書きで使い勝手が悪いので、今後　設定内容をINPUTする仕組みを試みたいと思います。 また、引続き　他にも様々なNW機器設定を自動化してみようと思います。

こんにちは。SCSKの松渕です。 皆さん、ペット飼っていらっしゃいますか？自分のペットは、周りとどれだけ違うんでしょうか。気になったことありませんか。 そして、AIでどれだけちゃんと識別できるんだろうか、と。 ということで、今回はGoogle Cloud Vertex AIのAutoMLを利用して、 写真に写っている猫を、私の飼っている猫（リク）と、そのほかの猫を分類するモデル「リクか、リク以外か」を作ってみました。 用語整理　～Vertex AI と AutoML と Vertex AI Vision～ 前段として用語の整理します。コロコロと名前変わるのでわかりにくいですよね。。 Vertex AI Google Cloudが提供するAI開発のための 統合プラットフォーム です。 データの準備からモデルのトレーニング、そして運用まで、AI開発の全工程をサポートする強力な基盤といえます。 Vertex AIの中では、AIモデルを作るためのアプローチとして、主に2つの方法が提供されています。           カスタムトレーニング ：データサイエンティストがPythonなどのコードを書いてモデルを構築する方法です。 AutoML（自動機械学習） ：今回利用する方法で、専門的な知識がなくてもカスタムAIモデルを作成できる機能群です。 AutoML Vertex AIプラットフォーム内で利用できる機能群で、 専門家でなくてもカスタムAIモデルを作成 できます。「画像」「テキスト」「表データ」など、様々なデータに対応したAutoMLがあります。今回は、 画像を使ったAutoML を利用しました。 以前は「AutoML Vision」と呼ばれてました。 Vertex AI Vision: 少し混乱しやすいのですが、 Vertex AI Vision （旧称Visual Inspection AI）という全く別のサービスもあります。リアルタイムの動画ストリームや膨大な画像データから継続的にインサイトを抽出し、高度なビジョンAIアプリケーションを構築・運用することを目的としています。 製品の正常/異常の分類　タスクについて 今回はAutoMLですが、Vertex AI Vision（旧称Visual Inspection AI）でも「製品の正常/異常の分類」という目的であれば画像から二値分類タスクができます。 Visual Inspection AIの新モデル Anomaly Detection を触ってみた！！(Tech hermony) データ準備 Step1：目標枚数の決定 画像分類用のAutoMLでは、 各ラベルにつき最低10枚 のサンプルがあればモデル作成できます。今回のケースでは最低20枚（リク10枚、リク以外10枚）が必要でした。一般的に、学習データは多ければ多いほど精度が向上し、画像のパターンも可能な限り多様な条件である方が望ましいです。 今回は、リク50枚、リク以外50枚の合計100枚で試しました。 Google Cloudのドキュメントでは、各ラベル（クラス）につき 1,000枚以上 を推奨しています。 AutoML モデルの上限(Google Cloud ドキュメント) データ拡張（Data Augmentation）について 最低10枚という非常に少ない枚数でも学習できるのは、 内部的にデータ拡張が行われている ためだと考えられます。 事前構築済みの検索スペース(Google Cloud ドキュメント) データ拡張（Data Augmentation）って知っていますか？？①(Tech hermony) サンプルの集め方について 「画像のパターンも可能な限り多様な条件」と書きましたが、これは一般的な原則です。 ユースケースによっては、特定の条件に画像を揃えた方が望ましい場合もあります。 例えば、動物病院で診察前の猫の全体像を映した写真のように、 固定の場所である程度統一された画角で撮影されることが想定される場合 は、サンプル画像もそれに合わせて 条件が統一されたもの で集めた方がモデルの精度は高まります。 一方で、 今回は「いわゆる日常写真」から リクを分類することを想定していたため、明度や背景、リクのポーズなども意図的に 「多様な条件」 で収集しました。 Step2：サンプル画像収集（リク画像） スマホに保存されている沢山の画像の中から50枚選んでPC送るだけでした。かわいい。   Step3：サンプル画像収集（リク以外画像） 猫カフェに行った時の写真や親戚の猫の写真などを集めました。 気持ち、リクと色味が似ている猫を中心に集めました。こちらもかわいい。 構築 Step4：データセットの作成 データセット作成画面へ Vertex AI のトップ画面（ダッシュボード）の下段にある「データセットを作成」を押下します。 単一ラベル分類を選択 データセットを作成の画面に遷移します。 データセット名を入力します。 今回は二値分類タスクのため、「単一ラベル分類」を選択して、「作成」を押下します。   データ保管のリージョンについて 上記の画面でリージョンがアイオワになっていることに気づいた方もいるかもしれません。 これは、内部的にVision Warehouseを使用しているためで、このブログ執筆時点では、 提供されているリージョンがオランダとアイオワのみとなっています。 Vision Warehouse のリージョンの選択(Google Cloud ドキュメント) そのため、 画像のAutoML 使う場合、データ保管リージョンに 日本を選べない のでご注意 ください。 画像インポート方法選択 画面のインポート方法を選択。今回はパソコンから直接画像アップロードしました。 画像アップロード確認 パソコンからアップロードしたらこのような画面が出てきました。 データ分類（トレーニング、検証、テスト）が各画像に対して選べるようになってます。 下にスクロールし、サンプル画像を保管するGCSのパスを入力して「続行」を押下します。 インポートを待つ インポートが開始されます。時間を計測していませんでしたが、合計100枚（約22MB）で20分くらいかかったと思います。 愛猫への思いが強く、画像が大きめだったのも原因かもしれません。 以下のような文言が出てきます。 また、インポート終わったらメールも届きます。 Step5：ラベリング ラベル定義 インポートが終わるとデータセットの画面にデータがずらっと並びます。とてもかわいい。 新規ラベル追加をクリックしてラベル作ります。 今回は「riku」と「non_riku」としました。ちなみに、ラベルに日本語やハイフンは使えません。 ラベル割り当て 画像選択してラベル割り当てます。 Step6：トレーニング トレーニング開始ボタン押下 すべての画像にラベルを割り当てられたら、右側の「新しいモデルのトレーニング」を押下します トレーニング方法選択 カスタムモデルを作る場合はここでカスタムトレーニングを選択します。今回はAutoML選択。 余談ですが、「Edgeモデル」も選択できます。 これは、リアルタイム応答が必要な場合や、IoT機器への搭載、オフラインで動作させるようなユースケースで有用です。 AutoML Edge モデルのトレーニング(Google Cloud ドキュメント) モデルの詳細 今回は新しいモデルのトレーニングを選択します。 学習の割合は手動で変えることも可能ですが、今回はデフォルトの通りの割合で進めます。 Vertex AIのデフォルトで以下の割合で分割されます。 トレーニング：80% 検証：10% テスト：10% AutoML モデルのデータ分割の概要(Google Cloud ドキュメント) トレーニングオプション 増分トレーニングかどうか尋ねられます。既存のモデルに追加学習を行う場合は増分トレーニングを選び、既存モデルを選択します。 今回は新規なのでそのまま続行します。 ノード時間の最大値を選択 どの程度の時間使って学習するかの最大値を選択します。 8～800の間 で入力します。最小の8で進みます。     トレーニング待ち トレーニング完了まで待ちます。 なお、トレーニング完了したらメールが届きます。 トレーニング完了 トレーニング完了したら、「トレーニング」の項目に完了と出力されます。 今回は1時間43分かかりました。 評価、デプロイ Step7：評価結果確認 モデル全体の評価指標確認 AutoMLの素晴らしい点の一つは、 モデルの評価まで終わらせてくれる ところだと思います。 トレーニング終わった時点で 再現率、適合率、混合行列、PR曲線等の各種指標を出力 してくれます。 今回は、いい感じに1つ間違えていました。 偽陽性が1サンプル ありますね。 参考までに、混合行列と再現率/適合率/正解率の計算方法は以下の通りです 間違えたサンプルの確認 混合行列で、1サンプル間違えているのが確認できました。 評価のラベルから「riku」ラベルを選択すると、 間違えたサンプルと正解したサンプルが見れます 。 ・・・なるほど、リクっぽい猫ですね。 ただ、スコアも0.552と、閾値である0.5をわずかに上回っただけだったことが確認できます。 正しかったサンプルの確認 正しく分類できたものは、どれも高いスコアであることがわかります。かわいい。 non-rikuも0.78～1の間のスコアでした。 実案件においては、 スコアによって対応を変えるケース も考えられます。 例えば、0.5を閾値にして「リクか、リク以外か」の二値分類とするだけでなく、 スコアが0.7未満の場合には「リク以外の可能性もある」といった選択肢を設け、 人間が目視確認するフローを組み込むなど 、ユースケースに応じた柔軟な対応検討が必要となるでしょう。 Step8：デプロイして遊んでみる やりたいことはほぼ終わったのですが、せっかくならデプロイまでしようと思います。 エンドポイントにデプロイを選択 モデルの画面から、「デプロイとテスト」を選び、「エンドポイントにデプロイ」を押下。     エンドポイントの定義 エンドポイント名を選択して続行を押下します。 画面に記載の通りですが、 エンドポイントは標準（インターネット経由でのアクセス） になります。 プライベートアクセスにするには、カスタムモデルもしくはAutoML 表形式モデルのみです。 とはいえ、デフォルト設定でも IAMで認証されたトークンが必須 になるため、 誰でもアクセスできるわけではないのでご安心ください。 モデル設定 モデル設定を行います。「コンピューティングノードの数」は、今回は1としてます。 本番環境への適用なら2以上をお勧めします。 AutoMLのSLOは、2ノード以上を利用した前提で99.9%と定義 されております。 AutoML VisionのSLO(Google Cloud ドキュメント)     モデル設定 モデルのデプロイされるまで待ちます。   テスト デプロイも完了したらメールきます。体感10分くらいでした。 以下の画面のステータスが「アクティブ」になります。 また、下部に「モデルのテスト」という項目が出てきました。ここからテストします。   今までのサンプルとはまた別の画像でテストしてみます。しっかりとリクと判定されましたね！ かわいい。 今回はコンソールからGUIでのテストで終わりますが、もちろんAPIからも呼び出し可能です。 後片付け エンドポイント削除の前に、モデルのデプロイを解除が先に必要です   エンドポイントの削除が可能になりました。削除して終わります。 Step9：コストの確認 後日、コスト確認しました。 合計　 \4,259- 　でした。 トレーニング（8ノード時間）：　 \4,120- デプロイ（1ノード、約40分）：　\   139- まとめ 今回は、Google Cloud Vertex AI の AutoML を使って、愛猫リクとそれ以外の猫を分類するオリジナルAIモデル「リクか、リク以外か」を構築しました。 AutoML を利用することで、専門的な知識がなくても、 データの準備からラベリング、モデルのトレーニング、そして評価、デプロイまでの一連のプロセスをスムーズに進められる ことがお分かりいただけたかと思います。特に、直感的な GUI 操作で高品質なモデルが構築できる点は、AutoML の大きな魅力です。 実際のビジネス案件でAIモデルを使うとなると、評価は非常に重要なポイント になります。100%の精度は現実的に難しいため、どの評価指標を重視するか、そして間違えた場合の対応をどうするかといった判断が不可欠です。 具体的には、 再現率 を重視するのか、 適合率 を重視するのか。また、誤分類が発生した際の セーフティネットとして人の判断を組み込む のか、といった検討が求められます。各評価指標を深く理解した上で、 「このユースケースでは、この程度の数値が出ればビジネスに活用できる」という明確な判断基準 を持つことが、AI導入成功の鍵となるでしょう。

本記事は 夏休みクラウド自由研究2025 8/6付の記事です 。 今年もSCSKの技術ブログ「TechHarmony」で今月「夏休みクラウド自由研究 2025」企画が開始されていますが、Catoクラウドチームとしては、8/4から8/13の合計10記事を担当します。   はじめに 「夏休みクラウド自由研究」として別テーマで記事を考えていたのですが、ちょうど昨日（2025年8月5日）Cato Networks社のパートナープログラムについての”お知らせ”を掲載することになったため、その補足記事を投稿することにしました。 昨日の”お知らせ”については以下をご覧ください。 Cato Networksのパートナー最高位である「MSP Advancedパートナー」を獲得し、SASE導入さらに加速 Cato Networks社のパートナープログラムは、正式には「 Cato Networks チャネルファーストパートナープログラム 」というものです。 パートナープログラムの詳細については公式ページをご覧ください。 https://www.catonetworks.com/ja/partners/ Cato Networksのビジネスは、100％パートナー経由であるため、パートナーのビジネス成長が、Cato Networks社のビジネス成長となるため、より高いレベルで包括的な支援を提供すべく今回パートナープログラムが用意されました。 実際には、数年前から、Cato Networks社にはパートナープログラムの整備や、Cato Networks社のホームページ上へ、パートナー企業を掲載するように依頼をしていたのですが、やっとパートナープログラムがリリースされたことになります。 しかしながら、まだパートナー掲載ページは準備されていませんので、Catoクラウドを検討されるお客様にとっては、パートナーがどこなのか分からず、ご自身でWeb検索や問い合わせをするしかない状況は変わっていません。   パートナータイプ 比較のために、例えばAWSにおいては、パートナーは、パートナータイプごとに「サービスパス」「ソフトウェアパス」「ハードウェアパス」「トレーニングパス」「ディストリビューションパス」の5つの”パス”に分けられています。 ちなみに、AWSにおいてSCSKは「サービスパス」となります。 Catoのパートナーも、パートナータイプごとに特化された「 サービスプロバイダー（SP） 」、「 マネージドサービスプロバイダー（MSP） 」、「 付加価値再販業者（VAR） 」、「 エージェント 」といった4つのプログラムが準備されています。また、現時点では 日本国内パートナーは、MSPとVARの2つのいずれかに分類 されています。 上記以外に、いわゆる一次卸業者・ ディストリビューター（Distributor） がありますが、お客様が直接Catoクラウドのライセンスを購入したり、設計/構築、保守運用を受けるのは、ディストリビューターではなく、パートナー（上記4つのいずれかのタイプから）となりますので割愛します。 ディストリビューターからは、Catoクラウドのライセンス購入したり、その他サービスを受けることはできませんので、必ずパートナーを見つける必要があります。 SCSKはパートナーで、単なるCatoクラウドのライセンス販売だけではなく、PoC支援から設計/構築/移行はもちろんのこと、独自のマネージドサービス、マネージドセキュリティサービス（SOC、セキュリティアドバイザリーサービスなど）を提供しており、Cato社のサポート認証「Cato Distinguished Support Providers（CDSP）」も取得していることから 「マネージドサービスプロバイダー（MSP）」に認定 されております。 CDSPについて https://blog.usize-tech.com/cato-cdsp-scsk/   パートナーランク（ティア） AWSパートナーでは、実績や専門性に応じて「セレクト」「アドバンスト」「プレミア」の3つのティア（ランク）が準備されています。 ちなみにAWSでは、当社は最上位である「プレミア」となりますので「サービスパス」と合わせて、SCSKは「AWSプレミアティア サービスパートナー」となります。 Catoのパートナープログラムも階層型になっており、パートナーのエンゲージメント、投資、パフォーマンスのレベルに合わせて、最初の階層である「 スターター（Starter） 」と、上位の「 アドバンスド（Advanced） 」の2つのランクが準備されています。 AWSとは異なり「プレミア」はまだ準備がされていないため 「アドバンスド」が現時点での最上位ランク（ティア） となります。 パートナーランク（ティア）の条件は公開されていないため、ここでも記載は割愛しております。 SCSKは、ランク条件をクリアし、最上位の「アドバンスド」認定を受けておりますので、「マネージドサービスプロバイダー（MSP）」と合わせて、「 Cato Networks MSP アドバンスドパートナー 」を獲得 したことになります。   パートナー選びについて Catoクラウドの検討が進み、ライセンス見積り、設計/構築見積りなどが必要となった場合は、パートナーを選ぶ必要があります（ディストリビューターではなく） 単純にCatoクラウドのライセンスを購入するだけの場合は「 エージェント 」パートナー、Catoクラウドの設計/構築なども委託をしたい場合には「 付加価値再販業者（VAR ）」パートナーから選ぶことも可能ですが、Catoクラウドの設計/構築だけではなく、その後の運用保守（マネージドサービス、SOC）を含めた支援やサービス提供を “安心して” 提供を受けたい場合には「 マネージドサービスプロバイダー（MSP） 」パートナーから選ぶ必要があります。 現在（2025年7月時点）、日本国内にはCatoパートナー企業が 150社 以上存在します（ちなみにCatoクラウドの国内導入実績は約650社です） 前述の通り、日本国内パートナーは「マネージドサービスプロバイダー（MSP）」と「付加価値再販業者（VAR）」のいずれかに分類されていますが、その殆どは「付加価値再販業者（VAR）」の「スターター」となります。また、その内、販売実績があるパートナーは約50社（1/3）とのことですので、実績のないパートナーが約100社近くいることには注意が必要です。 実際に、別のパートナーでPoCを実施したが、問い合わせの回答が返ってこず、PoCが思ったように進まず、改めて当社へ声掛けをいただいた例や、すでに本番利用されていて、不具合が発生しており、問い合わせを実施しているが、何ヶ月も不具合が解消せずに困って当社へお問い合わせいただく例も増えてきています。 Catoクラウドのパートナー選びにおいては、単純にディストリビューターに紹介されたパートナーや、既存取引のあるパートナーへ声掛けをするのではなく、正しくパートナー選びを行うために、今回のパートナープログラムが整備されました。 これまではCatoクラウドのマネージドサービスが必要な場合のパートナー選びは 24時間365日の電話/メールのサービス窓口がサービス提供されているか？ CatoのSD-WANエッジデバイスであるCato Socketの24時間365日のオンサイト保守（4時間駆け付け）がサービス提供されているか？（標準保守はセンドバック） CatoのSOCがサービスが提供されているか？ 単純にサービスメニューがあるだけでなく、導入実績（具体的な顧客導入事例）があるか？ Catoクラウド認識技術者を複数名以上有しているか？ 「Cato Distinguished Support Providers（CDSP）」認証を取得しているか？ などの個別で確認が必要でしたが、今回パートナープログラムがリリースされたことにより、 パートナータイプは「マネージドサービスプロバイダー（MSP）」なのか？ パートナーランクは「スターター」なのか「アドバンスド」なのか？ だけで、容易に確認できるようになりました。 残念ながらCato社のホームページ上でパートナーを掲載するページはまだ準備されていませんが、パートナー企業へパートナータイプとランクを確認することで容易に判断が可能となりました。   まとめ SCSKは「 Cato Networks MSP アドバンスドパートナー 」を獲得しただけではなく、先月（2025年7月15日）に開催されたCato Networks社の日本で3回目となるパートナーサミット「Japan Partner Summit Tokyo 2025」で、 3年連続でアワード受賞 をしています。 新規顧客の売り上げに最も貢献したパートナーとして「 Japan Highest New Logo Revenue 2024 」と、最も卓越したサポートを提供し、お客様の満足度向上に貢献したパートナーとして「 Japan Best Technical Support Partner 2024 」の2つのアワードを ダブル受賞 しています。 Cato Partner Summit 2025 で 3年連続パートナーアワード受賞、さらに今年はダブル受賞！ Cato Networks社のパートナーサミット「Japan Partner Summit Tokyo 2025」で 3年連続パートナーアワード受賞、今年はダブル受賞となります。 blog.usize-tech.com 2025.07.22 つまり、新規にCatoクラウドを検討しているお客様はもちろんですが、すでにCatoクラウドをご利用中でサポートを含め各種マネージドサービスに困っているお客様がもしいらっしゃれば、ぜひ当社まで お問い合わせ ください。 日本国内でも「SASE（Secure Access Service Edge、サッシー）」、「Cato Networks（ケイトネットワークス）」、「Catoクラウド（正式名称は、Cato SASE Cloud Platform）」の認知度は徐々に上がっていますが、まだまだ認知度が高いとは言えない状況です。 SCSKでは、2021年からSASEの主要な４ソリューションを一同に紹介を行うオンラインセミナー「SCSK SASE Solution Summit（S4、エスフォー）」を定期的に開催しております。これまで15回開催し、述べ2,200名以上の方にご参加いただいております。Catoクラウドにおいては、SASE初心者向けの簡単セミナー、主要機能を2時間で説明するデモセミナーをオンライン（無料）で開催し、さらに全国各地で半日のハンズオンセミナーを年間通じて定期的に開催しておりますので、ご興味ある方は、ぜひご参加ください。 Catoクラウド イベント・セミナー情報 | よくあるご質問 | Cato Cloud ケイトクラウド - SCSK 定期的にCatoクラウドをご紹介するセミナーを開催しております。・2024年9月26日（木）Catoクラウド ハンズオンセミナー【札幌開催分】　～全国5都市開催（東京/大阪/名古屋/博多/札幌）～　... cato-scsk.dga.jp 最近、Catoクラウドのパートナーが増え、同業他社からお申し込みが増えておりますが、事前に当社にご相談のないパートナー様からお申し込みは、事務局でお断りしておりますので、予めご了承ください。 セミナー以外に、Catoクラウドの お客様導入事例 の制作、好評をいただいているCatoクラウド FAQサイト 運営、この TechHarmony（技術ブログ） で、Catoクラウドの日本語での情報提供を積極的に行い、皆様のお役に立ち、Catoクラウドの認知度の向上ができればと考えております。 最後に、Catoクラウドをご利用者（ユーザ）様を対象としたユーザーコミュニティ「 Cato Circle（ケイトサークル） 」を発足しました。 Catoクラウド ユーザーコミュニティ「Cato Circle」を発足しました！ Catoクラウド ユーザーコミュニティ「Cato Circle（ケイトサークル）」の発足についての記事となります。 blog.usize-tech.com 2025.07.02 Cato Circleは、ユーザーコミュニティなので、通常のセミナーのように一方的に説明を行う「説明型」イベントではなく、利用者であるお客様が、Catoクラウドの自社での活用方法や、利用上の課題を発表し、利用者同士が情報を共有する「双方向型」のイベントとなります。 お客様同士のネットワーク構築・交流から、情報交換のきっかけをご提供し、課題や悩みを共有し、解決のヒントを得ていただくことが Cato Circle の目的となっております。 Catoクラウドをご検討中のお客様も参加いただくことが可能ですので、Catoクラウドに少しでも興味をお持ちになられた方は、ぜひ当社まで お問い合わせ ください。 Catoクラウド エンジニアブログまとめ記事 Catoクラウドのエンジニアブログ（TechHarmony）でのまとめ記事となります。 blog.usize-tech.com 2024.02.27

皆さん、こんにちは！ 皆さん、生成AI活用していますか？ 文章を書かせたり、プログラムのコードを生成させたり、最近では気兼ねなく悩みを打ち明けられる良き相談相手として活用している人もいるようです。 でも、なんだか彼らの回答って、いつも丁寧で優等生すぎると思いませんか…？ 「もちろんですよ！」「お役に立てて光栄です！」 …いや、嬉しいんだけど、たまにはもっと個性的で、厳しくしてくれるAIがいてもいいのでは…？ そんなことを考えていた私は、ふと思いました。 「人間の相談にズバッと答えらられる、こてこての関西弁のAIがいてもいいのではないか？」 というわけで今回は、Amazon Bedrock、Amazon Rekognitionを使って、 食事の画像を送ると、その内容を認識して関西弁で鋭いツッコミと的確なドリンク提案をしてくれる「辛口AIソムリエ」 を開発してみました！ この記事は、 生成AIで何か面白いものを作ってみたい！ AWSに興味があるけど、何から始めればいいかわからない… プログラミング初心者だけど、AIアプリ開発に挑戦したい！ という方にピッタリな内容です。早速アプリの概要を見ていきましょう。 実際にAIソムリエに相談してみよう 百聞は一見にしかず！ということで、まずはこの「辛口AIソムリエ」がどんな風に動くのか見てみましょう。 例えば、深夜に飯テロの定番、ピザの画像をAIに送ってみると… 【AIソムリエからの返信】 うわぁ、なんやこのハイカロリーなピザは！? お前、夜中にこんな濃い味付けのものを食べとるんか!? アホちゃうかいな。ほんまに… (ひと呼吸おいて)まぁしゃあないからこの俺が特別に合う飲み物を選んでやるわ。 1. サングリア – スパイシーなピザに合うのは、程よい酸味とフルーツの香りを持つ赤ワインベースのサングリアやろ。食欲もそそられるしな。 2. トマトジュース – 濃厚なトマトソースと同化する赤い果汁飲料は、ピザの重たさを軽減してくれるはずや。ビタミンCも補給できてお得やろ? 3. コーラ – 炭酸の刺激的な喉越しが脂っこいピザをスッキリさせてくれる。糖分もあるから夜食にぴったりやで。 お前らも知らんふりしてたけど、結構グレードの高い組み合わせやと思うぜ? なんでやねん、この俺に任せときゃよかったんちゃうの? …どうでしょう？（笑） めちゃくちゃ口は悪いですが、言っていることは意外と的確。こんなAIがいたら、日々の食事がちょっと楽しくなりそうじゃないですか？   システムの全体像（アーキテクチャ） さて、このAIソムリエがどんな仕組みで動いているのか、簡単な図で見てみましょう。 ユーザーが食事の画像のURLを、 AWS Amplify で作成したフロントエンドからAPIに送ります。 Amazon API Gateway が「受付窓口」としてリクエストを受け取ります。 AWS Lambda が「司令塔」としてメインの処理を実行します。 Lambdaは、まず画像の分析を Amazon Rekognition に依頼します。 Rekognitionは画像から「Pizza」や「Cheese」といったキーワード（ラベル）を返します。 次にLambdaは、そのキーワードを基に Amazon Bedrock に応答文の生成を依頼します。このとき、AIの回答を調整するためにプロンプトを設定します。 Bedrockが生成した個性的な文章が、ユーザーに返されます。 このように、Lambdaを中心にRekognition、Bedrockで回答作成をしてもらうことでサーバーレスなサービスを実現しています！   このシステムのキモ！AIに魂を吹き込むプロンプト設定 このシステムの面白さの9割は、Amazon Bedrockに渡しているプロンプトにあるといっても過言ではありません。 プロンプトとは、生成AIに対する「指示書」や「台本」のようなものです。ここの書き方次第で、AIの性格や口調、役割を指定して回答を調整していきます。 ただ「ピザに合う飲み物を教えて」と聞くだけでは、普通の丁寧な答えしか返ってきませんので、今回は以下のようなプロンプトを用意しました。 # 命令 あなたは辛口な関西人として、AIソムリエの役割を完璧に演じてください。 # あなたのキャラクター設定 (ペルソナ) - **口調:** 常に横柄でドSな関西弁。一人称は「俺」、相手のことは「お前」と呼ぶ。 - **性格:** 短気でせっかち。回りくどいことは大嫌い。面白いかどうかを常に考えている。 - **口癖:** 「なんでやねん！」「アホか！」「知るか！」「しゃあないな」などを自然な会話の流れで使うこと。 - **行動:** 1. まず、目の前にある食べ物（入力情報）に対して、強烈な一言（イジりやツッコミ）をかます。例：「なんやこれ、茶色いな！」「こんなもん夜中に食うとんのか、アホやろ！」など。 2. 次に「まぁしゃあないから、この俺が特別に合う飲み物を選んだるわ」というような、恩着せがましい前置きを入れる。 3. 最後に、最高のドリンクを3つ(アルコール飲料とソフトドリンクをバランスよく)提案する。提案理由は的確で分かりやすいが、言い方は偉そうにすること。 # 入力情報 - Rekognitionが画像から検出した食べ物の特徴: {', '.join(labels)} # 出力タスク 上記のキャラクター設定を忠実に守り、入力情報に対して最高のドリンク提案を生成してください。 ポイントは、AIに 「あなたは何者か（ペルソナ）」と「具体的にどう振る舞うべきか（行動）」 を、箇条書きで分かりやすく指示している点です。 このように細かく役割設定をすることで、AIが指定されたキャラクターになりきって応答を生成してくれるようになります。これこそが「プロンプトエンジニアリング」の面白さですね…！   全体を動かすLambdaの中身 最後に、司令塔の役割を果たすAWS Lambdaのコード（Python）を見てみましょう。 全体の流れはとてもシンプルです。 import json import urllib.request import boto3 # 各サービスクライアントを準備 # (Bedrockはバージニア北部リージョン 'us-east-1' が推奨です) bedrock_runtime = boto3.client( 'bedrock-runtime' , region_name= 'us-east-1' ) rekognition = boto3.client( 'rekognition' ) def handler ( event, context ): try : # 1. 画像URLを受け取る body = json.loads(event.get( 'body' , '{}' )) image_url = body.get( 'imageUrl' ) # 2. Rekognitionで画像からキーワードを検出する with urllib.request.urlopen(image_url) as response: image_bytes = response.read() response_rekognition = rekognition.detect_labels( Image={ 'Bytes' : image_bytes}, MaxLabels= 10 , MinConfidence= 80 ) labels = [label[ 'Name' ] for label in response_rekognition[ 'Labels' ]] # 3. 上記で解説した「プロンプト」を作成する # labelsには ['Pizza', 'Cheese', 'Food'] などが入ります prompt = f""" # 命令 あなたは辛口の関西人として...(中略)... # 入力情報 - Rekognitionが画像から検出した食べ物の特徴: {', '.join(labels)} # 出力タスク ...(後略)... """ # 4. Bedrockにプロンプトを渡し、応答を生成してもらう model_id = 'anthropic.claude-3-sonnet-20240229-v1:0' request_body = { "anthropic_version" : "bedrock-2023-05-31" , "max_tokens" : 1000 , "messages" : [{ "role" : "user" , "content" : [{ "type" : "text" , "text" : prompt}]}] } response_bedrock = bedrock_runtime.invoke_model( body=json.dumps(request_body), modelId=model_id, ) response_body = json.loads(response_bedrock.get( 'body' ).read()) suggestion_text = response_body[ 'content' ][ 0 ][ 'text' ] # 5. 生成された文章をユーザーに返す return { 'statusCode' : 200 , 'headers' : { 'Access-Control-Allow-Origin' : '*' , 'Content-Type' : 'application/json' }, 'body' : json.dumps({ 'suggestion' : suggestion_text}) } except Exception as e: print( f"Error: {e} " ) return { 'statusCode' : 500 , 'body' : json.dumps({ 'error' : str (e)})}   まとめと今後の展望 いかがでしたでしょうか？ この記事を通して、AWSのAIサービスを組み合わせることで、ただ賢いだけでなく、人間味あふれる（？）個性的なAIアプリケーションを簡単に作れることを実感いただければ幸いです！ Amazon Rekognition→ 現実世界の情報をインプット！ Amazon Bedrock → プロンプトエンジニアリング でAIに役割を付与、回答を作成 AWS Lambda→システム全体の連携 このパターンを覚えておくだけで、作れるものの幅がグッと広がるはずです。 今回は関西弁のツッコミAIでしたが、自分の好きなアニメキャラクターの口調を真似させてみるなど、回答の方向性を調整することも可能です！ 「食事だけじゃなくて、服装を判定してファッションチェックさせるのも面白いかも？」 そんな風に、ぜひ皆さんのアイデアで、もっと面白くてユニークなAIをたくさん生み出してみてください！ 最後まで読んでいただき、ありがとうございました！ぜひ皆さんもサーバーレスアプリケーション作ってみてください！

Catoを導入後、管理者の方は日々の運用の中で設定の追加や変更を行っているのではないでしょうか。 しかし、ふと「今の設定のままほっておいて大丈夫なのか…」と不安になることはありませんか？ そんなときに役立つのが、Catoに標準搭載されている「Best Practiceチェック機能」です。 この機能を使えば、管理コンソール上の設定状況を自動で確認し、Best Practice（推奨設定）に沿っていない箇所を洗い出すことができます。 「この機能知ってはいるけど、英語だし量が多くて細かくチェックするのは大変…」という方もいるかもしれません。 今回は、この便利な機能の活用方法をわかりやすくご紹介します。 概要 Best Practice（Home > Best Practice）のページをみてみます。 ざっと全体をみると、現時点では以下のカテゴリで設定状況を確認しているようです。 項番 項目名 確認範囲 １ Internet Firewall Internet Firewall ２ Application Control App ＆ Data Inline（App Control Rule） ３ Data loss Prevention App ＆ Data Inline（Data Control Rule） ４ WAN Firewall WAN Firewall ５ Remote Port Forwarding Remote Port Forwarding ６ Threat Prevention IPS,DNS Protection,Anti-Malware ７ Account Level Security Settings セキュリティ機能全般 ８ TLS Inspection TLS Inspection ９ Access モバイルユーザ関連設定全般 10 Network Rules Network Rules 11 Account level Network Settings ネットワーク機能全般 12 Resiliency ＆ Recovery 機能全般(耐障害性・復旧の観点で確認) さらに、各カテゴリ内のチェック項目毎にImpactとStatusが表示されているのがわかります。 Statusは、Best Practiceと実際の設定の比較結果となっており、「Passed(合格)」「Fail(不合格)」のどちらかで判定されます。Impactは影響度を表しており「High(高)」「Midium(中)」「Low(低)」で判定されます。   また、キラキラマーク(✨)がついているチェック項目があります。 これらは、AI駆動型システムにより判定している項目で、例えばInternet Firewallの場合「テストルールが残っていないか？」や「期限切れのルールが残っていないか？」などといった確認をしてくれているようです。 Catoは近年AIの活用に力を入れていますが、この機能はその1つです。   画面上部をみると、各チェック項目を確認した結果が直感でわかるような表示になっています。 Score： 現時点(2025年8月)でチェック項目数は69項目のようです。 弊社の検証環境では69項目中48項目はPass(合格)しており、スコアが83％であることがわかります。 Status： 「All」「Passed(合格)」「Fail(不合格)」から選択ができ、デフォルトでは「All」になっています。 ここまでの情報から、チェックを行う際は画面上部のStatusでFail(不合格)を選択し、表示された各チェック項目のうちImpactが「High(高)」のものから優先的にチェックをしていく方法がよさそうです。 活用例 それにしても量が多いので、ここからは私が個人的に確認することをお勧めしたい項目をピックアップしてご紹介します。 項目は以下の4つです。 Internet Firewall TLS Inspection Network Rules Resiliency ＆ Recovery 特に Resiliency ＆ Recoveryは確認必須 です！ 他にも、Network RulesやInternet Firewallはルール数が多く管理が煩雑になりがちですし、TLS Inspectionは「どんな設定をしたらいいのかわからない」というお声をよくいただきます。 今回はこれらの項目での活用方法を5つご紹介します。 活用例① Internet Firewall セキュリティ強化 セキュリティ強化の観点では、以下の項目のうちImpactが「High(高)」に分類されているものは確認必須です。 Name 説明 Block Risky Categories リスクの高いカテゴリをBlockする設定となっているかを確認します Block/Prompt Suspicious Categories 不審な行動や特徴を示すウェブサイトやコンテンツをBlockする設定となっているかを確認します Block Risky Applications リスクの高いアプリケーションをBlockする設定となっているかを確認します Block Risky Services リスクの高いネットワークサービスまたはプロトコルをBlockする設定となっているかを確認します   ルールの棚卸 棚卸の観点では、AI駆動型システムを利用した項目が活躍します。 Name 説明 Review Temporary Rule 一時的なルールを検出します。 Review Testing Rule テスト用ルールを検出します。 Review Expired Rule 有効期限が切れたルールを検出します。 Review Rules with Future Expiration Date 有効期限が近いルールを検出します。 Review Contradicting Rules 条件は同じですがアクションが異なる矛盾したルールを検出します。 Unused Rules 使用されていないルールを検出します。 活用例② TLS Inspection 設定アシスト 「何をInspect(検査)して何をBypass(検査をスキップ)すべきかわらない」といった場合はこの項目を参考にします。 Name 説明 Bypass OSes and Categories Bypassすべき対象をBypassする設定になっているかを確認します Inspect Recommended Destinations Inspectすべき対象がInspectする設定になっているかを確認します 活用例③ Network Rules 耐障害性の向上 ” NAT ”や” Route Via ”の設定を行う場合、可用性や耐障害性の観点で以下の3つの項目は確認必須です。 Name 説明 Define Multiple IP Addresses for NAT Internet Rules 複数の出口IPアドレスを指定する設定になっているかを確認します。 （単一出口IPアドレスの指定は、耐障害性のBest Practiceに準拠していません。） Define Multiple PoP Locations for Egress Rules 複数のPoPロケーションを指定する設定になっているかを確認します。 （単一PoPロケーションの指定は、耐障害性のBest Practiceに準拠していません。） Define Specific Source or App/Category for Internet Egress Rules SourceやApp/Categoryで「Any」が設定されて いない かを確認します。 （「Any」の指定は、ネットワークのベストプラクティスに準拠していません。） 活用例④ Resiliency ＆ Recovery レジリエンスの向上 これらの項目はすべてのお客様に必ずご確認いただきたい項目です。 Name 説明 WAN Recovery Advanced Configuration is enabled WAN Recovery(※1)が有効になっていることを確認します。 Off Cloud Traffic Enabled for at Least One Socket WAN Interface WAN Recovery用にOff-Cloudトラフィック(※2)が有効化されたWANインターフェイスが少なくとも1つ設定されていることを確認します。 Internet Recovery is enabled for all Always-on Users Always-onユーザーに対してInternet Recovery(※3)が有効化されていることを確認します。 (※1)WAN Recovery：Cato Cloudとの接続に問題が発生した際に、Socketサイト間でインターネット経由のVPNトンネルを使用してWANトラフィックの接続性を保持します。この機能は、すべてのSocketサイトでデフォルトで有効になっています。 (※2)Off-Cloud：Off-Cloudトラフィックは、Cato Cloudを経由せずに、Socket間で直接インターネット経由のDTLSトンネルを使用して送信されるトラフィックです。 (※3)Internet Recovery：Always-onポリシーが有効になっているユーザーがCato Cloudに接続できない場合、インターネットトラフィックの復旧をサポートする機能です。 対処方法 説明不要と思いますが念のため。これらのチェック項目をチェックし、設定をBest Practiceに沿うように修正したい場合の対処方法をご紹介します。 例えば、弊社の検証環境ではテストルールが多数設定されておりますので、活用例①「 ルールの棚卸」の観点でチェック項目をチェックし、不要なテストルールを削除てみます。 今回はテストルールが6つ設定されておりました。 このうち、「Captive Portal Test」は先日検証を終えた不要なルールですので削除します。 この時「Go to Intenet Firewall」をクリックすると、ワンクリックでIntenet Firewallの設定ページに飛ぶことができました。これは地味に便利な機能だなと感じました。あとは通常通り対象ルールを削除するだけなので手順は省略します。 新機能の紹介　- Best Practice Catalog – 最近、Best Practice Catalog（Resources > Best Practice Catalog）という新機能がリリースされました。 この機能を利用すると、カテゴリ全体や個別のチェック項目を有効/無効にすることができます。 例えば、カテゴリの中には「Remote Port Forwarding」がありましたが、「Remote Port Forwarding」の機能は使っていないといった場合です。この場合は、「Remote Port Forwarding」のカテゴリを無効にすることで、Best Practiceページのカテゴリ「Remote Port Forwarding」が削除されます。   また「Intenet Firewall」カテゴリ内のチェック項目「Service Telnet」は、暗号化がされないため傍受のリスクがありBlockが推奨されていますが、業務利用でBlockができないといった場合です。 この場合は、チェック項目「Service Telnet」を無効にすることで、Best Practiceのページから削除することができます。 このように、各企業様のポリシーに合わせて有効/無効化させることで、Best Practiceのページは格段に見やすくなります。 まとめ 以下の手順でチェックを行うとチェックのハードルが格段に下がります。 Best Practice Catalog（Resources > Best Practice Catalog）で不要なカテゴリを無効化 Best Practice（Home > Best Practice）画面上部のStatusで「Fail(不合格)」を選択し、Best Practiceに準拠していない項目のみを表示 表示された項目のうちImpactが「High(高)」のものや、本記事の必須項目を優先的にチェック おわりに 今回は「Best Practiceチェック機能」をご紹介しました。 推奨設定に沿った構成ができているかどうかを確認することは、非常に重要です。「Best Practiceチェック機能」を活用することで、設定の不備を発見することが可能です。 さらに弊社では、セキュリティ・アーキテクト・コストの3つの観点からBest Practiceに基づき、現状の設定内容を確認し、報告書を作成する「設定診断サービス」をご提供しております。 設定に不安がある方や、第三者の視点での確認をご希望の方は、ぜひ「設定診断サービス」のご利用をご検討ください！

こんにちは！SCSKの髙橋です🌸 この記事では、AWS Summit Japan 2025に参加して得た知見をご紹介します。 AWS Summitについて ご存じの方が多いと思いますが、AWS SummitはAWSが開催する情報交換や事例紹介のためのイベントで、2025は幕張メッセで開催されました。 まじめな技術要素の展示以外にも、企業がおもしろいイベントを企画していたり（くじ引きとか、VR体験会のようなものも見ました） セッションがあらかた終わったあと、夕方以降にはお楽しみイベントがあったりします。 クイズ大会はエンジニア vs Quiz Knockの戦いがなかなか熱い展開でしたね。去年より規模が大きくなっていました！来年も楽しみです。 早押しクイズ大会の様子 また、たくさん資格を取ると表彰式で拍手がもらえるようです。 （SCSK社員もたくさん表彰されていました！） あっ！弊社 AWS Security Incident Response を活用したインシデント対応 今回私が聴講したセッションの中で、持って帰りたいと思ったのはこの話題です。 端的に言うと2024年12月のre:Inventでに発表された比較的新しいサービスの紹介なのですが、（全然知らなかった・・・） AWS Security Incident Response – AWS その前段の話が大変共感を呼ぶ内容でしたので、有効活用できる場面があるのではと感じました。 従来のインシデント対応における課題 まず、セッションの中で紹介されていた、従来のインシデント対応での課題（つまり、AWS Security Incident Responseで解決できそうな課題）について触れさせてください。 ざっとまとめると以下のような内容でした。現場によっては回避できている課題もあるとは思いますが、どれもなんとなく聞いたことのある話です。 コミュニケーション インシデントが起きても誰に報告していいかわからない、誰が作業の承認をできるのかわからない、など コミュニケーションがボトルネックになってしまう状況があるという課題です。 アラートのトリアージ 全てのアラートをしっかり確認する時間も人員もなく、対応が必要なアラートの見極めも難しいという課題です。 ツールとメカニズム 何度も同じアラートが起きていても、アラート発生時に過去の対応をチェックするツールが無く、 同じインシデント対応を繰り返してしまうという課題です。 本題から逸れるので割愛しますが、このあとも、セキュリティ担当者の84%がストレスや疲労を抱えている、といった生々しい話が続きました。 AWSが課題をどう解決してくれるのか そこで、AWS Security Incident Responseが、 お客様のセキュリティインシデントのより早く効率的な 準備、対応、復旧 を支援します。 とのことです。 具体的な例がないとわかりづらいですね。 アラートの監視と調査を自動化し、必要な時だけ通知してくれる インシデントの対応メンバーをあらかじめ登録・管理できる AWSのCirtチームから24/7の支援を受けられる メインの機能としては上記のような部分ということです。 紹介されていた事例として、例えばS3バケットに大量のデータ削除などがあった場合、 GuardDutyで検知した内容をEventBridgeでAWS Security Incident Responseに連携することができます。 自動的にAWS Security Incident Responseがインシデントの内容をトリアージし、対処が必要と判断した場合にケースを作成します。 このケースは自分で作成することもできます。 インシデントの作成も、AWS側だけでなく、自分からできます。 予め登録しておいた連絡先に通知が飛び、対応が始まります。 AWSのCirtチームに助けてほしい場合は、ボタン一つで切り替えることができるそうです。 これら全てがコンソールで操作でき、メンバーとのやりとりもダッシュボード上で行えます。（チャット、ビデオ通話など） AWS Incident Detection and Response との違い そういえば、似たようなサービスが無かったかな・・・と探してみたら、ありました。 AWS Incident Detection and Response とは AWS Incident Detection and Response は、対象となる AWS エンタープライズサポートのお客様に、障害の可能性を減らし、重要なワークロードの中断からの復旧を加速するための、プロアクティブなインシデント対応を提供します。 触ったことがないと、サービス同士の違いがいまいちわかりにくいです。名前も似ています。どう違うのかAIに聞いてみました。 Security Incident Response はセキュリティインシデントに特化しているので、データの侵害や不正アクセスへの対処がメインになりそうです 。 Incident Detection and Response の方が汎用的で日常的な使い方ができます。 また、 Security Incident Response  のほうが顧客が自立して動くのではなくAWS側が動いてくれるという要素が強くて、 インシデントの発見よりはその後の対応に重きを置いているというような感じです。（試験対策のようになってしまいましたね・・・） 気になるお値段 料金次第で、少し触って感触を確かめてみようかと思ったのですが・・・ AWS セキュリティインシデント対応の価格 料金は、登録されたアカウント全体の AWS の月間利用額に基づいており、 最低月額料金は 7,000 USD です。AWS の費用が増えると、階層によって異なるパーセンテージを支払うことになります。より高いレートは、新しい各階層の支出額にのみ適用されます。 階層 1:  AWS の月間利用額が最初の 0 USD から 125,000 USD の場合、 最低月額料金 7,000 USD 階層 2:  前の階層の合計 + 次の 125,000 USD から 250,000 USD までの支出の 5.0% 階層 3:  前の階層の合計 + 次の 250,000 USD から 500,000 USD までの支出の 3.5% 階層 4:  前の階層の合計 + 次の 500,000 USD から 1,000,000 USD までの支出の 1.5% 階層 5:  前の階層の合計 + 1,000,000 USD を超える支出の 0.5% 最低100万円ですか・・・エンジニア一人分ですかね？ちょっとだけ触って試してみるのは難しそうです🥺 （ Incident Detection and Response と価格帯は同じのようです） 体験版として触れる機会が無いか少し探してみたのですが、確認した範囲では見つかりませんでした。 最後に どれくらいスムーズに対応できるようになれるか、使ってみないとやはりなんとも言えそうにないですが、 セキュリティインシデント対応のフローがあまり定まっていないシステムだったら、導入することでかなり考えることが少なくなる気がします。 夜中に叩き起こされている皆さんが、少しでも安眠できるようにというのと、対応後の管理もお任せできるので、あとから「これってどういう対応したんだっけ？」というのも探しやすくなるみたいです。 ちなみに、ご紹介したセッションのオンデマンド配信は2025/7/11までと聞いていましたが、なぜか2025/7/28現在も利用可能です。 いつまで公開されているかわかりませんが、リンクを置いておきます。 AWS Security Incident Response を活用したインシデント対応

本記事は 夏休みクラウド自由研究2025 8/4付の記事です 。 こんにちは！Catoクラウド担当の中川です。 夏休みクラウド自由研究企画にて、Catoクラウド技術者がこれから投稿を開始しますが、本記事が最初の記事になります！ 早速ながら、この記事ではCatoの Captive Portal という機能をご紹介していきます。 Captive Portalとは Captive Portalとは、 利用者がインターネットにアクセスする前に、利用規約や制限等に対して同意を求める画面を表示させてからインターネット環境を提供する仕組みです。 一般的にゲスト用Wi-Fiを提供する際に利用されます。 例えば空港やホテルのお客様、オフィスへの来訪者用に提供されるようなネットワークです。 こういった、社内ネットワークへはアクセスさせず、インターネット環境のみを提供したい場合に利用します。 設定方法 今回は、 Socket配下にゲストWi-Fi用のセグメントを作成することを想定し、設定していきたいと思います！ CatoのCaptive Portalの設定方法は非常に簡単で、CMAにてSecurity＞Internet FirewallからCaptive Portal用のルールを作成します。 SourceでゲストWi-Fi用に用意したネットワークセグメントを選択して、ActionsでCaptive Portalを選択するだけです。 今回はSite「検証環境」の「LAN 02」セグメントをゲスト用Wi-Fiとして検証しました。 なお、ゲストはCaptive Portalでの接続後、他のユーザ同様にInternet Firewallのルールが適用されます。すべてのユーザでギャンブルカテゴリをブロックしているのであれば、ゲストも当然ブロックされることになります。   利用者の画面イメージ 実際にWi-Fiに接続し、インターネット接続を試してみると、以下のようなCatoへの接続を確認するCaptive Portalの画面になります。 Connectのボタンを押すと、Cato社のホームページへと遷移しました。 ＜Captive Portal画面＞ ↓ ＜Connect押下後、Cato社ホームページへ＞ 上画像はデフォルト設定でかなり簡素に感じたかと思いますが、この画面の設定はAccount ＞ Captive Portalから変更可能です。 デフォルト設定は下記のようになっており、7か所がカスタマイズできます。 会社ロゴ ロゴの背景カラー 接続ボタンのカラーとテキスト内容 ゲストWi-Fi利用の同意を求める文面を入れるか メールアドレスの入力を求めるか（チェックすると、入力が必須になります） セッション有効期間 接続ボタン押下後のリダイレクトURL 次に、以下のようにカスタマイズしてみました。 ロゴをSCSKの会社ロゴに 接続ボタンを、SCSKの会社カラーにし「Guest Wi-Fiに接続する」の表記に ゲストWi-Fiに接続するにあたっての同意を求める文面を追記 メールアドレスの入力を必須に リダイレクト先をSCSKのホームページに ↓ すると、当然ではありますが、このような画面に変更されました。 ※事前確認の文面で、数字の箇条書きを設定している箇所がありますが反映されませんでした。。 メールアドレスを入力しボタンを押下すると、設定した通り、今度はSCSKのホームページへとアクセスされました。 ＜Captive Portal画面＞ ↓ ＜今度はSCSKホームページへ遷移＞ イベントの見え方 CMAのHome ＞ Eventsでイベントログを確認してみました。 特徴としては、ActionがCaptive Portalとなっていたことと、入力を必須としたメールアドレスが”Guest User”としてログに記録されていたことです。 何かあった際に調査できるよう、メールアドレスの入力は必須としておくのが良いかもしれません。 ※なお、有効にしていない場合にも”Guest User”のフィールドはありましたが、空欄となっていました。 考慮ポイント ここでは検証してみて気づいた、Captive Portalの利用をするにあたって考慮すべきポイントを2つ記載します。 通信制御 特別な設定をしていない場合、他のSite配下のユーザと同様に、Catoクラウドを介して他拠点のリソース / インターネットへ接続可能です。ゲスト用Wi-Fiの用途からすると、少なくとも他拠点のリソースへは接続できないようにすべきです。 そのため、Cato社はゲスト用Wi-FiのセグメントはInternet Onlyの設定を推奨しています。名前の通りの設定で、この設定を有効にしたセグメントはインターネットへの接続しかできなくなります。 設定箇所は、Networks > 対象Site ＞ Site Configuration ＞ 対象のセグメントで、以下のチェックボックスです。 通信帯域 ゲスト用Wi-Fiも当然ながら、Socketを経由してCatoクラウドへ接続します。 例えば、ゲストとして来訪された方が大容量ファイルをダウンロードなどした場合には、拠点の帯域ひっ迫を引き起こしてしまう可能性があります。 余裕を持った帯域ライセンスでご契約されている場合には問題ないですが、拠点内の社員のみの利用を想定して帯域を契約していた場合には注意が必要です。 おわりに Captive Portalのご紹介いかがでしたでしょうか。 多くのお客様に使われている機能ではないですが、ここ最近お客様よりご相談いただくことがありましたので、今回ご紹介させていただきました。 設定値は少なく複雑な内容ではないので、ゲスト用Wi-Fiの設置をご検討されているお客様はCaptive Portalでの設定をご検討いただければと思います。 ご覧いただきありがとうございました。 この後にもCato担当メンバの投稿が続きますので、ぜひお楽しみください！