こんにちは。SCSKの磯野です。 Google CloudのVMで、外部に公開するようなWebサイトを運用している場合、該当のWebサイトの死活監視を行うためのモニタリングが必要となります。 今回は、VMで稼働しているパブリックなWebサイトに対して、どのように死活監視をすればよいかをご紹介します。 前提 本記事は以下を前提とします。 VMインスタンスで構築しているWebサイトは、一般公開されているものとする VMインスタンスは、インスタンスグループに属しているものとする（マネージド/非マネージドは問わない） 本記事では、どのメトリクスを監視すればよいかについては言及しますが、実際の監視実装方法までは言及しません。 実装方法については以下の記事を参照ください。 Google Cloud における監視方法について- モニタリングとロギング Google Cloudにおける監視はログ監視とメトリクス監視の２種類に分けることができます。Cloud Loggingの使い方、Cloud Monitoringにおけるクエリの書き方、Terraformでアラート実装方法等をご紹介します。 blog.usize-tech.com 2025.06.09   方法①：URLでの稼働時間チェックを行う（推奨） HTTP/HTTPS 稼働時間チェックは、デフォルトでレスポンス コードが 2xx  であることを確認します。いわゆる 外形監視 に該当するため、パブリックなWebサイトに対する死活監視としては最も推奨される方法となります。 HTTP と HTTPS の場合、すべての URL リダイレクトをフォローし、稼働時間チェックで受信した最終的なレスポンスから成功基準を評価します。HTTPS チェックの場合、SSL 証明書の有効期限は、最後のレスポンスで受信したサーバー証明書に基づいて計算されます。 稼働時間チェックに成功するには、次の条件を満たす必要があります。 HTTP ステータスが指定した条件に一致する。 レスポンス データに必須のコンテンツがないか、必要なコンテンツがすでに存在する。 公開の稼働時間チェックを作成する  |  Cloud Monitoring  |  Google Cloud cloud.google.com   方法②：VMのヘルスチェックログを監視する インスタンスグループに属しているVMは、健全性変更ログ（ヘルスチェックログ）を出力します。UNHEALTHYログの監視を行うことで、VMのヘルスチェックステータスの監視に近いものを実装可能です。 ただし、特に非マネージドインスタンスグループについては、インスタンスが停止してWebサイトに5xxエラー等でアクセスできない場合でも ヘルスチェックのUNHEALTHYログが出力されないケースがある（※） ため、方法①を推奨します。 VM の健全性の変化をモニタリングする  |  Compute Engine Documentation  |  Google Cloud cloud.google.com ※インスタンスを停止すると、0/0となりステータスが正常とみなされてしまうため   方法③：VMインスタンスの稼働時間チェックを行う VMインスタンスの稼働時間チェックでは、稼働時間メトリクスが欠損していないかを監視することで「インスタンスが稼働しているか」の確認を行うことができます。 Webサイトの稼働確認ではなく、あくまでもVMの稼働確認 となるため、要件に応じて方法①を使用してください。 terraformでの作成例は以下の通りです。 resource "google_monitoring_alert_policy" "vm_stoped" { display_name = "VM Instance - Uptime Absent(VM Stopped)" combiner = "OR" conditions { display_name = "VM Instance - Uptime" condition_prometheus_query_language { query = <<EOT absent(avg by (instance_name, project_id)( increase(compute_googleapis_com:instance_uptime{ monitored_resource="gce_instance", project_id="{プロジェクト名}", instance_name="{インスタンス名}"}[5m])) ) == 1 EOT duration = "240s" # 最大 240 秒間はデータは表示されないため } } enabled = true notification_channels = "xxx(通知先のslackなど)" alert_strategy { notification_prompts = ["OPENED"] } }   まとめ いかがだったでしょうか。 今回は、VMで稼働しているパブリックなWebサイトに対して、どのように死活監視をすればよいかをご紹介しました。 本記事が皆様のお役に立てれば幸いです。

こんにちは。SCSKの磯野です。 Dataformでは、環境ごとに異なるプロジェクトにテーブルをリリースすることができます。 Dataformで複数プロジェクトかつ複数環境にリリースする方法 Dataformで、同一のSQLXファイルから複数環境（dev、prod）向けにリリースを行う方法を記載します。 複数のプロジェクトを使用する場合でも、カスタムコンパイル変数を使用することで実現が可能です。 blog.usize-tech.com 2024.09.24 Dataformの アサーション 結果 についても、環境ごとにプロジェクトやデータセットを変更して出力したいケースがあると思います。 今回は、アサーション結果の出力先を環境ごとに変える方法をご紹介します。 アサーション出力先の プロジェクト を環境ごとに変更する方法 アサーション結果は、デフォルトで workflow_settings.yaml の defaultProject で設定された プロジェクト に出力されます。 テーブルへのリリースと同様、アサーションについてもリリース構成の「Google Cloud プロジェクトID」というコンパイル変数をオーバーライドすることで、環境ごとにプロジェクトを設定することができます。 詳細は下記の記事を参照ください。 Dataformで複数プロジェクトかつ複数環境にリリースする方法 Dataformで、同一のSQLXファイルから複数環境（dev、prod）向けにリリースを行う方法を記載します。 複数のプロジェクトを使用する場合でも、カスタムコンパイル変数を使用することで実現が可能です。 blog.usize-tech.com 2024.09.24 アサーション出力先の データセット を環境ごとに変更する方法 アサーション結果は、デフォルトで workflow_settings.yaml の defaultAssertionDataset で設定された データセット に出力されます。 しかしプロジェクトとは異なり、 アサーション用のデータセットは、UI上からリリース構成のコンパイル変数としてオーバーライドできません 。（※執筆日時点） データセットを環境ごとに変更したい場合は、APIを通じて実装する必要があります。APIドキュメントは下記の通り。 Method: projects.locations.repositories.releaseConfigs.create  |  Dataform  |  Google Cloud cloud.google.com ※releaseConfigs.create -> リクエスト本文 -> codeCompilationConfig -> assertionSchema まとめ いかがだったでしょうか。 今回はDataformにて、アサーション結果の出力先を環境ごとに変更する方法をご紹介しました。 本記事が皆様のお役に立てれば幸いです。

こんにちは。SCSKの磯野です。 Dataformにはアサーションという機能があります。 アサーションを使用してテーブルをテストする  |  Dataform  |  Google Cloud Dataform コアを使用して Dataform にアサーションを作成します。 cloud.google.com また、Dataformでは増分テーブルを構成することができます。 増分テーブルを構成する  |  Dataform  |  Google Cloud Dataform コアを使用して Dataform の増分テーブルを構成する。 cloud.google.com そこで、 アサーションにおいても増分ロジックでスキャンする ことができないか、調査してみました。 やりたいこと 例えば下記のようなBigQueryのテーブルがあったとします。 ファイルを受信した時刻・ファイルのフォーマットチェック結果が格納されているテーブルです。 ※本記事では以後、本テーブルを result_table とします received_time ：ファイルを受信した時刻 format_check_result ：ファイルのフォーマットが想定通りかをチェックした結果 format_check_time ：ファイルのフォーマットチェックを行った時刻 前提/要件 フォーマットチェックは毎日18:00に行われるため、 result_table は毎日更新される。 フォーマットチェックがFALSE（＝異常なファイルを受信していた）の場合はアサーションエラーとするが、アサーションの実行対象はその日にチェックしたデータのみとしたい。 前日に届いたファイルが異常だった場合、前日はアサーションエラーとなるが、翌日はアサーションエラーとしたくない ※上記の例の場合、2025/7/1はアサーションエラーとなるが、2025/7/2,3はアサーションエラーとしたくない モチベーション result_table は、スキャン量を考慮して増分テーブルで構成されている。アサーションがフルスキャンとなってしまうと、 result_table を増分で構成した意味がなくなってしまう。 一度異常なデータが格納されても、エラーは発砲され続けないでほしい。常に最新のデータのみのアサーションを実行してほしい。   課題：「type: “incremental”」の組み込みアサーションはフルスキャンとなる 実装方法・コード まずは、 result_table を作成している処理の組み込みアサーションとして実装してみました。 テーブルのいずれかの行が  false  の場合、アサーションは失敗します。 config { type: "incremental", name: "result_table", assertions: { rowConditions: [ 'format_check_result = TRUE' ] }, (略) } SELECT ... 結果 テーブルの作成は増分ロジックとなっていたのですが、 組み込みアサーションについてはフルスキャンとなってしまいました。   対処法：手動アサーションを使用する 実装方法・コード result_table の作成処理とアサーションを分離し、手動アサーションとして実装してみました。 手動アサーション SQL クエリは行を返さないようにする必要があります。クエリの実行時にクエリが行を返すと、アサーションは失敗します。 アサーションを使用してテーブルをテストする  |  Dataform  |  Google Cloud Dataform コアを使用して Dataform にアサーションを作成します。 cloud.google.com config { type: "assertion", } SELECT * FROM ${ref("result_table")} WHERE format_check_result = FALSE -- チェック失敗(false)していたらアサーションエラーとする -- アサーションとresult_tableへのデータ格納はセットで実行する前提。 AND format_check_time >= DATETIME_SUB(CURRENT_DATETIME("Asia/Tokyo"), INTERVAL 5 MINUTE) 結果 下記工夫をすることで、 アサーションを増分ロジックで構成することができました。 手動アサーションとする 直近5分間にresult_tableへINSERTされたデータのみをアサーションチェックすることで、増分ロジックを実現 まとめ いかがだったでしょうか。 今回はDataformのアサーションにおいて、増分ロジックでスキャンする方法についてご紹介しました。 手動アサーションによる実装であれば、クエリの書き方次第で増分ロジックでアサーションを実装することができることがわかりました。 本記事が皆様のお役に立てれば幸いです。

こんにちは、SCSK吉田です。 先日6月下旬、社内勉強会の一環としてServiceNowを使った社内ハッカソンを開催しました！ 今回は社内ハッカソンの開催レポートとなります。   はじめに 社内でハッカソンを実施しようとしたきっかけは、 SCSK社内でも、更にServiceNowを盛り上げていきたい！ となります。 また、ハッカソンへの参加を通じ、普段の業務ではできない新しい経験や、技術の獲得にもつながれば良いなという思いもあり、様々な方にご協力いただき社内ハッカソンの開催にいたりました。 ハッカソン開催までの道のり ServiceNow社の方々にもご協力いただき、ハッカソンを含め、２月から６月にかけて計５回の社内勉強会を開催しました。 第４回はアイデアソン、第５回がハッカソンとなります。 始めに、第１回から第４回までの勉強会を簡単に振り返ります。 第１回社内勉強会：ServiceNow製品概要＆トレーニング・認定資格の紹介 まずは、ServiceNowをまだよく知らないという社内の方に向けて、ServiceNowの製品概要、及び近年のAIに関する取り組み、そしてこれらの情報を学べる場としてのServiceNow University（旧Now Learning）、そしてSCSKのServiceNowに関する取り組みを紹介しました。 また、私の方からは、ServiceNow Universityを活用した学習・キャリア開発、認定資格を取得する価値を語らせていただきました。 当日は約６０人の方に参加いただき、大盛況のうちに終えることができました。 第２回社内勉強会：ServiceNowのアプリ開発を学ぶ（ハンズオン） 第２回では、主にServiceNowのアプリ開発に興味がある方に向けて、アプリ開発の基本的な考え方・構造を紹介しました。 基本である「Task」「Process」「UI」のコンセプトを学んだ後、実際にServiceNow Studioを使用してハンズオンを実施しました。 参加者の方々には、アプリ・ロール、データモデル、フロー、ワークスペースの作成など、アプリ開発の一連の流れを体験していただきました。 第３回社内勉強会：ServiceNow Japan Hackathon 2024の振り返り＆Now Assistの勉強 社内アイデアソン、ハッカソン参加者と共にServiceNow Japan Hackathon 2024の内容を振り返りました。 昨年のテーマである「PUT AI to Work」の理解、各参加チームの選定テーマの傾向などハッカソンの概要、そしてNow Assistの機能を学習しました。 また、チーム分けを行い、次回アイデアソンに向けたネクストアクションを共有しました。 ※ServiceNow Japan Hackathon 2024の開催レポート ServiceNowハッカソン2024開催レポート はじめに 去る2024年9月9日、ServiceNowの開発者向けイベント「ServiceNow Japan Hackathon 2024」が開催されました。開催のたびにご参加いただく開発者の数が増え、今年も過去最多となる48チーム、265... www.servicenow.com   第４回社内勉強会：アイデアソン 「AIの活用」をテーマとし、第３回勉強会から約１カ月間、各チームが考えたアイデアをプレゼンしました。 選定されたテーマを分類すると以下の通りとなります。各チームとも高齢化や人手不足を背景とした各業界の課題にアプローチするアイデアです。短い準備期間でしたが、各チームがターゲットとする業界における課題をしっかりと分析したうえで、ServiceNowでどのようにアプローチするかまで考えていただきました。 マンション管理 介護 教育 各チームのプレゼンに対し、AI機能の活用、アイデアの新規性、影響度、実現性などの観点で審査を行い、１位チームを決定しました。 （審査を実施していますが全チームハッカソンへ進みます） ハッカソン 参加者概要 参加者：１５名 チーム数：４チーム ServiceNowの開発経験者率：２割 開発期間：１カ月 成果発表 ServiceNowでの開発は初めてというメンバーが多い中、アイデアソンの内容をServiceNowへの開発へ落とし込み、全チームが実際に動くデモと共にプレゼンを実施いただきました。 以下、各チームのデモ部分を中心にどのような発表内容だったか簡単に振り返ります。 マンション管理業務へのServiceNow活用 マンション住人から問い合わせやクレームに対し、Virtual Agentを活用したセルフサービスの提供 セルフサービスで解決しない場合は、チケット起票、担当者へのアサイン、チケットのクローズまでの一連の流れをワークフローで自動化 介護者支援プラットフォームとしてServiceNow活用 介護者からの悩み・相談に対し、Virtual Agentを活用したセルフサービスの提供 フォローアップが必要な場合は、チケットを自動起票の上、AIによる問い合わせ内容の要約、優先度付けを実施 AWAを活用し、空き状況、保有スキルをもとに自治体等の担当者へ自動でチケットをアサイン 教育現場における先生・保護者・生徒をつなぐプラットフォームとしてServiceNow活用 ポータルを活用し、先生・保護者・生徒間のシームレスな情報共有を実現 行事の出欠確認や日程調整など各種申請をServiceNow上でデジタル化 各教師に属人化する業務ノウハウ、過去の保護者からの問い合わせ、テスト資料などの紙資料をナレッジとして蓄積 蓄積されたナレッジを活用し、教師・保護者・生徒に対しVirtual Agentによるセルフサービスの提供 教育現場における教員不足、長時間労働問題の解決を目指したServiceNowの活用 生徒からの問い合わせに対する回答をAI Agentが代行することで、教師の業務負担軽減 AI Agentが過去の類似の問い合わせ、それに対する回答を検索し、その内容を踏まえた上で生徒へと回答する   プレゼン後にはQAの時間も設け、活発な議論が行われました。 各チームのプレゼンに対し、アイデアソンと同様にAIの活用、サービスの新規性や将来性・拡張性などの観点で審査を行い優勝チームを決定しました！ 優勝チームには、ささやかながら優勝記念品をプレゼントしました。 ハッカソンの振り返り ServiceNowでの開発未経験者が多いハッカソンでしたが、各チームが選定した課題に対し、ServiceNowで使用する製品、アーキテクチャ、AI機能の活用方法、ライセンス形態を踏まえたマネタイズ方法まで考えていただき、非常に良い学びの場とすることができました。 以下、参加者からの声となります。 製品選定、及びアーキテクチャの検討から実装までを経験でき、良い学びの機会となった。 ServiceNow × AIの可能性を感じた。よりServiceNowのことを学んでいきたいと思った。 さいごに 弊社は昨年度初めて、ServiceNow Japan Hackathon 2024に参加させていただきましたが、アイデアソン敗退でハッカソンへ進むことができませんでした。今後、ServiceNw社主催のハッカソンに参加する機会があったら、今回の社内ハッカソンでの学びを活かし、ハッカソン進出、及び入賞を目指していきたいと思います！

こんにちは！ SCSK株式会社　小鴨です。 最近はひどく暑いですね 正直ラスベガスの方が涼しかったです（笑） そんな自分ですが、今日も Knowledge 25 　 のご紹介を始めます！！   前回の記事は準備・到着編になります。 まだ読んでいない方は以下リンクからどうぞ！ 【ServiceNow】Knowledge25への参加記録！！その１　～準備・到着～ – TechHarmony   JAPAN WELCOME SESSION 「始まり」のイベント ラスベガスの空気になれたのもつかの間、早速イベントが始まります。 初日は日本からの参加者のみで行う「JAPAN WELCOME SESSION」が開催されます。 恐ろしく豪華なホテル「Wien(ウィーン)」に集合し、日本人向けに用意された特設部屋に向かいます。 ウィン ラスベガス（ラスベガス）：（最新料金：2025年） 美しい庭園に囲まれたオシャレなホテル 奥まで進むとゴルフ場もあり、日本のおじ様たちは目を輝かせていました。 なぜか屋内にメリーゴーランドがあったり (Wienと関係があるのでしょうか？) JAPAN WELCOME SESSION開始 会場では入り口で渡された番号札に従って机につきます。 下の写真のように、立食形式で食事を楽しみながらServiceNowからのイベント説明を聞く形ですね。 イベントの過ごし方を学ぶのももちろんですが、ここでは日本人同士の交流も一つの目的です。 自分も卓につくなり早速名刺交換を始めたのですが… 　どうも、部長の～～です どうも、係長の～～です   あ、どうも特に何者でもない小鴨です… やっぱりこういうイベントに来る人は重役の方が多いのですね、、、 自分の卓は特に上の役職、年次の方が多く、ずっと緊張してしまいご飯があまり食べられませんでした。 (全員が美味しかったと語る「和牛バーガー」が食べられなかったのは今回の出張最大の後悔です) 誇りを賭けた戦い ということでここからは非常に楽しませてもらったプログラムの一つ 「クイズ大会」の紹介です。 こちらはServiceNowの方から出題される8つの4択問題を早押し形式で回答するというものであり 正解を選べたとしても、遅く回答したのでは点数が低くなってしまうという思いのほかゲーム性の高いものになっています。 高得点者は前に出て景品をもらえるということを聞いたとき SCSKの名前を前面に押し出すことができる！と感じ これは遊びではなく、企業間の戦争だと捉えて本気でクイズに挑みました。 ライバルは400人！   第一問！ 本イベントの参加人数は？   21000人！ 圧倒的21000人っ！！     第二問！ 本イベントのセッション数は？ 愚問！ 1000超だ     …なんて真面目に答えていると あれ？オレ2位？ まだ折り返しだけど 第6問！ もう覚えてないけど答えが分からないから適当に回答！ ・・・正解！ 天の意志が　オレを選んでいる…オレに「勝て」といっている…！ 　クク…悪くねえな…頂点の景色ってやつは   第7問！ 「ServiceNowのCEOが中学生の時に買った大きな買い物は？」 ・・・は？ こんなんどうやって推測せえと にやにやしているServiceNowスタッフの方々が悪魔のように見えました。 くそがっ！！ だが焦ってはいけない、ここまで培ってきた直感を信じるのだ！ 弱気に流れている人間は理に頼ろうとする、直感に頼ることが出来なくなる… ポチッ… が！駄目っ！！　不正解！ここにきて不正解！ 3位転落！   ラスト8問目 1位を狙うにはどうする？ もう問題と解答を見ている暇はない、回答が表示されると同時に適当にボタンを押すんだ！ ポチッ…   あとがき そんな形で、Knowledge25一日目は終了 明日からの本番に向けて日本メンバー一丸となったセッションでした。 色々ありましたが、自分は最後の選択に効果はありません。 美しく燃え尽きた夜でした。 次回からはいよいよイベント本番の様子を詳しく紹介していきます。 ●異文化に圧倒される初日 ●やっぱり英語は話せた方が良い ●ServiceNowってすごいんだな といったところが語れるといいなと思っています。 引き続きその3もゆったりとお楽しみください。

今回は Prisma Cloud ではなく、Cortex Cloud の API を使用してみようと思います。 Cortex Cloud は2025年度第3四半期後半に一般提供される予定の サービスです。 本記事では、Cortex Cloud のデモ環境でAPIを実行したときの手順を解説します。なお、デモ環境のためコンソール画面のスクリーンショットをお見せできないことをご了承ください。 本記事は2025年6月時点の記事になりますので、リリース後変更されている可能性があります。 API URLについて Cortex Cloudでは、以下フォーマットのURLに対して、リクエストすることでREST APIを使用できます。 https://api-{fqdn}/public_api/v1/{name of api}/{name of call}/ URLのFQDN部分は契約しているお客様ごとに異なり、以下手順でURLを取得できます。 「Settings」>「Configurations」>「API keys」に移動します。 右上の「Copy API URL」が取得できるのでこれをコピーしておきます。 参考(公式ドキュメント) Prisma CloudのAPI URLはリージョンごとにわかれていましたが、Cortex CloudのAPI URLは契約しているお客様事に異なっていて、そこはPrisma Cloudとの違いだなと思いました。 APIキーの発行 APIのキーの発行を行います。 APIキー発行手順(公式ドキュメント) Settings > Configurations > Integrations > API Keysに移動します 右上の「New Key」を押下します セキュリティレベル項目を選択します。 今回は「Standard」を選択しました。 Roleを選択します。 今回は「Instance Administrator」を選択しました。 Commentは任意の文字を入れてください。 Enable Expiration DateはいつまでにこのAPI keyが使用できなくなるかの期限を設定できます。 各設定が完了したら「Generate」を押下して、その時のAPI Key IDをコピーしておきます。 作成が完了するとAPI Keyの一覧に追加されていると思います。 API keysテーブルの作成した行の「ID」列の値もコピーしておきます。 セキュリティレベルは2種類あり、StandardとAdvancedがあります。 セキュリティレベル 説明 Standard APIキーをそのまま使用できます。 Curlのリクエストに適しています。 Advanced nonceとタイムスタンプを使用してハッシュ化する必要があります。 独自のスクリプトに適しており、リプレイ攻撃を防ぐことが目的です。 Prisma Cloudと違い、セキュリティレベルの設定があるところが、Cortex CloudとPrisma Cloudの違いかなと思いました。 また、Prisma Cloudでは一時的なAPIキーを発行して、そのAPIキーでREST APIを利用していましたが、APIキーを発行するREST APIが消えてそのままリクエストできるように変更されていました。 実際にAPIを使用してみた 取得したAPI URLと、APIキーを利用して、実際にAPIを利用してみます。 今回は接続しているプロバイダー(インスタンス)情報を取得する API とPythonのrequestsライブラリを使用して実際にプログラムを作成し、インスタンス情報を取得します。 事前に必要な値 現在コピーしているのが以下3つです。 ・API URL ・API key ID ・APIkeyテーブルの「ID」列の値 コードの作成 api_key_idの変数には APIkeyテーブルの「ID」列の値 を入れます。 api_keyの変数には API key ID を入力します。 ※API key関連は*でマスクしています。 urlには「https://api-{fqdn}」を先ほどコピーしたAPI URLに置き換えます。 api_key_id = "*" api_key = "***************************" url = "https://api-{fqdn}/public_api/v1/cloud_onboarding/get_instances" ペイロードを作成します。 今回はGCPのインスタンス情報を取得するのでFilterのSEARCH_VALUEをGCPに変更しています。 payload = { "request_data" : { "filter_data" : { "sort" : [ { "FIELD" : "STATUS", "ORDER" : "DESC" } ], "paging" : { "from" : 0, "to" : 50 }, "filter" : { "AND" : [ { "SEARCH_FIELD" : "CLOUD_PROVIDER", "SEARCH_TYPE" : "EQ", "SEARCH_VALUE" : "GCP" } ] } } } ヘッダーは以下の様に作成しました。 x-xdr-auth-idには先ほど作成した APIkeyテーブルの「ID」列の値 を格納した変数を入力します。 Authorizationには先ほど作成した API key ID を格納した変数を入力します。 headers = { 'Content-Type': "application/json", "x-xdr-auth-id": str(api_key_id), "Authorization": api_key } 最後にリクエストし、返ってきた値を標準出力します。 response = requests.post(url, json=payload, headers=headers) print(response.text) コードの全体像 コードの全体像は以下の通りです。 import requests api_key_id = "5" api_key = "*************************************" url = "https://api-<company>.paloaltonetworks.com/public_api/v1/cloud_onboarding/get_instances" payload = { "request_data" : { "filter_data" : { "sort" : [ { "FIELD" : "STATUS", "ORDER" : "DESC" } ], "paging" : { "from" : 0, "to" : 50 }, "filter" : { "AND" : [ { "SEARCH_FIELD" : "CLOUD_PROVIDER", "SEARCH_TYPE" : "EQ", "SEARCH_VALUE" : "GCP" } ] } } } } headers = { 'Content-Type': "application/json", "x-xdr-auth-id": str(api_key_id), "Authorization": api_key } response = requests.post(url, json=payload, headers=headers) print(response.text) 実行結果 返ってきた値は以下です。 GCPインスタンス情報が確認できます。 載せられない情報は*でマスクしています。 { "reply": { "DATA": [ { "instance_id": "**********************", "cloud_provider": "GCP", "instance_name": "**********************", "account_name": "**********************", "accounts": 1, "scope": "ACCOUNT", "scan_mode": "MANAGED", "creation_time": 1748334058291, "custom_resources_tags": "[{\"key\": \"managed_by\", \"value\": \"paloaltonetworks\"}]", "provisioning_method": "TF", "additional_capabilities": "{\"xsiam_analytics\": true, \"registry_scanning\": true, \"serverless_scanning\": true, \"registry_scanning_options\": {\"type\": \"ALL\"}, \"data_security_posture_management\": false}", "is_pending_changes": 0, "status": "WARNING", "outpost_id": "**********************" }, { "instance_id": "**********************", "cloud_provider": "GCP", "instance_name": "", "account_name": null, "accounts": null, "scope": "ACCOUNT", "scan_mode": "MANAGED", "creation_time": 1748333605143, "custom_resources_tags": "[{\"key\": \"managed_by\", \"value\": \"paloaltonetworks\"}]", "provisioning_method": null, "additional_capabilities": "{\"xsiam_analytics\": true, \"registry_scanning\": true, \"serverless_scanning\": true, \"registry_scanning_options\": {\"type\": \"ALL\"}, \"data_security_posture_management\": false}", "is_pending_changes": null, "status": "PENDING", "outpost_id": "**********************" } ], "FILTER_COUNT": 2, "TOTAL_COUNT": 13 } } さいごに 実際に触ってみるとPrisma CloudとAPIキーの発行や使用方法が少し変わっていました。 APIの数が多くないので、一般提供時にはもっと数が増えていそうです。 2025年度第3四半期後半に一般提供される予定ということで、楽しみです。 当社では、複数クラウド環境の設定状況を自動でチェックし、設定ミスやコンプライアンス違反、異常行動などのリスクを診断するCSPMソリューションを販売しております。 マルチクラウド設定診断サービス with CSPM｜ SCSK株式会社 ご興味のある方は是非、お気軽にお問い合わせください。

この度、 Catoクラウドのユーザーコミュニティ（ユーザ交流会、ユーザ会）、 「 Cato Circle（ケイトサークル） 」を発足いたしました。そして、Cato Circle についての記念すべき初投稿記事となります。   ユーザーコミュニティ発足の背景について Catoクラウドのユーザーコミュニティ（ユーザ交流会、ユーザ会）、「 Cato Circle（ケイトサークル） 」を発足しました。 Catoクラウド（正式名称は「Cato SASE Cloud Platform」）は、2025年6月時点で日本国内の採用企業数が630社を超えており、当社 SCSK もおかげさまでCatoクラウドのご契約をいただいているお客様も年々増加し、ついに 60社を超えることができました。 ひとえにご利用いただいているお客様のおかげです。ありがとうございます。 数年前より、Catoクラウドご利用のお客様から、他の利用者との交流を行いたいとのお声をいただいておりました。 実際に、当社で導入事例化をさせていただいたお客様と直接話をしたいと言うご依頼があった場合は（当社のお客様だけに限らず）お客様同士で会話をする機会をセットさせていただいたことが、過去に何度かございます。 また、以前より、お客様が参加できるイベントの開催を、Cato Networks社（Japanおよび本社）へ働きかけを行っておりましたが、今年（2025年）もお客様参加のイベント開催は難しいとの回答があったため、当社が主催となって、ユーザーコミュニティの立ち上げを行い、この度その活動を開始する運びとなりました。   Cato Circleについて ユーザーコミュニティ「 Cato Circle 」については、もちろんですがCato Networks社から名称を含めて、承認を得ております。 コミュニティ名称に“SCSK”の名前が付いていないのは、今回のユーザーコミュニティ「Cato Circle」の立ち上げ、および初回オフサイト会議に関しては、当社SCSKのお客様が中心となりますが、将来的には、Cato Network（Japan）社へ運営を引き継ぎ、当社以外の他のパートナー様のCatoクラウドご利用者様にも範囲を広げる前提としているためです。 Cato Circle は、” ユーザーコミュニティ ”ですので、通常の企業セミナーのように、一方的に説明を行う「説明型」イベントを行うのではなく、 利用者であるお客様が、Catoクラウドの自社での活用方法や、利用上の課題を発表し、利用者同士が情報を共有する「双方向型」のイベントを目指しております 。 つまり、お客様同士の交流、ネットワーク構築から、情報交換のきっかけをご提供し、課題や悩みを共有し、解決するヒントを得ていただくことが Cato Circle の目的となっております。 一方で、Cato Networks社や、当社（SCSK）のサービスに関するフィードバックをいただき、サービス開発や改善に役立てることももう一つの目的としています。 特に、Cato Networks社（本社）へ、日本国内の利用者の声をきちんと届けることが、非常に重要だと思っています。（例えば、JPNIC問題など）   他のサービスとの違い 他のサービスで例えば、AWS（Amazon Web Services）は、日本国内でのサービス提供は2011年3月の東京リージョンのローンチで、すでに14年が経過していますが、国内・海外での代表的なイベントやユーザーコミュニティは以下になります。 AWS re:Invent 2025 毎年12月にアメリカ、ラスベガスで開催されるAWS最大の年次カンファレンス。世界中のクラウド技術者、開発者、企業担当者が一堂に会し、最新AWSサービスや技術動向、クラウド活用事例などを学ぶイベント。今年は、12月1日から5日に開催。 AWS Summit Japan 2025 企業担当者とAWSパートナーが参加し、情報交換ができる日本国内最大級のAWSイベント。今年は、6月25日、26日に開催。 AWS Partner Summit 2025 AWSのパートナー限定で開催されるイベント。AWSパートナーが集い、最新のAWSテクノロジーやソリューション、ビジネスの加速方法について学び、ネットワークを広げるイベント。今年は、5月8日に開催。 JAWS-UG（Japan AWS User Group） 日本最大のAWSユーザーコミュニティ。2010年2月に発足。全国各地やテーマ別に「支部」があり、勉強会や交流イベントを非営利で開催。年間400回近いイベントが開催。 一方で、Cato Networks社は、2015年イスラエルで創業し、日本国内においては2018年に東京PoPが開設され、今年が8年目となります。ちなみに、当社のCatoクラウドの取り扱いは2019年からですので、今年で7年目となります。 Catoクラウドでは、現在 3.のパートナー向けのイベントについては、2023年より「APJ Partner Summit」が毎年7月に開催されており、今年で3回目の開催となりますが、それ以外のイベントは現時点では開催されていません。 2023年 Partner Summit Cato Networks の「Partner Summit in Tokyo 2023」にて最優秀パートナーアワードを受賞 2024年 Partner Summit Cato Networksの「APJ Partner Summit 2024」にてパートナーアワードを2年連続で受賞 前述したように、2.のお客様が参加できるイベントの開催を期待し、要望しております。   Cato Circle初回会議と今後の運営について Cato Circle の初回会議は、2025年9月にオフサイト会議を東京八重洲（ SCSK LINK SQUARE ）で開催します。 当社の お客様（4社）による事例紹介 を実施いただくことが決定しており、Catoクラウドの現状の活用方法、工夫されていること、課題などをそれぞれ発表いただく予定です。 その後、 発表企業4社とCato社、当社を含めたパネルディスカッション を予定しております。パネルディスカッションでの質問事項については、参加の皆様に、お申し込み時に事前に記載していただいております。 それ以外には、Cato Networks社によるCatoクラウドのサービスロードマップの紹介、当社のサービスの紹介も行う予定です。 夕方から懇親会を予定しており、お客様同士の名刺交換を含めた、ネットワーキングを行っていただきます。 次回以降については、ユーザ同士の意見交換会（ディスカッション）、新機能のワークショップ、もちろん東京以外での開催もすでに検討しております。また、オンラインでコミュニティツールなどの活用もして行ければ、と考えています。 将来的には、AWSのユーザーコミュニティ（JAWS-UG）のような自発的な活動ができれば理想的ですが、Catoクラウドは、AWSとは異なりお客様への直接販売はしておらず、パートナー販売のみとなっていますので、当社を含めたパートナー企業が中心に運営を行うことになると考えており、他のパートナー様の協力も必要不可欠になると考えています。 あるいは、“Cato Summit Japan”や”Cato Forum Japan” のようなユーザが参加できるイベントが開催されるようになれば、このユーザーコミュニティの役割は不要になるかも知れません。 いずれにしても、当社のお客様は、ぜひ Cato Circle へご参加ください。もし、当社のお客様で、まだ Cato Circle の案内が来ていないと言う方がいらっしゃれば、当社担当者までお問い合わせください。 ちなみに、冒頭の「Cato Circle」のロゴは、まだCato社に承認をもらったものではありませんので、正式なロゴができたら、別途掲載する予定です。   まとめ 日本国内でも、 SASE（Secure Access Service Edge、サッシー） 、 Cato Networks 、 Catoクラウド（Cato SASE Cloud Platform ）の認知度が徐々に上がっていますが、まだまだ十分とは言えない状況です。 2023年、2024年と品川駅の自由通路にて屋外広告を出稿していましたが、2025年も今週６月30日から出稿していますので、ぜひ品川をお通りの際は、ご覧ください。 SCSKでは、2021年からSASEの主要な４ソリューションを一同に紹介を行うオンラインセミナー「 SCSK SASE Solution Summit（通称 S4 エスフォー） 」を定期的に開催しております。これまで16回開催し、述べ2,400名以上の方に参加いただいております。 また、Catoクラウドについては、 初心者向けの簡単セミナー から、管理ポータルで主要機能をデモ形式で説明する デモセミナー 、全国各地にてオフラインで開催する ハンズオンセミナー なども定期的に開催しておりますので、ご興味ある方は、すべて無料ですので、ぜひご参加ください。 Catoクラウド イベント・セミナー情報 | よくあるご質問 | Cato Cloud ケイトクラウド - SCSK 定期的にCatoクラウドをご紹介するセミナーを開催しております。・2024年9月26日（木）Catoクラウド ハンズオンセミナー【札幌開催分】　～全国5都市開催（東京/大阪/名古屋/博多/札幌）～　... cato-scsk.dga.jp S4セミナー、Catoクラウドセミナー以外にも、Catoクラウドの お客様導入事例 の制作、 FAQサイト の運営、この TechHarmony（技術ブログ） で、Catoクラウドの日本語の情報を提供し、少しでもCatoクラウドの認知度向上と、皆様のお役に立てればと考えております。 Catoクラウドに少しでも興味をお持ちになられた方は、ぜひ当社まで お問い合わせ ください。 Catoクラウド エンジニアブログまとめ記事 Catoクラウドのエンジニアブログ（TechHarmony）でのまとめ記事となります。 blog.usize-tech.com 2024.02.27

こんにちは。SCSKの磯野です。 Dataformでは、リモートリポジトリをGitHubリポジトリと接続することができます。 Dataformに接続済みのGitHubリポジトリの名称を変更したくなったので、どのような影響があるのかを調査してみました。 サードパーティの Git リポジトリに接続する  |  Dataform  |  Google Cloud Google Cloud コンソールを使用して、Dataform リポジトリをリモートの Git リポジトリにリンクします。 cloud.google.com 結論 ワークフローのスケジュール、コンパイル、ブランチへのcommit・push・pull、いずれの操作も問題ありませんでした。 検証方法 DataformをGitHubリポジトリと同期し、ワークフローのスケジュール設定を入れておきます ワークフロー構成で実行をスケジュールする  |  Dataform  |  Google Cloud GitHubのリポジトリをリネームする 検証結果 Dataformのソースとしてコンソール上に表示されるURLは変わらないが、リネーム後のGitHubリポジトリにリダイレクトされる ワークフローのスケジュールは正常に稼働 新規ワークスペースの作成（ブランチの作成）も問題なし Dataform 開発ワークスペースを作成する  |  Google Cloud リネーム後に作成したワークスペース上で、commit,push,pullいずれも問題なし リネーム前に作成したワークスペース上で、commit,push,pullいずれも問題なし Dataformのブラウザではなく、ローカル環境での開発を行っている場合は、ローカル環境で参照しているリモートURLを更新する必要があります。 【GitHub】リポジトリ名を変更する - Qiita はじめに リポジトリ名を変更するとそのリポジトリのリモートリポジトリURLが変更されるので、ローカル環境においても参照するリモートURLを更新する必要がある。 手順１．GitHubのウェブサイト上でリポジトリ名を変更する リポジトリの se... qiita.com   まとめ いかがだったでしょうか。 今回は、Dataformに接続済みのGitHubリポジトリの名称変更による影響について調査しました。リネームする際は、影響範囲を調査の上実施ください。 本記事が皆様のお役に立てれば幸いです。

Prisma Cloudはパブリッククラウドやアプリケーションのセキュリティ強化に役立つツールですが、Prisma Cloud自身のセキュリティも考慮する必要があります。例えば、Prisma Cloudの監査ログは適切に保管し、いざという時に確認できるようにしておく必要があります。 しかしながら、Prisma Cloudの監査ログは 最大120日間しか保管されない ため、それ以降の日付のログを確認することができません。 そこでPrisma Cloudの監査ログを外部へ転送する機能を利用して、Amazon SQSに転送し、AWS LambdaでAmazon S3にログを保管する仕組みを構築します。この仕組みにより、121日以前のログも確認可能となり、いざという時でもログを確認できるようになります。 本記事では、この仕組みの構築方法を解説するとともに、Lambdaプログラム(Python)も共有します。 Prisma Cloudの監査ログを外部に保管しておきたい方やPrisma Cloudのセキュリティを強化したいという方のお役に立てれば幸いです。 監査ログの転送機能について まず、Prisma Cloudの監査ログを外部へ転送する機能について説明します。 本機能に関する公式のドキュメントは こちら で、本機能はPrisma Cloudに登録済みのSQSまたはWebhooksに対してログを転送できます。そのため、事前にSQSまたはWebhooksを用意して、統合というところに登録をしておく必要があります。本記事ではSQSに対してログを転送をします。 また、 注意点としてPrisma Cloudへのログインに成功したログは転送されないためご注意ください。 他のすべての監査ログは転送されるとのことです。裏付けとなるドキュメントは こちら です。 AWS構成図 AWS側のリソースは以下構成で構築します。 複数のPrisma Cloudテナントを管理している想定のため、各テナントごとの監査ログを一つのS3バケットに、テナントごとにフォルダを分けて保管できるようにしています。処理の流れは、ログがPrisma CloudからSQSへ転送され、SQSがメッセージを受信すると監査ログ保管用のLambdaが起動します。LambdaはSQS名からテナントを判断し、受信したログをS3バケット内のテナント用フォルダに出力します。 SQS名は以下ネーミングルールで構築することで、Lambdaがどのテナントから送られてきたログであるかを判断できるようにします。 ＜テナント識別子＞-PrismaCloudAuditLog-queue.fifo こうすることで、監査ログ保管用のS3バケットには以下ネーミングでログが保管されます。 /＜テナント識別子＞/yyyy/mm/dd/prismacloud-auditlog-＜テナント識別子＞-yyyymmdd-hhmmss.json   Pythonソースコード 以下はLambda上で動かすPythonプログラムです。 import json import os import logging import boto3 from datetime import datetime, timedelta # ロギングの設定を行う - INFOレベルでログを出力する logger = logging.getLogger() logger.setLevel(logging.INFO) def extract_prefix_from_sqs_name(sqs_name): # SQS名の先頭から最初の「-」の部分の文字列をプレフィックスとして抽出する return sqs_name.split('-')[0] def lambda_handler(event, context): # S3クライアントを初期化する s3_client = boto3.client('s3') # 環境変数からS3のバケット名を取得する bucket_name = os.environ['S3_BUCKET_NAME'] # SQSメッセージの処理開始をログに記録する logger.info('Starting the processing of SQS messages') try: # 各SQSメッセージを処理する for record in event['Records']: message_body = record['body'] # メッセージの本文を取得する message_id = record['messageId'] # メッセージIDを取得する # メッセージの受信時刻を取得し、日付形式に変換する timestamp = record['attributes']['ApproximateFirstReceiveTimestamp'] message_datetime_utc = datetime.utcfromtimestamp(int(timestamp) / 1000) # UTCをJSTに変換する jst_offset = timedelta(hours=9) message_datetime_jst = message_datetime_utc + jst_offset # 日付フォルダとファイル名を決定する date_folder = message_datetime_jst.strftime('%Y/%m/%d') time_stamp = message_datetime_jst.strftime('%Y%m%d-%H%M%S') # SQSの名前からプレフィックスを抽出する sqs_name = record['eventSourceARN'].split(':')[-1] base_prefix = extract_prefix_from_sqs_name(sqs_name) # ファイル名を構築する file_name = f"prismacloud-auditlog-{base_prefix}-{time_stamp}.json" # S3キーを組み立てる s3_key = f"{base_prefix}/{date_folder}/{file_name}" # メッセージをS3に保存する旨をログに記録する logger.info(f"Saving message {message_id} to S3 bucket: {bucket_name}, key: {s3_key}") # メッセージをS3バケットに保存する処理 s3_client.put_object( Bucket=bucket_name, Key=s3_key, Body=message_body ) # メッセージをS3に保存したことをログに記録する logger.info(f"Successfully saved message {message_id} to S3") except Exception as e: # メッセージ処理中にエラーが発生した場合、エラーログを記録し、ステータスコード500でレスポンスを返す logger.error("Error occurred while processing the messages: %s", str(e)) return { 'statusCode': 500, 'body': json.dumps('Error occurred while processing the messages') } # すべてのメッセージの処理が成功したことをログに記録する logger.info('All messages have been processed successfully') return { 'statusCode': 200, 'body': json.dumps('Messages have been saved to S3!') }   AWS側リソースの構築 以下のようにSQS、S3、IAMロール・ポリシー、Lambdaを構築します。 SQS SQSのコンソール画面を表示し、「キューを作成」を押下します。 タイプを「FIFO」で設定し、名前を入力したら、他の項目は必要に応じて変更ください。今回、他の項目は全てデフォルト設定とし、最下部の「キューを作成」を押下して、SQSを構築しました。 SQSの構築が完了したら、そのSQSを開き、以下URL部分をコピーして、メモしておきます。 このURLは後ほどPrisma CloudへSQSを登録する時に利用します。 S3 S3はデフォルト設定で構築しました。必要に応じて設定は変更ください。 IAMロール・ポリシー Lambdaに付与するIAMロールと、そのロールに付与するIAMポリシーを作成します。 以下のカスタムポリシーを作成し、そのポリシーを持つロールを作成しました。 { "Version": "2012-10-17", "Statement": [ { "Sid": "Statement1", "Effect": "Allow", "Action": [ "sqs:*", "logs:CreateLogGroup", "logs:CreateLogStream", "logs:PutLogEvents" ], "Resource": "*" }, { "Sid": "Statement2", "Effect": "Allow", "Action": "s3:PutObject", "Resource": [ "arn:aws:s3::: <監査ログ保管用のS3バケット名> /*" ] } ] } ロールの信頼関係タブでは以下のようにLambdaがこのロールを引き受けられるように許可します。 上記以外はすべてデフォルト設定としました。   Lambda Lambdaのコンソール画面を表示し、「関数を作成」を押下します。 関数名に関数の名前を入力し、ランタイムは最新バージョンのPythonを選択します。実行ロールで「既存のロールを使用する」を選択して、先ほど作成したIAMロールを選択し、「関数の作成」を押下します。 Lambda関数が作成されたら、デフォルトコードを先ほどご紹介したソースコードに置き換えて、「Deploy」を押下します。 上部にて、関数が正常に更新された旨の緑のメッセージを確認した後、「トリガーを追加」を押下します。 トリガーの設定に「SQS」を選択し、SQSキューには先ほど構築したSQSキューを選択します。 「トリガーをアクティブ化」にチェックがついていることを確認し、最下部の「追加」を押下します。 最後に環境変数タブにて、以下環境変数を作成します。値は先ほど作成したS3バケット名を指定します。 キー 値 S3_BUCKET_NAME 監査ログ保管用のS3バケット名 Lambdaも紹介した設定以外はすべてデフォルト設定としました。   Prisma Cloud側の設定 次にPrisma Cloud側で、統合へのSQS登録と監査ログの転送設定を行います。 統合へのSQS登録 まず、Prisma CloudがSQSへログを転送するときに利用するIAMロールとポリシーを作成します。 ドキュメントの手順 に則って作業をします。 これから作成するIAMロールにはランダムな文字列ではなく128ビット形式のUUIDで外部IDを設定する必要があります。手作業で作成しても良いのですが、Prisma Cloudコンソールにて外部IDを生成することができますので、コンソールにて作成します。 監査ログの転送をしたいPrisma Cloudテナントにログインし、SystemAdmin ロールにスイッチします。 「Settings」＞「Integrations & Notifications」画面を表示し、「Add Integration」を押下します。 「Amazon SQS」を選択した後、次の画面で「More Options」にチェックをいれます。 External Idにある、「Generate」を押下すると、128ビット形式のUUIDが表示されますので、コピーしておきます。 IAMロールのコンソールへ移動し、IAMロールを作成します。 信頼されたエンティティタイプは「AWSアカウント」を選択し、AWSアカウントは「別のAWSアカウント」を選択して、Prisma CloudのAWSアカウントIDである、 188619942792 を入力します。 「外部IDを要求する」にチェックを入れて、先ほどコピーしていたUUIDを入力して、「次へ」を押下します。 ここではポリシーを付与せずに、他はデフォルト設定としてロールを作成します。 作成後、ロールに以下カスタムポリシーを付与して、ロールは完成です。 作成したロールのARNをコピーしておきます。 { "Version": "2012-10-17", "Statement": [ { "Action": [ "sqs:GetQueueAttributes", "sqs:ListQueues", "sqs:SendMessage", "tag:GetResources", "iam:GetRole" ], "Resource": "*", "Effect": "Allow" } ] } Prisma Cloudのコンソールへ戻り、「Role ARN」にコピーしておいたIAMロールのARNを入力します。次に「Queue URL」にはSQS構築時にメモしておいたSQS URLを入力し、「Next」を押下します。 「Test Integration」を押下し、以下Prisma CloudとSQSの疎通成功の緑のメッセージが表示されることを確認し、「Save Integration」を押下します。 監査ログの転送設定 最後に監査ログの転送設定を行います。 ドキュメントの手順 に則って作業をします。 「Settings」＞「Enterprise Settings」画面を表示し、下の方にある「Send Audit Logs to integration」を有効化します。 その後、統合に登録した先ほどのSQSを選択して、画面右上の「Save Settings」を押下します。 以上で監査ログの転送設定が完了となります。 実際に監査ログがS3に保管されているか これにてPrisma Cloudの監査ログがAWSのS3バケットに保管されるようになります。実際にログが保管されているか確認したいと思います。監査ログ保管用のS3バケットに以下ネーミングでログが保管されているはずです。 /＜テナント識別子＞/yyyy/mm/dd/prismacloud-auditlog-＜テナント識別子＞-yyyymmdd-hhmmss.json まず、Prisma Cloudで監査ログに記録されるような行動をとります。 その後、S3バケットにアクセスすると、想定通りのパスにログが保管されていました。   ログの中身も先ほどの行動が記載されており、想定通りです。 { "result": "Successful", "actionType": "CREATE", "ipAddress": "XXX.XXX.XXX.XXX", "action": "'YYYY'(with role 'System Admin':'System Admin') created the account group. The group wasn't given access to any cloud accounts.", "resourceName": "TEST", "user": "YYYY", "timestamp": 1750991540913, "resourceType": "Account Group" }   さいごに 当社ではPrisma Cloud利用して、複数クラウド環境の設定状況を自動でチェックし、 設定ミスやコンプライアンス違反、異常行動などのリスクを診断するCSPMソリューションを販売しております。 興味のある方は是非、お気軽にお問い合わせください。 マルチクラウド設定診断サービス with CSPM｜ SCSK株式会社

初めまして。 SCSKの吉田拳多です。 今回は ServiceNowにおける多要素認証(MFA)の認証方法と、多要素認証(MFA)の除外設定について紹介したいと思います。 本記事は執筆時点(2025年6月)の情報になります。最新の情報は製品ドキュメントを参考にしてください。 Yokohamaバージョンからの仕様変更について Yokohamaバージョンより、ServiceNow にログインする際に多要素認証(MFA)が必須化されました。 引用： 認証 リリースノート ・マルチファクター認証 (MFA) は、 ServiceNow® への非 SSO ログインすべてにデフォルトで適用されます。   ServiceNowにログインする際の多要素認証(MFA)の種類について ServiceNowにログインする際の多要素認証(MFA)の認証方法はデフォルトでは以下の3つです。 -Authenticator等の認証アプリを使用した認証 -生体認証、パスキー、またはハードウェアセキュリティを使用した認証 -メールを使用した認証(sys_userに登録されたメールアドレス宛に認証コードが送付される) その他にSMSを使用した認証も可能ですが、別途設定が必要となるので、設定方法については今回は省略します。 多要素認証(MFA)の除外設定について 多要素認証(MFA)が必須化されましたが、お客様によっては多要素認証(MFA)の対象外としたいユーザーもいるかもしれません。 今回は多要素認証から除外する設定として以下の2つの方法を紹介します。 ①ロールによる除外設定 ②グループによる除外設定 ①ロールによる除外設定では、指定したロールをもつユーザーを多要素認証(MFA)の対象から除外できます。 デフォルトの設定では、以下のロールについてはマルチファクター基準にてMFAを適用するように設定されているため、多要素認証(MFA)の対象から除外できません。 ・admin ・user_admin ・security_admin ロールによる除外設定ではマルチファクター認証>MFAコンテキストの「Has MFA exempted role」を編集します。 Has MFA exempted roleをクリックすると以下の画面が表示されます。 条件にロールを設定することで、設定されたロールを持つユーザーは多要素認証(MFA)から除外されます。 ※デフォルトではsnc_externalロールが指定されており、snc_externalロールをもつユーザーは多要素認証(MFA)の対象外となります。 ※セキュリティの観点から以下の条件は指定できません。 次の値と異なる、次の値を含まない、次の値と同じ、(空)である、(空)でない、フィールド値が空白、次の値と異なる   実際の検証について 下記の検証を行おうとしたところ、想定通りに動かず断念しました。 有識者の方がおりましたら情報提供いただけますと幸いです。 検証したかったこと (1)PDI環境に多要素認証(MFA)の設定を実施。    snc_externalロール以外のユーザーについては、MFA認証を求められるようになる。 (2)snc_internalロールを持つテストユーザーを作成、ログインの際にMFA認証が求められることを確認。 (3)Multi-factor Authentication>MFA Context Has MFA exempted roleの設定で、対象にsnc_internalを設定することにより、snc_internalロールを持つユーザーが MFA認証の対象から除外されていることを確認(①ロールによる除外設定) (4)Multi-factor Authentication>MFA Context Is a member of MFA exempted groupの設定で、作成したテストユーザーが所属するグループを設定することで、 MFA認証の対象から除外されていることを確認(②グループによる除外設定) 実際にPDI環境に実施したMFA認証の設定 ①プロパティの有効化 Multi-factor Authentication>Properties Enable Multi-fuctor authenticationの値を[true]に変更 ②MFAコンテキストポリシーの有効化 Multi-factor Authentication>MFA Context ポリシーを有効化 ③ロールベースの基準を有効化 Multi-factor Authentication>Multi-factor Criteria Role based multi-factor authenticationを「Active」に変更 ④MFA除外設定の確認 Multi-factor Authentication>MFA Context Has MFA exempted roleを確認し、条件がRole is snc_externalとなっていることを確認 上記により、snc_externalロール以外のユーザーはログインの際にMFA認証を求められる想定でした。 参考文献： 多要素認証 (MFA) の適用に関する FAQ – サポートとトラブルシューティング しかし、実際にsnc_internalロールを持つユーザーを作成し、ログインを試みたところ、 MFA認証を求められず、ログインできてしまいました。 (検証したかったことの(2)で断念) まとめ 今回は ServiceNowにおける多要素認証(MFA)の認証方法と、多要素認証(MFA)の除外設定について紹介するはずが、 検証がうまくいかず断念しました。 進展あり次第記事の更新をさせていただきます。

こんにちは。SCSK梅ヶ谷（うめがたに）です。 6月25日（水）、26日（木）に開催されたAWS Summit Japan 2025に出展しました。 今回、SCSKは プラチナスポンサー として、スポンサーセッションでの事例紹介とブース出展を行いました。 【近日開催！】AWS Summit Japan 2025「AWSで、夢ある未来を共に創る。SCSK」ブースのご紹介！ – TechHarmony 私は AIエージェント サービスのミニシアター登壇とブースでのご説明を担当しましたので、当日の様子をご紹介します！ AIエージェント ミニシアター 当社では近日、 AIエージェント のサービスをInfoWeaveへ追加リリースすることを予定しており、AWS Summit Japan 2025ではサービスのご紹介とプロトタイプのデモを行いました。 InfoWeave（インフォウィーヴ）ってどういうサービスなの？ SCSKが提供するAWS 生成AIソリューションだよ。 RAG構成を自社のAWS環境上に3日で展開できるテンプレートを提供しているの。 InfoWeave（インフォウィーヴ） は2024年にリリースされたサービスで、 S-Cred + プラットフォーム のオプションとして提供されています。 まず、ミニシアターコーナーのご紹介です。 当社のミニシアターコーナーでは合計6つのセッションを、1日に3回行っておりました。 11時から17時まで休みなくセッションが詰まっていますね！ 複数回行われるので1度見逃しても安心です。 AIエージェントについては、 「 InfoWeaveで始めるAIエージェント -新しい形の業務効率化 -」 と題して、セッションを行っています。 こちらがミニシアターでご説明した様子です。 AIエージェントがどのように構成され、どう業務に活用できるのかを、ユースケースを交えてご紹介しました。 私は1日1回ずつ登壇しました。10分という短い時間でしたが、製品から構成図までをギュッとまとめてお伝えすることができたかなと思っています。 席数は限られていましたが、立ち見でも多くの方々に集まって頂けてとても嬉しかったです！ AIエージェント 出展ブース 次にブースの様子です。 ミニシアターコーナーの裏側で各ソリューションのブースを設けており、AIエージェントも、このように展示を行っていました。 画面には説明の動画を流しています。 デモでは実際にプロトタイプの AIエージェントを動かし、Webサイトへの情報登録をプロンプトだけで動かすシナリオ 等、実演を行いました。 ミニシアターでお伝えし切れなかった部分も、実際の画面を見ていただくことでイメージを掴んでもらい、来場者の方々と質疑応答を交えながらお話できました。 1日目午前中の様子。この後基調講演が終わると夕方までの間、多くのお客様に訪れていただきました！ フォローアップセミナーを開催します InfoWeaveのAIエージェント機能は、近日リリースを予定しています。 利用をご検討されているみなさまや、AWS Summitで聞き逃したのでまずはどんなものか知りたいという方々に向けて、フォローアップセミナーを開催します。 サービスについてより具体的にご説明する予定ですので、是非ご参加ください！ プロンプトでブラウザ操作からデータ分析まで完全自動化！マルチAIエージェントをAWSで「らくらく」構築する手法（2025年07月29日） ｜ SCSK株式会社 なお、現在のInfoWeaveは、 RAGを簡単に構築できるサービス を提供しています。 こちらも気になる方は、SCSKのホームページに説明がありますので、ご参照ください。 RAGソリューション InfoWeave｜サービス｜企業のDX戦略を加速するハイブリッドクラウドソリューション かんたんRAG環境構築 S-Cred+ InfoWeaveをリリースしました – TechHarmony さいごに 弊社のセッションやブースにお越しいただいたみなさま、誠にありがとうございました。 私はこれまでAWS Summitへは参加者として訪れていましたが、今回はじめて出展者として参加しました。 セッションやブースを回ることはあまりできませんでしたが、ミニシアターとブースでみなさんと接することができ、とても刺激的な2日間でした！ 今年のAWS SummitはAI関連テーマが非常に多かったと感じています。 昨年よりもAIを業務に活用した事例が増えていたり、AIエージェントのような比較的新しい技術、それから既存のサービスにAIを取り入れたものなど、1年で大きな変化が見られたと感じています。 また来年はどのようなAWS Summitになっているかと考えると、ワクワクしますね。 一緒に、次の変化を楽しみましょう！

こんにちは！最近倒立で腕立て伏せを試みようと頑張っております、いとさんです。 初めての投稿はgpt-4oとGeminiを使用したWordpress内のアコーディオン実装の工程、成果物を紹介いたします。 基本となるコードは以下サイトを参照いたしました。 任意の投稿や固定ページへプラグインなしでアコーディオンコンテンツを作る方法 クリックすると展開して、もう一度クリックすると閉じる、企業サイトでよく見かける「よくある質問」のようなコンテンツを、プラグインを使わずにWordPressの特定の固定ページや特定の投稿へ挿入する方法を www.momosiri.info 下記コード(JavaScript,CSS) の実装には、Code Snippetsプラグインを用いると便利です。 手順 JavaScriptの開発は未経験だったので、生成AIの力を借りて実装してみました。 上記で紹介したサイトのコードを基に「このコーディングをもとに複数のアコーディオンを作成するコーディングを教えて」とGeminiに命令したところ、以下のようなコードが返ってきました。 実装したらこのような形になりました。 上手く実装できたように見えます。 テキストエディタからビジュアルエディタに戻してみましょう。 あれ？？<br />タグが付いてCSSが消えてしまいました。 CSSが消えてしまうので特定のクラスのCSSに影響が出るようにワードプレス内のカスタマイズにCSSコード埋め込みます。 ダッシュボードの外観＞カスタマイズ＞追加CSSで移動します。 JSコードも埋め込んだ方が他の方もFAQ追加時に編集しやすいですよね。 プラグインのコードスニッペトでfunctionPHPを追加します。 上記のコードを設定しCSSコードのボックスやアコーディオン間の隙間、ドロップシャドウなど気になる部分に関する壁打ちをAzureのgpt-4に対して行ったら下記のコードを出力しました 上記のコードを追加CSSに実装するとこのようになります。(所々大きさなど変更しました。) 変更を完了しプレビューしてみましょう。 視認性が良く見やすいアコーディオンが完成しました。 結果 細かい壁打ちは省略しましたが、大雑把な指示でも細かくコーディングを出力し正確性も高かったです。   Appendix：アコーディオンの中身のコード <div class="faq-section"> <h2 class="mt-0">FAQ 2</h2> <!-- 2nd Section: 12 Accordion Items --> <div class="faq-item"> <div class="faq-button">Q: のスケーリング▼</div> <div class="faq-detail">のスケーリングオプションについての情報。</div> </div> <div class="faq-item"> <div class="faq-button">Q:の価格モデル▼</div> <div class="faq-detail">の価格モデルに関する詳細です。</div> </div> <div class="faq-item"> <div class="faq-button">Q: のデータ移行▼</div> <div class="faq-detail">データ移行プロセスの説明です。</div> </div> <div class="faq-item"> <div class="faq-button">Q: のバックアップソリューション▼</div> <div class="faq-detail">バックアップソリューションの概要。</div> </div> <div class="faq-item"> <div class="faq-button">Q: の地域サービス▼</div> <div class="faq-detail">地域サービスの詳細に関して。</div> </div> <div class="faq-item"> <div class="faq-button">Q: のコンプライアンス▼</div> <div class="faq-detail">のコンプライアンスについての情報。</div> </div> <div class="faq-item"> <div class="faq-button">Q: インスタンスタイプ▼</div> <div class="faq-detail">インスタンスタイプの比較と選定。</div> </div> <div class="faq-item"> <div class="faq-button">Q: AWSのネットワーク機能▼</div> <div class="faq-detail">ネットワーク機能に関する詳細情報。</div> </div> <div class="faq-item"> <div class="faq-button">Q: イベント▼</div> <div class="faq-detail">イベントスケジュールについて。</div> </div> <div class="faq-item"> <div class="faq-button">Q: のトレーニング＆認定▼</div> <div class="faq-detail">トレーニングと認定プログラムの詳細。</div> </div> <div class="faq-item"> <div class="faq-button">Q: サポートプラン▼</div> <div class="faq-detail">サポートプランについての概要。</div> </div> <div class="faq-item"> <div class="faq-button">Q: パートナープログラム▼</div> <div class="faq-detail">パートナープログラム詳細。</div> </div> </div>

本記事は「Amazon Q CLI でゲームを作ろう Tシャツキャンペーン」に向けて執筆した記事です。 こんにちは。最近はサクレパインとガリガリくんが美味しいです。いとさんです。 今回は、滑り込みで Amazon Q CLIを使ったキャンペーン に参加してみました。 ↓流行に乗れている方の記事はこちら 期間延長！まだ間に合う！Amazon Q CLIでゲームを作ってTシャツが貰えるキャンペーン！！2025-06-30まで！🎮👕🏃💨 Amazon Q というビッグウェーブに乗りたいので、とっかかりとして丁度良さそうなキャンペーンに参加してみました。Amazonという冠が付いているにも関わらず、AWS以外のリソース(ファイル)に対しても精度高く作成や変更を行えるAmazon Qには非常に驚かされました。 blog.usize-tech.com 2025.06.13 Amazon Q Developerが孤独にゲームを作るまでの軌跡 Amazon Qだけでゲームを作ってみました。 blog.usize-tech.com 2025.06.14 ビッグウェーブに乗ってAmazon Q CLIでゲームを作りました。 Amazon Q CLIでプログラムが少し複雑なブラウザゲームを作成しました。 blog.usize-tech.com 2025.06.16 環境 claude-4-sonnetを使用しました。   ゲームの作成 では準備が出来たのでかわいいゲームを作っていこうと思います。 プロンプトは以下のように投げました。 クマのぬいぐるみがお花と食べ物を見て手を叩く姿、とてもかわいいですね。 数分で数百行のコードができました。 こちら完成したゲーム(ver1)早速遊んでみましょう。 なんか全体的に小さいですね‥花の変わる速度も少し早いきがしました(3秒に一回変わっている？) 大きさと速度を修正しましょう。 全体的に大きくそして、アニーメーションも追加しました。 さて見映えはどうなったでしょうか？(ver2) おお‥写真じゃわかりにくいですがアニメーションが追加されたことにより面白さが増しました。 クマの大きさ、花、キャンディー(お菓子になってしまった)の大きさも⭕️視認性が良くなりました。 まとめ もう少し時間があれば自身で作成したイラストなどをS3に入れてオリジナル性のあるものが作れたかもしれない。 だがこの短時間で複数の指示とアニーメーションの追加、ボタンの設定まで出来るのはすごく精度だ高いと感じました。   Appendix ソースコード 随時更新予定です‥ 引き続きの問題 ・お菓子に反応しない→何回か試せば変更しそう

こんにちは。SCSKの北川です。 今回はServiceNowの更新セットプレビュー時のエラー対応についてまとめました。 更新セットの移送手順はこちら 【ServiceNow】更新セット移送の基本ガイド – TechHarmony 本記事は執筆時点（2025年6月）の情報です。最新の情報は製品ドキュメントを参考にしてください。 プレビューエラーの対応 プレビューした更新セットにエラーが見つかった場合、以下のようなメッセージが表示されれます。 関連リスト「Update Set Preview Problems」より、問題となっているレコードを確認してください。 各Preview Problemに対し、以下のいずれかを選択してください。 ・Accept remote update：エラーを受け入れて変更を適用する ・Skip remote update：問題のレコードを適用しない すべてのエラーに対応後、再度[Commit Update Set]を押下します。 以上がプレビューエラーの対応手順です。 レコードの手動移送や再作成が必要なケースもあります。 対応後に[Run Preiew Again]を押下してプレビューエラーが0件になっていることを確認してください。   発生頻度の高いプレビューエラー 次にプレビュー時に発生する頻度の高いエラーを2つご紹介します。 ①Could not find a record in 〇〇〇 for column □□□ referenced in this update …□□□ のレコードがが移送先環境の〇〇〇に存在しない Could not find a record in sys_ui_policy for column ui_policy referenced in this update UI ポリシーアクションが作成・更新されているが、UI ポリシーのレコードが存在しない Could not find a record in sys_user for column owner referenced in this update カタログアイテムに設定されているownerが移送先のsys_userテーブルに存在しない Could not find a record in sys_hub_flow for column flow_designer_flow referenced in this update カタログアイテムに設定されているフローデザイナーが移送先のsys_hub_flowテーブルに存在しない ②Found a local update that is newer than this one …移送した更新セットより新しいバージョンの更新セットがすでに移送先環境に存在している まとめ 今回はServiceNowのプレビューエラー対応についてご紹介しました。 エラーが発生しても、原因を整理しながら冷静に対応することが大切です。

本記事は、Prisma CloudのApplication Securityがサブスクリプションの一覧に表示されず、Application Securityを有効化できない人に有効化する方法をお伝えする記事となっています。 Application Securityとは Application Securityとは、ソフトウェア開発ライフサイクル全体を通じて、コードからクラウドまでの包括的なセキュリティを提供する機能です。本機能によって、ソフトウェア開発環境の可視化や、クラウドの設定ミスやコードの脆弱性を特定することができます。さらに、ポリシーを使用して脆弱なコードのデプロイを防ぎ、脆弱性に対処するためのコード修正案を提示してくれる便利な機能となっています。 経緯 そんなApplication Securityを利用しようと機能を切り替えようとしたところ、私のテナントではApplication Securityが表示されていませんでした。(有効化していると以下赤枠内にApplication Securityが表示されます) Palo社のドキュメント( Prisma Cloudでアプリケーションセキュリティを有効にする) に従い、有効化しようと Profile > View Subscriptions を見ると、Application Secuirtyが表示されていないという事象が発生しました。   解決方法 結論、 Profile > View Subscriptions からCode Securityを有効化することでApplication Securityを利用できるようになりました。 Code Securityを有効化してすぐにApplication Securityが表示され、機能を切り替えることができました。   サポートに問い合わせしたところ、「Application Securityは既に有効化されているため、Code Securityを有効化してみてください。」と回答をいただきました。Application Securityを有効化した覚えはありませんでしたが、先ほどのドキュメントの最下部に 最新のテナントではApplication Securityがデフォルトで有効化されている との記載があり、これが理由だったようです。 Latest Prisma Cloud tenants are pre-subscribed to Cloud Application Security. Please check your  Subscription  status on the console.   また、Code Securityを有効化するとApplication Securityが利用できるようになる理由については、そもそもCode SecurityがApplication Securityの前身にあたる機能で、 23年8月のアップデート によって、Code SecurityにCI/CD Securityが追加され、Application Securityという名前に変更されたという経緯がありました。なぜ前身の機能名であるCode Securityがサブスクリプションの一覧に表示されていたのかは不明ですが、Code Securityを有効化しないとApplication Securityが利用できないのも納得がいきました。 Code Securityを有効化しても解決しない場合は、 Prisma Cloudコンソールの前提条件 を確認し、Application Securityを利用するのに必要な *.bridgecrew.cloud へのアクセスや他前提条件のFQDNへアクセスが許可されているか確認いただくと良いと思います。   さいごに 当社ではPrisma Cloud利用して、複数クラウド環境の設定状況を自動でチェックし、 設定ミスやコンプライアンス違反、異常行動などのリスクを診断するCSPMソリューションを販売しております。 興味のある方は是非、お気軽にお問い合わせください。 マルチクラウド設定診断サービス with CSPM｜ SCSK株式会社

こんにちは、SCSKの嶋谷です。 これまでに3度SaaS型監視サービスMackerelに関する記事を投稿してきた結果、先日Mackerelアンバサダーを拝命いたしました。今後もアンバサダーとしてMackerelを広めていきたいです。 今回の記事もMackerelに関する記事になっています。 弊社が提供している監視サービスではOracle Databaseの監視をしたいというお客様が一定数います。 Mackerelでは、DBのクエリ実行回数やテーブルロックの回数を監視する機能がありますが、それだけでは不足している部分があります。その一例としてOracle Databaseでの監視が挙げられます(後述)。 そのため、お客様に対してMackerelを利用した監視サービスを提供する場合、Oracle Databaseの監視は提供できないのでお客様の要望に応えることができません。 どうにかしたいなとMackerelのドキュメントを読み漁っていると、ユーザが独自に取得した監視データ(数値)をエージェントを利用してMackerelに連携する機能を発見しました。そこで、Oracle Databaseからデータさえ取得できればMackerelに連携することができ、Oracle Databaseの監視ができるのではないかと考え、実装してみました。 私の部署では若手を中心にブログを書いているので、ぜひ他の記事もご覧ください！ MackerelのAPIを使って性能データをCSV形式で出力してみた – TechHarmony CloudWatchのアラート通知をMackerelに移行してみた – TechHarmony Mackerel で AWS のサーバーレスサービスを監視してみた – TechHarmony MackerelでのDB監視 Mackerelでは、メトリックプラグインを利用してMySQLやPostgreSQLの状態を監視することが可能です。SQL Serverの状態を監視するメトリックプラグインは提供されていません。 メトリックプラグイン – mackerel-plugin-mysql – Mackerel ヘルプ メトリックプラグイン – mackerel-plugin-postgres – Mackerel ヘルプ 導入においてMackerelではOracle Databaseの監視する機能が不足していると記載しましたが、監視する方法はあります。例えば、AWS RDSでDBを構築する際にエンジンとしてOracleを選択することでAWSインテグレーションの機能を利用して監視することができます。 AWSインテグレーション – Mackerel ヘルプ しかし、 オンプレミスサーバ や EC2上のサーバ に自前でOracle Databaseを構築している場合、監視可能な機能が不足しています。 今回はこの部分を解決したいと考えています。 MackerelでのOracleDB監視の概要 今回は下記の流れをPowershellスクリプトで実装して、Oracle Databaseの監視を実現しました。 ①Oracle Databaseに接続 OracleのクライアントツールであるSQLPlusでOracle Databaseに接続しています。 ②SQL文を実行してデータ(数値)を取得 ③取得データをエージェントを利用してMackerelに投稿 スクリプト概要 Oracle Databaseの監視を実現するために、作成したファイルを以下に示します。 今回はスクリプトに修正を加えることを減らすために、接続情報やSQL文を別のファイルとして用意しました。 修正が必要な場合には、スクリプトではなくsqlファイルやiniファイルを修正することを想定しています。 ファイル名 説明 mac_ora_text.ps1 Oracle Databaseに接続してデータを取得後、Mackerelに連携するスクリプト query.sql 実行するSQL文を記述したファイル setting.ini Oracle Databaseへの接続情報などを記載したファイル 以下が作成したスクリプトです。 # Oracle DatabaseにSQLPlusで接続→クエリを実行してデータを取得→Mackerelに送信 # mackerel-agent.confファイルからAPIキーを読み取る function Get-MackerelApiKey { param ( [string]$filePath ) $configContent = Get-Content -Path $filePath foreach ($line in $configContent) { if ($line -match "apikey\s*=\s*`"(.+)`"") { return $matches[1] } } return $null } # APIキーを取得 $MACKEREL_APIKEY = Get-MackerelApiKey -filePath ".\mackerel-agent.conf" # hostIDの取得 $HOSTID = Get-Content -Path ".\id" # 現在時刻をエポック秒で取得 $currentUtcTime = [DateTime]::UtcNow $unixtime = [int][double]((Get-Date $currentUtcTime -UFormat %s)) # ユーザ自身で接続情報(ユーザ名やパスワード)とSQL文を別のファイルに準備していただき、そのファイルを読み込み $filePath = "setting.ini" $sqlfilePath = "query.sql" $PARAM = @{} $ses_counts = @() try { Get-Content $filePath -ErrorAction Stop | % { $PARAM += ConvertFrom-StringData $_ -ErrorAction Stop } } catch { Write-Error "File not exists: $filePath" exit 0 } # グラフ名とメトリック名を,区切りで分割して配列に格納 $metric_num_arrays = $PARAM.metric_num -split "," $fig_name = $PARAM.figure_num -split "," # 取得した接続情報を各変数に代入 $username = $PARAM.username $password = $PARAM.password $connectString = $PARAM.connectString # SQLファイルからクエリを読み込み try { $query = Get-Content -Path $sqlfilePath -Raw -ErrorAction Stop } catch { Write-Error "SQL File not exists: $sqlfilePath" exit 0 } # Oracleへの接続・クエリの実行 # -Sオプションを付与して結果のみを取得する $result = $query | sqlplus -S $username/$password@$connectString # SQLの結果ごとに空白行が生成されるので削除 $result = $result | Where-Object { $_ -ne "" } # エラー内容はAPIを利用して送信 # ヘッダーの設定 $headers = @{ "X-Api-Key" = $MACKEREL_APIKEY "Content-Type" = "application/json; charset=UTF-8" } $counter = 0 # 下記4つの文字列がクエリ結果に含まれていればSQL文のミスや接続情報の設定ミスと判断してエラー内容を送信して終了 $errorMessages = @("ORA-", "TNS-", "SP2-","ERROR:") $maxCheckAttempts = 3 foreach ($line in $result) { foreach ($errorMessage in $errorMessages) { if ($line -match $errorMessage) { $line = $line -replace '"', '' # JSONデータの作成 # messageにエラー内容を格納 # maxCheckAttemptsにはにアラートを発生させる条件である連続同一エラー回数 # statusはWARNINGになっていますが、Criticalでも問題ありません。。 # エラー内容によってアラートレベルを変更する場合は改変が必要です。 $POSTJSON = @" { "reports": [{ "source": { "type": "host", "hostId": "$HOSTID" }, "name": "$monitorname", "status": "WARNING", "message": "$line", "occurredAt": $unixtime, "maxCheckAttempts": $maxCheckAttempts }] } "@ $utf8Bytes = [System.Text.Encoding]::UTF8.GetBytes($POSTJSON) $response = Invoke-RestMethod -Uri "https://api.mackerelio.com/api/v0/monitoring/checks/report" -Method Post -Headers $headers -Body $utf8Byte exit 1 } } } # この部分まで到達した際は、エラーが起きずデータが取得できている状態。 # 現在のアラートが起きているかを確認して、起きていればアラートをクローズする(データが取得できているため) # APIを利用してアラートの内容を取得 $alert_response = Invoke-RestMethod -Uri "https://api.mackerelio.com/api/v0/alerts" -Method Get -Headers $headers # 取得したアラート($alert_response)にはMackerel発生しているアラートすべてが含まれている # アラートから$errorMessagesに含まれているアラートだけを取得 $response_removes = @() foreach ($errorMessage in $errorMessages) { $response_removes += $alert_response.alerts | Where-Object { $_.message -match $errorMessage} } if ($response_removes.Length -ne 0){ Write-Host "not null" $body = @" { "reason": "solve" } "@ #アラートをクローズ $utf8Bytes = [System.Text.Encoding]::UTF8.GetBytes($body) for ($i = 0; $i -lt $response_removes.Length; $i++) { $return = Invoke-RestMethod -Uri "https://api.mackerelio.com/api/v0/alerts/$($response_removes[$i].id)/close" -Method POST -Headers $headers -Body $utf8Bytes Write-Output $return } }else{ Write-Output "null" } # クエリ結果の値は文字列として取得されるので数値としてあつかう処理 for ($i = 0; $i -le $result.Length-1; $i++) { Write-Host $result[$i] $ses_counts += [float]$result[$i] } # マカレルエージェントが認識できる形式で出力・Mackerelへデータ送信 # {metric name}\t{metric value}\t{epoch seconds} # ↑上記のフォーマットで標準出力することでMackerelにデータを送信することができる。 # metric nameにおいて、名前の最後のドットまでが共通するメトリックがひとつのグラフにまとめられて投稿される # メトリック名の先頭には自動的に"custom."が付与される#> # 下記の場合、グラフ名「custom.oracle.sql」にses_countのメトリック名でデータが可視化される foreach ($metric in $metric_num_arrays) { Write-Host "oracle.sql.$($fig_name[$counter]).$metric`t$($ses_counts[$counter])`t$unixtime" $counter++ } 以下にスクリプトの簡単な仕様を記載します。 (1)必要情報の取得 スクリプト実行における必要な情報を取得します。 ・MackerelAPIKey ・ホストID ・DB接続情報(ユーザ名・パスワード・インスタンス名) ・Mackerelに表示されるグラフ名、メトリック名 ・SQL文 (2)Oracle Databaseに接続してデータを取得 DB接続情報、SQL文をもとにOracle Databaseに接続してデータを取得。 データが取得できない場合は、エラー内容を文字列で取得し、アラートとしてMackerelに連携します。 エラーの原因は下記が考えられます。 ・DB接続情報の設定ミス ・SQL文の記述ミス ・ネットワークエラー　など Mackerelの仕様上、一度投稿されたアラートはMackerel上に表示され続けます。 そのためデータを取得できた場合は、アラートが解決されたと判断してOracle Databaseに関する投稿済みのアラートを自動でクローズします。 (3)データの連携 取得したデータをMackerelに連携します。連携したデータはグラフとして可視化されるので、(1)の処理で取得したグラフ名やメトリック名も同時に連携します。 利用手順 (1)以下のファイルをエージェントのconfigファイルが格納されているフォルダに配置 ・mac_ora_text.ps1 ・query.sql ・setting.ini (2)setting.iniに以下の情報を記述 ・DB接続情報 ・グラフ名 ・メトリック名 グラフ名、メトリック名は連携するデータの個数分定義する必要があります。 (3)query.sqlにSQL文を記述 (4)エージェントのconfigファイルに以下を追記 [plugin.metrics.プラグイン名] command = [“powershell”, “mac_ora_text.ps1”] プラグイン名は任意で設定可能です。 (5)エージェントの再起動 スクリプトの実行結果 データを取得できた場合 データを取得できた場合、Mackerelに連携されて下記のグラフのように可視化されることを確認しました。 このグラフは接続しているOracle Databaseのセッション数を示しています。 今回はセッション数のグラフを可視化してみましたが、SQLを実行して取得できる数値データはすべて連携できます。 データを取得できない場合 データを取得できない場合、以下のようなアラートがMackerel上に表示されることを確認しました。 DB接続情報の設定ミス時のエラー SQL文の記述ミス時のエラー 上記のエラー内容は一例ですが、エラー内容を連携することでアラートの原因を一目で理解できます。 課題 Oracle Databaseに接続してデータ取得後、Mackerelに連携することはできましたが、課題はあります。 ・今回作成スクリプトはWindowsにしか対応しておらず、Linuxに対応していない ・MySQLやPostgreSQLなどの他のデータベースには対応していない(プラグインでは取得できないデータを取得する場合に限る) 今後はこの課題を解決していきたいと考えています。 ただ、MackerelでOracle Databaseの監視を実現する第一歩になったと感じています。 今回はOracle Databaseを対象としましたが、今後はSQL Serverの監視を実現できるようにもしていきたいです。 まとめ 今回はOracle DatabaseからSQL文を用いてデータを取得して、Mackerelに連携するスクリプトを作成しました。 PowerShellスクリプトでの開発は初めてだったので、構文や規則から学ぶ必要があり実装に時間がかかりました。 時間がかかった分、Mackerel上にグラフが可視化されたときは感動しました！ 現在のスクリプトには課題が多くあり、機能として提供するには程遠い状態です。 自分一人の力では限界があるので、部署の方と協力して提供レベルにまで高度化していきたいです。 最後までご覧いただきありがとうございました！

初めまして。星です。 ServiceNowのクローンのやり方について説明させていただきます。 クローンという方法ひとつ取ってもやり方は様々です。 ここには書かれているのは手法の一つであることにご注意ください。 なぜクローンをする必要があるのか ServiceNowではライセンス契約を行うと、インスタンスは2つもらうことができます。 一般的には１つを本番環境、もう一方を開発環境として運用することが一般的です。 ServiceNowを使っていると一方のインスタンスをもう一方へクローンする場面があります。 例えばバージョンアップの時です。バージョンアップでは本番環境をいきなりバージョンアップするのはリスクがあるため、一度開発環境へバージョンアップを行い、バージョンアップ後の挙動を確かめることが有効です。 しかし、その際に本番環境と開発環境が全く別の設定では、本番環境が実際にどのような変更が加わるのか確認できなくなるため、十分な効果が得られません。 そのため、開発環境へ本番環境をクローンすることで、「本番環境と全く同じ開発環境」を作成してからバージョンアップを行うことでバージョンアップでの検証をより実際の設定に合わせた状態で行うことができ、バージョンアップの品質が向上いたします。 本番環境をクローン先として指定することはまずないため、 本記事ではクローン元となるソースインスタンスのことを本番環境、クローン先となるターゲットインスタンスのことを開発環境と記します。 前準備 クローンを行う際に設定・確認すべきことがあります。 1.開発環境をクローンして問題ないか →関係部署と連携を取り、合意を得てください。 2.本番環境、開発環境でMFA認証を必要としないadmin権限を持つユーザを準備。 →MFA認証設定がされていると、ユーザ情報を使ってログインができません。 3. 環境特有の設定、開発中のデータはないか →該当データがある場合は一時的に更新セットまたはXMLファイルでServiceNow外に保存してください。 ※クローンの前後でバージョンが変化してしまう場合は更新セットは適用できないため注意。 クローンの設定 クローン先（開発環境）のシステムプロパティ設定 クローン先（開発環境）にadmin権限ユーザでログインします。 sys_properties.list でシステムプロパティを開きます。 (※デフォルトではシステムプロパティ一覧を開くモジュールはありません) 開いたリストでglide.db.clone.allow_clone_target を検索します。 glide.db.clone.allow_clone_target の値が true となっていることを確認します。 trueでない場合はtrueに変更します。 [推奨作業] クローン元（本番環境）もadmin権限ユーザでログインし、同様にglide.db.clone.allow_clone_targetを開いて 値がfalse となっていることを確認します。 falseでない場合はfalseに変更します。 ※誤って本番環境をクローン先としないための設定なので本番環境はfalseの状態にしてあることが望ましいです。 クローンターゲットの選択 クローン元（本番環境）にadmin権限ユーザでログインします。 システムクローン > クローンターゲット からクローン先（開発環境）の名前のレコードを開きます。 クローンターゲット設定 ユーザ名とパスワードを開発環境インスタンスのadminユーザに変更して更新します。 システムクローン > クローンを要求 を開いて図のように設定します。 プロファイル ：空欄 ターゲットインスタンス ：クローン先（開発）インスタンスを選択 クローン予定開始時間 ：クローン処理を開始する日時 ※指定した時刻と異なる時刻が設定されることがあるため、送信前に再確認推奨 完了時メール ：クローン完了時にメール用を受信するユーザ（メールアドレスを直接入力しても可） オプション ：すべてチェックを入れる。 特定のテーブルからコピーされたデータ ：完全 設定が終わったら送信ボタンを押下します。送信時にユーザ認証が要求されるので、クローンターゲット設定で設定したものと同じユーザ名、パスワードを再度入力します。 Warning画面が表示された場合は、内容を確認の上でOKを押下します。 以下画面ショット以外のWarningが表示される場合もあるため、内容を必ず確認してください。 クローン設定確認 システムクローン > ライブクローン > アクティブクローン を開きます。 作業で設定したクローンのレコードを開き、意図した通りの設定になっていることを確認します。 設定した実行時間になるとクローン処理が自動実行されます。 通常、開始から1~1.5時間程度で完了しますが、長引くこともあります。 （筆者はなぜか４時間ほどかかったことがありました。） クローン中にクローン先（開発環境）インスタンスへログインしないよう徹底してください。 深夜1時～などログインされない時間帯での設定をお勧めします。 クローン処理完了確認 クローンが完了したことをメールで確認します。 下記のようなメールがServiceNowより届きます。 ServiceNow内で完了したことを確認したい場合は、クローン元(本番)インスタンスでシステムクローン >ライブクローン > クローン履歴から該当のクローン履歴を選択すると確認できます。 クローン後作業 事前準備でServiceNow外に保存していた更新セットやXMLをインポートする。 注意 このクローン方法は情報が 全てクローン されます。 考えられる注意点の例を以下に記載します。 ・クローン元（本番環境）にいなかったユーザは削除され、存在したユーザもクローン先（開発環境）にログインする際のパスワードがクローン元（本番環境）と同じになる ・クローン元（本番環境）に機密情報が含まれる場合、クローン先（開発環境）にも機密情報がクローンされます。 終わりに 今回紹介したのは特殊な設定を行わない、一番シンプルなクローン方法です。 インスタンスごとに「このテーブルはクローンされたくない」「このテーブルはクローンしてしまうと困る」などの要件がある場合もあると思います。その場合はテーブルの徐外設定/保存設定を行うことができるのですが、またそれは機会があれば詳しく説明できればと思います。

こんにちは SCSKの酒井です。 ServiceNowのナレッジ機能にて、テンプレートを作成する機会があったので、その方法を紹介させていただきます。 本記事は執筆時点（2025年6月）の情報です。最新の情報は製品ドキュメントを参考にしてください。 投稿の経緯 ナレッジを作成するにあたって記入項目を標準化、統一化できれば良いな、という要望から本機能の使用を検討しました。 調査した中で分かったことをまとめてみたので、ぜひ目を通してみてください。   実装方法・画面 事前準備 1, 以下のプラグインをインストール Knowledge Management Advanced Installer (com.snc.knowledge_advanced.installer) Knowledge Management Advanced (com.snc.knowledge_advanced) ※ Xanadu リリース以降、新規PDI等作成した場合は、 ナレッジ管理 詳細プラグインが自動的に有効になります。   実装手順 1, メニューから[Article Templates]を入力し、KnowledgeメニューのAdministration配下にある[Article Templates]に移動 OOTBでは5つほどレコードが存在しています。 2, [New]を押下して、新規でテンプレートを作成 3, [Submit]を押下後、テンプレート内で使用するフィールドを定義 フィールドタイプはOOTBで「HTML、文字列、整数、日付、日時」が準備されています。 4, テンプレートに追加したフィールドが、ナレッジのフォームでも表示されるようにフォーム構成を整える KnowledgeメニューのArticles配下にある[Create New]に移動し、作成したテンプレートを選択 その後、以下画面に遷移するので、このフォーム画面に、フォームレイアウト等を使用して項目を表示させる 5, 記事を作成し、公開 OOTBの記事作成と同様です。 今回は画像を添付したり、リンクを埋め込んだりできるように、HTML型を使用しています。   記事作成後の画面 実際の記事   tips フィールドのTypeを[String]から[Translated Text]に変更 実装手順の[3]でフィールドを作成しますが、題名となる[Field Name]のTypeはStringというものになっていて 他の言語への翻訳が適用されません。 日本語訳したい！という場合には、Typeを変更すると、翻訳レコードを作成できるようになります。 ただ、「項目Typeを変更する」という方法はパフォーマンスに不要な影響を与える恐れがあるので、 あくまでも一例としてご認識いただけますと幸いです。 参考文献：Service Now Support 日付や投稿の経緯などの題名の色付け 実装手順[3]のフィールド作成時に、[]にて値を設定するとその値に応じて背景色やフォント、文字の色の指定が可能です。 今回は以下太字部分の[red]を[gray]に変更して試してみました。 例）テンプレートヘッダーの背景を赤色、24 ピクセルのフォントサイズ、Arial フォントファミリー、白のテキスト色で表示する background-color: red ; font-size: 24px ; font-family: Arial ; color: white ; 感想 テンプレートを作成することで、以下のようなメリットが挙げられます。 初めて実装をおこなってみて、理解が深まり非常に勉強になりました。 興味のある方はぜひ試してみてください。 書式の統一 により、文書全体の見栄えや読みやすさを確保 入力項目の標準化、必須項目の明示 によって、必要情報の抜け漏れを防止 記述内容が定型化 されることで、作成工数を削減し、業務の効率化を実現  

本記事ではPrisma Cloudのユーザ権限制御方法と、そこで利用できるカスタム権限グループについて解説します。カスタム権限グループに割り当てることができる権限の一覧も載せていますので、これからPrisma Cloudのカスタム権限グループを作成しようとしている方のお役に立てればと思います。 ユーザ権限の制御方法について Prisma Cloudでは、ユーザの権限制御方法としてロールベースのアクセス制御(RBAC)が用いられています。 ユーザに権限を付与したいときは、以下図のように権限グループが割り当てられたロールをユーザに割り当てます。 権限グループではユーザに許可したい操作が権限として割り当てられており、Prisma Cloudがデフォルトで用意しているデフォルト権限グループと、許可したい操作をカスタマイズできるカスタム権限グループの2種類があります。ユーザには最小権限を持たせたいといった、デフォルト権限グループでは要件を満たせない場合にカスタム権限グループを作成するのが良いと思います。 注意点として、カスタム権限グループにはデフォルト権限グループで許可された操作の内、一部割り当てることができない操作が存在します。 例えば、デフォルト権限グループのSystem Admin(管理者権限相当)では、アドオンの有効/無効化ができますが、カスタム権限グループでは一部アドオンの有効/無効化の操作権限を割り当てることができませんのでご注意ください。 デフォルト権限グループの一覧 デフォルト権限グループとその簡単な説明を一覧化してみました。これら権限グループをロールに割り当てて利用します。各権限グループの詳細は こちら から確認いただけます。さらに、各権限グループで許可されている具体的な操作を知りたい場合は こちら から確認いただけます。 権限グループ名 説明 System Admin サービスを完全に制御でき、アカウントグループやクラウドアカウントを作成、編集、削除可能 Account Group Admin アクセスが許可されたクラウドアカウントおよびアカウントグループの読み取り/書き込み権限を保有 Account Group Read Only 指定されたセクションを表示する読み取り専用権限を保有 Cloud Provisioning Admin クラウドアカウントのオンボーディングと管理を行う権限を保有 Build and Deploy Security ランタイムセキュリティ機能へのアクセスを提供し、DevOpsユーザーのアクセス許可を制限可能 Developer アプリケーションセキュリティ機能へのアクセスを提供   カスタム権限グループに割り当て可能な権限の一覧 カスタム権限グループに割り当て可能な権限を以下に一覧化してみました。 Prisma Cloudの各機能に対して、View(読取)、Create(作成)、Update(更新)、Delete(削除)の4つの操作を許可するか指定します。 View：ユーザはPrisma Cloudの機能を読み取り専用で表示できるようになります Create：ユーザはPrisma Cloud内のリソースを作成できるようになります Update：ユーザはPrisma Cloud内のリソースを更新できるようになります Delete：ユーザはPrisma Cloud内のリソースを削除できるようになります ちなみにカスタム権限グループは こちらの手順 で作成します。 機能（大区分） 機能（中区分） View Create Update Delete Dashboard Code Security & Application Security Tabs 〇         Vulnerability 〇       Asset Inventory Overview 〇       Application Inventory Applications 〇 〇 〇 〇 Investigate Asset 〇         Config 〇         Audit Events 〇         Network 〇         Vulnerability 〇         Applications 〇         Saved Searches 〇 〇   〇 Policies Policies 〇 〇 〇 〇   Manage Policies Compliance Mapping     〇   Compliance Standards 〇 〇 〇 〇   Overview 〇         Reports 〇 〇 〇 〇 Alerts Overview 〇         Snooze/Dismiss     〇     Remediation     〇     Rules 〇 〇 〇 〇   Reports 〇 〇 〇 〇   Notification Templates 〇 〇 〇 〇   Remediate Vulnerabilities   〇     Data Security Posture Management Data Security Posture Management     〇   Data Security Data Security Profile 〇 〇 〇 〇   Data Security Patterns 〇 〇 〇 〇   Data Security Snippet Masking 〇   〇     Data Security Resource 〇   〇     Data Security Inventory 〇         Data Security Dashboard 〇       Settings Account Group 〇 〇 〇 〇   Access Keys 〇   〇 〇   Permission Groups 〇         Roles 〇 〇 〇 〇   Users 〇 〇 〇 〇   Trusted Login IP Addresses 〇 〇 〇 〇   Trusted Alert IP Addresses 〇 〇 〇 〇   SSO 〇   〇     Audit Logs 〇         Anomaly Trusted List 〇 〇 〇 〇   Anomaly Threshold 〇   〇     Resource List 〇 〇 〇 〇   Cloud Accounts 〇 〇 〇 〇   Providers 〇 〇 〇 〇   Application Security 〇         Licensing 〇         Integrations 〇 〇 〇 〇   Enterprise Settings 〇   〇   Compute(Radars) Cloud Radar 〇   〇     Hosts Radar 〇   〇     Containers Radar 〇   〇     Serverless Radar 〇   〇   Compute(Defend)- Vulnerabilities & Compliance Policies Code Repositories Vulnerability Policies 〇   〇     Images/Containers Vulnerabilities & Compliance Policies 〇   〇     Host Vulnerabilities & Compliance Policies 〇   〇     Serverless & App-Embedded Runtime Policies 〇   〇     Custom Compliance Policies 〇   〇   Compute(Defend)- Runtime Policies Container Runtime Policies 〇   〇     Host Runtime Policies 〇   〇     Serverless & App-Embedded Runtime Policies 〇   〇   Compute(Defend)- WAAS Policies WAAS Policies 〇   〇   Compute(Defend)- CNNF Policies CNNF Policies 〇   〇   Compute(Defend)- Access Policies Docker Policies 〇   〇     Secrets Policies 〇   〇     Kubernetes & Admissions Policies 〇   〇   Compute(Defend)- Custom Rules Custom Rules 〇   〇   Compute(Monitor)- Vulnerabilities & Compliance Results Vulnerabilities Dashboard 〇   〇     Compliance Dashboard 〇   〇     Code Repositories Vulnerabilities & Compliance Results 〇   〇     Images/Containers Vulnerabilities & Compliance Results 〇   〇     Hosts Vulnerabilities & Compliance Results 〇   〇     Serverless & App-Embedded Vulnerabilities & Compliance Results 〇   〇   Compute(Monitor)- CI Results CI Results 〇   〇   Compute(Monitor)- Runtime Results Container Runtime Results 〇   〇     Host Runtime Results 〇   〇     Serverless & App-Embedded Runtime Results 〇   〇     Runtime Dashboards 〇   〇     Image Analysis Sandbox 〇   〇   Compute(Monitor)- WAAS Results WAAS Events 〇   〇   Compute(Monitor)- CNNF Results CNNF Runtime Results 〇   〇   Compute(Monitor)- Access Results Docker Runtime Results 〇   〇     Kubernetes & Admission Runtime Results 〇   〇   Compute(Monitor)- Updates Data Updates Pushed to Client Browsers 〇   〇   Compute(Manage) Cloud Account Policy 〇   〇     Cloud Discovery Results 〇   〇     Logs 〇   〇     Defenders Management 〇   〇     Alerts 〇   〇     Collections and Tags 〇   〇     Credentials Store 〇   〇     Authentication 〇   〇     System 〇   〇     System Privileged 〇   〇     Utilities 〇   〇   Application Security Projects 〇       Alarm Center Alarm Center 〇   〇 〇   Alarm Center Settings 〇 〇 〇 〇 Action Plans Overview 〇         Notification Templates 〇 〇 〇 〇   Action Plan     〇     Remediation & Delegation     〇   気を付けてほしいポイント 見落としやすく注意が必要だと思ったのが、Compute(Manage) > System PrivilegedのView操作です。 System Privilegedでは、Prisma Cloudコンソールが現在利用しているAPIトークンを取得することができ、このトークンを利用してユーザがPrisma Cloud APIにコンソールが持っている権限でAPIリクエストを送信できます。つまり、ユーザに許可していない操作を実行される恐れがあるため注意が必要です。   さいごに 当社では Prisma Cloud を利用して、複数クラウド環境の設定状況を自動でチェックし、 設定ミスやコンプライアンス違反、異常行動などのリスクを診断するCSPMソリューションを販売しております。 興味のある方は是非、お気軽にお問い合わせください。 マルチクラウド設定診断サービス with CSPM｜ SCSK株式会社

はじめに Prisma Cloudでは月に一回アップデートがあります。 内容としては新機能のリリース情報やUI変更のお知らせからAPIの更新情報など多岐にわたりますが、今回は2025年5月に機能更新がいくつかあったので、その中で筆者が気になった2つをピックアップしその内容を紹介したいと思います。 ちなみにPrisma Cloudのアップデート情報はPalo Alto社のこちらのサイトからご覧いただけます。 Features Introduced in 2025 紹介する機能更新 今回私が紹介する機能更新は以下2つです。Prisma CloudのCSPMを利用していれば、自動で反映される更新をピックアップしました。 ・Azure VNetフローログの取り込み ・AWS ca-west-1リソースの取り込み Azure VNetフローログの取り込み Microsoft Azureアカウントのオンボーディングにおいて、既存のNSGフローログに加え、VNetフローログの取り込みが可能になりました。また、VNetフローログは、既存のAzureポリシーのデータソースとしても追加されます。既存のテナントに対する影響はなく、追加の設定や構成の変更も必要ありません。 また、NSGフローログに関しては以下のことがMicrosoftより発表されています。 NSGフローログの廃止: 2027年9月30日にネットワークセキュリティグループ（NSG）フローログが廃止される予定です。 新規NSGフローログの作成停止: 2025年6月30日以降、新しいNSGフローログを作成することができなくなります。 サポート終了: 提供終了日の後は、NSGフローログで有効になっているトラフィック分析がサポートされなくなります。また、サブスクリプション内の既存のNSGフローログリソースも削除されます。 そのため、NSGのフローログ廃止に伴い、VNetフローログへの移行が推奨されます。 Microsoftの発表についてはこちらから↓ フロー ログの読み取り – Azure Network Watcher | Microsoft Learn AWS ca-west-1リソースの取り込み AWSリソースの検出が新たにca-west-1（カナダ、カルガリー）のリージョンに対応しました。 日本国内でこのリージョンを利用している企業は多くはないかと思われますが、ca-west-1の追加によって、よりグローバルな環境でのリソース管理が可能になります。 Prisma Cloudが対応するリージョンの詳細はクラウドサービスプロバイダーのリージョンでご覧いただけます。 Prisma Cloudでのクラウドサービスプロバイダーのリージョン 一部未対応のリージョンはありますが、主要なリージョンはほぼ対応済みとなっています。 まとめ 今回は2025年5月にあった機能更新を紹介しました。 機能更新を確認しないと、急にアラートが発生したり、把握していない処理を行う場合があります。 機能更新を適切に確認し、PrismaCloudを適切に利用する必要があります。 この記事が、ご自身またはご自身の職場のクラウド環境のセキュリティリスクを見直すきっかけになれば幸いです。 また、当社では、Prisma Cloudを利用して複数クラウド環境の設定状況を自動でチェックし、設定ミスやコンプライアンス違反、異常行動などのリスクを診断するCSPMソリューションを販売しております。ご興味のある方はお気軽にお問い合わせください。リンクはこちら↓ マルチクラウド設定診断サービス with CSPM｜ SCSK株式会社 マルチクラウド環境のセキュリティ設定リスクを手軽に確認可能なスポット診断サービスです。独自の診断レポートが、運用上の設定ミスや設計不備、クラウド環境の仕様変更などで発生し得る問題を可視化し、セキュリティインシデントの早期発見に役立ちます。 www.scsk.jp