今回は 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

こんにちは、SCSK伊藤です。 いよいよAWS Summit Japan 2025が今週となりました。 水曜日は雨天の予報も出ておりますが、足元にお気をつけて幕張メッセにお越しくださいませ。 今年のSCSKの出展内容は以前発信した記事に掲載していますので、ご確認ください。 AWS Summit Japan 2025に出展します！ SCSKは 2025/6/25(水)～6/26(木)開催の日本最大の AWS を学ぶイベント「AWS Summit Japan」に出展します。 SCSKセッションでは、”AIで振り込め詐欺を防止しろ!四国銀行の9ヶ月の挑戦”というテーマで、株式会社四国銀行様の開発事例をご紹介いたします。 blog.usize-tech.com 2025.05.12 【近日開催！】AWS Summit Japan 2025「AWSで、夢ある未来を共に創る。SCSK」ブースのご紹介！ SCSKはいよいよ開催が迫る「AWS Summit Japan」に出展します。ブースでは「AWSで、夢ある未来を共に創る。SCSK」をテーマに独自ソリューションの4商材を展示、ミニシアターでは6つのAWS関連ソリューションから発表いたします。 blog.usize-tech.com 2025.06.02 さて、今回はブースでお配りするノベルティに注目したいと思います。 今年のSCSKブースは、過去最大のノベルティの取り揃えになっています。 MLBクリアファイル（前段左右）： ブローシャー配布に利用 クーリングタイル（中段左）　　： ブース各商材に来訪いただいた方へご提供 ミニクーリングファン（中段右）： ミニシアターアンケート回答の方へご提供 貝印ツメキリ（後段）： 営業スタッフよりご提供 TechHarmonyご愛顧の方への特別ノベルティ： 「TechHarmony見てます！」と仰っていただいた方へご提供 今日は、その中でも、 目玉グッズである「貝印の爪切り」に注目してみたいと思います 。 何故爪切り？ ＳＣＳＫは、貝印株式会社様がＡＷＳを活用できるように、クラウド推進組織の立ち上げ、運用基盤の確立、効率的なクラウドリフトなど、様々なご支援を実施しています。   製造業 AWS 事例 | 貝印株式会社 製造業 AWS 事例｜貝印株式会社様が既存のIT環境を刷新し、クラウド移行を通じて組織改革を推進した成功事例を詳しく解説します。 www.scsk.jp クラウドでのお取引を皮切りに、 他にも基幹系、データ活用、ネットワークやセキュリティなど、 色々な領域をお任せ頂いています。そんなご縁も有り、また 「貝印の爪切りの切れ味は素晴らしい」と常々伺っていたため、今年のノベルティの一つとして選定させて頂きました ！     そのクオリティやいかに！？   外観 さて、それでは早速サンプルを使って、切れ味を試していきましょう。 まずは開封して、その上下左右からしっかり観察していきます。安価な爪切りにありがちな微妙なガタつきや、爪カバーの微妙な隙間などは見当たりません。切る際に、てこの支点となる部分についても、絶妙な曲線美で、動作のスムーズさを予感させます。 切れ味 ちなみに、皆さんは爪切りにこだわりはありますか？　私はこれまで、ドラッグストアで手頃なものをなんとなく選んでいました。 しかし、今回この貝印の爪切りを使ってから、その考えが180度変わりました。まず、 特筆すべきはその 切れ味 です 。一般的な爪切りによくある「バチン！」という衝撃や、切った後の爪のガタつきが全くありません。 まるで 吸い込まれるようにスッと切れる感覚 。これは本当に驚きです。軽い力でスムーズに切れるので、 爪への負担も少ないように感じます 。   そして、この滑らかな切れ味のおかげで、 切った後の爪の断面がとてもきれいに仕上がります 。ヤスリを使う手間も省けるほどで、これには本当に感動しました。爪切り一つでこんなにも快適さが変わるのかと、目から鱗が落ちる体験でした。     まとめ 正直、ノベルティでここまで実用性とクオリティを兼ね備えたものを提供してよいのか！？と、心配になるレベルでした。 しかも、貝印様の爪切りのラインナップには、さらに高級な「関孫六」シリーズもあるそうです。丁度ボーナスが出た私のご褒美に最適！　鍛冶屋の精神が籠った逸品に納得です。貝印様のおかげで、私のクオリティオブライフがうなぎ上りです。ありがとうございました。     入手方法 こちらの爪切りですが、数量限定との事で、日ごろお世話になっていてブースにお見えになったお客様や、ブースでご商談後に別途個別商談のお約束を頂けたお客様に、セールス担当の判断でお配りする事になっています。 ぜひ、AWS活用に関するお悩みをＳＣＳＫブースでお教えください！   そして、爪切り以外にも、色々と限定グッズをご用意しています。 貝印の爪切りをゲットできなくても、ぜひ、お気軽にＳＣＳＫブースに遊びに来てください！  

こんにちは SCSKの庄司です。 前回、ServiceNowの注文ガイドの基本機能についてご紹介いたしました。 【ServiceNow】注文ガイドの基本 注文ガイドとは、複数のアイテムを生成する1つのサービスカタログ要求を送信するための機能です。複数のサービスカタログアイテムを一連の流れで選択・同時注文できるようになります。 blog.usize-tech.com 2025.05.29 今回は前回記事の末尾に記載いたしました、注文ガイド内での申請内容への順序付け方法を紹介していきます。 本記事は執筆時点（2025年6月）の情報になります。最新の内容は製品ドキュメントを参考にしてください。 順序付けとは？ 「順序付けって何？」という方も多いかと思いますので、まず簡単に説明します。 今回も、PDI（Personal Developer Instance）にデフォルトで実装されている「New Hire」注文ガイドを使用します（以降「新規雇用」注文ガイドと表記します）。 この注文ガイドは、新入社員に必要な備品やアカウントをまとめて申請できる便利なものです。 以下のようなカタログアイテムが含まれています。 Standard Laptop Developer Laptop (Mac) Standard 27″ Monitor New Email Account Apple iPhone 13 Samsung Galaxy S22 Ultra 5G Corp VPN Desk Set Up 上記のアイテムの中に例えば、以下のような前後関係がある場合を考えてみます： 「Corp VPN」は「New Email Account」が完了してからでないと申請できない 「Standard 27″ Monitor」は「Desk Set Up」の後でないと手配できない しかし、デフォルトの注文ガイドではすべてのアイテムが同時に申請されるため、このような前後関係がある場合に問題が発生します。 ここで役立つのが「順序付け機能」です。この機能を使うことで、申請時は一括申請可能でも、処理の順番をコントロールすることができます。   プラグインの導入 早速注文ガイドの実行順序設定方法を紹介していきます。 この機能を利用するには、まず以下のプラグインを有効化する必要があります。 ・Order Guide Sequential Fulfillment(com.glideapp.servicecatalog.order_guide_sequencing) ①[すべて]>[システム定義]>[プラグイン]に遷移し、Order Guide Sequential Fulfillmentプラグインを検索します。 ②Order Guide Sequential Fulfillmentプラグインをインストールします。 上記手順で事前準備完了です。    プロセスの構築 上記手順実施後、注文ガイドフォームに遷移すると[シーケンスを生成]ボタンが表示されます。 「新規雇用」注文ガイドフォームを開くと、[シーケンスを生成]ボタンがあることが確認できますね。 [シーケンスを生成]を押下すると、以下のような確認のポップアップが表示されます。 Process name欄に名前を設定し、[生成]を押下します。 デフォルトでは「(注文ガイドの名前) プロセス」になっているので、問題ない場合はそのまま[生成]を押下します。 [生成]ボタン押下後、数秒待つとWorkflow Studioに自動遷移し、上記で設定した名前のPlaybookが表示されます。   生成されたプロセスでは、全アイテムが横並び（＝同時実行）になっています。 ここに、前述した通り以下の前後関係を設定していきます。 「Corp VPN」は「New Email Account」が完了してからでないと申請できない 「Standard 27″ Monitor」は「Desk Set Up」の後でないと手配できない まずはプロセスから、Corp VPNを選択します。 右側に出るプロパティのStart ruleで「After specific activities」を、Starts after で「New Email Account」を選択し、[保存して閉じる]を押下します。 すると、プロセス内で「Corp VPN」が「New Email Account」の後続に来るようになったことが視覚的にわかります。 同様に、「Desk Set Up」の後に「Standard 27″ Monitor」が来るように変更します。    最後に、右上の [アクティブ化] を押してプロセスを有効化します。 以上で、以下の過程をプロセス上で再現することが出来ました。 「Corp VPN」は「New Email Account」が完了してからでないと申請できない 「Standard 27″ Monitor」は「Desk Set Up」の後でないと手配できない   動作確認 順序付け設定前後で、RITM（要求アイテム）レコードのステージの動きにどのような違いがあるかを確認してみましょう。 順序なし（デフォルト）の場合 並行でのプロセスの場合、以下のように注文ガイドを送信した後各アイテムのステージが一気に動き出します。   前後関係があるにも関わらず「Corp VPN」や「Standard 27″ Monitor」もすぐにステージが進んでしまいます。 順序付けありの場合 以下のように、前提となるアイテムを設定した「 Corp VPN」、「Standard 27″ Monitor」 のみ他アイテムと異なり最初のステージ（未開始）のままであることがわかります。   では、「Corp VPN」の前提となっている「New Email Account」を完了してみましょう。 「Corp VPN」のステージが動き始めたことが確認できました。 「Standard 27″ Monitor」も同様です。 「Desk Set Up」が完了すると、ステージが動き始めたことが確認できます。   以上が注文ガイドへの順序付けをした際の動作になります。 他にも、プロセスには様々なオプションがあるので簡単に紹介していきます。   補足：プロセスの便利なオプション 1. ステージ（レーン）の追加 プロセスではアイテムごとに順序や前後関係を決めるだけでなく、 関連するアイテムをグループ化し、ステージ単位で順序制御が可能です。 複雑な申請プロセスの整理に有効です。 2. 条件分岐の追加 プロセスには、フロー同様条件分岐を追加することが出来ます。 たとえば「前のアイテムが成功していなければ後続をスキップする」といった条件付きの処理が可能です。 3. アクティビティの追加 プロセスにはアイテムや条件分岐のみでなく、アクティビティを追加することが出来ます。   アクティビティには、フローやサブフロー、カスタムのアクションなども含まれています。 サブフローやスクリプトアクションなどの追加により、差し戻し時の連鎖対応や動的な挙動制御も可能です。 アクティビティをうまく使えるかどうかで、注文ガイドで実現できる要件の幅がぐっと広がります。 4. ビュー切り替え（ダイアグラム／ボード） 注文ガイド自体の機能と直接関係はありませんが、プロセス編集画面のビューを変更することが出来ます。 ダイアグラムビュー ：視覚的な流れを確認しやすい ボードビュー ：アイテムの並び替えやグループ化に便利     私は「編集はボードビュー」「確認はダイアグラムビュー」で使い分けています。   まとめ 注文ガイドは、ユーザーが1つの申請で複数のアイテムを同時にリクエストできる便利な機能です。 今回ご紹介した「順序付け機能」を活用することで、依存関係のある業務プロセスでもスムーズに運用できるようになります。 注文ガイドを構築する際は、ぜひ「プロセスの生成」による順序制御も取り入れてみてください。

SCSK 永見です。 Amazon Q Developerはコード生成などに活用できるAIサービスです。 有料版であるQ Developer Proは、IAM Identity Center(以下、IIC と記載します)が必要になりますが、Organizationsの”子アカウント”であるメンバーアカウントや、Organizationsの機能を利用していないスタンドアロンアカウントでも利用することができます。 そこで今回は、メンバーアカウントでIICアカウントインスタンスを有効化し、Q Developer Proをサブスクライブする方法をお伝えします。 前提知識：IICの組織インスタンスとアカウントインスタンス 一言で表すと、管理アカウントで設定されたIICが組織インスタンス、メンバーアカウントやスタンドアロンで設定されたIICがアカウントインスタンスです。 組織インスタンスとアカウントインスタンス、何が違うの？というのは、公式ドキュメントの表が最もわかりやすいです。 IAM アイデンティティセンターの組織インスタンスとアカウントインスタンス - AWS IAM Identity Center IAM アイデンティティセンターの組織インスタンスとアカウントインスタンスについて説明します。 docs.aws.amazon.com Q Developer Proに必要なAWSマネージドアプリケーションへのシングルサインオン(上の表①)は、IICアカウントインスタンスでも有効です。 IICの機能のイメージとして一番強い、AWSアカウントへのシングルサインオンの機能(上の表②)は、正確にはIIC組織インスタンスの機能です。 AWS IAM Identity Center で使用できる マネージドアプリケーション - AWS IAM Identity Center IAM Identity Center を使用して、 AWS マネージドアプリケーションへのシングルサインオンアクセスを許可します。 docs.aws.amazon.com 今回は、メンバーアカウントでIICアカウントインスタンスを作成し、Q Developer Proをサブスクライブする手順をご紹介します。 Q Developer Proのサブスクライブ手順 全部で4つのステップで実施します。 第一ステップ：メンバーアカウントにてIICアカウントインスタンスの有効化 まずはIICを有効にします。どのリージョンにIICを作成するか決めたうえで作成しましょう。 IICのコンソールへ遷移します。 決めたリージョンにて「有効にする」をクリックします。 もろもろ確認事項を読み、「有効にする」をクリックします。この環境はIIC組織インスタンスがあるので注意書きが出ていますが、共存は可能です。 作成ができました。 ここで作成したリージョンとAWS access portal URLはこの後使いますので控えておきましょう。今回は 東京リージョン(ap-northeast-1) 、AWS access portal URLは https://access_portal_url.awsapps.com/start として、説明を記載します。 第ニステップ：IICユーザー作成 次にIICにてサブスクライブするためのユーザーを作成します。ユーザーのメールアドレスが必要になります。 IICのコンソール左部「ユーザー」をクリックします。 「ユーザーを追加」をクリックします。 ユーザーの情報を入力します。今回はパスワードの受け取り方法としてワンタイムパスワードを選択します。もちろんEメールへ送信でも問題ありません。 必要に応じてグループに追加します。今回は追加せずに手順を進めます。 ユーザーの情報に間違いがないことを確認し、「ユーザーを追加」をクリックします。 これで作成は完了です。パスワードを控えておきましょう。Eメールへ送信した場合はその手順に従ってください。 第三ステップ：Q Developer Proのサブスクライブ 次は作成したユーザーを使って、Q Developer Proのサブスクライブを行います。 Amazon Q Developerのコンソールへ遷移します。   この記事を執筆している2025年6月現在、Q Developerはバージニア北部(us-east-1)とフランクフルト(eu-central-1)でのみ公開されていますが、 IICのリージョンと合わせる必要はありません 。 今回はIICの作成は東京リージョン(ap-northeast-1)で、Q Developer Proのサブスクライブはバージニア北部(us-east-1)で実施します。 Amazon Q Developerのコンソールにて「使用を開始」をクリックします。 第二ステップで作成したユーザーのメールアドレスを入力し、「続行」をクリックします。 初めてQ Developerを利用する際は、プロファイル作成の画面が出てきます。特別な設定は不要なので、任意のプロファイル名、説明を入力し、「作成」をクリックします。 正常にセットアップが完了した旨のメッセージが表示されます。 左上のハンバーガメニューから「セッティング」を開くと、プロファイル等の情報が、「サブスクリプション」を開くと、サブスクライブしているグループやユーザーの情報を見ることができます。 第四ステップ：IDEのセットアップ 最後に、IDEにおける設定を行います。お手持ちのIDEを起動してください。今回はVisual Studio Codeを例にとり説明します。対応のIDEは下記を参照ください。 IDE に Amazon Q Developer 拡張機能またはプラグインをインストールする - Amazon Q Developer IDE で Amazon Q Developer をセットアップする方法について説明します。 docs.aws.amazon.com まずは左端の拡張機能のアイコンから「Amazon Q」を検索し、「install」をクリックします。 インストールが終わると出てくるAmazon Qのアイコンをクリックします。 Company AccountがIICを使ったProプランを指します。Company Accountを選択し、Continueをクリックします。 無料版であるPersonal Accountは、AWSアカウントやIICがなくとも、Builders IDがあれば使えます Start URLには IICのAWS access portal URL (今回の例ではhttps://access_portal_url.awsapps.com/start)を入力し、Regionには IICを作成したリージョン (今回の例ではap-northeast-1。Q Developerのプロファイルがあるリージョンではありません)を選択し、Continueをクリックします。 ブラウザを開いてよいかのポップアップが出たら「Open」をクリックします。 ブラウザに遷移し、第三ステップでサブスクライブ済のユーザーでサインインします。   MFAの設定が求められたら使い慣れた方法で設定しておきましょう。 アクセスを許可してよいか を選択する旨のメッセージが出てくるので、「アクセスを許可」をクリックします。 承認された旨のメッセージがブラウザに表示されたら、ブラウザを閉じ、Visual Studio Codeに戻ります。 左側で、CHATが入力できるようになっていたら成功です！ 実際の使い方は、下記をご参照ください。 【Amazon Q】Q Developerを試してみました！ 今年7月から、Visual Studioでも利用ができるようになったAmazon Q Developerはどんな機能があるのか…今回は色々な機能を試してみました。 blog.usize-tech.com 2024.08.20 躓きやすいポイント 躓きやすいポイントを3点併せてご紹介します。 サブスクライブはどのユーザーで実施するの？ IAMユーザーでサブスクライブをします。先述のとおり、IICアカウントインスタンスのユーザーはAWSアカウントへのシングルサインオンはできません。 IAMユーザーでコンソールへサインインし、IICアカウントインスタンスのユーザーを指定してサブスクライブする という流れです。 IIC組織インスタンスのユーザーが使える方はそちらでも可能です。 が、この記事を参照されている方はおそらく使えないと思われるのでIAMユーザーでサブスクライブ と記載しています。 ユーザーを追加したいときはどうするの？ 試しにこのユーザーを追加してみましょう。 Q Developerのコンソールの「サブスクリプション」から「サブスクライブ」をクリックすることで追加できます。 何も出てこないのでちょっとびっくりしますが、検索バーへIICユーザーの「表示名」を入力し検索すると選択できるようになります。   セキュリティは大丈夫なの？ セキュリティ観点の一つとして、AIオプトアウトポリシーの設定がなされているか、があります。 管理アカウントの管理者へ問い合わせしてみてください。 【AWS】AIサービスを使うときのセキュリティ設定 AIサービスに入力したデータを、AWSが保持しないよう制限する「AI サービスのオプトアウト」の設定をご紹介します。 blog.usize-tech.com 2025.06.09 まとめ メンバーアカウントでQ Developer Proを有効化する方法をご紹介しました。 この記事が皆様のお助けになれば幸いです。

/var/log/wtmp を Log Analytics ワークスペースにそのまま取り込もうとすると、文字化けが発生します。 ネット上に情報が無く、サポートに問い合わせて解決に至りましたので、小ネタですが誰かの助けになればと思い記事にします。 やりたいこと Azure Log Analytics ワークスペースからクエリ投げて、/var/log/wtmpのログを表示したいです。 しかしwtmpファイルの性質上、うまくいきませんでした。   wtmpとは 概要 /var/log/wtmpはLinux OSにおいてログインのイベントを記録するファイルです。 システムの利用状況を把握し、セキュリティ監査やトラブルシューティングを行うために利用されます。 本記事において重要なのが、テキストファイルではなく、バイナリファイルとして記録されていることです。 バイナリファイル バイナリファイル内のデータは0と1のビット列で構成されており、人間では解釈できない構造になってます。 cat /var/log/wtmp つまりcatコマンドを入力しても中身見れないのです。（Linux OSのVMにログインして入力することを想定） 専用のlastコマンドが必要で、 last これだと人間が読める形式で表示してくれます。   Log Analytics 使ってみる データ収集ルール VMにログインせずともAzureポータルからログを確認するために、Log Analyticsを使用します。 データソースの追加 データソースの種類：カスタムテキストログ ファイルパターン：/var/log/wtmp テーブル名：wtmp_CL レコード区切り記号：End-of-Line 変換：source       問題点 設定完了しましたら、 Log Analytics ワークスペースで実施します。         結果のRawData列 に注目してほしいのですが、文字化けしてます。 “}pts/0ߢOh��1pts/0ts/0vmlinux-tomioka0110.15.172.5��Oh�” Log Analyticsのデータ収集ルールの機能には様々なデータソースの種類がありますが、使用している「カスタムテキストログ」ではその名の通りテキストファイルのみを対象とします。 「それなら、別のデータソースの種類にすれば良いのでは？」と思われるかもしれません。 しかし、残念ながら別のデータソースの種類ではファイルパターン（’/var/log/wtmp’）の指定できません。 つまり カスタムテキストログを使用 → 文字化けが発生 別のデータソースの種類を使用 → /var/log/wtmp を読み取ること自体ができない という八方塞がりの状態になってしまうのです。   解決策 単純ですが、lastコマンドの結果を新しいテキストファイルに出力して、そのテキストファイルを読み取ることで解決します 手順 1.Linux OSのVMにログインして以下のコマンド入力します。 last -f /var/log/wtmp > /var/log/wtmp.log 2.Azureポータルのデータ収集ルールに移動し、ファイルパターンを/var/log/wtmp.logに変更 3.Log Analytics ワークスペースで テーブル名のクエリを入力して実行             RawData列に人間が読める形式で出力されました。 “vmlinux- pts/0 10.15.172.5 Mon Jun 16 07:46 – 08:31 (00:44)” カスタム ログを設定し、OS 上にログが出力された後、2 時間程度経過しないと Log Analytics ワークスペース上でクエリが出来ない場合があります。 Azure Monitor エージェントでカスタム ログを取得する方法 | Japan Azure Monitoring Support Blog   さいごに 本当は余計なテキストファイルを追加せずに、読み取る方法があれば良いなと思っています。 Log Analytics ワークスペースが /var/log/wtmpのようなバイナリ形式のログファイルを直接サポートし、ログを収集・分析できるようになる未来を期待しています。

「AWS Bedrock」を使って、サクッと社内ガイドラインの検索システムを構築していきます。APIやpythonとかはよくわからないけど、簡単に生成AIアプリケーションを試してみたい人はぜひ参考にしていただければと思います。 プログラミングの知識も不要です。 AWS Bedrockを使用する訳 下記の理由からIT・AI初心者が「AWS Bedrock」を使用して生成AIを学ぶことをお勧めします。 世界最大のクラウドシェア率を誇るAWSのサービスである。 参考になる記事がネットにたくさん落ちているので、不明点があっても課題を解決しやすいです。 色々なAIモデルを試せる。 例えばOpenAI社が提供しているChatGPTは「GPTモデル」を採用していますが、他にもいろいろなモデルがあり、それぞれ別の強味があります。 今回は汎用的なテキスト生成に強味があるAnthropic社の「Claudeモデル」を使用しています。 マネージドサービスが豊富。 サーバやミドルウェアなどの領域をAWS側に管理してもらえるので、インフラの知識がなくても簡単にAIサービスを作れます。   実施したいこと 上記のような感じで、社内の至る所に点在しているガイドラインをいちいち検索しなくても、 知りたいことをチャット形式で質問すれば、AIが社内文書から自分で回答を探してきてくれるようにできます。 例えば、以下のような社内ガイドラインがあるとします。 （サンプル）社内ルールの一般的なガイドライン こちらは実際のSCSKの社内ガイドラインではなく、ChatGPTに作成してもらったサンプルの社内ガイドラインになります。 （「適当に社内ガイドラインのサンプルを作成して」「項目は複数個作成して」というプロンプトを入れて作成しました。） サンプルの社内ガイドライン Bedrockで自由に聞きたいことを質問すると、社内ガイドラインに記載されている文章の中からAIが適切な回答を探して返してくれるシンプルな社内ガイドライン検索システムです。 こんな感じでAIが回答を生成してくれます   構築手順 S3にドキュメント（社内ガイドライン）の取り込み 「S3」にて「08523-yabutani-bedrocktest」というバケットを作成し、ドキュメントをアップロードしました。 バケットは名前を設定しただけで、他の設定は特に何もしていません。 今回はワード形式のファイルを取り込みましたが、エクセル形式やPDFデータも読み込めるそうです。 Amazon Bedrock ナレッジベースデータの前提条件 - Amazon Bedrock ナレッジベースにデータを使用する前に、必要な前提条件について説明します。 docs.aws.amazon.com ナレッジベースを設定 「Amazon Bedrock」→「ナレッジベース」→「作成」をクリックします。 「ベクトルストアを含むナレッジベース」を選択し、ナレッジベース名（適当な名前でOK）とS3のデータソースを入力し「次へ」を押します。 データソース名（適当な名前でOK）と先ほど作成した「08523-yabutani-bedrocktest」というバケットを選択し「次へ」を押します。 「適用」→「次へ」を押し「確認して作成」の画面で設定に誤りがないことを確認し、「ナレッジベースを作成」を押下します。 S3格納データを同期 ナレッジベースが作成されますので、データソース名を選択し、「同期」をクリックします。 同期しないとS3にアップロードした社内ガイドラインを読み込めません。もし別の社内ガイドラインを追加したい場合は、S3にファイルをアップロードした後、都度「同期」をクリックする必要があります。   動作確認方法 「データソースの同期が完了しました 」と表示されますので「ナレッジベースをテスト」をクリックします。 「モデルを選択」から以下を選択し「適用」を押下します。 カテゴリ：Anthropic モデル： Claude 3.5 Sonnet   v1   プロンプト(質問)を入れてみます。 質問：カードキーをなくしたらどこに電話すればいいの サンプルとして作成した以下の社内ガイドラインに記載している内容を元に、AIが回答を作成してくれました。 （サンプル）社内ルールの一般的なガイドライン 回答： カードキーを紛失した場合、即座に2つの連絡先に報告する必要があります。まず上司に連絡し、次にITサポートデスクに連絡してください。ITサポートデスクの電話番号は0120-123-456です。