本記事は 夏休みクラウド自由研究 8/5付の記事です 。 こんにちは。ひるたんぬです。 先日この暑さに身体がやられてしまい、休みのほとんどを寝て過ごしました… 何もせずにただひたすら横になることに最初は罪悪感を感じておりましたが、休みの過ごし方は人それぞれ。たまには（なんならいつも？）こんな休日があってもいいですね。休むことも大切です(自戒)。皆さんは休日どのように過ごされていますか？ ［新連載］ファストリ柳井氏の改心　猛烈一転「休みを取らないのは罪悪」 かつて、無休で猛烈に働いていた経営者も、年3回の長期休暇を欠かさなくなった。「休みを取らないことは罪悪」「日本人はもっと長期の休みを取るべきだ」――。ファーストリテイリング柳井正会長兼社長に休みとの向き合い方を聞いた。 business.nikkei.com さて、今回の企画名が「夏休みクラウド自由研究」でしたので、プレビュー版としてリリースされたばかりのAWS App Studioを使ってカンバンボードのプロジェクト管理ツールを作ってみようと思います。 AWS App Studioとは？ 約一ヶ月ほど前の7月10日にパブリックプレビューとなった新しいサービスです。 AWS App Studio is a generative AI-powered service that uses natural language to build enterprise-grade applications, empowering a new set of builders to create applications in minutes . With App Studio, technical professionals without deep software development skills, such as IT project managers, data engineers, and enterprise architects, can quickly develop business applications tailored to their organization’s needs . 引用：AWS 「 AWS App Studio 」 要約すると、「生成AIを活用することで、ソフトウェア開発などの専門的な知識がなくとも自身の組織の要望に沿ったアプリケーションを短時間で生成できるサービス」と言ったところでしょうか。 開発領域においても生成AIを利用したサービスが次々とリリースされていますね！ 料金につきましては、開発やテストなどをする分には無料で利用できますが、作成したアプリケーションを公開した場合、その時間に応じて料金が発生するようです。¹ ¹ アプリケーションによって動作するサービスの利用料金が別途発生します。 Generative AI–powered, low-code application builder – AWS App Studio Pricing – AWS View the pricing information for AWS App Studio—a generative AI–powered, low-code application building service. Start bu... aws.amazon.com   使い方 インスタンスの作成 マネジメントコンソールにて「AWS App Studio」と検索すると出てきます。 現在はオレゴンリージョンでのみ提供されているため、下記画面が表示された場合は、リージョンを切り替えてください。 App Studioの画面が表示されるので、セットアップの「開始」を押下します。 App Studioのインスタンス作成画面に移るので、表示に従って次のものを用意します。 IAM Identity Center Account Amazon CodeCatalystスペース CodeCatalystについては私は以前スペースを作成していたため、そちらを流用しました。 スペースの作成方法や利用方法につきましては、以下の記事をご参照ください。 Amazon CodeCatalyst で AWS Lambda の CI/CD 環境を構築する 2023年4月にGAとなった「CodeCatalyst」を触ってみたので、それについてお話ししようと思います。 blog.usize-tech.com 2024.05.24 また、IAM Identity Center Accountについては作成していなかったため、この画面で作成します。 IAM Identity Center Accountをこの画面で作成すると、オレゴンリージョンで有効化・作成されます。他の任意のリージョンで作成したい場合は、あらかじめ作成したうえで、この画面で選択することも可能です。 管理者グループ・ビルダーグループの名前を設定し、管理者グループユーザーに最低1人のユーザーを追加します。今回は、私一人のみの寂しい開発ですので、管理者グループユーザーにのみユーザー情報を記載しました。 最終的に確認事項にチェックを入れ、「設定」を押下します。 …と思ったのですが、「設定」ボタンがグレーアウトしたまま押すことができませんでした。 改めて見てみたところ、権限上何かが読み取れていなかった（何が読み取れていなかったのかは見落としました…）ので、それが原因かもしれません。 そのため、あらかじめIAM Identity Center Accountを作成し、割り当てをしたうえで「設定」を押下します。 するとセットアップが始まります…が、なんとこれ、最大で30分かかると書いてありますね。 アイスでも食べながら大人しく待つことにします。この季節のアイスはたまらないですよねぇ…冬にこたつに入りながら食べるアイスもまた良いのですが。 別画面に遷移しても問題はありません。進捗はApp Studioトップ画面の「設定に戻る」から確認できます。 私の環境では、15分ほどで設定が完了したという画面に切り替わりました。 そうしましたら、「App Studio に移動」を押下します。 App Studioにサインイン 最初に以下のような画面が表示されます。なんというか…CodeCatalystに似ていますね。 ここから「Sign in」を押下します。 ここでは先程のIAM Identity Center Accountで登録したユーザー名やパスワードを入力し、サインインします。 サインイン後にMFAの追加が求められる場合がありますので、必要に応じて追加してください。 サインインが完了するとApp Studioのトップページが開きます。ここからは英語ですね… アプリを作る 管理者グループでサインインをしている場合、最初に「Admin hub」が表示されているので、左側ペインより「Builder hub」を押下して移動します。 移動後に「CREATE A NEW APP」を押下します。 アプリ名は適当に設定し、アプリの作成方法を選択します。今回は一人ぼっちの開発なので、せめてもの思いでAIを仲間に入れようと思います。（「Generate an app with AI」を選択します。） 次にアプリに含めるデータソースの有無を尋ねられます。ここはオプションの選択項目であり、あとでも設定できるため、今は「Skip」を選択します。 するとセッションの準備が始まり… 1分もしないうちに作成画面が表示されました。 ここでは 自分で一からプロンプトを入力 サンプルのプロンプトを使用（カスタマイズもできる） のどちらかで、AIに命令を与えます。今回は以下の要件を完結に英語で表現して入力を与えてみました。 プロジェクト管理ツールを作りたい カンバンボード形式の見た目 「Backlog」「In progress」「Done」の3つの項目からなる ユーザーはタスクの作成と移動が簡単にできる この情報からAIがアプリケーションの概要を作成してくれるので、内容を確認します。 自身の要件を確認するには「Your requirements」を、実際に作成されるアプリケーションの要件を確認するには「App overview」を確認すると良いと思います。 …すごいですね。拙い文章だったのですが、やりたいことが概ね記載されているように思えます。 ここで、私はタスクに重要度を付与できる機能を与えることを忘れていることに気づいたので、それも追加してみます。 そして、更新後の要件をもう一度確認してみると…きちんと重要度に関する要件が追加されていますね！ 今回はこれで要件を充足していると思うので、「Generate app」を押下しアプリケーションを作成します。しばらくするとアプリケーションが作成された、と表示されるので、「Preview app」もしくは「Edit app」のどちらかを押下します。 今回は「Preview app」を押下し、実際のアプリケーションを見てみようと思います。 アプリケーションの出来栄えは…？ 完成したアプリケーションはこちらです。 カンバンボード形式でタスク一覧を見れる機能と、タスクを新たに追加する機能、タスクを移動させる機能（Backlog→In progress, In progress→Done）が実装されていました。 もちろん既存サービスなどの理想形とはまだまだ差がありますが、たった数文を与えただけでこれだけのアプリケーションができることは驚きました。事前のAIとの対話でもっと要件を具体化する、もしくは編集画面にて自分の思うように画面や処理を変更することができるので、ここは工夫の余地があるなと思いました。 ▼実際の編集画面   おわりに 今回は「自由研究」がテーマでしたので、自分が全く触れていない新しいサービスを体験し、その所感を記事にしました。生成AIとの対話を通して簡単にアプリケーションが作れる一方で、細かいところなどにはまだまだ人間の工夫が必要なのかなというのが正直な感想です。 これからも自身の技術力向上のための取り組みは続けつつ、生成AIと上手に付き合うためのスキルも磨いていきたいなと思った次第です。

本記事は 夏休みクラウド自由研究 8/4付の記事です 。 みなさんこんにちは。 本ブログでは、Prisma Cloudを用いたサービス開発や運営の中で得た知見や、使いこなし方を共有することで、クラウドセキュリティの重要性の認知度を高め、対策レベルを向上させることを目指しています。ただの情報発信ではなく、実際の使用例や失敗から学んだ教訓など、実務に役立つ具体的な内容も提供していきます。 今回は、CWPPについての2つ目の記事として、PrismaCloudのCWPP機能の中核を成すDefender（エージェント）について詳しく解説していきたいと思います。   Prisma CloudのDefenderの機能 Prisma CloudのDefenderは、クラウド環境のセキュリティを強化するためのエージェントです。Defenderはホスト、コンテナ、サーバーレス環境を包括的に保護し、リアルタイムの監視と脅威の防御を提供します。以下にDefenderの具体的な機能を解説します。 1. ランタイム防御 プロセス監視 Defenderは実行中のプロセスをリアルタイムで監視し、不審なプロセスの起動や異常な挙動を検出します。これにより、マルウェアや不正な活動を早期に発見し対応することができます。 ファイルシステム監視 ファイルシステムの変更をリアルタイムで監視し、不審な変更を検出します。例えば、重要なファイルの改ざんや不正なファイルの追加を検知し、アラートを発することが可能です。 ネットワークトラフィック監視 ワークロード間のネットワークトラフィックを監視し、不審な通信や異常なトラフィックパターンを検出します。これにより、例えば情報漏洩に繋がる外部の悪意あるIPアドレスへの通信をブロックすることができます。 2. 脆弱性管理 脆弱性スキャン DefenderはCI/CDパイプラインと連携し、コンテナイメージやホストの脆弱性を詳細にスキャンします。デプロイ前に脆弱性を検出し修正でき、脆弱なイメージからコンテナを起動しないように制御することが可能です。 脆弱性の優先順位付け 公開リスクやリスクスコアに基づいて、最も優先順位の高い脆弱性を特定します。これにより、重要な脆弱性に迅速に対応することができます。 3. 自動応答 自動応答 脅威を検出した際に自動的に対応策を講じます。例えば、感染したコンテナを自動的にターミネートし再作成することで、被害の拡大をリアルタイムに防ぐことができます。 4. コンプライアンス管理 コンプライアンスチェック Defenderは業界標準や内部ポリシーに基づいたコンプライアンスチェックを実行します。コンプライアンス違反を早期に検出し修正することができます。 5. サーバーレスセキュリティ サーバーレス関数の保護 DefenderはAWS Lambda、Azure Functions、Google Cloud Functionsなどのサーバーレス関数を保護します。関数の脆弱性をスキャンし、継続的に監視します。 ランタイム保護 サーバーレス関数の実行中に脆弱性や不審な活動を検出し、リアルタイムで対応します。これにより、サーバーレス環境のセキュリティを強化します。   まとめ Prisma CloudのDefenderは、ランタイム防御、脆弱性管理、自動応答、コンプライアンス管理、サーバーレスセキュリティなど、多岐にわたる機能を備えており、クラウド環境のワークロードに対する包括的なセキュリティ対策を提供します。クラウド環境のセキュリティ対策として、Defenderはもはや必須と言えるでしょう。ただし、エージェントの導入は運用上のデメリットもありますので、その辺りがイメージできるように、次回以降、Defenderのホスト上での動作原理や、エージェントレスとの違いについても詳しく解説していきます。   最後に、当社ではPrismaCloudを用いたマネージドサービスを提供しているので紹介させてもらいます。 ＝＝＝ 【CSPMマネージドサービス SmartOneCloudSecurity】 SmartOneCloudSecurityは、Prisma Cloud を用いたCSPMマネージドサービスです。Prisma Cloud の導入から設定変更まで、弊社技術担当者がお客様のCSPM対策をサポートします。CSPMの導入を検討中の方はもちろん、Prisma Cloud を利用中だけど機能や運用面でもっと上手に活用したい、というような課題をお持ちな方は、お気軽に下記URLからお問い合わせください。Prisma Cloud のPoCの相談も受けています。 New!! CWPPの導入サポートも始めました！ Smart One Cloud Security® パブリッククラウドのセキュリティ設定を診断/監視するマネージドCSPMサービスです。Palo Alto Networks社Prisma Cloud（CSPM機能）を使い易く、簡単に導入いただけます。 www.scsk.jp

本記事は 夏休みクラウド自由研究 8/3付の記事です 。 こんにちは、SCSK齋藤です。 今回は、SQSキューポリシーに明示的な拒否を設定しましたが、考えが甘かったせいで、SQSにアクセスできなくなったお話を書いていきます。 そして、その教訓からIAMのポリシー定義について、再び学びを深めてみたいと思います。 何が起こったか？ SQS→Lambdaへと連携するようなサーバレスアーキテクチャを開発している時に、SQSに次の２点のアクセス制御を実施したいと考えました。 SQSへメッセージを送受信するリソースを、特定のLambdaのみにしたい 人手による運用が入るのを考慮し、マネジメントコンソール経由で全IAMユーザーからのアクセスは許可したい。 そのため、実際に定義したキューポリシーは下記の通りです。 # # ------------------------------------------------------------# # # SQSQueuePolicy # # ------------------------------------------------------------#   SQSPolicy:     Type: AWS::SQS::QueuePolicy     Properties:       Queues:         - !Ref SQS       PolicyDocument:         Version: "2012-10-17"         Statement:           #IAMユーザと必要リソース以外のアクセスを拒否           - Effect: Deny             Principal: "*"             Action: "sqs:*"             Resource: !GetAtt SampleSQS.Arn             Condition:               StringNotEquals:                 aws:UserAgent:                   - aws-internal-console               ArnNotLike:                 aws:SourceArn:                   - !Sub "arn:aws:lambda:*:${AWS::AccountId}:function:sample-lambda-*" 上記ポリシーを設定し、SQSをSAMテンプレートから作成してみましたが、管理者権限を持ったIAMユーザーからでは、マネジメントコンソール上に作成したSQSが表示されません。 なお、CloudShellを開き、SQSのリストをAWS CLIで表示してみたら、リストの一覧には出てきました。 AWS CLI上だけ見えるのも変だと思いながらも、そのままAWS CLIで削除コマンドを実施しましたが、Access Deniedになり、削除できませんでした。 まさしく、八方塞がりな状態でした。。。   暫定対処 上記の状態に陥ったので、ひとまずキューを削除する方法を考えました。 ① 特定のLambdaのみからアクセスできるようにする意図で、キューポリシーを書いていたので、そのLambdaからキューを削除することができないか？ →実際に試してみましたが、こちらもAccess Deniedされてしまいました。。なぜだ。。。。 ② ルートユーザーから削除できないか？ →こちらは成功いたしました。やはり最後の頼みの綱は、ルートユーザーなんだなと感じました。   キューポリシーを振り返る 一旦削除はできたので、改めて定義したキューポリシーの何がいけなかったのかを考察していきます。 ポイントは、２つです。 IAMユーザーからマネジメントコンソールで閲覧させる権限の記述の誤り ポリシーの中の、下記が問題でした。 StringNotEquals:    aws:UserAgent:       - aws-internal-console こちらを書いた意図としては、IAMユーザーがマネジメントコンソール経由でSQSの操作ができるようにするために記載しました。 元々は、PrincipalをNotPrincipalにする下記の記載方式を検討していましたが、NotPrincipal内ではuserに*は使えないとのことで作成ができませんでした。 NotPrincipal: arn:aws:iam::111122223333:user/*   また、事後調査でわかりましたが、下記のようなドキュメントも見つけたので、NotPrincipalとDenyはそもそも相性が悪いんだということもわかりました。 AWS JSON ポリシーの要素: NotPrincipal - AWS Identity and Access Management AWS JSON ポリシー言語の NotPrincipal 要素を定義します。 docs.aws.amazon.com   そのため、チャット式の生成AIに聞いたら、aws:UserAgentを用いた書き方を提案されたので、今回のような書き方をしました。。。 しかし、インターネットで調べてもこのような書き方は出てこないので、嘘情報だったのではと思います。 実際、今回記載した内容は「aws-internal-console」というアプリケーションからのHTTPリクエストという意味になるそうです。 マネジメントコンソール上でHTTPヘッダーを確認しましたが、aws-internal-consoleという情報は出てこなかったです。 これでは、マネジメントコンソールからアクセスできませんね。。。 Denyステートメント内でのLambdaへの権限の記述誤り Lambdaについては、下記のように記載していました。 ArnNotLike:  aws:SourceArn:  - !Sub "arn:aws:lambda:*:${AWS::AccountId}:function:sample-lambda-*" これは、LambdaのARNを指定して、Denyから回避しようとしてました。 しかし、正しくはLambdaにアタッチされている IAMロール をNotとして回避させてあげないといけません。 あくまでLambdaからSQSへ操作する実行主体は、IAMロールなので、それに対する権限の記載をしないといけなかったという訳です。   正しい記載は何か？ いろいろ調査した結果、正しい記載は下記ではないかと考えられます。 {   “Version”: “2012-10-17",   “Statement”: [     {       “Effect”: “Deny”,       “Principal”: “*”,       “Action”: “sqs:*“,       “Resource”: “arn:aws:sqs:ap-northeast-1:${AWS::AccountId}:SampleQueue”,       “Condition”: {         “ArnNotEquals”: {           “aws:PrincipalArn”: [             “arn:aws:iam::${AWS::AccountId}:user/*“,             “arn:aws:iam::${AWS::AccountId}:role/service-role/example-role”           ]         }       }     }   ] } ArnNotEqualsの中身は、aws:PrincipalArnで統一をします。 その中で、下記２つを記載して、それぞれのことを実現します。 “arn:aws:iam::${AWS::AccountId}:user/*“ ・・・そのアカウント内の全IAMユーザーへのアクセス制御を実現。 “arn:aws:iam::${AWS::AccountId}:role/service-role/example-role” ・・・Lambdaに付与しているIAMロールへのアクセス制御を実現。   今回の教訓 今回アクセス拒否されてしまった事象の教訓としては、下記がございます。  Lambdaへのアクセス制御は、付与しているIAMロールへのアクセス制御が必要。 ・実行権限を付与する主体が何なのかは、今後権限付与する際にしっかり調査する必要があると感じました。 NotPrincipalとDenyはそもそも相性が悪い。 ・AWS側も非推奨としているので、DenyをするならConditionの中にaws:PrincipalArnを書く方法を採用すべきですね。 ポリシー作成後に検証して動作確認するとはいえ、安易に生成AIのいうことを聞いてはいけない。 ・今回は明示的な拒否のため、アクセスできなくなるリスクが孕んでおり、そういう場合には慎重に調査をすべきと感じました。   まとめ 今回は、SQSへのアクセスができなくなった事象についてまとめました。 IAMの記述方式は複雑であり、非常に奥が深いことを再実感しました。 正しい仕様を理解することはやはり重要ですね。

本記事は 夏休みクラウド自由研究 8/2付の記事です 。 こんにちは。SCSKの江木です。 夏休みクラウド自由研究2024の2日目の記事になります。 みなさん、単体テストケース作成に時間がかかりすぎていませんか？ 先日Dialogflow CXの単体テストケースを作成していて、抜け漏れチェックに追われて、かなり時間がかかってしまいました。 今回はテストケース作成の時間を削減すべく、グラフ理論を使って、単体テストケース作成を自動化する方法を実装してみました。 このグラフ理論の考え方は他にも使えると思うので、ぜひご覧ください。 Dialogflow CXにおける単体テストケースについて 単体テストの方法 Dialogflow CX(以下、Dialogflow)は他のサービスと連携して使用されることが多いのが現状です。したがって、本記事におけるDialogflowの単体テストはDialogflow単体で動作するかという意味で使用していますので、ご了承ください。 これを踏まえて、Dialogflowの単体テストは以下の方法で行うことを想定しております。 基本的にはページレベルでテスト ループのテストはフローレベルで テストは正常系、異常系、ループに分ける それぞれの観点について詳しく説明していきます。 基本的にはページレベルでテスト 一般的にプログラムの単体テストは関数/メソッドといった単位で行いますが、このプログラムにおける関数/メソッドをDialogflowで置き換えるとページと捉えることができます。 従って、ページレベル単位でテストを行います。 ※一般的な単体テストと捉えていただけるとわかりやすいと思います。 ループのテストはフローレベルで 聞き返し機能をチャット/ボイスボットに備えるため、DialogflowのAgentにはループが存在することがあります。 ループのテストはページレベルで行うとテストケースが複雑になるため、フローレベルで行います。 テストは正常系、異常系、ループに分ける テストは正常系、異常系、ループの3つに分けて行います。 正常系ではパラメータ入力およびイベント発生における動作確認を行います。異常系では無効な入力に対する動作確認を行います。 また、正常系・異常系は以下の観点でテストを行います。 正しく遷移するか 画面が仕様通りに表示されているか 取得情報に誤りがないか 一方で、ループは以下の観点でテストを行います。 ループがフローに影響がないか ループは正常系に入れてもよいのですが、テスト観点が異なるためテストジャンルを分けました。 作成するテストケースについて 上記のテスト観点を踏まえて、テストケースを作成していきます。作成したテストケースは以下のようなエクセルシートで出力したいと思います。また、出力されるエクセルシートは全部埋められているわけではなく、抜け漏れチェックのためにエクセルシートの一部をテスターが埋めるようにしています。 ※横に長いため、分割しています。 実装 アーキテクチャ アーキテクチャは以下の図を想定しています。 Cloud StorageのバケットにAgentのファイルをアップロードすると、テストケースが同じバケットに出力されるように設計しています。 実装方針 テストケース作成にはページの遷移先、ループの検出が不可欠です。そこで、グラフ理論の考え方でDialogflowのフローは有向グラフであることに着目し、Pythonのグラフ系ライブラリであるNetworkXを使って、実装しました。NetworkXを使うことで、ループ検出、ルート検索が容易になります。 有向グラフとは？ 有向グラフとは、下図のように頂点と、それらを結ぶ辺が向きを持つグラフです。辺の向きは矢印で表され、矢印の先端が頂点の終点、矢印の根元が始点となります。 いざ実装！ それでは実際に実装していきます。Dialogflowのフローを有向グラフに置き換える箇所を中心にプログラムを抜粋して紹介していきます。 トリガーの設定 Cloud Storageのトリガーを設定していきます。Cloud StorageのバケットにAgentのファイルが格納された際にCloud Functionsが起動するようにしたいので、以下のように「google.cloud.storage.object.v1.finalized」で設定します。   Agentファイルの読み込み CloudEvent関数を使用して、Cloud Storageにアップロードされたファイル名の取得を行います。その後、ファイル名からAgentをjson形式でCloud Storageから読み込みます。以下は、アップロードされたAgentのファイルから辞書形式でAgentの詳細を取得するプログラムです。 @functions_framework.cloud_event def main(cloud_event):   #GCSバケットの名前   bucket_name = cloud_event.data['bucket']   #zipファイルの名前   blob_name = cloud_event.data['name'] #Agentファイル以外がアップロードされた場合は終了   if blob_name.split(".")[1] != "zip":         return 　　#flowごとのjsonが格納された辞書を取得 　　Agent_dict = get_dict(bucket_name,blob_name) また、辞書形式でAgentを取得するget_json関数の詳細は以下の通りです。 def get_dict(bucket_name: str,blob_name: str) -> dict:   storage_client = storage.Client()   bucket = storage_client.bucket(bucket_name)   blobs = storage_client.list_blobs(bucket_name)   blob = bucket.blob(blob_name)     content = blob.download_as_string()   # zipファイルを読み込む     zip_f = zipfile.ZipFile(BytesIO(content))   # zipファイルの中身のファイル名を取得     lst = zip_f.namelist()     selected_items = [item for item in lst if 'flows' in item]   Agent_dict = {}   for item in selected_items:       flow_name = item.split('/')[1]       tag = item.split('/')[-1].split('.')[0]       if flow_name not in Agent_dict:           Agent_dict[flow_name] = {}       with zip_f.open(item) as myfile: # openを利用してファイルにアクセス           json_detail = json.load(myfile)         Agent_dict[flow_name][tag] = json_detail return Agent_dict 有向グラフの作成 それでは、辞書型のAgentからグラフを作成していきます。以下は辞書型のAgentから、page名をkey、そのpageからの遷移先の配列をvalueとした辞書を作成し、その辞書からグラフを作成していくプログラムになります。また、page_dictはflowごとのpage一覧が格納された辞書を表しています。 def make_graph(page_dict: dict,flow_name: str,Agent_dict: dict) -> Graph:       #page名が入った配列を作成。End Sessionページが入っていないので追加する page_list = page_dict[flow_name]         page_list.append("End Session")       #page名をkey,遷移先の配列をvalueとした辞書を作成       dict_flow = {} #page名からflowを探索して、遷移先の配列を作成       for page in page_list           if page == "Start Page":                  dict_flow[page] = search(Agent_dict[flow_name][flow_name])           elif page == "End Session":                dict_flow[page] = []           else:             　 dict_flow[page] = search(Agent_dict[flow_name][page]) 　　　 #グラフ作成       g = nx.DiGraph(dict_flow) return g   テストケースの作成 正常系、異常系、ループの3つのジャンルで作成していきます。 正常系テストケースの作成 正常系のテストケースを作成するプログラムは以下の通りです。イベントを確認するテストケースとパラメータを確認するテストケースに分けて作成してします。rowは操作するエクセルシートの行、wsはエクセルシート、flow_dictはflowの辞書を表しています。 def make_normal(row: int,page: str,ws: sheet,flow_dict: dict) -> Tuple[int,sheet]:     test_category = "正常系"   #イベントテストケース作成 #イベント一覧の取得   event_list,event_json = get_event(page,flow_dict) #異常系のイベントを除去   event_list_remove_abnormal = [event for event in event_list if 'sys.no-match' not in event and 'sys.no-input' not in event and 'long-utterance' not in event]   if len(event_list_remove_abnormal) != 0:       for event in event_list_remove_abnormal:           category_sentence = "イベント(" + event + ")"           transition = "遷移しない"           for event_detail in event_json["page_event"]:               if event_detail["event"] == event and "targetPage" in event_detail.keys():                     transition = event_detail["targetPage"] #テストケースをエクセルへ書き込み             row,ws = add_page_testcase(row,page,test_category,category_sentence,transition,ws)   #パラメータテストケース作成 #パラメータ一覧の取得   parameter_list = get_parameter(page,flow_dict) #遷移先一覧の取得   transitionRoute_list,transitionRoute_json = get_transitionRoutes(page,flow_dict)   if len(parameter_list) != 0:       param_all = ','.join(parameter_list)       category_sentence = "パラメータ(" + param_all + ")"       for route in transitionRoute_json:           for param in parameter_list:               transition = "遷移しない"               if "$page.params.status" in route["condition"] or param in route["condition"]:#page.paramsかパラメータ名が条件に入っていれば、そのルートをテストケースとする                   if "targetPage" in route.keys():                       transition = route["targetPage"] 　　　　　　　　　　　#テストケースをエクセルへ書き込み                     row,ws = add_page_testcase(row,page,test_category,category_sentence,transition,ws)   return row,ws 異常系テストケースの作成 異常系のテストケースを作成するプログラムは以下の通りです。no-match、no-inputイベントとlong-utteranceイベントに分けてテストケース作成を行います。no-match、no-inputイベントは設定された回数分テストケースを作成します。long-utteranceイベントはループ回数の指定があれば、指定の回数分テストケースを作成しますが、指定がない際はテストケースを1つのみ作成します。 def make_abnormal(row: int,page: str,ws: sheet,flow_dict: dict) -> Tuple[int,sheet]:     test_category = "異常系" #イベント一覧の取得   event_list,event_json = get_event(page,flow_dict)   event_list_abnormal = [event for event in event_list if "sys.no-match" in event or "sys.no-input" in event or "long-utterance" in event]     event_list_abnormal_not_longutterance = [event for event in event_list if "sys.no-match" in event or "sys.no-input" in event]   if len(event_list_abnormal_not_longutterance) != 0:       for event in event_list_abnormal_not_longutterance:           category_sentence = event + "イベント"           #pageのほうにある場合もある           transition = "遷移しない"           if "param_event" in event_json.keys():               for event_detail in event_json["param_event"]:                   if event_detail["event"] == event and "targetPage" in event_detail.keys():                     transition = event_detail["targetPage"]           elif "page_event" in event_json.keys():               for event_detail in event_json["page_event"]:                   if event_detail["event"] == event and "targetPage" in event_detail.keys():                       transition = event_detail["targetPage"] #テストケースをエクセルへ書き込み           row,ws = add_page_testcase(row,page,test_category,category_sentence,transition,ws)   #long-utteranceの時の処理   parameter_list = get_parameter(page,flow_dict)   transitionRoute_list,transitionRoute_json = get_transitionRoutes(page,flow_dict)   for event in event_list_abnormal:       if "long-utterance" in event:           #loop-countのパラメータがなければ(not-added)、テストケースは1つだけ作成する           flag = "not-added"           for route in transitionRoute_json: #long-utteranceのループ回数をカウントするパラメータを探索して、存在すればそのループカウント分だけテストケースを作成。               if "loop" in route["condition"] and "count" in route["condition"] and "$session.params" in route["condition"]:                   split_condition = route["condition"].split("=")                   loop_count_max = int(split_condition[1].strip())                   for i in range(loop_count_max):                       category_sentence = event + "-" + str(i+1) +"イベント"                       if i+1 != loop_count_max:                           transition = "遷移しない"                       else:                           transition = route["targetPage"] #テストケースをエクセルへ書き込み                       row,ws = add_page_testcase(row,page,test_category,category_sentence,transition,ws)                   flag = "added"           if flag == "not-added":               category_sentence = event + "イベント"               transition = "遷移しない" #テストケースをエクセルへ書き込み                 row,ws = add_page_testcase(row,page,test_category,category_sentence,transition,ws)     return row,ws ループテストケースの作成 ループのテストケースを作成するプログラムは以下の通りです。NetworkXの閉路を検知する関数を使って、ループ検知を行います。 def make_loop_test(row: int,pages: str,ws: sheet,g: Graph) -> Tuple[int,sheet]:   #有向グラフからサイクル検知でloopを検知     loop_list = list(nx.simple_cycles(g))   if len(loop_list) != 0:       for loop in loop_list:           loop.append(loop[0])           page_sentence = "⇒".join(loop)           test_category = "-"           category_sentence = "、".join(loop)             category_sentence = category_sentence + "におけるloopをカウントするパラメータの確認" #テストケースをエクセルへ書き込み             row,ws = add_loop_testcase(row,page_sentence,test_category,category_sentence,ws)         return row,ws ファイルの出力・保存 エクセルファイルをCloud Storageのバケットへ出力するプログラムは以下の通りです。エクセルファイルを一時ファイル的に保存するためにtmpフォルダを使用しています。（地味に苦労したポイントです！！）tmpフォルダへ格納した後、Cloud Storageのバケットへアップロードします。 def repository(wb: book,bucket_name: str,file_name: str) -> None: #エクセルの一時ファイルを保存 wb.save("/tmp/"+excel_filename) 　　 storage_client = storage.Client() bucket = storage_client.bucket(bucket_name)     blob = bucket.blob(file_name)   # エクセルの一時ファイルをCloud Storageのバケットへアップロード   blob.upload_from_filename("/tmp/" + file_name)     os.remove("/tmp/" + file_name) 出力結果 以下のAgentのテストケースを出力してみます。 以下のようにうまく出力することができました！（テストケースが多いので、抜粋しています） また、ループの検知がうまくできていることも以下のように見て取れます。 おわりに 今回はグラフ理論を使って、Dialogflow CXのテストケース作成の自動化を実装してみました。 本記事で実装しているのはループの検出のみですが、ルートの検出ももちろんできます。 ループ、ルートの検出が出来ると何がうれしいかといいますと、テストケースの抜け漏れを防げるということです！ Dialogflowの他にも、世の中にはグラフに置き換えることができるサービスで溢れていますので、それらのサービスをグラフに置き換えることができれば、今回のように何らかの自動化ができるかもしれませんね… 最後まで読んでいただき、ありがとうございました。

こんにちは。SCSKの島村です。 今年もGoogle Cloud のカンファレンスイベント Google Cloud Next Tokyo ’24 が パシフィコ横浜 にて開催されております。 8月1日（木）－2日（金） の二日間にわたり、 生成 AI やセキュリティをはじめ、ビジネスに欠かせないテーマを元に、基調講演、ライブ セッションやハンズオンなど 様々なプログラムがご用意されているGoogle Cloudのビッグイベントとなります。 ☟☟☟イベント詳細については、こちらの記事よりご確認ください。☟☟☟ まだ登録されていない方は、下記リンクよりご一読いただけますと幸いです。 Google Cloud Next Tokyo ’24 へ出展のお知らせ – TechHarmony (usize-tech.com) 本記事では、Google Cloud Next Tokyo’24「 Day1開幕速報 」として、 ・ Day 1 Keynoteまとめ ・ 弊社SCSKの展示ブースについて ・ （おまけ）現地の最新情報 　　　を共有できればと思います。 ご登録がお済でない方は、まずはこちらからご登録ください↓↓ 【招待コード  : FY24nx_pt030】 申し込み時にご入力ください！！ [速報] Keynote（10:00-11:30 D1-KEYNOTE 基調講演会場） 概要 Google Cloud Next 24 Tokyoの開幕イベント共に本日10時よりKeynoteセッションが行われました。 現地速報として、リリースされた新サービスの情報並びに会場の雰囲気をいち早くお伝えします。 （＊各サービスの詳細については、後日追って共有いたします。） Keynoteアーカイブは以下,Google Cloud 公式Youtubeから確認可能です。 Watch – DAY 1 基調講演 (cloudonair.withgoogle.com) 本Keynoteでは、 「話題の生成 AI を筆頭に多様なプロダクト アップデートや最新のソリューションの紹介」 「Google Cloud を導入しビジネスに革新をもたらすの企業のリーダーから、そのビジョンと取り組みについて」共有されました。 —本Keynoteにてご登壇された方々— ●東日本旅客鉄道 代表取締役副社長イノベーション戦略本部長 CTO・CDO・CIO 伊勢 勝巳 氏 ● LINEヤフー 上級執行役員 生成AI統括本部長 宮澤 弦 氏 ● 星野リゾート 代表 星野 佳路 氏 ● Google Cloud 日本代表 平手 智行氏 ● Google DeepMind プロダクト & エンジニアリング シニア ディレクター セシュ アジャラプ氏 ● Google Cloud AI ディレクター プロダクト マネージメント アーワン メナード氏 ● Google Cloud Google Workspace 事業本部 コラボレーション アプリ プロダクト マネージメント バイス プレジデント クリスティナ ベア氏 ● Google Cloud Retail & CPG Cluster カスタマー エンジニア 諏訪 悠紀氏 ● Google Cloud Google Workspace 事業本部 ソリューション エンジニアリング リード 白川 遼氏 Keynoteにて発表されたサービス 新たに発表されたサービス一覧 ＊各サービスの詳細については、後日追って共有いたします。次回のブログをお楽しみにしていただければと思います。 NEW ML Processing in Japan Geminiモデル in Japan Geminiに関する処理のすべてが日本国内で完結 NEW Gemini for Google Cloud Service Level Agreement(SLA) 高度に規則された業界でも安心してGeminiを利用可能 NEW Gemma 2 軽量かつ最先端のオープンモデルファミリー NEW MaaS（Model as a Service） Llama：405B（プレビュー）　8B/70B（Coming Soon） Mistral：Codestral（一般提供）Large 2（一般提供）NeMo（一般提供） NEW Gemini 1.5 Pro | Gemini 1.5 Flash コンテキストキャッシング 大規模なコンテンツキャッシュと新しいプロンプト入力を組み合わせGeminiでコンテンツ生成が可能 入力コストを最大で75％削減 NEW Grounding on Vertex AI ● サードパーティデータセットによるグラウンディング ● 高忠実度モードによるグラウンディング ●Dynamic Retrieval Keynoteでは、Geminiを利用したプロトタイプでのデモが紹介されたました。 日本語でのマルチモーダルな問い合わせをスマホから実施しており、インパクトのあるデモで会場でも拍手が起こっていました。また、本KeynoteではGoogle Cloudを活用されていリーダ企業様の事例を複数共有いただきました。   弊社SCSKの展示ブース（スポンサーブース＠Expo）について 今回、弊社SCSKは Platinumスポンサー として ブレイクアウトセッション &Ask the Speaker に登壇し 、 Expo 会場へのブースを出展 しております。 ＞＞展示ブースのコンセプト＜＜ 弊社は今年の4月にLas Vegasで開催されたGoogle Cloud Next ’24 Partner Summit において 『 Google Cloud ソーシャルインパクト パートナー オブ ザ イヤー 』を受賞しております。 AIの導入実績を評価いただいているのは国内では当社のみ。 AIを導入・活用した実績や受賞に関わるＡＩ技術のデモ、事例集を用意。イケイケでいきます。   —プレスリリースの詳細はこちらから— 国内企業で初受賞「Google Cloud ソーシャルインパクト パートナー オブ ザ イヤー」を受賞 (scsk.jp) Enterprise向けに画像（外観検査AI）や音声（コンタクトセンターAI）とマルチモーダルなデータを活用し、お客様課題解決、社会に新たな価値創出したことが認められ受賞に至りました。 展示ブースでは以下のデモをご用意しております。是非お立ち寄りください。 出展デモ概要 ■「電話基盤⇒音声認識⇒自動要約オプション⇒VOC分析」 (PrimeTiaas＋Voiceek　紹介・デモ) ■ ボイスボットオプション（DialogflowCXを利用したPrimeTiaasオプションサービス　紹介・デモ） ■ PrimeAgentGAI（Google CloudのDialogflowCX＋Agent Builderのデモ） ■ 生成AIによる問い合わせ業務アシスタントツール（Agent Builder Search、Geminiなどを使った文書検索デモ） ■ Security Operations(SecOps・運用サービス紹介)   出展デモ詳細：（生成AIによる問い合わせ業務アシスタントツール） 弊社にて展示させていただいているデモの中から一部をご紹介させていただきます。 詳細気になった方は是非、会場SCSKブースまでお越しください!!!!!!   生成AIによる問い合わせ業務アシスタントツール　とは？ 問い合わせ業務を対応されているオペレーター向けの生成AIアシスタントツールです。 流行りのRAG（Retrieval-Augmented Generation）による検索やマルチモーダル（画像）での回答生成で、 『 オペレーターの回答支援を実施するプラットフォーム 』です。 以下、簡単に機能を紹介いたします。 【機能一覧】 ■ 問い合わせ機能 ① Geminiへの問い合わせ：複数のGeminiモデルから選択可能で、オペレーターが作成した回答文の添削などを支援します。 ② ドキュメント検索：クラウド上に保存したナレッジから候補となる回答を検索し回答文作成を支援します。 ③ 過去問合せ検索：過去とのお客様とのやり取りを集約し、類似の問い合わせから回答文作成を支援します。 ④ Geminiへの問い合わせ（マルチモーダル）：お客様から受領した添付画像を元に回答文作成を支援します。 ■ 問い合わせ履歴確認機能 ■ サンプルプロンプト管理機能 ■ ダッシュボード機能   利用イメージ [問い合わせ機能] 実際のデモ画面①☟☟☟☟ [ダッシュボード機能] 実際のデモ画面②☟☟☟☟   おまけ：現地会場（パシフィコ横浜）の様子 [現地写真]D1-KEYNOTE 基調講演会場 Keynote開始前には会場は満員近くになり、開始と同時に会場には拍手が響き渡りました。 会場MAP Next仕様のバス 横浜駅西口からパシフィコ横浜ノースまでの連絡バスが運行しておりました。 [パシフィコ横浜ノース] ノース | 施設ガイド | パシフィコ横浜 (pacifico.co.jp)   最後に 今回はGoogle Cloudのカンファレンスイベントである Google Cloud Next ’24 Tokyoについて現地速報をお届けしました。 本日から2日に渡るイベントをGoogle Cloud のPartnerとして一緒に盛り上げていければと思います。 弊社SCSKも Platinumスポンサーとして出展させていただいております！ 現地では、会場の雰囲気も味わうことができ、Google Cloud の熱気も感じることができおります。 是非、皆様と会場にてお会いできることを楽しみにしています。 また、弊社出展サービスに関してのお問い合わせは以下のフォームからお願い致します。 お問い合わせ製品・サービス名に「Google Cloud」を選択してください。 お問い合わせ｜クラウド移行だけでは描けない、理想のDXを実現する www.scsk.jp 新サービスの発表もありより詳しい内容については調査・整理し、本ブログにて情報発信できればと思います。 今後とも、AIMLに関する情報やGoogle CloudのAIMLサービスのアップデート情報を掲載していきたいと思います。 最後まで読んでいただき、ありがとうございました！！！

本記事は 夏休みクラウド自由研究 8/1付の記事です 。 こんにちは、広野です。 以前、以下の記事で Amazon Bedrock や Agents for Amazon Bedrock を使用した最小構成 RAG 環境構築を紹介しておりました。当時はAmazon Bedrock 関連のリソースを一部 AWS CloudFormation ではデプロイできなかったのですが、今はサポートされたためにできるようになりました。 React アプリに Agents for Amazon Bedrock への問い合わせ画面を組み込む [RAG・レスポンスストリーミング対応] Agents for Amazon Bedrock を使用して簡単な RAG をつくってみましたので、問い合わせ画面コードの一部を紹介します。 blog.usize-tech.com 2024.02.15 当時の構成を現在は変更しており、Knowledge Base に使用するデータベースを Amazon OpenSearch Serverless から Aurora Serverless v2 Postgresql に変更しています。 本シリーズ記事では、環境構築用の AWS CloudFormation のサンプルテンプレートを 3 記事に分けて紹介します。説明を分割するため、テンプレートを3つに分けていますのでご了承ください。 初回は VPC 編です。 本記事で取り扱う構成 RAG 環境全体の構成 以下のアーキテクチャで、RAG アプリケーションを構築しています。このうち、赤枠の部分が本シリーズ記事で取り扱う箇所です。series 1 VPC 編では、Amazon Aurora Serverless v2 Postgresql を構築する際に必要な VPC について説明します。 VPC の構成 Amazon Aurora Serverless v2 をデプロイするためには VPC が必要になります。サーバーレスなんですが、VPC リソースからアクセス可能にするためにそのような仕様にしているのだと思います。以下の VPC を用意します。 Aurora Serverless はプライベートサブネットに配置します。リーダーインスタンスやレプリカは設定していません。 Aurora Serverless を配置するときに、RDS サブネットグループが必要になります。任意の 2 つ以上のサブネットをグループに登録します。これが Aurora Serverless の設定で必要になるため、マルチ AZ 構成が必須になります。 データベースなので、プライベートサブネットに配置します。選択したサブネットに、VPC 内からアクセスするためのエンドポイントが作成されます。ただし Agents for Amazon Bedrock からは Data API 経由で接続するため、VPC は通りません。 エンドポイントにはセキュリティグループを関連付けます。ここでは、サブネットの CIDR から Postgresql に接続するためのデフォルトポート番号を開けておきます。 Agents for Amazon Bedrock が Aurora Serverless に接続するときのクレデンシャルは、Secrets Manager から取得します。これについては次回の記事で紹介します。 NAT ゲートウェイは本記事では省略しました。 AWS CloudFormation テンプレート 図に掲載している、Amazon Aurora Serverless、Agents for Amazon Bedrock、Secrets Manager は次回記事のテンプレートに含まれます。 Aurora Serverless で使用する RDS サブネットグループとセキュリティグループはここで作成し、次回のテンプレートで使用するためリソース情報をエクスポートしておきます。 AZ は仕様上、使用可能な 2 つの AZ をアルファベット順に前から選定します。東京リージョンだと b が使用できないため a と c が選定されますが、多くのリージョンでは a と b が選定されます。ここでは、東京リージョンでの使用を想定して a と c がリソースの名前に使用されています。ご注意ください。 AWSTemplateFormatVersion: 2010-09-09 Description: The CloudFormation template that creates A VPC, Subnets, an Internet Gateway and Routings. Additionally, a RDS subnet group and a security group for Aurora serverless. # ------------------------------------------------------------# # Input Parameters # ------------------------------------------------------------# Parameters: SubName: Type: String Description: System sub name of sample. (e.g. test) Default: test MaxLength: 10 MinLength: 1 VPCCIDR: Type: String Description: IP Address range for your VPC (16 bit mask) Default: 192.168.0.0/16 MaxLength: 14 MinLength: 10 AllowedPattern: ^((25[0-5]|2[0-4][0-9]|1[0-9][0-9]|[1-9]?[0-9])\.){2}0\.0/16$ PublicSubnetACIDR: Type: String Description: IP Address range for your public subnet A (24 bit mask) Default: 192.168.1.0/24 MaxLength: 16 MinLength: 10 AllowedPattern: ^((25[0-5]|2[0-4][0-9]|1[0-9][0-9]|[1-9]?[0-9])\.){3}0/24$ PublicSubnetCCIDR: Type: String Description: IP Address range for your public subnet C (24 bit mask) Default: 192.168.2.0/24 MaxLength: 16 MinLength: 10 AllowedPattern: ^((25[0-5]|2[0-4][0-9]|1[0-9][0-9]|[1-9]?[0-9])\.){3}0/24$ PrivateSubnetACIDR: Type: String Description: IP Address range for your private subnet A (24 bit mask) Default: 192.168.101.0/24 MaxLength: 16 MinLength: 10 AllowedPattern: ^((25[0-5]|2[0-4][0-9]|1[0-9][0-9]|[1-9]?[0-9])\.){3}0/24$ PrivateSubnetCCIDR: Type: String Description: IP Address range for your private subnet C (24 bit mask) Default: 192.168.102.0/24 MaxLength: 16 MinLength: 10 AllowedPattern: ^((25[0-5]|2[0-4][0-9]|1[0-9][0-9]|[1-9]?[0-9])\.){3}0/24$ Resources: # ------------------------------------------------------------# # VPC # ------------------------------------------------------------# VPC: Type: AWS::EC2::VPC Properties: CidrBlock: !Ref VPCCIDR EnableDnsSupport: true EnableDnsHostnames: true InstanceTenancy: default Tags: - Key: Name Value: !Sub sample-VPC-${SubName} - Key: Cost Value: !Sub sample-${SubName} InternetGateway: Type: AWS::EC2::InternetGateway Properties: Tags: - Key: Name Value: !Sub sample-IGW-${SubName} - Key: Cost Value: !Sub sample-${SubName} InternetGatewayAttachment: Type: AWS::EC2::VPCGatewayAttachment Properties: InternetGatewayId: !Ref InternetGateway VpcId: !Ref VPC # ------------------------------------------------------------# # Subnet # ------------------------------------------------------------# PublicSubnetA: Type: AWS::EC2::Subnet Properties: AvailabilityZone: !Select - 0 - Fn::GetAZs: !Ref AWS::Region CidrBlock: !Ref PublicSubnetACIDR MapPublicIpOnLaunch: true VpcId: !Ref VPC Tags: - Key: Name Value: !Sub sample-Public-a-${SubName} - Key: Cost Value: !Sub sample-${SubName} PublicSubnetC: Type: AWS::EC2::Subnet Properties: AvailabilityZone: !Select - 1 - Fn::GetAZs: !Ref AWS::Region CidrBlock: !Ref PublicSubnetCCIDR MapPublicIpOnLaunch: true VpcId: !Ref VPC Tags: - Key: Name Value: !Sub sample-Public-c-${SubName} - Key: Cost Value: !Sub sample-${SubName} PrivateSubnetA: Type: AWS::EC2::Subnet Properties: AvailabilityZone: !Select - 0 - Fn::GetAZs: !Ref AWS::Region CidrBlock: !Ref PrivateSubnetACIDR VpcId: !Ref VPC Tags: - Key: Name Value: !Sub sample-Private-a-${SubName} - Key: Cost Value: !Sub sample-${SubName} PrivateSubnetC: Type: AWS::EC2::Subnet Properties: AvailabilityZone: !Select - 1 - Fn::GetAZs: !Ref AWS::Region CidrBlock: !Ref PrivateSubnetCCIDR VpcId: !Ref VPC Tags: - Key: Name Value: !Sub sample-Private-c-${SubName} - Key: Cost Value: !Sub sample-${SubName} # ------------------------------------------------------------# # Subnet Group for RDS # ------------------------------------------------------------# PrivateSubnetGroup: Type: AWS::RDS::DBSubnetGroup Properties: DBSubnetGroupName: !Sub sample-${SubName} DBSubnetGroupDescription: !Sub Subnet Group for KB database for sample-${SubName} SubnetIds: - !Ref PrivateSubnetA - !Ref PrivateSubnetC Tags: - Key: Cost Value: !Sub sample-${SubName} # ------------------------------------------------------------# # Security Group for RDS # ------------------------------------------------------------# AuroraSecurityGroup: Type: AWS::EC2::SecurityGroup Properties: GroupName: !Sub bedrock-rag-kb-sample-${SubName} GroupDescription: !Sub Allow Aurora PostgreSQL for sample-${SubName} VpcId: !Ref VPC SecurityGroupIngress: - IpProtocol: tcp FromPort: 5432 ToPort: 5432 CidrIp: !Ref PrivateSubnetACIDR - IpProtocol: tcp FromPort: 5432 ToPort: 5432 CidrIp: !Ref PrivateSubnetCCIDR Tags: - Key: Cost Value: !Sub sample-${SubName} - Key: Name Value: !Sub sg-bedrock-rag-kb-sample-${SubName} # ------------------------------------------------------------# # RouteTable # ------------------------------------------------------------# PublicRouteTableA: Type: AWS::EC2::RouteTable Properties: VpcId: !Ref VPC PublicRouteTableC: Type: AWS::EC2::RouteTable Properties: VpcId: !Ref VPC PrivateRouteTableA: Type: AWS::EC2::RouteTable Properties: VpcId: !Ref VPC PrivateRouteTableC: Type: AWS::EC2::RouteTable Properties: VpcId: !Ref VPC # ------------------------------------------------------------# # Routing to Internet # ------------------------------------------------------------# PublicRouteA: Type: AWS::EC2::Route Properties: RouteTableId: !Ref PublicRouteTableA DestinationCidrBlock: 0.0.0.0/0 GatewayId: !Ref InternetGateway PublicRouteC: Type: AWS::EC2::Route Properties: RouteTableId: !Ref PublicRouteTableC DestinationCidrBlock: 0.0.0.0/0 GatewayId: !Ref InternetGateway # ------------------------------------------------------------# # RouteTable Associate # ------------------------------------------------------------# PublicSubnetARouteTableAssociation: Type: AWS::EC2::SubnetRouteTableAssociation Properties: SubnetId: !Ref PublicSubnetA RouteTableId: !Ref PublicRouteTableA PublicSubnetCRouteTableAssociation: Type: AWS::EC2::SubnetRouteTableAssociation Properties: SubnetId: !Ref PublicSubnetC RouteTableId: !Ref PublicRouteTableC PrivateSubnetARouteTableAssociation: Type: AWS::EC2::SubnetRouteTableAssociation Properties: SubnetId: !Ref PrivateSubnetA RouteTableId: !Ref PrivateRouteTableA PrivateSubnetCRouteTableAssociation: Type: AWS::EC2::SubnetRouteTableAssociation Properties: SubnetId: !Ref PrivateSubnetC RouteTableId: !Ref PrivateRouteTableC # ------------------------------------------------------------# # Output Parameters # ------------------------------------------------------------# Outputs: # Subnet PrivateSubnetGroupName: Value: !Ref PrivateSubnetGroup Export: Name: !Sub sample-${SubName}-PrivateSubnetGroupName # Security Group AuroraSecurityGroupId: Value: !Ref AuroraSecurityGroup Export: Name: !Sub sample-${SubName}-AuroraSecurityGroupId まとめ いかがでしたでしょうか？ VPC 作成テンプレートはどこにでもある情報だと思いますし、マネジメントコンソールでも以前より簡単に作れるようになっているので必要性は低いかもしれませんが、私は普段からこのテンプレートを活用して VPC をデプロイしています。 次回は Knowledge Base 用 Aurora Serverless のデプロイがテーマです。 本記事が皆様のお役に立てれば幸いです。

はじめに 今回はPythonで作成したAWS Lambda関数を保護するサーバーレスディフェンダーの導入方法を解説していきます。 サーバーレスディフェンダーには関数組み込み型とレイヤー型の2つの種類があり、今回は両方導入方法を解説していきたいと思います。 サーバーレスディフェンダーとは CWPP(Cloud Workload Protection Platform)の中の機能の一つでAWS LambdaとAzure Functionを保護するための機能です。 ※ARM64 アーキテクチャはサポートされていません 他のディフェンダー種類については こちら から確認できます。 何から保護してくれるのか Prisma Cloud のサーバーレスディフェンダーは、以下のリスクから AWS Lambda 関数を保護します。 プロセスアクティビティ ポリシーに対して、起動されたサブプロセスを検証することを可能にします。 ネットワーク接続 インバウンドとアウトバウンドの接続を検証し、明示的に許可されたドメインへのアウトバウンド接続を許可します。 ファイルシステムアクティビティ 関数がアクセスできるファイルシステムの部分を制御します。 サーバーレスディフェンダーに必要な通信経路 Lambda が Prisma Cloud の特定IP/ドメインと通信できる必要があります。 IPは日本リージョンの場合以下の通りになります。 詳細は こちら です。 通信方向 IPアドレス Egress 35.194.113.255 Ingress 35.200.123.236 関数組み込み型とレイヤー型の設定作業の違い 関数組み込み型とレイヤー型のそれぞれの作業概要を説明します。 関数組み込み型 Prisma Cloud コンソールからサーバーレスディフェンダー用ライブラリをダウンロードする Lambda関数のフォルダにサーバーレスディフェンダーのライブラリを配置する Lambda関数がサーバーレスディフェンダーを利用できるようにソースコードを追記する 環境変数を設定する レイヤー型 Prisma Cloud コンソールからサーバーレスディフェンダー用ライブラリをダウンロードする サーバーレスディフェンダー用のLambdaレイヤーを作成する すべての Lambda 関数にレイヤーを適用する 環境変数、ハンドラー設定を行う どちらが導入が簡単か レイヤー型の方が導入が簡単 です。一度レイヤーを作成すれば、Lambda関数ごとにライブラリを配置することや、コードを修正する必要が無くなります。 対応バージョンと対応言語 サーバーレスディフェンダー(AWS Lambda)の対応言語とバージョンは以下の通りです。 詳しくは こちら を参照ください。 言語 バージョン C#(.NET Core) 6.0 Java 8, 11 Node.js 14.x, 16.x, 18.x Python 3.6, 3.7, 3.8, 3.9 Ruby 2.7 サーバーレスディフェンダーの導入(関数組み込み型) 環境変数用の値を取得 左上の選択が「ランタイムセキュリティ」になっていることを確認します。 「ホーム」→ 左ペイン「MANAGE」→ 「Defenders」に行きます。 「Manual deploy」を押下します。 押下すると設定画面に遷移します。 変更した設定値は以下の通りです。 Method: Single Defender Defender Type: Serverless Defender – AWS 次に「Manual Deploy」に行き設定をします。 Runtime: Python Deployment type: Embedded Function name: defender-test Region: Tokyo            Runtimeは今回はLambdaでPythonを使用するのでPythonを指定しています。 同様に関数組み込み型を使用する場合は、Embeddedを指定します。 FunctionNameはLambdaの関数名と同じにします。 RegionはTokyoを指定しています。 ディフェンダーライブラリのダウンロード 「1. Download file」の「Command」か「Download file directly」どちらかでライブラリのダウンロードを行ってください。       ダウンロードしたライブラリを事前に解凍しておきます。           「3. Handler」の部分はのちに使用する部分ですが、今は使用しないのでスキップします。 TW_POLICYの生成 Lambdaの環境変数に使うTW_POLICYの生成を行っていきます。 「Generate」ボタンを押して、KeyとValueを保存しておきます。 サーバーレスディフェンダーの導入 以下サーバーレスディフェンダー導入前のLambdaのコードになります。 コード自体は本編に関係ないので深くは解説しませんが、S3内の特定ファイルにログを書き込むコードになっています。 import boto3 import json def lambda_handler(event, context): s3_bucket_name = 's3-lambda-log-test' s3 = boto3.client('s3') data = event['awslogs']['data'] if 'test' in data: print(f"Found 'test' in log data.") s3_key = f"log-data.json" s3.put_object(Body=json.dumps(data), Bucket=s3_bucket_name, Key=s3_key) return { 'statusCode': 200, 'body': json.dumps('Successfully processed log data.') } 1. Lambda関数の環境変数の設定 先ほどの「7.TW_POLICYの生成」で生成したKeyと値をLambdaの環境変数に入力します。 2. Lambda関数の修正 ライブラリの追加 最初に先ほど「6.ディフェンダーライブラリのダウンロード」にてダウンロードしたライブラリをLambdaに追加します。 先ほどダウンロードした「twistlock_serverless_defender.zip」を解凍します。 解凍し、中に入り「twistlock」というフォルダの中に入ります。 そうすると以下画像の3つのファイルがあることを確認します。 Lambda関数のファイルのダウンロードを行います。 「ファンクションコード .zip をダウンロード」を押下し、zipファイルをダウンロードし、解凍します。 解凍したファイルの末尾がランダムな英数字になっているので、元のLambda関数の名前に変更します。 1で解凍した「twistlock_serverless_defender」のディレクトリの中にある「twistlock」を今回ダウンロードしたLambda関数名のフォルダに入れます。 以下画像のようになれば大丈夫です。 lambda_function.pyとtwistlockを選択し、zip化します。 lambdaに先ほどzip化したzipファイルをアップロードします。 「コード」→ 画像右上の「アップロード元」→「.zipファイル」から先ほどのzipファイルを選択します。 以下画像のようになればライブラリの追加は完了です。 コードの修正 次にコードの修正をしていきます。 修正したコードは赤アンダーライン部分です。 先ほどLambdaにファイル追加した「twistlock.serverless」をimportして、「lambda_handler」関数をラップするとサーバーレスディフェンダーを関数に埋め込むことができます。 import boto3 import json import twistlock.serverless @twistlock.serverless.handler def lambda_handler(event, context): s3_bucket_name = 's3-lambda-log-test' s3 = boto3.client('s3') data = event['awslogs']['data'] if 'test' in data: print(f"Found 'test' in log data.") s3_key = f"log-data.json" s3.put_object(Body=json.dumps(data), Bucket=s3_bucket_name, Key=s3_key) return { 'statusCode': 200, 'body': json.dumps('Successfully processed log data.') } 3. 正常に Prisma Cloud と接続されているか確認 これで関数組み込み型のサーバーレスディフェンダーの導入が完了しました。 Lambda関数が1回動作しないとPrismaCloudコンソールに表示されないので1回動作させます。 Prisma Cloud コンソールで「ホーム」→「Defenders」に行くとLambda関数名が「Host」のところに出ているのが確認できます。   サーバーレスディフェンダーの導入(レイヤー型) 次はレイヤー型のサーバーレスディフェンダーの導入を行っていきます。 レイヤー用のzipファイルのダウンロード 左上の選択が「ランタイムセキュリティ」になっていることを確認します。 「ホーム」→ 左ペイン「MANAGE」→ 「Defenders」に行きます。 「Manual deploy」を押下します。 押下すると設定画面に遷移します。 変更した設定値は関数組み込み型と同じ以下の通りです。 Method: Single Defender Defender Type: Serverless Defender – AWS                   次に「Manual Deploy」に行き設定をします。 ManualDeployに行ったら以下を設定します。 Runtime: Python Deployment type: Layer Function name: defender-test Region: Tokyo 関数組み込み型とほとんど同様ですが、 Runtimeは今回はPythonを使用するのでPythonを指定しています。 Deployment typeはレイヤー型を使用する場合は、Layerを指定します。 Function nameはLambda関数名と同じにします。 RegionはTokyoを指定しています。 ディフェンダーライブラリのダウンロード Download fileのCommandかDownload file directlyどちらかでレイヤー追加用のzipファイルのダウンロードを行ってください。 TW_POLICYの生成 Lambdaの環境変数に使うTW_POLICYの生成を行っていきます。 「Generate」ボタンを押して、KeyとValueを保存しておきます。 レイヤーの追加 次はLambda関数にレイヤーを追加しますが、その前にレイヤーの作成を行います。 レイヤーの作成 「Lambda」→「レイヤー」→「レイヤーの作成」を押下していきます。 名前: twistlock .zipをアップロード: twistlock_defender_layer.zip 互換性のあるランタイム – オプション: python3.8 他はオプションなどは自由に選択などをしてください。 入力出来たら、「作成」を押下します。 名前はtwistlockを指定してください。 .zipをアップロードは先ほど「レイヤー用のzipファイルのダウンロード」の「5. ディフェンダーライブラリのダウンロード」でダウンロードしたzipファイルを選択してください。 互換性のあるランタイム – オプションはlambdaで使うランタイムを選択してください。 今回はpython3.8でLambda関数を作成したのでpython3.8を指定しています。 Lambda関数にレイヤーを追加する 「Lambda」→「(関数名)」→「コード」→ 一番下にある「レイヤー」→「レイヤーを追加」を押下します。 「レイヤーを選択」→「カスタムレイヤー」→先ほど作成した「twistlock」→ バージョンは最新のものを選択します 選択したら「追加」を押下します。 Lambda関数の環境変数の設定 関数組み込み型と同様に環境変数に設定するものがあるので設定します。 先ほど「6. TW_POLICY」で生成したKeyと値を環境変数に入力します。 次にORIGINAL_HANDLERを環境変数に追加する必要があるので追加します。 値には現在のハンドラ名を入力します。 「コード」→「ランタイム設定」→「ハンドラ」で現在のハンドラ名を確認できます。 デフォルトだと「lambda_function.lambda_handler」になっています。 ハンドラー設定の変更 次にLambda関数のハンドラー設定を変更します。 「コード」→「ランタイム設定」→「ハンドラ」に行きます。 ハンドラ: twistlock.handler ハンドラ名を変更したら「保存」を押下して保存します。 正常に Prisma Cloud と接続されているか確認 これでレイヤー型のサーバーレスディフェンダーを導入することができました。 関数組み込み型と同様でLambda関数を1回動作させないと Prisma Cloud コンソール上に現れないのでLambda関数を1回動作させます。 Prisma Cloud コンソールで「ホーム」→「Defenders」に行くとLambda関数名が「Host」のところに出ているのが確認できます。 おわりに 当社では、複数クラウド環境の設定状況を自動でチェックし、設定ミスやコンプライアンス違反、異常行動などのリスクを診断するCSPMソリューションを販売しております。 マルチクラウド設定診断サービス with CSPM｜ SCSK株式会社 CSPM ｜ Smart One Cloud Security® Powered by Prisma Cloud from Palo Alto Networks ｜ SCSK株式会社 ご興味のある方は是非、お気軽にお問い合わせください。

こんにちは、皆さん。 LifeKeeperの記事ではこれまで、製品に関する機能や利用用途についてご紹介してきました。 今回はそんなLifeKeeperとミドルウェアを組み合わせて、ミドルウェアにおけるニーズの高まりと 運用における可用性向上の方法についてご紹介していきたいと思います！   ミドルウェアにおける可用性ニーズについて 皆様は現在のパブリッククラウド環境において可用性の仕組みをどのように導入しており、 また、どんなミドルウェアの可用性を高めたいと考えておりますか。 先日、システム運用の関係者へWebアンケート（ITmedia）を実施した際、 このような結果がでました。 パブリッククラウド環境で可用性向上の仕組みを導入しているか？ という質問に対して、70%近くのお客様が可用性を導入している、と回答がございました。 システムの稼働が止まってしまっては大変ですから、大半のお客様は可用性を高めているといった結果でした。   続いて、可用性を更に高めるためには具体的なミドルウェアの選定も重要となってきます。 そこで、特に可用性を高めたいと考えているミドルウェアは何でしょうか？と質問したところ、 Microsoft SQL Server、Oracle Database、MySQL といった重要なデータ基盤である データベース関連の可用性向上のニーズが高いことが判りました。   一方で、ここ５年くらいの傾向として ・JP1/AJS ・Zabbix ・HULFT ・SVF などの共通基盤系といったミドルウェアの可用性向上ニーズの広がりを感じています。 このような傾向があるミドルウェアの中でも、 今回は 「HULFT」 について 「LifeKeeper」で可用性を高める方法をご紹介していきます！   HULFTについて まず、HULFTについてご紹介いたします。 HULFTとは、主に企業間やシステム間でのデータ転送やファイル転送を行うためのミドルウェア製品です。 特徴としては5つあります。 1. 高い信頼性 データ転送の確実性が高く、エラーが発生した場合のリトライ機能や転送状況の確認機能を備える 2. セキュリティ データ暗号化や認証機能により、安全なデータ転送を実現 3. 多様なプラットフォーム対応 Windows、Linux、Unixなど、さまざまなOSに対応 4. 簡単な操作性 GUIを利用して簡単に設定や管理が可能であり、利用が簡易 5. 高いパフォーマンス 大容量データの転送や高速なデータ処理が可能   このような特徴を持つHULFTは、金融機関や製造業をはじめとする多くの業界で利用されており、 企業内外でのデータ連携を効率化するための強力なツールとして評価されています。   HULFT × LifeKeeper データ連携ツールであるHULFTはシステム全体において重要な役割を担っており、 運用において高い可用性が求められます。   運用中はサーバーの障害やソフトウェアの障害など、24時間ｘ365日起こりうる障害への対策が必要となります。 そのため、障害対策として自動で検知し自動で復旧する事が望ましいです。   HULFTとLifeKeeperを組み合わせた構成イメージとしては以下のようになります。 このように、LifeKeeperを用いた高可用性ソリューションを組み合わせることで、 基幹系システムに求められるレベルの可用性の実現が可能となります。   製品ページ SCSKでは、上記で紹介したHULFT、そしてLifeKeeperの製品ページをご用意しております。   HULFT www.scsk.jp   「LifeKeeper」で安定稼働を実現 ｜ SCSK株式会社 「LifeKeeper」は、システム障害時にあなたのビジネスを守るＨＡクラスターソフトウェアです。オンプレ環境だけでなく、パブリッククラウド環境での安定稼働の実現にも最適です。長年培ったSCSK独自のノウハウでお客様の課題解決に向け最適なご... www.scsk.jp   ご参考までに、HULFT8のライセンス価格と技術サポート一年パックの価格表（サポート種別ごと）の定価について掲載いたします。 待機系のライセンス価格につきましては、稼働系ライセンス価格の 半額 となっております。 ■ライセンス価格 対象OS 稼働系 待機系 Linux \650,000 \325,000 Windows \400,000 \200,000   ■通常技術サポート 対象OS 稼働系 待機系 Linux \98,000 \49,000 Windows \60,000 \30,000 ※通常技術サポート窓口の対応時間として、 月曜日～金曜日9：30～17：00（祝祭日及び年末年始を除く）   ■24/365技術サポート 対象OS 稼働系 待機系 Linux \196,000 \98,000 Windows \120,000 \60,000 ※24/365技術サポートサービスとして、24時間365日をサポート   最後に 今回は、ミドルウェアの可用性ニーズが高まってきていること そして、そのミドルウェアの中の「HULFT」という製品をご紹介させていただきました。 HULFTにLifeKeeperを用いることで高可用性が実現でき、業務の安定稼働に向けて一役買うことができたらと思います。

こんにちは。磯野です。 Cloud RunでPythonプログラムを実行する際、ログレベルをCloud Loggingへ反映させる方法をご紹介します。 はじめに Cloud Runのログは自動的にCloud Loggingへ反映される Cloud Runのログは、print文やloggingライブラリを使用して標準出力に文字列を出力すると 自動的に Cloud Logging に記録  されます。 しかし、このままだとすべてログレベルがデフォルトとなってしまいます。（下記画像参照） ↑WARNINGやERRORレベルのログも、デフォルトとして表示されている このままではエラー調査やフィルタの活用が難しくなってしまう、ということで、本記事ではログレベルの反映方法をご紹介します。 方法１：公式ドキュメントの記載方法を利用 下記を参考に設定します。 Python 用 Cloud Logging の設定  |  Google Cloud cloud.google.com コードの記載方法 ログの設定方法 import google.cloud.logging client = google.cloud.logging.Client() # 実行中の環境に基づいて Cloud Logging ハンドラを取得し、 # このハンドラを Python のログモジュールと統合します。 # デフォルトでは INFO レベル以上のすべてのログをキャプチャします。 client.setup_logging() ログの出力 import logging text = "Hello, world!" logging.warning(text) Cloud Loggingへの出力結果 無事にログレベルが反映されました。 ところが… 該当のCloud Runジョブ画面 ＞ログ という画面遷移であればログが表示されたのですが 該当のCloud Runジョブ画面 ＞ 該当の実行ID ＞ ログという画面遷移だと、ログが表示されませんでした。 labelsに”run.googleapis.com/execution_name”が付与されておらず、ジョブ単位にログをフィルタすることができなかったのが原因のようです。ジョブ単位にログをフィルタする必要がある場合は、方法2を推奨します。 ※こちらGoogleの不具合のようで、googleapiのgithub上で本件 issue になっていました。 追って解消されるかもしれません。 方法2： StructuredLogHandler ()を使用する コードの記載方法 ログの設定方法 import logging import google.cloud.logging from google.cloud.logging_v2.handlers import StructuredLogHandler logger = logging.getLogger() handler = StructuredLogHandler() logger.setLevel(logging.INFO) logger.addHandler(handler)   ログの出力 出力方法は方法１と同じため、割愛します Cloud Loggingへの出力結果 ログレベルの反映・labelsの付与ができました。   まとめ ログレベルの反映に苦労したので、記事にしました。 参考になれば幸いです。

こんにちは。SCSK株式会社の上田です。 今回は、Zabbixの監視で利用できる”正規表現”という機能の使い方を紹介します。正規表現を使うことで、複雑な条件にマッチするログの監視をすることが可能です。 正規表現とは 正規表現 とは、 文字列のパターンを表現するための記法 です。特定の文字列を検索したり、置換したりする際に使われます。 例えば、電話番号やメールアドレスのフォーマットに一致する文字列を抽出したり、 Sysログ等の大量の文字列の中から特定のキーワードを含む行を検索したりするときに、正規表現が使われます。 Zabbixにおける正規表現 Zabbixでは、 Perl互換の正規表現（PCRE、PCRE2） がサポートされています。これにより、柔軟なパターンマッチングが可能になっています。 Zabbixで主に使用される正規表現をいくつか紹介します。 正規表現 意味 . 任意の一文字 * 直前の文字の0回以上の繰り返し + 直前の文字の1回以上の繰り返し ? 直前の文字の0回または1回の出現 ^ 行の先頭 $ 行の末尾 [abc] a,b,cのいずれか一文字 [^abc] a,b,c以外 | いずれかの文字列に一致 \ エスケープ文字（直後の文字を、正規表現ではなく普通の文字列とする） これらを組み合わせることによって、文字列のパターンを表現します。 とはいえ、この表だけではピンとこないと思いますので、いくつか例を挙げてみます。 【 .* 】は、 任意の一文字 ＋ それの0回以上の繰り返し ということで、 任意の0文字以上の文字列 を表します。 【 ^ zabbix .* test $ 】という正規表現は、 “ zabbix”で始まり”test”で終わる行 を表します。 【 \ [hoge \ ] 】という正規表現は、 “[hoge]”という文字列 を表します。ここで、 “[]” はそのままだと正規表現文字のため、 “[]” という文字自体にマッチさせたい場合はエスケープ文字の” \ “を使います。もしエスケープ文字が無ければ、 h,o,g,eのいずれか一文字 とマッチしてしまいます。 Zabbixでの正規表現の設定方法 ここまで正規表現とは何かについて説明してきました。続いてZabbixで正規表現を使う方法について説明します。 Zabbixでは、 アイテムキーに直接正規表現を書き込んだり 、 ユーザーマクロで正規表現を使ったり 、いろいろな場所で正規表現を使えます。 今回は、その中から グローバル正規表現 の使い方を説明します。グローバル正規表現の設定画面では、 ある文字列が作成した条件式にマッチするかのテストが実施できる ので、正しく正規表現が書けているかチェックできて便利です。 グローバル正規表現の設定方法 グローバル正規表現設定画面を開くには、ZabbixのWEBコンソールから 【管理　＞一般設定　＞正規表現】 と選択します。 正規表現の設定画面 デフォルトでいくつか正規表現が作成されています。 新しく正規表現を作成するために、右上のボタンをクリックします。 正規表現の作成画面 このような設定画面が開きます。 「文字列が含まれる」「いずれかの文字列が含まれる」「文字列が含まれない」 は、その名の通り入力した文字列が含まれるか含まれないかの条件を追記できます。 「結果が真」「結果が偽」 を選択すると、正規表現を使うことができます。 ここで、先ほど例示した正規表現を条件式に書いてみましょう。 条件式作成後の画面 これで、 【^zabbix.*test$】にマッチ し、かつ 【\[hoge\]】にマッチしない　 という条件の正規表現が作成できました。 想定通りの条件になっているかテストしてみましょう。 以下の3つの文字列を考えます。 　1：zabbixにおける正規表現のtest 　2：zabbixにおける正規表現のtestです。 　3：zabbixにおける[hoge]のtest これらは、作成した正規表現にマッチするでしょうか？ 1は、 【^zabbix.*test$】にマッチ し、かつ 【\[hoge\]】にマッチしない ので、 マッチします。 ※最終結果が真ならマッチしている、偽ならマッチしていないことを表します。 テスト①   2は、 【^zabbix.*test$】にマッチしない ので、 マッチしません。 テスト②   3は、 【^zabbix.*test$】にマッチ しますが、 【\[hoge\]】にもマッチする ので、 マッチしません。 (hogeのテストって何だろう。。。) テスト③ トリガー条件式への正規表現の適用 これで正規表現が作成できたので、これをトリガー条件式に適用してみましょう。 正規表現を使いたいトリガーの設定画面を開きます。条件式に、以下のように記入します。 find (/host/key,,"regexp","@正規表現名") find関数は、アイテムから一致する値を見つける関数です。 通常では、第1パラメーターにホスト名とアイテムキーを指定し、第4パラメータに一致させたい値を入力しますが、第3パラメータに “regexp” を指定することで、第4パラメータで正規表現が使用できます。 正規表現を指定ときは、頭に “@” を付けます。 今回は、ホスト「Zabbix server」の/var/log/messagesを監視するアイテムに対してトリガーを設定してみます。 トリガーの設定画面 これで、作成した正規表現に一致するログが出力されたら障害を検知するトリガーが作成できました。 障害検知テスト 実際にログを出力させてみて、障害検知するか確認してみましょう。 監視対象ログに、正規表現に一致するログを出力させてみます。 # echo zabbixにおける正規表現のtest >> /var/log/messages 出力したログが、アイテムとして取得されると。。。 ログアイテムの取得状況 想定通り、障害検知しました！ 障害検知結果 まとめ 今回は、Zabbixにおける正規表現の使い方と、ログ監視への適用方法をまとめました。今回は簡単な正規表現を作ってテストしましたが、うまく活用すればより複雑な条件で検知したいログを絞ることが可能です。 実際のログ監視への活用方法については、また別の記事でまとめようと思っています。 最後まで読んでいただき、ありがとうございました。   弊社ではZabbix関連サービスを展開しています。以下ページもご参照ください。 ★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

こんにちは、ひるたんぬです。 最近は耐え難い暑さが続いておりますね… 私はとても暑さに弱い生物なので、ひと月ほど前からエアコンの恩恵にあずかっているのですが、エアコンの設定温度ってとても難しいなと思っています。 というのも期待した温度にならないのです。28℃に設定してるのに25℃近くになったり、逆に30℃くらいになったり… エアコンも暑さでおかしくなってしまったのでしょうか…？今夏を乗り越えてくれるよう切に願っています。 さて、今回は業務でSDK(boto3)に触れている中で、ふと気になった点について調査をしました。 気になったこと Secrets Managerからシークレットを取得したい！と思った際、マネジメントコンソールでは各言語でのサンプルコードを示してくれています。（とても親切！！）例えば、Python3(boto3)の場合は以下のようになっています。 # Use this code snippet in your app. # If you need more information about configurations # or implementing the sample code, visit the AWS docs: # https://aws.amazon.com/developer/language/python/ import boto3 from botocore.exceptions import ClientError def get_secret(): secret_name = "SECRET_NAME" region_name = "REGION_NAME" # Create a Secrets Manager client session = boto3.session.Session() client = session.client( service_name='secretsmanager', region_name=region_name ) try: get_secret_value_response = client.get_secret_value( SecretId=secret_name ) except ClientError as e: # For a list of exceptions thrown, see # https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_GetSecretValue.html raise e secret = get_secret_value_response['SecretString'] # Your code goes here. このコードを見て、私は「 boto3.session.Session()ってなんぞや？ 」と思いました。 そう、この記述とはここで会ったのが初めてだったのです。 boto3のSessionとは こういうときに役に立つのは、やはり公式ドキュメントですね。 Boto3の公式ドキュメントには次のように記載があります。 A session stores configuration state and allows you to create service clients and resources. 引用：AWS 「 Boto3 1.34.146 documentation -Session reference- 」 つまり、アクセスキーやシークレットキーなどの認証情報を一つのオブジェクトとしてまとめて生成し、それをクライアントやリソースオブジェクトの生成時に引数として指定することで使い回すことができる、という仕組みのようです。複数のクライアントやリソースオブジェクトを生成する際に、いちいち認証情報を入力しなくて済むので、これは便利な機能ですね。 さらなる疑問 Sessionについて調べる中で、公式ドキュメント内でSessionを以下のように使っている場合もありました。 # Explicitly create a new Session for this thread session = boto3.Session() dynamodb = session.resource('dynamodb')   Python と Boto3 による Amazon DynamoDB のプログラミング - Amazon DynamoDB Python で DynamoDB をプログラミングする方法に関するさまざまな概念について説明します。 docs.aws.amazon.com そうです、”session”が一つ欠けているのです。こういうのすごく気になってしまうんですよね… こちらについては、結論から言いますと同じオブジェクトを指しておりました。 せっかくなので、boto3のソースコードを見て確認してみましょう。 今回は執筆時点での最新バージョンである「1.34.146」のコードで確認しています。 GitHub - boto/boto3 at 1.34.146 AWS SDK for Python. Contribute to boto/boto3 development by creating an account on GitHub. github.com boto3.session.Session()と記載する場合 この場合は、boto3フォルダにある”session.py”を参照し、Sessionクラスを呼び出しています。 boto3.Session()と記載する場合 この場合は、boto3フォルダにある”__init__.py”を参照します。 するとこのファイルの17行目に from boto3.session import Session と記載があります。これによって、boto3フォルダにある”session.py”を参照し、Sessionクラスを呼び出していることが分かりましたね。 おわりに 細かいところが気になってしまう性分なのでしっかり調べました。 こういうことを一つずつ知るたびに成長しているなぁ…と実感できて嬉しいです。 余談ですが、botoの名前の由来は「アマゾン川に自生する淡水イルカ（アマゾンカワイルカ）」だそうです。 アマゾンカワイルカ｜海棲哺乳類データベース www.kahaku.go.jp また、Boto 3 の数字はライブラリのメジャーバージョン（3番目）を示しているようです。 下記サイトに載っていたのですが、なぜDynamoDB上のドキュメントにBotoの由来などが記載されているのでしょうか…謎は深まるばかりですね。 Python と Boto3 による Amazon DynamoDB のプログラミング - Amazon DynamoDB Python で DynamoDB をプログラミングする方法に関するさまざまな概念について説明します。 docs.aws.amazon.com

  Cato Networks社が、2024年7月3日に発行された ガートナー（Gartner™）のマジック・クアドラント（Magic Quadrant™）のシングルベンダー SASE 部門においてリーダーに認定されました 。 ガートナーのマジック・クアドラントの調査レポートについては、以下のCato社のサイトから閲覧することが可能ですが、後日、Cato Networks社が日本語訳した調査レポートを無償公開する予定になっています。 Cato Networks named a Leader in the 2024 Gartner® Magic Quadrant™ for Single-Vendor SASE Cato named a Leader in the Gartner® Magic Quadrant™ for Single-Vendor SASE. Want to learn more? Download the full report... www.catonetworks.com   日本語記事 Cato Networks、2024年 Gartner Magic Quadrantのシングルベンダー SASE 部門においてリーダーに認定 Cato Networks株式会社のプレスリリース（2024年7月16日 10時00分）Cato Networks、2024年 Gartner Magic Quadrantのシングルベンダー SASE 部門においてリーダーに認定 prtimes.jp Cato Networks、2024年 Gartner Magic Quadrantのシングルベンダー SASE 部門においてリーダーに認定 Cato SASE クラウド プラットフォームは、引き続きエンタープライズ セキュリティ市場を形成 www.catonetworks.com   昨年（2023年）のマジック・クアドラントはチャレンジャー認定でした、今年は晴れてリーダーに認定されました。 特に日本の企業では、ソリューションの検討・採用時に、ガートナーのマジック・クアドラントを重要視されるケースが非常に多いので、とりあえずリーダーの認定されて一安心と言ったところです。   2024年にガートナーが、Secure Access Service Edge（SASE、サッシー）を提唱する以前（2015年）にCato Networks社は創業しており、Catoクラウドは、当初からSASEの概念で、クラウドネイティブなプラットフォームを構築しており、SASEの市場を新たに開発し、牽引した革新的なパイオニアとして評価されています。 また、企業買収（M&A）によるセキュリティ機能統合を行っていないことから、「統一されたプラットフォーム」が高い評価を得ており、単一で、シンプルなUIの提供が、ユーザにも高く指示されています。 その結果、ユーザエクスペリエンス（UX）についても、他ベンダーと比較して高い評価を得ています。 他ベンダーを比較し、（都度ベンダーに設定を依頼するのではなく）お客様ご自身で、設定・運用を行うことができるソリューションとしても、高い評価を得ています。    IT専門家やテクノロジー意思決定者による偏りのない評価とレビューである ガートナーのピア・インサイト（Gartner Peer Insights™） においても、Cato クラウド プラットフォーム は、シングルベンダー SASE の総合評価で 5 点満点中 4.7 点を獲得しており、検証済みレビューが 183 件あり、シングルベンダー SASE マジック・クアドラントに選出されたすべてのリーダーの 10 倍以上の評価レビュー数になります。   ガートナーの市場予想では、シングルベンダーSASEは、2024年の 20% から、2027年までに新しくSD-WAN購入する 65%がシングルベンダーSASEを採用するされており、今後、シングルベンダーSASE市場が大きく拡大するとされていますので、是非、Cato Networks社、Catoクラウドをご検討ください。   Cato Networks社、Catoクラウド（Cato Cloud/Cato SASE Cloud）については、以下の記事を是非ご参照ください。 Catoクラウド エンジニアブログまとめ記事 Catoクラウドのエンジニアブログ（TechHarmony）でのまとめ記事となります。 blog.usize-tech.com 2024.02.27 Catoクラウドにご興味をもられましたら、サービス紹介やデモ等を行いますので、お気軽に お問い合わせ ください。

皆様、いつもお仕事お疲れ様です。 今夏、Zabbix Jpanが主催する Zabbix全国5都市キャラバン2024 が開催されます！！ このイベントでは、Zabbixを知らない人から既にご利用いただいている方まで幅広い方を対象としたイベントとなっております。特に、Zabbixの導入をご検討されている方には有意義なイベントであると思います！ イベント概要 Zabbix全国5都市キャラバン2024では、 Zabbix Japan及びZabbixパートナー企業によるセミナー が行われます！Zabbixについての最新情報やパートナー企業のZabbixソリューションについて知ることができます！ イベントではセミナーと併せて テクニカル相談会 も実施されます！！相談会ではZabbix Japanのエンジニアやパートナー企業エンジニアが、導入やアップデート、運用に関する不明点や困りごとについて相談に乗ります。相談ごとのある方はぜひこの機会をご利用ください╭( ・ㅂ・)و ̑̑ ｸﾞｯ   開催日と会場は下記のとおりです。複数日程ございますので、都合のいい日程・会場でご参加いただければと思います。 2024年8月2日  （東京会場　：品川フロントビル会議室） 2024年8月23日（名古屋会場：AP名古屋） 2024年9月13日（大阪会場　：グランフロント大阪　カンファレンスルーム） 2024年9月20日（福岡会場　：JR博多シティ会議室） 2024年9月27日（札幌会場　：HOTnet共創空間 Akallabo）   Zabbix全国5都市キャラバン2024の来場登録は「 Zabbix5都市キャラバン2024 」からお願いします。 ホームページでは、セミナーの講演内容も記載されていますので、興味のある講演内容を探してみてください！   SCSKのセミナーについて SCSKは Zabbixへのスムーズな乗り換え – SCSK Plus サポート for Zabbixのご紹介 と題して、SCSKが今夏にローンチする Quick Start Package for Zabbix についてお話しさせていただきます。 本サービスは、弊社にて2017年よりZabbix構築サービスを提供してきた中で、よくある構築環境をパッケージ化したサービスとなります。サーバ環境や構築サービス、サポート等で複数のコースを用意しており、それらを組み合わせるバイキング形式のパッケージとなっております。 お客様環境に合わせて最適な組み合わせが可能となっております！！！ SCSKは上記5会場全てにおいて講演いたしますので、どこかの会場でお会いできることを楽しみにしてます！   さいごに 最後までお読みいただきありがとうございます。 ちなみにですが、ここまでZabbix全国5都市キャラバン2024について熱く語ってきましたが、筆者は5会場いずれにも参加しません。 本ページ見てイベントに参加しようと思った方は、筆者の分も楽しんできてくださいね！   本当のさいごのさいごに、弊社ではZabbix関連サービスを展開しています。以下ページもご参照ください。 ★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の吉田です。 初めてのブログ投稿となります。今後、ServiceNowに関する様々な情報をアウトプットしていきたいと思いますのでよろしくお願いします！ 2か月前のことになりますが、5月にServiceNowの年次ビッグイベント 「Knowledge 2024」 に参加してきました。 イベントの概要は以下の通りです。 日程：5月7日～5月9日の3日間 階催場所：米国ラスベガスのThe Venetian Convention & Expo Center 参加人数：グローバルで20,000人弱（うち日本からは300名以上が参加） 内容：KeyNote(基調講演)、Expo(展示会)、Session、オンサイトミーティングなど 今回は現地での体験談をお伝えします！ ラスベガスで認定資格取得にチャレンジ！ まずは自己紹介もかねて個人のお話から。 こちらはKnowledge 2024で実施された、イベント会場でServiceNowメインライン認定資格の受験にチャレンジする取り組みです。 今回、人事領域アプリケーションの導入者向け資格である「Certified Implementation Specialist – Human Resources」を受験し、見事合格することができました！ さらに本イベントには 日本から唯一の参加者 ということもあり、最終日のJapan Closing Sessionで紹介していただけました。 （自称：初代ラスベガスでServiceNow認定資格を取得した人） 試験後に合格したことをスタッフに伝えると記念のピンバッジを頂けました。 試験開始前に他の受験者と「緊張するね」と会話したり、イベント会場でバッジを見た人から「これは何？」と聞かれて立ち話が始まったりと、思いがけず海外の方とも交流できて非常に良い経験となりました。   KeyNote KeyNoteでは、Bill Mcdermott氏による講演や、製品ロードマップ、ライブデモなどが行われました。 特に生成AIに関する発表が多く、ServiceNowがビジネス変革のためのAIプラットフォームへと進化している点が強調されていました。 会場へは入りきれないほどの参加者が集まり、講演中は都度、歓声が上がるなどすごい盛り上がりでした。 KeyNoteを通じて、参加者全員のServiceNow、生成AIに対する熱気を改めて感じることができました。   Session・Expo イベント期間中は、多数のセッションが同時に開催され、各自が興味のあるセッションを予約して参加する形となります。 私は主に以下のセッションに参加してきました。 ServiceNowの活用事例 生成AIを活用する上でのTipsや機能紹介 製品ロードマップ ServiceNowの生成AI機能がリリースされてから数カ月にも関わらず、開催されたセッションのうち、生成AIに関するセッションが多くを占めていたのがとても印象的でした。   また、Expo会場では各企業の展示ブースがあり、ServiceNowを活用しているデモを見たり、企業の担当者と会話することができます。 IoTやAIとServiceNowを組み合わせた体験型のブースも数多くあり、会場全体で非常に盛り上がっていました。   最後に 以上、Knowledge 2024の現地体験レポートでした。 今回、初めての参加でしたが、個人として感じたことは主に以下3点となります。 ServiceNowに関わる全ての人の熱気がすごい ビジネスにおいてAIの活用が前提となっている時代となりつつある 個人としてAIを活用しきれていないことに対する危機感 また、ServiceNowに関わる者としてServiceNowをさらに盛り上げていこうというモチベーションをより上げることができたのが、一番の収穫でした。 今後もServiceNowに関する情報をアウトプットしていきたいと思います！  

こんにちは、SCSKでAWSの内製化支援『 テクニカルエスコートサービス 』を担当している貝塚です。 AWSサービスに接続するためのVPCエンドポイント(ssm.ap-northeast-1.amazonaws.com など)がVPCごとに作られていくのは管理上よろしくないと考える方はいらっしゃるようでして、VPCエンドポイントを1か所に集中させたいというご要望を頂くことがございます。 これを実現するうえで重要なのは、DNS名前解決をどのように行うか、です。本稿では、マルチアカウント環境において、AWSサービス用のVPCエンドポイント(ssm.ap-northeast-1.amazonaws.com など)を一つのVPCに集約した場合のDNS名前解決パターンについて考察します。 ※VPC間の接続にTransit Gatewayを何の説明もなく使用していますが、Transit Gatewayをよく知らないという方でも、VPC間を接続するサービスということだけ理解していれば本稿を読み進めるのに支障ありません。 プライベートホストゾーンを使う案 対象ドメイン(例：ap-northeast-1.amazonaws.com)のプライベートホストゾーンを作成し、各アカウント・各VPCに関連付けることで、ハブVPC上のVPCエンドポイントの名前が返るようにします。 アーキテクチャ図は以下の通りです。 プライベートホストゾーンではハブVPC上のDNS名とIPアドレスを対応付けるAレコードを作成しておきます。スポークVPCでAmazon Provided DNS(デフォルトで設定されるDNS)にDNSクエリを発行すると、プライベートホストゾーンに登録されたハブVPC上のIPアドレスが返ってきます。 こちらの構成は、クラスメソッドさんの下記記事で既に解説されていますので、本稿では気づいた点を何点か述べるに留めます。 複数VPCで名前解決を集約・共有する方法を試してみた | DevelopersIO 複数のVPCで名前解決をいい感じに共有または集約する方法を試してみました。今回シングルアカウント内のVPCで試していますが、大枠の考え方はマルチアカウントでも利用できると思います。 dev.classmethod.jp ap-northeast-1.amazonaws.com や amazonaws.com でプライベートホストゾーンを作成しようとすると、既にAWSに予約されているという理由でエラーになるので、bedrock.ap-northeast-1.amazonaws.com や kendra.ap-northeast-1.amazonaws.com のようにサービス名ごとにプライベートホストゾーンを作成する必要がある。 プライベートホストゾーンを他アカウントのVPCに関連付ける作業はマネジメントコンソールからは実行できず、CLI等から実施する必要がある。 名前解決したいホスト名の数 × 関連付けたいVPCの数 だけ関連付け作業を実施する必要があるので、規模が多くなってきたらスクリプト化・IaC化必須である。 ドメイン名 ap-northeast-1.amazonaws.com のゾーン作成はエラーになる プライベートホストゾーン設定例(kendra.ap-northeast-1.amazonaws.comゾーンのレコード作成) 他のアカウントのVPCにプライベートホストゾーンを関連付ける手順についても以下のクラスメソッドさんの記事で解説されていますので、そちらをご参照ください。 [Route 53]他のAWSアカウントのVPCにプライベートホストゾーンを関連付ける | DevelopersIO Route 53で作成したプライベートホストゾーンを他のAWSアカウントのVPCに関連付ける方法をご紹介します。 dev.classmethod.jp なお、この手順で関連付けられたホストゾーンは、マネジメントコンソールから確認することができず、CLIの route53 list-hosted-zones-by-vpc などで確認する必要があるようです。 DHCPオプションセットを使う案 スポークVPCにDHCPオプションセットを適用して、(EC2などが)参照するDNSサーバのIPアドレスにハブVPC上のRoute 53 Resolverインバウンドエンドポイントを指定する方法です。 アーキテクチャ図を描くと以下の通りです。 こちらも先ほどご紹介したクラスメソッドさんの記事で既に解説されていますので、本稿では詳しい説明を割愛します。 複数VPCで名前解決を集約・共有する方法を試してみた | DevelopersIO 複数のVPCで名前解決をいい感じに共有または集約する方法を試してみました。今回シングルアカウント内のVPCで試していますが、大枠の考え方はマルチアカウントでも利用できると思います。 dev.classmethod.jp ハブVPC内のRoute 53 Resolverインバウンドエンドポイントは、同じVPC内にあるVPCエンドポイント(この例の場合は bedrock.ap-northeast-1.amazonaws.com)の名前解決時にプライベートIPアドレスを返しますので、プライベートホストゾーンを作成する必要はありません。 スポークVPC(内のEC2等)が参照するDNSサーバがハブVPC上にあるため、スポークVPC独自の名前解決をさせたいときに難易度が上がります。例えばできる限りSession Managerがネットワーク障害の影響を受けないようにする目的で、Session Manager用のVPCエンドポイントだけはスポークVPC内に作成したい(他のVPCエンドポイントはハブVPC内に置きたい)となった場合に、対応ができません。 スポークVPCにRoute 53リゾルバ アウトバウンドエンドポイントを置く案 私が無い知恵をふりしぼって最初に考えた構成です。ハブVPCにRoute 53リゾルバ インバウンドエンドポイントを作成し、スポークVPCにはRoute 53リゾルバ アウトバウンドエンドポイントを作成します。スポークVPCで発行されたap-northeast-1.amazonaws.comドメインのDNSクエリは、リゾルバ転送ルールを使用してハブVPCのインバウンドエンドポイント(のIPアドレス)に向けてやります。 図にするとこのようになります。   この構成は動作します。しかし、VPCごとにRoute 53リゾルバ アウトバウンドエンドポイントが必要になり、冗長構成が必須であることも考慮するとそれだけで月180ドルの料金がかかってしまいますので、今回の目的に照らし合わせると没案と言わざるを得ません…。 Resource Access Managerでリゾルバルールを共有する案 私が費用対効果の悪い案をひねり出すより前に、AWSからとっくに以下のようなアーキテクチャが公開されていました。 複数の VPC から中央のAWS のサービスエンドポイントにプライベートにアクセスする - AWS 規範ガイダンス docs.aws.amazon.com リンク先にも示されていますが図にすると以下のようになります。(リンク先とは図が若干異なりますが、私なりに同じものをより分かりやすく示そうとした結果です) 構成を細かく分解して説明すると以下の通りです。 ハブVPCに、Route 53リゾルバ インバウンドエンドポイントだけではなく、Route 53リゾルバ アウトバウンドエンドポイントも作成する リゾルバ転送ルールを作成し、ap-northeast-1.amazonaws.comドメインの名前解決をRoute 53リゾルバ インバウンドエンドポイント(のIPアドレス)に転送するように設定する リゾルバ転送ルールをResource Access Manager (RAM)を使ってスポークアカウントと共有する スポークアカウント側で、リゾルバ転送ルールをスポークVPCに関連付ける 上記の通り構成することで、スポークVPC側にRoute 53リゾルバ アウトバウンドエンドポイントがなくても、Amazon Provided DNSは、ap-northeast-1.amazonaws.comドメインの名前解決DNSクエリを ハブVPCのRoute 53リゾルバ インバウンドエンドポイントへと転送してくれます。 構築時のポイント ハブアカウント側、リゾルバ転送ルールの作成 今回の目的は、ap-northeast-1.amazonaws.comドメイン(AWSサービスのVPCエンドポイント)の名前解決をハブVPCに転送することなので、ルールの作成画面でドメイン名にap-northeast-1.amazonaws.comを指定します。 VPCは指定する必要がありません。 ターゲットIPアドレスに、Route 53リゾルバ インバウンドエンドポイントのIPアドレスを指定します。 ルール作成画面 Resource Access Manager (RAM)を使用した転送ルールの共有 Resource Access Manager (RAM)メニューの「自分が共有: リソース共有」から「リソース共有を作成」ボタンを押します。 そこから先の設定は、以下にスクリーンショットを載せました。 「リソース – オプション」のところで「リゾルバルール」を選び、対象のルールをチェックします。 マネージド型アクセス許可は、デフォルトのまま変更しませんでした。 プリンシパルタイプは、「AWSアカウント」を選択し、スポークアカウントのアカウントIDを入力します。 また、スクリーンショットは載せていませんが、スポークアカウント側でResource Access Manager (RAM)メニューの「自分と共有: リソース共有」から「リソース共有を承認」する必要があります。 リゾルバ転送ルールをスポークVPCに関連付け 共有された転送ルールは、Route 53 > リゾルバー > ルール のルール詳細から、「VPCを関連付ける」をクリックし、スポークVPCを関連付けます。 VPC関連付け後の転送ルール(スポークアカウント側) 名前解決確認 以上で設定は完了です。スポークVPCのEC2からdigコマンドでssm.ap-northeast-1.amazonaws.comの名前解決を実行すると、ハブVPCのssmエンドポイントのIPアドレスが返ってきました。 DNSクエリの通信経路はどうなっている？ この構成で、DNSクエリ(UDP 53番ポートの通信)は実際にどのように行われているのでしょうか。調べてみることにします。 アーキテクチャ図再掲 この構成なら、スポークVPCのAmazon Provided DNS(10.1.0.2)からRoute 53リゾルバ インバウンドエンドポイント(10.0.33.153, 10.0.34.129)へのIP通信が発生しているのではないか？と推測しました。 しかし、DNSクエリログと照らし合わせながらVPCフローログを調べて行きますが、スポークアカウント側に該当するログはありません。それどころか該当の時間帯に、UDP 53番ポートの通信は一切発生していませんでした。 スポークアカウント側のDNSクエリログ スポークアカウント側のVPCフローログ。srcPortでDNSクエリログと照らし合わせを試みるが、該当ログなし 次に、ハブアカウントを見ていきます。 ハブアカウント側のDNSクエリログを見ると、上記と同時刻に同内容のDNSクエリが確認できるので、スポークVPCで発生したDNSクエリが、ハブVPCまで到達し、ハブVPC側で応答を返したと考えられます。以下がそのログです。 ハブアカウントのDNSクエリログ ハブアカウント側のVPCフローログも調べて行きます。スポークVPCからのUDP 53番ポート通信は発見できませんでしたが、該当時間帯に以下のログを発見しました。 ハブアカウントのVPCフローログ DNSクエリログのタイムスタンプと若干ずれがありますが、srcPortが一致(46161)していることから、同じ通信のことを指しているとみて間違いないでしょう。 srcAddrの10.0.34.254は、Route 53リゾルバ アウトバウンドエンドポイントのIPアドレス(のひとつ)です。スポークVPCで発生したDNSクエリは、Route 53リゾルバ アウトバウンドエンドポイントで一種のNATのようなものが行われてハブVPCにやって来たと推測できます。 dstAddrの10.0.34.129は、Route 53リゾルバ インバウンドエンドポイントのIPアドレス(のひとつ)です。ここまで到達して、Route 53による名前解決が行われたと考えられます。 以上の情報をまとめると、下図青色実線矢印の通信が確認できたことになります。 青色破線矢印の部分がどのように行われたか、ですが、VPC側のフローログを確認しても該当するログは発見できませんでしたので、AWSインフラ側を通る通信であり、ユーザ側(VPC)からは見えないようになっているのだと考えられます。 まとめ 本稿では、AWSサービス用VPCエンドポイントをひとつのVPCに集約したい場合のDNS名前解決アーキテクチャとして以下の4つを概観しました。 プライベートホストゾーンを使う案 DHCPオプションセットを使う案 スポークVPCにRoute 53リゾルバ アウトバウンドエンドポイントを置く案 Resource Access Managerでリゾルバルールを共有する案 また、第4案について、構築時のポイントを解説するとともに、DNSクエリの通信を追ってみた結果、通信の一部がAWSインフラ側を通っていると考えられることを示しました。 本稿の内容がDNS設計のお役に立てば幸いです。

本記事では、Catoクラウドを運用するにあたって、特に知っておくべきIT用語をピックアップして解説していきます。 Catoクラウドの運用においては、多くのネットワーク・セキュリティに関する専門用語が登場します。 これらの用語を知識として持っている方も多いかと思いますが、具体的にCatoでどのように扱われているか、実例を交えながらご説明します。 今回は【ネットワーク編】と題して、ネットワーク用語を取り上げてご説明していきます。 今後【セキュリティ編】【応用編】を随時公開予定です。 そもそもSASEとは、Catoクラウドとは何か、が知りたい方は以下の記事をご覧いただければと思います。 ・ 世界初のSASEプラットフォーム Catoクラウドとは？ – TechHarmony (usize-tech.com) それでは早速、用語解説を始めていきます。 パケット パケット(Packet)とは、データ転送において、効率よくデータを送るために小分けした単位のことです。 Catoでは、パケットがネットワーク上できちんと転送できているか、パケットロス率としてモニタリングできます。 ネットワーク運用で起こりうるケースとして、通常はスループットに比例してパケット数も増えるものですが、スループットは低いがパケット数が多いケースがあります。 小さなパケットを大量に送信している状態です。 この状態のとき、ルータやスイッチなどの性能制限によって、一定時間に処理できるパケット数に上限があり、期待した性能が出ないことがあります。 パケットロスと似た用語に、Catoではディスカードがあります。 ディスカードは、拠点の最大帯域を超えた通信が発生し、Socketがパケットを破棄したときに発生します。 ディスカードが多い時には、後程解説するスループットと合わせて最大帯域の増速をご検討いただければと思います。 トラブル時など性能グラフを見るときは、スループットだけでなくパケット数やディスカードも確認ポイントとなります。 フロー フロー(Flow)とは、ある特定のデータ通信の流れを指します。 これは、特定の送信元と受信先の間でやり取りされる一連のパケットを意味します。フローの具体的な要素としては、IPアドレス / ポート番号 / プロトコルの情報で構成されています。 Catoでは、フロー数のモニタリングも可能になっています。 また、ホストごとにもフロー数を見ることができ、特定のホストだけが異常な値を検出している場合にはセキュリティインシデントが発生している可能性も考えられます。 そういった調査観点でもフロー数をモニタリングすることは重要と言えます。 従来のネットワーク機器では、フロー数に比例してメモリを利用しています。ネットワーク機器上で、フローごとにNATや動的なFWルールの管理をしているため、機器のメモリ量に依存して同時に通信可能なフロー数に上限があります。 ただし、Catoではソフトウェアによってこれらの機能を実現しスケールアウトしています。Catoでは実質的なフロー数の上限は存在していないとも言えます。 トラフィック・スループット トラフィック(Traffic)とは、回線・ケーブルを流れるデータやその総量のことを言います。 また、トラフィックと近しい言葉に、スループット(=帯域)があります。 トラフィックがデータ総量であるのに対して、スループットは単位時間あたりに流れるデータ量のことを言います。 一般的なモバイル通信におけるトラッフィクの平日の一日の推移としては、お昼時間帯や帰宅時間帯がピークになり、深夜から早朝にかけた時間帯が少ない傾向にあります。 また、企業においては、勤務開始の午前9時前後がピークになった後なだらかになり、お昼時間帯には再度Youtubeなどへのアクセスが増えるためやや上昇、勤務終了以降の18時ごろから段々と少なくなるという傾向にあります。 さらに、回線・ケーブルごとに利用可能な最大帯域が決められています。 これは、ISPとの契約時に回線ごとに決めるもので、最大帯域を大きくするほど費用もそれに応じて高くなります。 最大帯域を超えると、パケットの破棄や通信遅延が発生してしまうため、想定される帯域と予算を天秤にかけながら、ネットワーク設計者は契約帯域を決定する必要があります。 Catoクラウドでは、スループットをモニタリングできます。 通信が不安定になった際には、こちらのグラフで最大帯域を超過していないか確認いただくのも1つの切り分け方法と言えます。 スループットが最大帯域に張り付いているような状況の際には、契約帯域の増速をご検討いただければと思います。 QoS QoS（キューオーエス）とは、「Quality of Service」の略称で、日本語では「サービス品質」と訳されます。 インターネットや社内ネットワークなどで、データを送受信する際の品質を確保するための仕組みです。 QoSは、重要なデータが遅延したり止まったりしないように、どのデータを優先して送るかを決めて品質を確保します。 通常、回線の最大帯域を超えるトラフィックが発生すると、通信機器で遅延やパケットの破棄が発生します。 このような問題を解決する仕組みがQoSです。QoSには優先制御や帯域制御といった制御の種類があります。 優先制御であれば、例えばWeb会議のような即時性が求められる通信に対して優先度を高く設定することが多いです。 一方で、メールのような急がない通信では、優先度を低く設定することがあります。 この制御によって、Web会議の快適な通信を実現できます。 CatoクラウドでもQoSの仕組みが導入されています。詳細を知りたい方は、以下の記事をご覧ください。 ・ CatoクラウドのQoSについて – TechHarmony (usize-tech.com) ルーティングテーブル ルーティングテーブルとは、主にルータやL3スイッチなどのネットワーク機器がデータをどこに送るかを決定するために使用するテーブルのことです。 また、ネットワーク機器に限らずPCやサーバのようなIPアドレスで通信する、ほぼ全ての機器がルーティングテーブルを持って通信しています。 例えば皆さんお使いのPC上で、Windowsであれば、コマンドプロンプトで route print というコマンドを打てばルーティングテーブルを見られます。 ルーティングテーブルは、基本的には次の要素で構成されています。 • 宛先IPアドレスもしくはサブネット：最終的なデータ転送先のIPアドレスもしくはサブネット。 • ゲートウェイ：データが次に送られる中間地点のIPアドレス。 • 出力インターフェース：データが送信されるネットワーク機器のポート • メトリック：ルートの優先順位を示す値。小さいほど優先度は高くなる。 Catoに限らず、ルーティングテーブルはネットワーク構成を考えるうえで、まず最初に検討を始める部分と言えます。 DHCP DHCPは、「Dynamic Host Configuration Protocol」の略称で、ネットワーク管理プロトコルの一つです。 ネットワーク内の機器に自動的にIPアドレスを割り当てる際に主に使用されます。 DHCPはIPアドレスの他、IPアドレスのサブネットマスク、ネットワーク内で利用可能なDNSサーバのIPアドレス、外部ネットワークとの出入り口であるデフォルトゲートウェイのIPアドレス、割り当てられたアドレスのリース期間（使用期限）などの情報を通知します。 DHCPの利点は、機器利用者が手動で設定することなく、ネットワーク管理者が適切な設定を自動で適用できることです。 DHCPは、ネットワーク管理者にとって、IPアドレスの管理負担軽減のため有効なプロトコルとなっています。 ドメイン名・FQDN ドメイン名とは、ネットワーク上に存在するコンピュータやネットワークを識別するための名前のことです。 コンピュータやネットワークを識別する際、IPアドレスが利用されますが、単なる数字の羅列のため人間が覚えづらく識別しづらいです。 そのため、識別しやすいように、文字・記号を組み合わせたドメイン名をつけることができます。 例えばGoogleであれば、「www.google.co.jp」にアクセスします。 上図のように、ドメインは実世界の住所表示のように広い領域を指す名前から順に範囲を狭めていく階層構造になっています。 各階層の識別名を「.」で区切って表記されています。 一番右が最上位階層で、左に向かって階層が下がっていきます。 それぞれ右からトップレベルドメイン(jp)、セカンドレベルドメイン(co)、サードレベルドメイン(google)呼ばれます。 また、特に実際にアクセス先となる「www.google.co.jp」は「FQDN」（完全修飾ドメイン名）とも呼ばれます。 なお、Catoでは、FWルールを設定する際、ドメイン名とFQDNを区別して設定する仕様になっています。 仮にgoogle.co.jp配下のサブドメインをすべて制御したい場合はDomainを選択、www.google.co.jpを完全一致で個別に制御したい場合にはFQDNを選択します。 このように、Catoに限らず用語ごとの設定仕様をよく確認することも実際の設定作業において重要になります。 DNS DNSとは、「Domain Name System」の略称で、上記で説明したドメイン名とIPアドレスの対応関係をネットワーク上で管理しているシステムのことです。 外部からのドメイン名の問い合わせ解決するサーバをDNSサーバと呼びます。 反対にDNSサーバへ問い合わせするコンピュータをDNSクライアントもしくはDNSリゾルバと言います。 また、ドメイン名とIPアドレスの対応関係をサーバへの問い合わせによって明らかにすることを「名前解決」と呼びます。 ドメイン名から対応するIPアドレスを求めることを「正引き」、逆にIPアドレスからドメイン名を割り出すことを「逆引き」と呼ばれます。 ネットワーク設計において、特に社内ネットワークなどでFQDNを使った通信がある場合には、どのDNSサーバへ問い合わせするかを意識して設計することが必要です。 まとめ いかがでしたでしょうか。 すでに理解できていた用語もあれば、人によってはあいまいに理解して誤用していた用語もあったのではないでしょうか。 本記事では、ネットワーク設計・運用において特に重要な用語を取り上げています。 Catoクラウドの初期設定や障害調査で用語の意味が理解できない場面で、ぜひ本記事に立ち戻ってご活用いただければ幸いです。 今後続編として、【セキュリティ編】【応用編】の投稿も予定しています。

こんにちは、SCSKの齋藤です。 今回はAWSサービスのモックを作成し、プログラムをテストする方法の簡単な例をブログにしました。   モックとは？ ソフトウェアテストを行う際に、代用する下位モジュールスタブの一種です。 プログラムを作成した際に、作成したプログラムから別のモジュールを呼び出したりする際に、別のモジュールの代用品として理想的な値を返すようなオブジェクトです。 例えば、AWSリソースを操作するようなLambdaのソースコードをテストする場合、AWSリソースの部分を代用品としてモックを使うことで、ソースコードが正しく動作するかをテストできます。   AWSのモックツール 代表的なものとして、motoがあります。 Moto: Mock AWS Services — Moto 5.0.12.dev documentation docs.getmoto.org これを用いると、開発環境のPC上などで擬似的にAWSリソースを作成することができます。 全てのAWSリソースは網羅されていないらしいのですが、Lambdaと連携されるような代表的なサービス（S3、SQS、DynamoDB、STSなど）は、含まれております。   motoを使ってPythonのテストをしてみた！ 今回は実際にmotoを使ったモックによるテストを行ってみます。 今回私が検証した環境は下記になります。 マシン：Mac Book Pro IDE：Visual Studio Code 仮想環境構築 今回は、プログラムを実行するための仮想環境から構築していきたいと思います。 仮想環境構築の前に、プロジェクトフォルダの作成を行います。 PC上のどこでも良いので、空のプロジェクトフォルダをまず作成します。中身は何も作成しません。   その次に、ターミナルを開いて、下記コマンドを入力し、仮想環境をPython３代で作成します。 仮想環境名は各自で命名してください。（今回は、myvenvで作成しました。） $ cd プロジェクトフォルダ名 $ python3 -m venv 仮想環境名   仮想環境を構築後、下記コマンドで仮想環境をアクティベートします。 ・Linux・Mac $ source 仮想環境名/bin/activate もしくは、 $ . 仮想環境名/bin/activate ・Windows $ .\仮想環境名\Scripts\activate 仮想環境に切り替わったため、Pythonのバージョン確認をします。 (仮想環境名)$ python -V 先頭に仮想環境名が付与され、Python３代がインストールされているのを確認できます。 そのまま、仮想環境にパッケージのインストールを行います。 今回インストールするのは、AWS SDK for Pythonであるboto3、モックツールのmoto、Pythonのテストツールのpytestの３点です。 pip install boto3 pip install moto pip install pytest あくまで仮想環境上でのインストールなので、仮想環境を閉じれば、これらのツールは使えません。 VSCodeでのフォルダ・ファイル作成 VSCode上で、先ほどのプロジェクトフォルダを開きます。 まだ空のフォルダしか作成されていないので、その中にさらにフォルダとファイルを作成していきます。 今回は、下記画像のようなフォルダ構成とすることを目標とします。 このフォルダを実現するために、新たに作成するフォルダは「 src 」フォルダと「 tests 」フォルダです。 それ以外のフォルダについては自動で作成されます。 srcフォルダとtestsフォルダ内で作成するファイルをそれぞれ解説いたします。   srcフォルダ app.py メインのソースコードをこのファイルに書きます。 boto3を用いて、S3のバケットの情報を取得して、返却する処理を実行します。 今回は簡略的に、取得したバケットの1つ目の情報のみを返却します。 boto3でのS3へのリクエストやレスポンスの形は、boto3のドキュメントを参照してください。 https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/s3/client/list_buckets.html import boto3 def list_bucket(): s3=boto3.client('s3') response=s3.list_buckets() bucket_info=response['Buckets'][0] return bucket_info   testsフォルダ 本フォルダはテストに必要なファイル類を定義します。 __init__.py テスト対象のファイルがsrcフォルダにありますが、これをtestsフォルダのファイルが読み込めるようにしなければなりません。 そのため、testフォルダのファイルにパス情報を渡す必要があります。 その処理を、下記のコードで実現します。 import os import sys sys.path.append(os.path.abspath(os.path.join(os.path.dirname(__file__), '..', 'src'))) 上記コードで何をしているか内訳を見てみると、 1. os.path.dirname(__file__)・・・開いているファイル（__init__.py）のディレクトリ名を取得します。 （/Users/usename/Desktop/sample-project/tests） 2. os.path.join()関数により、1で取得したディレクトリに、”..”と”src”という文字列を連結します。 （/Users/usename/Desktop/sample-project/tests/../src） 3. os.path.abspath()関数により、2で連結したパスを正規化します。 （/Users/usename/Desktop/sample-project/src） 4. sys.path.append()関数により、3で正規化されたパスをpytestに渡しています。   conftest.py このファイルが本記事の要である、モックをしている箇所になります。 環境構築の際にインストールしたmotoから、mock_awsというツールをインポートしています。 このmock_awsというツールが、ローカル上で、仮想的なAWS環境を実現してくれます。 この仮想的な環境に、「test_bucket」という名前のS3バケットを作成します。 import pytest from moto import mock_aws import boto3 @mock_aws @pytest.fixture def setup_s3(): with mock_aws(): s3=boto3.client('s3') s3.create_bucket( Bucket='test_bucket', CreateBucketConfiguration={ 'LocationConstraint': 'ap-northeast-1', },) yield s3 test_app.py これまで作成したファイルを元に、実際にテストを行うファイルです。 テストの関数に、conftest.pyのsetup_s3関数を継承させます。 これにより、このテストコードはsetup_s3関数内のモックしたS3を使うことができます。 この状態で、テスト対象である、srcフォルダのapp.pyのlist_bucket関数を実行します。 そして、モック化した際に「test_bucket」という名前でS3を作成しているので、その名前が取得できているのかをassert文で評価します。 import app def test_list_bucket(setup_s3): response=app.list_bucket() assert response['Name']=='test_bucket' テストの実行 VSCodeのターミナルを立ち上げて、下記コマンドを入力します。 python -m pytest テストが合格してます！ これによりモック化して作成したS3バケット「test_bucket」の情報を、正しく取得できたことを確認できました。 モックしないとどうなるか？ 今回conftest.pyでモックを作成しました。 しかし、それを作らずにテストした場合は、環境上にセットされているAWS CLIの情報を元に、実際にAWS環境にアクセスされてしまいます。 大規模な開発などの場合、まだAWS環境が用意されていないが、Pythonのソースコードを開発しなければならない場合などはあり得ます。 そうした場合、AWS環境に接続せずとも、正しく動作されていることをテストするには、モックというのがどうしても不可欠になりますね。 そもそも、単体テストというのは、作成したプログラム自身が正しいかどうかを確認するプロセスのため、それ以外のものについては正しい値が返却されるという想定で、モックを作って実施するのは当然かと考えられます。 実際にAWSリソースへのアクセスをしてプログラムが正しく動くかどうかは、機能テストなどの段階で検証するため、単体テストでは適切にモックを使うことを意識すると良いと思います。 まとめ 今回はPython上で、AWSリソースのモックのやり方を簡単に紹介しました。 motoは、大変便利なツールですので、単体テストを行う際はぜひ使うようにしましょう！

はじめに Cato クラウドを利用のお客様から、ときどき次のようなお問い合わせが来ることがあります。 Web ページ内の動画を再生できない Web ページは開けるが正常に表示されない Cato クラウドに接続しなければ正常に Web ページが表示されるのであれば、上記のような問題は Cato クラウドによって引き起こされていると考えられます。 このような場合、ブラウザのデベロッパーツールを利用すればお客様自身で素早く解決できる可能性がありますので、そのトラブルシューティング方法をご紹介します。 トラブルの原因 Cato クラウドに接続しなければ正常に Web ページが表示されるのに、Cato クラウドに接続するとおかしくなるという問題が起きた場合、お客様自身で Web ページへのアクセスに関するイベントを確認し、Internet Firewall で許可したり TLS Inspection をバイパスしたり、他にもいろいろと試されるのですが、解決できずにお問い合わせいただくことがあります。 表示がおかしくても Web ページ自体は開けているのであれば、その Web ページへのアクセスは Cato クラウドによって制限されることなく行えていることを意味します。しかし、表示がおかしくなるということは、その Web ページから参照されている他の Web サイトへのアクセスがブロックされている可能性があります。 世の中の多くの Web ページでは、そこにアクセスしたとき、ブラウザのURL欄に表示される FQDN (ドメイン名) 以外の Web サイトへのアクセスも行われ、JavaScript、CSS、画像や動画、その他リソースの読み込みが行われます。それらの読み込みがブロックされると、結果として Web ページ内の一部が表示されない、レイアウトが崩れる、一部機能が動作しないといった事象に繋がります。 例として、弊社の Web ページ (https://www.scsk.jp/) を挙げてみます。この Web ページでは、サイト内検索機能を実現するために “c.marsflag.com” というドメインにアクセスして JavaScript などを読み込むようになっています。試しに Cato クラウドの Internet Firewall を用いてこのドメインをわざとブロックするようにしてみると、次の図のように検索機能が利用できなくなってしまいました。 ドメインをブロックしていない場合（正常な表示） 一部ドメインをブロックした場合（検索ボックスが無くなって使えなくなっている） こういった問題の原因は Web ページを見るだけではわかりづらく、お客様に通信のキャプチャを取得していただいたうえで弊社や Cato のサポートにて解析・調査しているのですが、ブラウザのデベロッパーツールを利用すればお客様自身で素早く解決できる可能性があります。 トラブルシューティング方法 ここでは一般的によく利用される PC 用ブラウザで、デベロッパーツールを利用してトラブルシューティングする方法を説明します。先ほどの例のまま “c.marsflag.com” ドメインをブロックしている状態で試しています。 Google Chrome の場合 Google Chrome では、キーボードの「Ctrl + Shift + I キー」を押すとデベロッパーツールが表示されます。あるいは、メニューの「その他のツール」の中から「デベロッパーツール」を選択して表示することもできます。 上図のブラウザ画面の右のほうの領域を占めているのがデベロッパーツールです。このうち「Network」タブがトラブルシューティングの肝です。デベロッパーツールを表示してから Web ページを表示 (F5 キーで再読み込み) すると、ブラウザと Web サーバとの間で行われる多数の HTTP 通信の内容が全て表示されます。 一覧では HTTP 通信の Name, Status, Type などが表示されていますが、Cato クラウドをお使いの場合は通信先のドメイン名が重要ですので、一覧のヘッダ部分を右クリックして「Domain」も選択して表示させるようにするのがお勧めです。 すると、”c.marsflag.com” というドメインへのアクセスで HTTP ステータスコード 403 のエラーとなっていることが一目でわかります。 この 403 エラーとなっている行を選択し、右クリックして “Open in new tab” を選択してその URL を別のタブで開いてみると、たしかに Cato クラウドのブロック画面が表示されました。 これにより、”c.marsflag.com” というドメインの URL へのアクセスが Cato クラウドによってブロックされていることがわかりましたので、あとはイベントログを確認しつつ、実際にブロックしている機能 (Internet Firewall など) のルールを変更すればアクセスできるようになります。Cato クラウドのブロック画面以外が表示されるようであれば、おそらく Web サイト側の問題の可能性が高いです。 また、Web ページが表示されるのが遅いという場合、デベロッパーツールの各行の「Time」を見ると、どのリソースへのアクセスでどれだけ時間がかかったのかわかります。Cato クラウドを使わない場合は素早く表示されるのに Cato クラウド経由だと遅くなるような場合には、時間がかかっているアクセスの URL を特定できれば、原因特定や改善にも役立ちます。 Microsoft Edge の場合 Microsoft Edge も Google Chrome と同様に、キーボードの「Ctrl + Shift + I キー」を押すか、メニューの「その他のツール」の中から「開発者ツール」を選択すれば、デベロッパーツールを表示できます。 表示が日本語化されていたり、ツールの名称が「Microsoft Edge DevTools」や「開発者ツール」となっていたりしますが、デベロッパーツールの利用方法や機能は Google Chrome とほぼ同じです。 Mozzila Firefox の場合 Mozzila Firefox もキーボードの「Ctrl + Shift + I キー」を押すか、メニューの「その他のツール」の中から「ウェブ開発ツール」を選択すれば、デベロッパーツールを表示できます。 見た目は Google Chrome などと異なりますが、同様に利用してトラブルシューティングを行えます。 まとめ 本記事では、ブラウザのデベロッパーツールを用いたトラブルシューティング方法の一例を説明しました。 Web ページの一部の表示がおかしいときのトラブルシューティングとして記載していますが、他の問題が起きたときもデベロッパーツールが役立ちますので、ぜひご活用ください！

Catoの運用支援をしていると「WEBサイトへ アクセスできなくて困っている 」という問い合わせをいただくことが多いです。 今回は、上記のようなトラブルが発生した際に CMAのEvents機能から切り分けを行う方法  をご紹介します。 画⾯は2024年7⽉時点のものです。 機能アップデート等で変わる場合がありますので、あらかじめご了承ください。 Eventsとは 「Events」は、Catoクラウド利用時のログが一元的に確認できる機能です。 基本的な操作方法は、以下の記事をご参照ください。 Catoクラウド Eventsの確認方法 CatoクラウドのEvents画面の見方、ログの絞り込み方について解説します。 blog.usize-tech.com 2023.08.22   注意！！Eventsに表示されない通信 Eventsの確認をする前に、以下の設定をしている通信はEventsに表示されませんのでご注意です。 トラブルが発生している通信が当てはまっていないかをまず確認ください。 １）Internet/WAN Firewall等のセキュリティルールの設定の際に[Event]の項目をTrackにしていない Trackにすることで、設定したルールにより許可もしくはBlockされた通信をEventsで確認できるようになります。 ２）BypassやSplit Tunnelを利用している通信 ３）Off-Cloudを利用した拠点間の通信 BypassやSplit Tunnel、Off-CloudでCatoを経由させていない場合に発生するトラブルは、Catoを経由していないためCato起因である可能性が低いです。利用しているネットワーク環境等の確認をまず実施ください。   トラブルシューティングの際によく使うField Eventsでのトラブルシュートは、主にフィルタリングを利用して問題に関連する通信を絞り出すことから始まります。 しかし、Eventsには多くのFieldが存在するため、問題が起きた際はどれを見ればよいの？という事態に陥ってしまうかもしれません。 以下に私がトラブルシューティングの際によく確認するFieldについて紹介します。 ※トラブルの内容にもよりますが、以下はWebサイトが見れない事象が起きた場合によく見ているFieldです。 Field名 内容 Action Catoの機能により実行された動作がわかる 例）Monitor、Allow、Block、Alertなど Sub-type Catoの機能。上記の[Action]がどの機能で実施されているのかがわかる 例）Internet/WAN Firewall、TLS、IPS、App Security Rule [Sub-type]のどのルールにマッチしているのかがわかる Category 通信がどのカテゴリに分類されているのかがわかる PoP Name 通信を行う際に入り口となるPoP名がわかる Source IP 送信元IPアドレス Source is Site or SDP User 送信元がSocket配下か、SDPユーザかがわかる Domain Name 通信先のドメイン名 Full Path URL 通信先のフルパスURL Destination IP 宛先IPアドレス Network Rule どのNetwork Ruleにマッチしているかがわかる Public Source IP トラフィックの送信元であるPoP によって割り当てられたグローバルIPアドレス Network RuleによりEgress IPにNATされている場合も表示される Source Site Socket配下の場合はSite名、SDPユーザの場合はユーザ名が表示される User Email 送信元ユーザのメールアドレス TLS Inspection TLS Inspectionで検査を行っているかがわかる 「1」の場合は検査済み、「0」の場合は検査なし 上記は、ざっくりとした説明ですが、すべてのFieldの意味については以下のCatoのKnowledgeサイトを参照ください。 https://support.catonetworks.com/hc/en-us/articles/5131416221085-Explaining-the-Event-Fields   Eventsを利用したトラブルシューティング手順 次に、実際にお問合せの多い「Webサイトにアクセスできない問題」を例に、Eventsでの切り分け手順について説明します。 問題が発生したらまず以下の手順で実際にトラブルシューティングを実施してみましょう。   手順①　Eventsでログを確認する前に以下の情報を事前に確認しておきましょう。 ・いつ：問題が発生した日時 ・どこで：Socket配下からのアクセス、もしくはリモートからのアクセスか ・誰が：送信元のIPアドレス、もしくはユーザ情報(メールアドレス) ・宛先情報：宛先IPアドレスやWebサイトのURL ・何の通信：プロトコルやポート番号、アプリケーション 上記を確認出来たらEventsを使ってトラブルシューティングを実施してみましょう。   手順②　どこから通信を行ったかを絞る Socket配下からのアクセスか、リモート(SDPユーザ)からのアクセスかがわかる場合は、初めに絞ってしまいましょう。 ・Socket配下からのアクセスの場合 [Network]>[Sites]から拠点を選択し、[Site Monitoring]>[Events]をクリック ・SDPユーザからのアクセスの場合 [Access]>[Users]からユーザを選択し、[User Monitoring]>[Events]をクリック ・上記が特に決まっていない場合 [Monitoring]>[Events] 上記のようにEventsはユーザ単位、Site単位で確認することが可能です。   手順③　問題が発生した時刻に絞る Eventsの右上にあるカレンダーボタンをクリックし、問題が発生した日時を絞り込みましょう。   手順④　宛先を絞る アクセス先をドメインもしくは宛先IPアドレスで絞りましょう。   手順⑤　Actionを確認 [Fields]からActionを選択し、対象の通信がBlockされていないか確認しましょう。 Actionの中にBlock以外の項目が複数ある場合があります。 今回はBlockのEventsを確認したいので、以下○枠の「⊕」をクリックしてさらに絞り込みましょう。   手順⑥　Sub-Typeを確認 手順⑤でBlockされていた場合、次にSub-typeからCatoのどの機能でBlockされているのかを確認しましょう。 上記の画像でいうと、通信をBlockしているのは、Internet Firewallだということがわかります。   手順⑦　Ruleを確認 手順⑥で、Blockを実行している機能が分かりましたら、どのルールでBlockされてしまったのかを確認しましょう。 これでBlockを実行しているルールが判明しました。 原因であるCatoの機能、ルールが確認できたらCMA側で設定変更を行い問題を解消しましょう。 原因別の対応例 EventsでBlockが確認できた場合 上記の手順でEventsからCatoの機能によるBlockが確認できましたら、アクセスができるように設定変更を行いましょう。 例として以下パターン別の対応例をご紹介します。 パターン１　Internet/WAN FirewallでBlockされていた よくあるのが、Internet Firewallで意図せずBlockされていたパターンです。 「通信が間違ったカテゴリに分類されていた」や「そもそも上位のルールでBlockされていた」といった事例が多いです。 解決方法としては上記の手順⑦にてBlockしているルールを確認し、それに合わせて設定の変更を行いましょう。 ▼ 上位のルールにブロックされていた 上記手順の⑦番で、どのルールによりBlockされていたのかを確認できたとします。 確認ができたら、上位に許可ルールを作成することで問題が解消します。 ▼間違ったカテゴリに分類されていた 上記手順の⑦番で、Blockしているルールの内容を確認し、通信が間違ったカテゴリに分類されていることがわかった場合。 対象のドメインのカテゴリを変更することで問題が解決します。 カテゴリ変更の方法につきましては、以下の技術ブログを参考ください。 Catoで業務通信がブロックされてしまう事象の解決策！～SWGで誤分類されたサイトを管理者で修正する機能～ Catoを使っていると、業務でアクセスするドメイン（URL）が誤ったカテゴリに分類され、通信できない！ということがあります。今回は、そんな問題が発生した場合の新しい回避策「カテゴリの手動修正」を紹介します。 blog.usize-tech.com 2024.02.22 上記のようにカテゴリの変更で解決する場合もありますが、Internet FirewallもしくはWAN Firewallで該当の通信を許可してしまった方が早くて確実です。 アクセスができなくて困っている場合は、まずはFirewallルールでの許可設定を行いましょう。   パターン２　IPSやAnti-MalwareでBlockされていた CatoのIPSやAnti-Malware機能によってBlockされていたというケースもあります。 Blockされていた通信が問題ないと判断できる場合は、Allow Listを作成することで問題を回避できます。 なお、Allow Listは[Security]>[IPS]の[Allow List]タブから作成できますが、Eventsの画面からでも作成が可能です。 例として、IPSでBlockされていた際にEvents画面からAllow Listを作成する方法について記載します。 手順①：「4.Eventsを利用したトラブルシューティング手順」で、IPSによるBlockを確認 手順②：表示されたEventsの「＋」をクリックして詳細を展開 手順③：詳細が展開されたら[Signature ID]をクリック 手順④：Allow Listの作成画面が画面右から展開されるので、環境に合わせて設定し、[Apply]をクリック Allow Listの作成手順は以上です。 ※Anti-Malwareの場合も同様の手順でAllow Listを作成できます。 Signature IDによっては、CMAからAllow Listを作成しても許可されない場合があります。 その場合はCatoのバックエンド側でホワイトリストに登録してもらわなくてはいけないため、Catoのサポートチームへ依頼してください。 EventsでBlockではなくMonitorと表示されていた場合 これまではEventsでBlockされていた(Catoの機能でBlockされていた)ケースについてご紹介しました。 しかし、Webサイトにアクセスできない状況なのに、Eventsで見ると通信はBlockされずにMonitorと表示されているケースもあります。 これは、宛先への通信はCatoを通過していることを表しており、宛先側で何かしらのアクセス制限がされている可能性があります。 そういった場合は、TLSインスペクションのBypass設定やCatoを迂回させる設定などをお試しください。 設定方法などの詳細につきましては以下の技術ブログを参照ください。 Cato経由でのWebサイト接続のトラブル例とその対処法 Cato経由でのWebサイトの接続トラブルについて、事例とその対処法についてご紹介します。 blog.usize-tech.com 2024.04.19   例外事例 上記のように、通信がMonitorと表示されているとEventsから原因を特定することは難しいですが、例外事例もあるのでご紹介します。   事例：Webサイトにアクセスすると「プライバシーが保護されません」ページが表示される どのWebサイトへアクセスをしても以下画像のように「プライバシーが保護されません」と表示されてしまうといった事例があります。 原因の一つとして、TLS Inspection機能を有効にしているにも関わらず、端末にCatoのルート証明書を導入していないことが挙げられます。 上記の事象が証明書のインストール有無が原因かどうかは、Eventsから特定することができますのでご紹介します。 TLS Inspection機能の詳細につきましては、以下の技術ブログをご参照ください。 CatoクラウドのTLS Inspection機能で躓く証明書の仕組み Cato クラウドでHTTPS通信のセキュリティ対策を行うためのTLS Inspection機能で躓くことの多いTLS証明書関連の仕組みや課題について解説します。 blog.usize-tech.com 2023.10.06 ▼確認手順 手順①：日時やドメイン情報などで絞り、アクセスしたWebサイトへの通信をEventsで表示させる 手順②：Actionを確認する ここでは、Block表示はありませんでしたが、Monitorの他にAlertがあるので「⊕」を押して絞ります。 手順③：Eventsの詳細を展開する Sub-typeがTLSであることがわかります。 Sub-typeがTLSの場合は、「TLS Error Description」からAlertとなった理由が確認できます。 実際に検証も行ってみましたが、端末にCatoのルート証明書が入っていない場合は「certificate unknown」と表示されます。 同様のEventsが確認できた場合は、Catoのルート証明書がインストールされていないことが原因の可能性があります。   まとめ 本投稿では、トラブル時のEventsの見方や対処法について一例をご紹介しました。 トラブルでお困りの方のお役に立てれば幸いです。 なお、弊社の FAQ サイトでは 、よくあるご質問やCato クラウドのアップデート情報を公開しておりますので、是非ご参照ください！

こんにちは、広野です。 最近、AWS Lambda 関数から AWS Elemental MediaConvert の API を呼び出そうとしたときに気付いたことを話します。API エンドポイントが変わっていました。いつから変わっていたのかわからないのですが。 そもそも MediaConvert って？ ひとことで言うと、動画をエンコードしてくれるサービスです。動画処理ソフトウェアができることに近いです。私は MP4 のデータをストリーミング可能な形式 HLS に変換する目的で使用しています。ユーザがアプリ UI からアップロードした動画データを自動的にエンコードするのに便利です。 What is AWS Elemental MediaConvert? - MediaConvert AWS Elemental MediaConvert is a file-based video processing service that provides scalable video processing for content ... docs.aws.amazon.com 変更点 本題です。 今現在の AWS Elemental MediaConvert のマネジメントコンソール画面です。左側のメニュー、矢印の位置に「アカウント」という設定があったのですが、無くなっていました。 実はこのアカウントの設定には、アカウントかつリージョン固有の MediaConvert API エンドポイントの URL が表示されており、API を呼び出すときにはその URL を使用しなければならない、という仕様がありました。 例えば AWS Lambda 関数 (Python) では、以下のようにエンドポイントを打ち込んでいました。 client = boto3.client('mediaconvert', region_name='ap-northeast-1', endpoint_url='https://xxxxxxxx.mediaconvert.ap-northeast-1.amazonaws.com' ) マネジメントコンソールからアカウントの設定が無くなったことを受けて AWS ドキュメントを確認したところ、以下のように DescribeEndpoints は不要になったと書いてありました。これがアカウントかつリージョン固有の API エンドポイントだったはず。 Note that DescribeEndpoints is no longer required. We recommend that you send your requests directly to the regional endpoint instead. Endpoints - AWS Elemental MediaConvert API Reference /2017-08-29/endpoints Operation ID: DescribeEndpoints 200 response The service can't process your request because of a p... docs.aws.amazon.com 結論 試してみたら、AWS Lambda 関数からの MediaConvert API 呼出は API エンドポイント指定 なし で動きました。 client = boto3.client('mediaconvert') 従来の方法で作成済みの AWS Lambda 関数が動くかは未確認です。過去に作成していたリソースを削除してしまったため。ですが互換性維持のため、動くのではないかと想像します。 まとめ いかがでしたでしょうか？ この変更についてアナウンスがあったのかわからず、変更に気付いたときは戸惑いました。 短いですが、本記事が皆様のお役に立てれば幸いです。