こんにちは。SCSKの上田です。 Zabbixには、 サポート期間 があることをご存知でしょうか？ Zabbixを安心して利用し続けるためには、サポート期間を把握し、適切なバージョンアップを行うことが必要不可欠です。 今回は、 Zabbixのサポート、そしてバージョンアップの重要性 について書いていきます。 サポートの種類について Zabbixのサポートには、 ３種類のサポート があります。リリース後の期間に応じて享受できるサポートの種類が確定します。 フルサポート 期間：バージョンのリリースから3年間 対応内容： インストール方法、使用方法、設定方法に関するお問い合わせ 問題の原因調査・分析 すべてのレベルのバグ修正 機能改善要望への対応 リミテッドサポート 期間：フルサポート終了から2年間 対応内容： インストール方法、使用方法、設定方法に関するお問い合わせ 問題の原因調査・分析 深刻度の高いバグの修正 セキュリティフィックス 延長サポート 期間：リミテッドサポート終了から2年間 対応内容： インストール方法、使用方法、設定方法に関するお問い合わせ 問題の原因調査・分析 フルサポートが終了すると、 深刻度の高いバグしか修正されなくなります 。また、リミテッドサポ―トが終了すると、 セキュリティフィックスを含むアップデートも行われなくなります 。 そのため、 サポート期間が終了する前に、新しいバージョンにバージョンアップすることが重要 となってきます。 なお、対応内容に記載のお問い合わせや問題の調査に関しては、 有償の Enterpriseサポート に加入する必要があります 。弊社でもEnterpriseサポートを取り扱っておりますので、詳細は以下のページを御参照ください。 （※延長サポートで加入される方は、事前にご相談ください） サービス内容｜SCSK Plus サポート for Zabbix Zabbix社の認定パートナーとして、さまざまなシステム環境でZabbixを構築・運用してきたSCSKでは、そのノウハウをフルに活かして、お客様のZabbix活用をトータルでサポートしています。 www.scsk.jp 各バージョンのサポート期間 各バージョンのサポート期間をまとめました。（サポートが継続されているLTSバージョンのみ） バージョン リリース フルサポート終了 リミテッドサポート終了 延長サポート終了 Zabbix 7.0 LTS 2024/6 2027/6 2029/6 2031/6 Zabbix 6.0 LTS 2022/2 2025/2 2027/2 2029/2 Zabbix 5.0 LTS 2020/5 2023/5 2025/5 2027/5 Zabbix 4.0 LTS 2018/10 2021/10 2023/10 2025/10 直近では、 2025年5月末にZabbix 5.0のリミテッドサポートが終了 し、 2025年10月末にZabbix4.0の延長サポートが終了 します。 そのため、 2025年6月からZabbix 5.0のセキュリティフィックスを含む全てのアップデートが行われなくなり、 2025年11月からZabbix4.0に関するお問い合わせができなくなります。 現在上記のバージョンをご利用中の方は、ご注意ください。 現在ご利用中のZabbixのバージョンは、以下のように確認可能です。 CLIの場合 以下のコマンドでバージョンが出力されます。 # zabbix_server -V GUIの場合 Web管理コンソールの最下部にバージョンが表示されます。 バージョンアップの重要性 昨年Zabbixでは、 CVSSスコアがCriticalの脆弱性が3件 発表されました。 【緊急】Zabbix の脆弱性情報 CVE-2024-22116 (CVSS 9.9) 2024年8月9日（現地時間）にZabbix社は、監視ソリューション「Zabbix」に深刻な脆弱性があると公表いたしました。 この脆弱性が悪用された場合は、システム全体が危険にさらされる可能性があるため、緊急のアップデートが推奨されております。 blog.usize-tech.com 2024.08.21 【緊急】Zabbix の脆弱性情報 CVE-2024-42327 (CVSS 9.9) Zabbixに関する深刻な脆弱性について、詳細を説明します。 blog.usize-tech.com 2024.11.29 【緊急】Zabbix の脆弱性情報 CVE-2024-42330 (CVSS 9.1) Zabbixに関する深刻な脆弱性（CVE-2024-42330）が発表されました。本記事で詳細と対処方法について説明します。 blog.usize-tech.com 2025.02.03 リミテッドサポートが終了すると、このような緊急性の高い脆弱性が見つかってもマイナーバージョンがリリースされず、対応がメジャーバージョンアップしかなくなってしまいます。 Zabbixのメジャーバージョンアップは、バージョン間によってはトリガー条件式が変わっていたり、マクロを書き換える必要があったりと、 考慮すべきポイントが多い です。 そのため、 余裕を持ったバージョンアップの計画 をオススメします。 最後に 今回は、Zabbixのサポートについてまとめました。 Zabbix 4.0とZabbix 5.0に関してはもうすぐサポートが終了しますので、お早めにバージョンアップをご検討ください。 弊社では、バージョンアップの支援を行っております。 バージョンアップのやり方が不明な方や、自社だけでのバージョンアップに不安のある方は、是非弊社までお声がけください！ ↓お問い合わせはこちらから↓ お問い合わせ 製品・サービスについて 入力 ｜ SCSK株式会社 SCSK株式会社 製品・サービスについてご意見・ご質問をお受けしております。 www.scsk.jp 最後まで読んでいただき、ありがとうございました。 弊社ではZabbix関連サービスを展開しています。以下ページもご参照ください。 ★Zabbixの基礎をまとめたeBookを公開しております！★ FAQ・お問い合わせ｜SCSK Plus サポート for Zabbix 導入をご検討される際、よくあるご質問と回答についてまとめております。 www.scsk.jp ★SCSK Plus サポート for Zabbix★ SCSK Plus サポート for Zabbix 世界で最も人気のあるオープンソース統合監視ツール「Zabbix」の導入構築から運用保守までSCSKが強力にサポートします www.scsk.jp ★YouTubeに、SCSK Zabbixチャンネルを開設しました！★ SCSK Zabbixチャンネル 本チャンネルでは、SCSK株式会社でのZabbixに関するトレンド/事例紹介などを動画にまとめて取り上げております。最新のトピックについては、以下の弊社HPもしくはツイッターアカウントをぜひ参照ください。ツイッターアカウント： www.youtube.com ★X（旧Twitter）に、SCSK Zabbixアカウントを開設しました！★ x.com x.com

こんにちは、広野です。 Amazon CloudFront のアクセスログをパーティション分けして Amazon S3 に保存できるようになるアップグレードがありましたので、既存アプリの構成を変更しました。AWS CloudFormation でデプロイしているので、テンプレートベースで説明します。 作成した構成 以下のように、2つの Amazon CloudFront ディストリビューションのアクセスログを 1つの共用 Amazon S3 バケットに保存する構成です。バケットの中でフォルダ分け (パーティション分け) します。これができないと後々 Amazon Athena での検索が高負荷になってしまいます。 AWS マネジメントコンソールからの設定は簡単で、以下公式ドキュメントの通りです。Amazon CloudFront ディストリビューションのロギング設定画面からできます。従来のロギング設定はコンソール画面上でも Legacy と表示されているので、間違えないかと思います。 標準ログ記録 (v2) を設定する - Amazon CloudFront Amazon CloudFront の標準ログ記録を有効にし、指定した配信先にアクセスログを送信できます。 docs.aws.amazon.com AWS CloudFormation によるデプロイ AWS CloudFormation でデプロイするときは、Amazon CloudFront のリソースとして定義するのではなく、Amazon CloudWatch Logs の設定として定義します。これは、上記ドキュメントにも書いてありましたが Amazon CloudWatch を内部的に使用しているからです。 なお、Amazon CloudFront は本体がバージニア北部リージョンにあるため、AWS CloudFormation でスタックを作成するときにはバージニア北部でテンプレートを流す必要があります。 概念的には以下の図のようになります。 今回の設計では、ログ配信先は共用の Amazon S3 バケットにしたかったので、その定義は 1つになります。 ログソースは Amazon CloudFront ディストリビューションが 2つありますので、定義は 2つになります。ログソースとログ配信先を紐づける定義が必要になるので、やはりそれぞれに必要になります。 AWS CloudFormation テンプレート 実際の例は以下になります。前提として、Amazon CloudFront ディストリビューションは完成していて、ID を知っている状況です。 細かい説明はテンプレート内にコメントします。 AWSTemplateFormatVersion: 2010-09-09 Description: The CloudFormation template that creates CloudFront access logging configurations. You had better delete the stack and create it again if you update this configurations. # ------------------------------------------------------------# # Input Parameters # ------------------------------------------------------------# Parameters: SubName: Type: String Description: System sub name of example. (e.g. prod or test) Default: test MaxLength: 10 MinLength: 1 # 1つ目のCloudFrontのIDをパラメータにしています。 CloudFrontDistributionIdImg: Type: String Description: The CloudFront distribution id for img. Default: XXXXXXXXXXXXX MaxLength: 15 MinLength: 12 # 2つ目のCloudFrontのIDをパラメータにしています。 CloudFrontDistributionIdAppsync: Type: String Description: The CloudFront distribution id for appsync. Default: XXXXXXXXXXXXX MaxLength: 15 MinLength: 12 Resources: # ------------------------------------------------------------# # CloudWatch Logs (for CloudFront) # ------------------------------------------------------------# # ログ配信先の定義です。1つのS3バケットを共用します。フォルダのプレフィックスに cloudfrontAccesslog を設定しています。 # 出力フォーマットは JSON にしていますが、実際には GZIP 圧縮されます。 LogsDeliveryDestination: Type: AWS::Logs::DeliveryDestination Properties: Name: !Sub s3-example-${SubName}-logs DestinationResourceArn: !Sub "arn:aws:s3:::example-${SubName}-logs/cloudfrontAccesslog" OutputFormat: json Tags: - Key: Cost Value: !Sub example-${SubName} # 1つ目のログソース定義です。 LogsDeliverySourceImg: Type: AWS::Logs::DeliverySource Properties: Name: !Sub example-${SubName}-cloudfront-img ResourceArn: !Sub "arn:aws:cloudfront::${AWS::AccountId}:distribution/${CloudFrontDistributionIdImg}" LogType: ACCESS_LOGS Tags: - Key: Cost Value: !Sub example-${SubName} # 1つ目のログソース、ログ配信先の紐づけ定義です。 LogsDeliveryImg: Type: AWS::Logs::Delivery Properties: DeliverySourceName: !Sub example-${SubName}-cloudfront-img DeliveryDestinationArn: !GetAtt LogsDeliveryDestination.Arn # 記録する項目はデフォルトです。 RecordFields: - timestamp - DistributionId - date - time - x-edge-location - sc-bytes - c-ip - cs-method - cs(Host) - cs-uri-stem - sc-status - cs(Referer) - cs(User-Agent) - cs-uri-query - cs(Cookie) - x-edge-result-type - x-edge-request-id - x-host-header - cs-protocol - cs-bytes - time-taken - x-forwarded-for - ssl-protocol - ssl-cipher - x-edge-response-result-type - cs-protocol-version - fle-status - fle-encrypted-fields - c-port - time-to-first-byte - x-edge-detailed-result-type - sc-content-type - sc-content-len - sc-range-start - sc-range-end - timestamp(ms) - origin-fbl - origin-lbl - asn # ここで年月日と時間でパーティション分けしています。 S3SuffixPath: img/{yyyy}/{MM}/{dd}/{HH} S3EnableHiveCompatiblePath: false Tags: - Key: Cost Value: !Sub example-${SubName} DependsOn: - LogsDeliveryDestination - LogsDeliverySourceImg # 2つ目のログソース定義です。 LogsDeliverySourceAppsync: Type: AWS::Logs::DeliverySource Properties: Name: !Sub example-${SubName}-cloudfront-appsync ResourceArn: !Sub "arn:aws:cloudfront::${AWS::AccountId}:distribution/${CloudFrontDistributionIdAppsync}" LogType: ACCESS_LOGS Tags: - Key: Cost Value: !Sub example-${SubName} # 2つ目のログソース、ログ配信先定義です。基本的な設定は1つ目と全く同じです。 LogsDeliveryAppsync: Type: AWS::Logs::Delivery Properties: DeliverySourceName: !Sub example-${SubName}-cloudfront-appsync DeliveryDestinationArn: !GetAtt LogsDeliveryDestination.Arn RecordFields: - timestamp - DistributionId - date - time - x-edge-location - sc-bytes - c-ip - cs-method - cs(Host) - cs-uri-stem - sc-status - cs(Referer) - cs(User-Agent) - cs-uri-query - cs(Cookie) - x-edge-result-type - x-edge-request-id - x-host-header - cs-protocol - cs-bytes - time-taken - x-forwarded-for - ssl-protocol - ssl-cipher - x-edge-response-result-type - cs-protocol-version - fle-status - fle-encrypted-fields - c-port - time-to-first-byte - x-edge-detailed-result-type - sc-content-type - sc-content-len - sc-range-start - sc-range-end - timestamp(ms) - origin-fbl - origin-lbl - asn S3SuffixPath: appsync/{yyyy}/{MM}/{dd}/{HH} S3EnableHiveCompatiblePath: false Tags: - Key: Cost Value: !Sub example-${SubName} # 1つ目のロギング設定が完了していないのに2つ目をデプロイしようとするとエラーになります。 # そのため DependsOn を使用して1つ目の設定が完成後に2つ目をデプロイするよう制御しています。 DependsOn: - LogsDeliverySourceAppsync - LogsDeliveryImg   また、本件の構成ではログ配信先 Amazon S3 バケットに以下のバケットポリシーが必要です。 S3BucketLogs: Type: AWS::S3::Bucket Properties: BucketName: !Sub example-${SubName}-logs OwnershipControls: Rules: - ObjectOwnership: BucketOwnerEnforced PublicAccessBlockConfiguration: BlockPublicAcls: true BlockPublicPolicy: true IgnorePublicAcls: true RestrictPublicBuckets: true Tags: - Key: Cost Value: !Sub example-${SubName} S3BucketPolicyLogs: Type: AWS::S3::BucketPolicy Properties: Bucket: !Ref S3BucketLogs PolicyDocument: Version: "2012-10-17" Statement: - Effect: Allow Action: s3:PutObject Principal: Service: delivery.logs.amazonaws.com Resource: !Sub "${S3BucketLogs.Arn}/*" Condition: StringEquals: aws:SourceAccount: !Ref AWS::AccountId s3:x-amz-acl: bucket-owner-full-control ArnLike: aws:SourceArn: !Sub "arn:aws:logs:us-east-1:${AWS::AccountId}:delivery-source:example-${SubName}-*" 注意事項 繰り返しになりますが、AWS CloudFormation テンプレートはバージニア北部リージョン (us-east-1) で実行します。 今回使用している AWS CloudFormation のログ配信先リソース定義 AWS::Logs::DeliveryDestination は、単純に変更しようとすると Name を変更しなさい、というエラーが発生します。なので変更をかける都度、Name を動的に変更したいのですが AWS CloudFormation テンプレートの記述のみでは実現できないので、もし変更する際には一度スタックを削除する方が確実です。カスタムリソースで AWS Lambda 関数と組み合わせたり、CI/CD ツールの機能や CDK とかであれば実現は可能と考えます。 また、ログソースと配信先を紐づける定義 AWS::Logs::Delivery は同じ種類のログ配信 (S3 なら S3、Firehose なら Firehose) を 1つのログソースに複数設定できないので、AWS CloudFormation で変更をかけようとするとこれまたエラーになります。上述、一度スタックを削除した方が確実と申し上げたのはそのような理由もあります。これらの課題は AWS さんによる今後の改善を期待します。 従来、Amazon CloudFront から Amazon S3 にロギングするときには、対象の Amazon S3 バケットに ACL が必要でした。新しいロギングではそれが不要になり、代わりにバケットポリシーが必要になっています。既存のロギング用バケットに AWS CloudFormation による変更をかける際には、先に ACL を手動削除しないとエラーになることがあります。 まとめ いかがでしたでしょうか？ なんとなく、今後 AWS リソースのロギング設定は今回のように Amazon CloudWatch Logs 側での設定に集約されていくのかな？と感じました。実際、イベントトリガーのアクションについては Amazon EventBridge が主流になっていますし、ロギングもそうなるのかな、という想像です。 本記事が皆様のお役に立てれば幸いです。

こんにちは、ひるたんぬです。 GWも終わり、しばらくは祝日のない日が続きますね。 今年のGWはいわゆる「飛び石連休」でした。カレンダーを眺めているとふと気になったのですが、なぜ、日曜日の祝日は振替休日となるのに、土曜日の祝日は振り替えてくれないのでしょうか…（今回のGWですと、5月3日の憲法記念日ですね。） とある日の衆議院議会でも取り上げられていました。（質問答弁内容は こちらから ） 関連法令を調べてみると、「国民の祝日に関する法律」にて以下のように定められていました。 「国民の祝日」が 日曜日に当たるとき は、その日後においてその日に最も近い「国民の祝日」でない日を休日とする。 引用：e-gov 法令検索「 国民の祝日に関する法律（昭和二十三年法律第百七十八号） 」 この法律が改正され、土曜日・日曜日に当たるとき…と変わる日を祈っております。 なお、弊社では土曜日が祝日に当たるときは、翌週月曜日を「一斉有給休暇取得日」と定めております。 参考： SCSK株式会社 「弊社の一斉有給休暇取得日のお知らせ（2025年度）」 さて、今回は少し局所的な内容についてご紹介したいと思います。 困ったこと Amazon WorkSpacesにてWindows OSを利用していたところ、キーボードが英字配列のキーボードとして認識されていました。 今回の構成 今回のWorkSpaces周りの設定は以下のようになっています。 後述しますが、今回は「ローカル管理者の設定」がミソでした。 ディレクトリ：Simple AD メンテナンスモード：無効 ローカル管理者の設定：無効 アクセスコントロール：Windowsの信頼されたデバイスのみ WorkSpaces タイプ：Personal バンドル：Standard with Windows 10 (Server 2022 based) プロトコル：DCV （WSP） 言語：Japanese 実行モード：常にオン（自動停止も同様でした） 接続方法 Amazon WorkSpacesクライアントアプリケーション バージョン：5.26.2.5308 接続元OS：Windows 11 23H2 やってみたこと 公式ドキュメントの確認 まずは、公式の回答を確認します。 WorkSpaces の言語とキーボードの設定 - Amazon WorkSpaces Amazon WorkSpaces で言語固有のキーボードを使用する方法を説明します。 docs.aws.amazon.com 上記に則り設定画面を参照しますが、肝心なキーボードレイアウトの変更画面が表示されません。 他の多くのサイトも同様の解決策を提示していたので、これは困ったものです。。 他のサイトを確認 他の解決策を確認したところ、デバイスマネージャーからキーボードのドライバーを変更している事例がありました。 Amazon WorkSpaces Windows 10 でキー配列を 106( 日本語 ) に設定する みなさん、WorkSpaces 使ってますか？ 私はあまり使わないのですが、最近、案件ベースで需要がでてきています。 オンプレでも EC2 上でもいいのですが、既存の AD に参加して使うケースが増えてます。 AD Co ... cpu100per.aminchu.net こちらも試してみましたが、私の環境では再起動すると元のドライバーに戻ってしまい、うまく設定ができませんでした。 また、設定作業を進めるうえで警告メッセージが表示されるのは少しいやな感じがしたため、この策の深堀りはやめました。 設定の見直し ここで、一度WorkSpacesの構成に立ち返ってみます。 今回は使用者に過大な操作権限を付与したくないため、「ローカル管理者」は無効、つまり接続先のユーザは「標準ユーザー」ということになります。 そのため、「標準ユーザーではキーボードレイアウトの変更ができない？」という仮説を立てて調査をしました。 すると、この仮説が正しいであろうことが判明しました。 Redirecting answers.microsoft.com 英語キーボードを日本語環境で使いこなすために必須の設定とは？ 事例詳細｜つなweB つなweb運営担当者が更新する詳細ページです。 tsunaweb.book.mynavi.jp そのため、この説を立証するべく、実際に操作してみます。 解決策 まずは、通常通りWorkSpacesに接続します。 このときのユーザーは先述の通り、管理者権限を持たないユーザーです。 次に、管理者アカウントへの切り替えを実行します。 WorkSpacesのクライアントアプリケーションから「表示」→「Ctrl + Alt + Delete で送信」をクリックします。 ユーザーの切り替えをクリックします。 もう一度「Ctrl + Alt + Delete で送信」をした後にサインイン画面が出るので、左下「他のユーザー」をクリックします。 ユーザー名とパスワードを入力します。 パスワードはディレクトリ管理者のパスワードです。 ユーザーの前に、ドメイン名を必ず入力し、ドメイン管理者としてサインインをしてください。 入力をしないと、ローカル管理者として認識されます。 ここまでできたら、後は公式ドキュメントに従い、キーボードレイアウト変更の画面まで進みます。 すると… レイアウト変更できるようになりました！🎉 後はレイアウトを変更し、WorkSpacesを再起動すれば設定が反映されます。 まとめと小言 今回は「ローカル管理者」が無効となっているWorkSpacesの環境において、アカウントの切り替えを実行することによりキーボードレイアウトを変更できる手順をご紹介しました。 バンドルでJapaneseを選んでいるので、最初から日本語キーボードになっていると嬉しいのですが… もしくは、私が英語配列のキーボードを使用すれば万事解決ですかね！

こんにちは。SCSKの坂木です。 今回はZabbixのcount関数を使った複雑な条件のログ監視を行う方法をご紹介します。 ログ監視は、例えば「”ERROR”という文字列が含まれる」「イベントIDが”777″」などシンプルな条件なら簡単に作成できますよね。 しかし、 5 分間で5回”ERROR”という文字列が含まれる といった条件はパッと作成できますか？ さらには、 5分間で 連続で 5回”ERROR”という文字列が含まれる といったように、「連続で」という条件がつくとさらに頭を悩ませるのではないでしょうか。 そこで今回は、このような条件式を作成できる count関数を用いたログ監視 について紹介していきます。   ログ監視 Linuxのログは、以下のアイテムキーで取得できます。 アイテムキー： log[監視するファイル名] 以下は、ログ監視のアイテム設定画像です。今回の場合、監視対象ファイルは/var/log/zabbix/testlogです。   複雑なログ監視のやり方 countを用いた監視方法① 監視対象ファイルにおいて、 評価期間のうちに〇回以上”検知文字列”が含まれる というトリガー条件式は以下の通りです。ちなみに、”検知文字列”では グローバル正規表現 は利用できないため、条件式に直接検知文字列を記載する必要があります。 障害の条件式： count([/ホスト名/アイテムキー],評価期間, ,”検知文字列”)>=〇   では、/var/log/zabbix/testlogにおいて、 5分間のうちに5回以上”ERROR”の文字列が含まれる といった条件式を考えてみます。 上記の式に当てはめて、作成してみましょう。 実際に/var/log/zabbix/testlogにログを書き込んでみます。 5分間のうちに、ERRORが5つ書き込まれているため、障害として検知しました。   countを用いた監視方法② 続いて、/var/log/zabbix/testlogにおいて、 5分間のうちに連続で5回以上”ERROR”の文字列が含まれる といった条件式を考えてみます。 まず、この 連続5回以上 という条件式は以下の通りです。 障害の条件式： count([/ホスト名/アイテムキー],#5, ,”文字列”)>=5 評価期間を、<数字> → #<数字>とすることで、時間 → 回数へ変更できます。   先ほどの条件を組み合わせると、こちらのようにトリガーを設定できます。andを使った条件式について詳しく知りたい方は こちら 。   実際に/var/log/zabbix/testlogにログを書き込んでみます。5分以内に連続せず5回以上”ERROR”を書き込むパターンと、5分以内に連続して5回以上”ERROR”を書き込むパターンを検証します。 5分以内に連続せず5回以上”ERROR”を書き込むパターン 5分以内に、”ERROR”を6個ファイルに書き込んでみました。結果、5回連続という条件は満たしていないため、障害として検知しませんでした。 5分以内に連続して5回以上”ERROR”を書き込むパターン 5分以内に、”ERROR”を連続して5個ファイルに書き込みました。結果、両方の条件を満たしているため障害として検知しました。   まとめ 本ブログでは、Zabbixの count関数を使った複雑な条件のログ監視 について紹介しました。 countを用いることで、ログ監視において特定の文字列を複数回検知したときに障害として検知できることを紹介しました。 この記事を参考にぜひ試してみてください！   Zabbixで複雑なログ監視を実装する方法シリーズファンの方へ 以下のブログでは、and/orを使った複合条件や除外条件について詳しく説明しています。 Zabbixで複雑なログ監視を実装する方法 ZabbixでLinux、Windowsのログ監視を行う方法と、複雑な条件のログ監視を行うときの条件式の書き方をご紹介します。 blog.usize-tech.com 2024.08.26

こんにちは。角田です。 先日、SASEについて初心者向けの解説記事を投稿しました。 【SASE簡単解説】SASEとは？ 初心者が1から解説 「近年バズワードとして注目されていることは知っているが、調べてみてもよく分からない。」これを機にSASEを理解したい、という方に向けて、超初心者向けの「SASEとは？」を1から丁寧に説明していきたいと思います。 blog.usize-tech.com 2025.03.24 今回はその続編として、初心者向け「SASEとは？」の第2弾をお届けします。 前回はSASEの概要やメリットについて触れましたが、今回は「いざSASEを導入しよう」となった際に気になるポイントについて、以下2つのテーマでご説明します。 SASE導入における懸念点・ハードル SASE導入を検討しやすいタイミング   SASE導入における懸念点・ハードル SASE導入にあたっては、多くの企業様から以下のような懸念や質問をいただきます。 ① 結局、現行ネットワークより高額になるのでは？ ② ネットワークをクラウドに移行しても、可用性やセキュリティは問題ないの？ ③ オンプレミスではなくなると可視性やコントロールが失われるのでは？ ④ 運用が変わるので使いこなせるか不安。学習コストもかかるのでは？ ここでは、それぞれの懸念に対して「実際のところはどうなの？」を丁寧に解説していきます。 ①結局、現行ネットワークより高額になるのでは？ コスト面は、多くの方が最初に気にされるポイントです。 よくあるご相談としては、 「今のネットワークから追加費用がかかるのでは？」 、 「クラウドは毎月(または毎年)の課金なので、長い目で見ると高額になるのでは？」 というものになります。 結論として、上記はどちらも誤解がありますし、むしろSASEを導入することで、 現行環境よりコストが削減できる 場合も数多くあります。 それぞれ、詳細を解説していきたいと思います。 「今のネットワークから追加費用がかかるのでは？」　に回答！ まず、SASEは現行ネットワークに追加導入するものではなく、 現行環境からリプレイスする(置き換わる)もの です。 SASEの費用は新たに発生しますが、その分、置き換わる既存機器やサービスの費用は削減できます。 つまり、基本的に「現行費用に加えて更にコストがかかってしまう」ことはありません。 SASE導入により削減可能な機器/サービスの例： 通信回線(専用線/閉域網)、通信機器(ルータ)、UTM、ファイアウォール、Proxy、VPN、 アンチマルウェアやIPS/IDS、CASBなどの各種セキュリティ製品   「クラウドは毎月/毎年コストの課金なので、長い目で見ると高額になるのでは？」　に回答！ 「クラウドサービスで毎月/毎年コストが発生する」ということ自体は、誤りではありません。 直感的には、一度購入すればその後支払いのないオンプレミスや買い切り型のほうがお得なイメージがあるかもしれません。 ただ、SASEは利用状況に応じて柔軟に帯域や機能を増減することが可能です。（使う分だけ都度契約・都度課金） つまり、一度購入すると保有し続けなければいけないオンプレミスと比べ、 コストの最適化 ができます。 また、SASEを導入すると、一般的に導入前と比較して ネットワーク/セキュリティの運用・保守にかかる負担は大幅に低減 されます。 ※例えば、オンプレミスのファイアウォールやVPN装置は頻繁に脆弱性が公表されるため、パッチ適応に相当の作業が必要となりますが、SASEではこのような作業が必要なくなります。 他にも、オンプレミス環境であれば発生する 機器リプレイス時の作業費は、SASEでは必要なくなります。 キャッシュとして見えないので分かりづらいですが、これらの人件費・運用/作業外注費(コスト)は削減できるということです。 コスト比較の際には、ぜひ オンプレミス製品の償却年数や運用・保守・リプレイス作業のコスト も加味し、整理していただければと思います。 オンプレミス/SASEにおけるコストのイメージ ※あくまでコスト形態を比較するためのイメージ図です。 補足：財務的な話になりますが、オンプレミスの場合は資産として計上される(固定資産税の対象となることもある)各種機器も、クラウド(SASE)では費用として計上できる(固定資産税を支払ったりする必要がない)ことも特徴です。 ② ネットワークをクラウドに移行しても、可用性やセキュリティは問題ないの？ こちらもコストと並んでよくいただく懸念点・ご質問となりますが、過度に心配する必要はありません。 まず、可用性についてですが、多くのSASEベンダはサービスレベル契約(SLA)が明示されています。 ※ファイブ・ナイン（99.999%）をSLAとしているSASEもあります。 SASEはインターネット回線を用いたサービスとなるため、その点はキャリア閉域網のほうが安心感があるかもしれませんが、 純粋な SASE(ベンダの持つWANバックボーン)の可用性は専用線と遜色ありません。 また、特に 日本はインターネット回線の品質が良く、切断もほとんありません。 可用性を重要視する場合は、インターネット回線を冗長化する構成も可能です。これにより閉域網と同等の可用性を実現できます。 セキュリティについても、クラウドの特性上「インターネットを使うので安全でない」と思われがちですが、これは誤解です。 SASEは 「インターネット回線を用いて、SASEベンダのセキュアなネットワーク網に接続する」仕組み となりますので、企業の通信がそのままインターネットに出てしまうことはありません。 また、SASEベンダが保持する各種データセンター・機器は厳重に管理・運用されているため、通常は自社での管理よりも安心です。 むしろ、各種セキュリティ機能を一元管理できるため、SASE導入は企業のセキュリティレベル向上に繋がります。 ③ オンプレミスではなくなると可視性やコントロールが失われるのでは？ 確かに、オンプレミス機器は自社にあり、目に見え、触れて確かめられる安心感があるため、クラウドに移行すると見えなくなる・制御できなくなる、という印象を持たれる方は多いです。 しかし、実際は逆です。 SASEではむしろ可視性とコントロールは向上します 。 SASEを導入すると、全ての通信がSASEを経由することとなり、より広範囲かつリアルタイムでの可視化・制御が可能になるためです。 オンプレでは見えにくかった部分（例：社外デバイスやクラウドサービスの利用状況など）も一元化し把握できるようになります。 例えばセキュリティインシデントが発生した際にも、複数機器のログを突き合わせて確認したり、機器ごとに対処する必要はありません。 ログはSASEで一元管理されており、ネットワーク設定変更などの対処も、SAESの中で完結することができるのです。 ※つまり、可視性とコントロールが向上しているということになります。 ④ 運用が変わるので使いこなせるか不安。学習コストもかかるのでは？ これまでオンプレミス中心だったネットワーク環境からSASEへと切り替わると、運用に大きな変化があるのは事実です。 そのため、「慣れない仕組みを使いこなせるか」という不安を感じる方も多くいらっしゃいます。 ですが、SASEはもともと「バラバラだったネットワーク・セキュリティ機器やサービスを統合する」ための仕組みです。 つまり 「新しくて難しくなる」というよりも「分散していたものが纏まり、管理しやすくなる」 と考えるほうが本質的です。 加えて、SASEは直感的なUIが多く、インフラ運用経験が浅い方でも扱いやすいよう設計されていますので、新たなメンバーが加入した際の教育や引き継ぎもとても簡単に行えます。 SASE導入により一時的な負荷や学習コストが発生するのは確かですが、 長期的には運用の負荷が軽減され、今より使いやすく、管理しやすい環境になるはずです。   SASE導入を検討しやすいタイミング 「SASEについて理解し、メリットを知り、不安要素も払拭された」というところで、次に「では、いつSASEを導入すればよいか？」という点も気になります。 SASEで現行よりコスト削減ができる場合も多いですし、スモールスタートも可能ではありますが、全社SASEとする場合は大きな投資にもなり得ます。 どのタイミングであればSASE導入を検討しやすいのか 、パターン別で以下のように分類してみました。それぞれ解説していきます。 No パターン 具体的な場面（例） ① ネットワークやセキュリティ機器の更改 ・WANの見直し、更改 ・VPN装置の見直し、機器の更改 ・Proxyサーバの見直し、サーバ機器の更改 ② 拠点の増設、グローバル展開 ・グローバル拠点展開/グローバルなネットワーク接続 ・企業買収(M&A) ③ クラウド化への適応 ・パブリッククラウドへのシステム移行(AWS、Azureなど) ・SaaSの急激な利用増 ④ その他のタイミング ・セキュリティインシデントへの対応、セキュリティの見直し ①ネットワークやセキュリティ機器の更改 冒頭で、SASEは既存機器のリプレース(置き換え)であると説明しました。 そのため、当たり前だと思われるかもしれませんが、 「機器の更新タイミング(EOLや契約更新など)」でSASEを導入するのが最も自然で予算化もしやすい です。 同様の機器を買い替える代わりにSASEを導入することで、無駄なく既存ネットワークの課題を解消する、というイメージとなります。 特に専用線やWANの更改タイミングは、全社SASE導入にもってこいのタイミングです。 一方で、昨今は リモートアクセス(VPNや仮想デスクトップなど)やProxyの切替にSASEを選択 され、徐々にWAN(拠点間通信)もSASEへ移行していく、という段階的な導入をされる企業が非常に増えています。 ※SSE(Secure Access Service Edge) → SASE(Secure Service Edge)という移行プロセスになります。 これは、在宅勤務やリモートワークの急速な普及に伴い発生した機器更改の機会を、SASE導入に繋げている好例です。 専用線やWANの更改だけに限らず、このタイミングの導入にもぜひ着目してみてください。 　SSE → SASE の移行イメージ　 ②拠点の増設、グローバル展開 事務所の新設や海外拠点の立ち上げ も、SASE導入の好機です。 特に海外拠点の場合は、個別の専用線調達、現地法令への対応、回線品質など、考慮事項が非常に多くなります。 SASEであれば、こうした煩雑さを最小限に抑え、短期間でセキュアなネットワークを展開できるため、手段として非常に有効です。 たとえば、まずは「新規拠点＋本社」だけSASEを導入し、そこから段階的に広げるというスモールスタートも可能です。 拠点新設、グローバル展開の予定がある場合は、ぜひスモールスタートも視野に入れてご検討ください。 ③クラウド化への適応 近年、開発スピードの向上、運用負荷の軽減、コスト最適化などを目的として、 システム全体のクラウド化 を推進する企業が非常に増えてきました。 自社がそのような方向性を目指している場合は、SASE導入のタイミングにも適しています。 サーバやアプリケーションのクラウド化に合わせて、ネットワーク・セキュリティもクラウド(SASE)化するというイメージです。 クラウドベースのアーキテクチャであるSASEは、IaaS、PaaS、SaaS問わずクラウドとの相性が良いです。 逆に、従来の境界型ネットワークの仕組みは、クラウド活用のボトルネックになることが多いです。 境界型ネットワークがクラウド活用のボトルネックとなる例： ・トラフィックがすべて本社/データセンターを経由するため、クラウド利用(インターネット利用)増加によりレスポンスが悪化する ・IaaS、SaaSごとのアクセス制御・ログ管理が煩雑化する ・拠点、本社/データセンター、クラウド間を個別最適で接続するため、運用が複雑化する SASEのメリットでもお話しましたが、SASEを導入すると上記のようなボトルネックは無くなります。 つまり、 SASEの導入はネットワークに関するボトルネックを排除し、企業のクラウド化を更に加速させる ことが出来るのです。 ④その他の導入タイミング 上記の通り、導入機会としてよくあるパターンを解説しましたが、もちろん、シンプルにSASEのメリットに魅力を感じ、導入に踏み切る企業様も数多くいらっしゃいます。 また、ネガティブな導入機会なので取り上げませんでしたが、「セキュリティインシデントが発生し、再発防止策を検討・実施する必要がある」という状況で早急にSASEを導入される方もいらっしゃいます。   「SASEには魅力を感じるけど自社でどう導入できるかまだイメージが湧かない」という方は、ぜひ一度弊社までご相談ください。 ご一緒にSASE導入の方向性について整理させていただければと思います。   おわりに いかがでしたでしょうか？ 今回は第1弾から少し踏み込んで、「SASE導入のよくある懸念点とその実態」、「SASE導入を検討しやすいタイミング」について説明しました。 詳しくない方にも伝わるよう、できるだけ分かりやすく解説したつもりですが、前回よりも踏み込んだ分、少し難しい内容もあったかもしれません。 イマイチ理解できなかった部分は、ぜひご自身でも深堀りしてみてください。 SCSKでは、長年に渡り SASEに関するセミナーを定期開催 しています。 直近では 2025/5/28(水) に、 世界初のSASEプラットフォームである「Cato(ケイト)クラウド」の簡単解説セミナー を開催します。 (オンラインセミナー) 世界初のSASE　Cato(ケイト)クラウドとは？　簡単解説セミナー 本セミナーでは、SASEの基本的な概念やその必要性・重要性から、世界初のSASEプラットフォームである「Cato（ケイト）クラウド」の特徴・強みについてご説明をいたします。また、セミナーの中では実際にCatoクラウドのデモをご覧いただけます... www.scsk.jp SASE全般について解説するパートもありますので、ご興味がある方は、ぜひご参加ください。 SASEはまだまだ知名度が低いですが、システム全体がどんどんクラウド化、モダナイゼーションしていく現代においては、とてもメリットがあるものだと感じています。 本記事が、皆さんのSASE導入や、SASEの更なる普及の一助になれば嬉しく思います。

初めまして。 SCSKの庄司です。 今回は、ServiceNowで「レコードのどの部分が、いつ、誰によって更新されたのか」の情報を取得・確認する方法を紹介していきます。 本記事は執筆時点（2025年5月）の情報になります。最新の内容は製品ドキュメントを参考にしてください。   事前準備：監査を有効化しよう ServiceNowは裏で「誰が何を変更したか」を記録する機能があります。 それが「監査ログ」です。 監査ログレコードは監査対象レコードの各フィールドの更新ごとに以下のような情報を自動で保存してくれます。 ・更新日時 ・対象フィールド名 ・更新前後の値 ・更新者　等 ただし最初からすべてのテーブルが監査対象になっているわけではありません。 まずは、特定のテーブルを監査対象に設定する方法を確認しましょう。 監査対象テーブルの設定手順 ①[システム定義]>[ディクショナリ]に移動 ②監査対象とするテーブルを検索し、列名=空欄、タイプ=コレクションのレコードを探す ③該当レコードの「監査」をTRUEに変更 テーブル丸ごとではなく特定の列のみを確認したい場合は、手順②でテーブルのレコードではなく対象としたい列のレコードを探し、「監査」をTRUEにしてください。 上記の手順を実施することでテーブルの監査ログ取得が可能となります。 ただし、手順実施以前のレコードの更新は取得できないことには注意が必要です。   監査ログを見てみよう さて、レコードの内容を更新して監査ログに更新内容がしっかりとキャッチされてるか見てみましょう。 今回はユーザー(sys_user)テーブルを監査対象としたので、ユーザーテーブルの任意のレコードの値(メール、部門、Web サービスへのアクセスのみ)を変更します。 変更前 変更後 監査ログの確認手順 ①Filter Navigatorに [sys_audit.list] を入力して監査ログテーブルにアクセス ②テーブル名やフィールド名、レコードのSys IDでフィルタをかけて検索します。 ③該当するレコードを探し、開きます。 監査ログレコードの各種列は以下内容を格納しています。 作成日時 監査対象レコードが更新された日時 テーブル名 監査対象レコードのテーブル フィールド名 監査対象レコードの更新されたフィールド ドキュメントキー 監査対象レコードのsysID ユーザー 監査対象レコードに更新をかけたユーザー 以前の値 監査対象レコードの該当フィールドの更新以前の値 新しい値 監査対象レコードの該当フィールドの更新後の値 試しにユーザーテーブルのたとえば「メール」フィールドを見てみると、先ほど更新した内容の更新日時、変更前後の値、更新者などがきちんと記録されています。 フォームコンテキストメニューから履歴を見る 一方で、わざわざ監査ログテーブルに遷移せずとも対象のレコードのフォーム画面から更新内容を確認する方法もありますので、そちらの方法も紹介します。 1.カレンダー形式で履歴を確認 ①対象のレコードのフォームを開く ②フォームコンテキストメニューから、[履歴]>[カレンダー]を選択 ③遷移先の「ユーザー履歴詳細」ページでは以下のような特徴があります。 ・レコードの更新履歴がカレンダー形式で表示されます ・各日付の更新者や更新内容がひと目で確認できます ・カレンダー上部に、フィールド名や更新前後の値も表示されます 2.リスト形式で履歴を確認 ①対象のレコードのフォームを開く ②フォームコンテキストメニューから、[履歴]>[リスト]を選択 ③遷移先の「レコード履歴」ページでは以下のような特徴があります。 ・フィールドごとのリスト形式で表示されます ・リスト上からはフィールド名や最終更新日時、最終更新者、更新前後の値などを確認することが可能です ・各レコードを押下することで、そのレコードに応じたフィールドの履歴を表示することができます    まとめ ServiceNowでは監査ログ機能を活用することで、「いつ・誰が・どこを・どう変更したのか」をしっかり追跡できます。 設定もシンプルなので、ぜひ日常の業務等に役立ててみてください。

こんにちは。SCSKの北川です。 今回はServiceNowの更新セット移送についてまとめてみました。 環境間の移送に不安がある方の参考になれば嬉しいです。 本記事は執筆時点（2025年4月）の情報です。最新の情報は製品ドキュメントを参考にしてください。 更新セットとは 更新セットは、カスタマイズや変更を他の環境へ移行するための機能です。 開発環境で行った変更を本番環境などへ反映させる際に使用されます。 更新セットの移送手順 移送対象の更新セットを選択 System Update Sets>Local Update Sets より移送したい更新セットを選択します。 自動で更新セットに記録されないテーブルがあるため、変更内容がすべてCustomer Updatesに含まれているか確認しましょう。 ステータスの更新 Stateを「In progress」から「Complete」に更新します。 XMLにエクスポート 保存後、Related Links[Export to XML]を押下します。 押下後、XMLファイルがダウンロードされていることを確認します。 移送先にインポート 移送先の環境にログインし、System Update Sets>Retrieved Update Sets より移送したい更新セットを選択します。 Related Links[Import Update Set from XML]を押下します。 エクスポートしたXMLファイルを選択し、[Upload]を押下します。 Retrieved Update Setsに移送対象の更新セットが追加されました。 プレビュー～コミット 更新セットを選択し、[Preview Update Set]を押下します。 Stateが「Previewed」に更新されました。 ※エラーの場合は対象レコードを確認・対応後に再度プレビューしてください。 [Commit Update Set]を押下します。 Stateが「Committed」に更新されました。 以上がServiceNowにおける更新セットの移送手順です。 コミット後は、移送内容が正しく反映されているかご確認ください。 まとめ 今回はServiceNowの更新セット移送についてご紹介しました。 初めて作業する方にも役立つ内容になっていれば嬉しいです。

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

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

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

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

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

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

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

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

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

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

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

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

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