こんにちは。SCSKの山口です。 今回は、BigQuery の、様々なレベルでのアクセス制御についてまとめます。 BigQuery のアクセス制御 BigQuery の IAM ロールと権限  |  Google Cloud 事前定義ロールとカスタムロールを含む、BigQuery 向け Identity and Access Management（IAM）によるアクセス制御のロールと権限について説明します。 cloud.google.com BigQuery では、下記のレベルでのアクセス制御が可能です。 リソースレベル データセット テーブル データレベル 列 行 公式ドキュメントには「データレベル」というワードありませんが、わかりやすくするために使用しています。 図式化すると以下の通りです。 アクセス制御が実装されているBigQuery では、ユーザは目的のデータ（宝石）を入手するために 各レベルに設定されたアクセス制御を潜り抜ける 必要があります。 もちろん、アクセス制御がされていない場合もあります。 今回のブログ（その①）では、 リソースレベルでのアクセス制御 について詳しく見ていきます。 リソースレベルのアクセス制御 前述しましたが、ここでいう「リソース」は データセット/テーブル を指します。 下記方法で設定することが可能です。 IAMを使用したアクセス制御 承認によるアクセス制御 VPC Service Controlsを使用する タグを使用する IAM Conditionsを使用する IAMを使用したアクセス制御 IAM を使用してリソースへのアクセスを制御する  |  BigQuery  |  Google Cloud cloud.google.com IAMを使用してBigQuery のアクセス制御を実装する場合は、下記のロールが必要です。 BigQuery データオーナー（roles/bigquery.dataOwner） 既に実装されているアクセス制御については、下記手順で、コンソール上で確認することができます。 データセット名の横の点三つをクリックし「アクションを表示」 「共有-権限の管理」をクリック 新たにアクセス権を付与する場合もコンソール上での操作が可能です。 （上記と同様の手順） （上記と同様の手順） 「プリンシパルを追加」をクリック 「新しいプリンシパル」欄にプリンシパルを入力 「ロールを選択」リストで付与するロールを選択 「保存」をクリック   承認によるアクセス制御 VPC Service Controlsを使用する BigQuery の VPC Service Controls  |  Google Cloud cloud.google.com VPC Service Controls の詳細については下記ドキュメントをご参照ください。 VPC Service Controls の概要  |  Google Cloud cloud.google.com BigQuery で VPC Service Controls を使用することで、データアクセスとデータの引き出しを制限することができます。   タグを使用する テーブルとデータセットにタグを付ける  |  BigQuery  |  Google Cloud cloud.google.com 事前に作成したタグを使用し、 リソースにタグが付いているかどうかに基づいて条件付きでポリシーを適用する 方法です。 タグはKey-Value ペアとして構成されるリソースで、組織リソースまたはプロジェクトリソース配下に作成することができます。詳細は下記をご参照ください。 タグの概要  |  Resource Manager Documentation  |  Google Cloud cloud.google.com タグを使用することで、例えば下記のような運用・制御が可能です。 [前提] 組織を管理している 組織内のデータアナリストはすべてグループ「 analysts@example.com  」のメンバ アナリストはプロジェクト「 userData 」に対して「 BigQuery データ閲覧者IAMロール 」を持つ アナリストの インターンの学生 が一名入ってきた [やりたいこと] インターンの学生にはuserData プロジェクトの 「anonymousData」 データセットを表示する権限のみ を付与したい [実現方式] 「anonymousData」 データセットにタグを付与 する インターン生のIAM（もしくはサービスアカウント）の「 BigQuery データ閲覧者IAMロール 」に対して タグの条件を追加する （公式ドキュメント内の例を参考にしています。） テーブルとデータセットにタグを付ける  |  BigQuery  |  Google Cloud cloud.google.com この方法に関しては、後ほど実践したいと思います。   IAM Conditionsを使用する IAM Conditions によるアクセス制御  |  BigQuery  |  Google Cloud cloud.google.com この方法では、指定された条件が満たされた場合のみBigQuery リソースへのアクセスを認可できます。 IAM Conditions は、プロジェクト、フォルダ、組織レベルでサポートされ、BigQuery データセット、テーブル、ルーティン、モデルに適用できます。 次の属性に基づいた設定が可能です。 属性 概要 値 request.time ユーザがBigQuery リソースへアクセスした時刻 – resource.name BigQuery リソースのパス projects/ PROJECT_ID /datasets/ DATASET_ID projects/ PROJECT_ID /datasets/ DATASET_ID /tables/ TABLE_ID resource.type BigQuery リソースのタイプ bigquery.googleapis.com/Dataset(Table) resource.service BigQuery リソースが使用するGoogle Cloud サービス bigquery.googleapis.com resource.tags BigQuery リソースに付加されたタグ –   具体的な実践は今回は省きますが、タグの使用でも説明した「IAMの条件を追加」から設定することが可能です。 [例：request.time]   実践1：IAMを使用したアクセス制御 IAMを使ってアクセス制御してみます。 以降はAdminとMemberでアカウントを分けて進めます。 Admin：データセット＋テーブル作成 下記データセットとテーブルを作成します。 データセット：yamaguchi_test_acctrl テーブル：test1,test2 次に、AdminのBigQueryで、 test1テーブル の権限の共有で下記を設定します。 プリンシパル：shXXXXX@XXXX（MemberのGoogleアカウントのアドレス） ロール：BigQuery データ閲覧者 Member：テーブル確認 Admin側で共有設定をする前は、test1.test2テーブルともに閲覧ができない状態でした。 Adminでtest1テーブルの共有設定を行うと、 test1テーブルのみ閲覧することができるようになりました。   実践2：タグを使用したアクセス制御 次に、同じことをタグを使って実現してみます。 今度はtest2テーブルに対する閲覧許可を実装します。 Admin：タグ作成＋付与 まず、タグを作成します。 次に、test2テーブルに作成したタグを付与します。 「詳細」タブから「詳細を編集」 タグの「スコープの選択」でプロジェクトを選択し、作成したタグ情報を入力 Admin：IAMの条件を追加 権限付与対象のプリンシパルの「BigQuery データ閲覧者」ロールに、下記IAMの条件を追加します。 条件タイプ：タグ 演算子：値IDがある キーID：tagKeys/281476642126196（タグ値詳細画面の「親キー」） 値ID：tagValues/281483470283076（タグ値詳細画面の「タグ値ID」） Member：テーブル確認 Admin側でタグ設定をする前は、test2テーブルが閲覧できない状態でした。 タグとIAMの設定完了後にtest2テーブルを再度確認すると、 test2テーブルも閲覧可能になりました。   まとめ 今回はBigQuery のアクセス制御 その①ということで、リソースレベルのアクセス制御を実践してみました。 本ブログで実践した通り、IAMによる制御と承認（タグ）による制御は共存させることができます。便利ではあるのですが、闇雲に設定してしまうと 意図しない認可が発生してしまう 恐れもあります。 IAMの設定に関しては下記ドキュメント等のプラクティスに準拠することをお勧めします。 IAM を安全に使用する  |  IAM のドキュメント  |  Google Cloud cloud.google.com まとめ②では、BigQueryテーブル内の行・列単位のアクセス制御について取り扱います。

本記事は 夏休みクラウド自由研究 8/22付の記事です 。 こんにちは。SCSKの吉田です。 本記事は、ServiceNowの開発者向け生成AI機能であるNow Assist for Creatorに関する記事となります。 Now Assist for Creatorには、いくつかの機能がありますが、今回は Code generation を紹介させていただきます。 本記事は執筆時点（2024年8月）の情報です。最新の情報は製品ドキュメントを参考にしてください。 Code generationとは Code generationは、自然言語で記載したいコードの説明を入力すると、その内容をもとにAIがコードをサジェスト、生成してくれる機能となります。 Code generationの使用には以下のようなメリットがあると個人的に感じており、ServiceNowの開発業務を大幅に効率化することができます。 開発経験の有無に関係なく、ServiceNowスクリプトの文法に沿ったコードを簡単に作成できる 過去作成したコードを見返したり、ドキュメントを読んだりなど、調査の時間を短縮できる 普段、ロード・ノーコード開発に慣れていると、久しぶりにコーディングする際に「どういう構文だったっけ？」となることがあります。 そんなとき、Code generationを使用すれば、ドキュメントを調べる必要もなくなるので非常に便利なツールです。 使い方 Now Assist for Creatorをインストールした後、Code generationをアクティベートとすることで、Business rule、Script Includeなどのスクリプトエディターや、Flow Designerで利用可能になります。 Now Assistのセットアップ方法は、以下の記事で簡単にご紹介していますので併せてご覧ください。 【ServiceNow×生成AI】Now Assistをセットアップしてみる ServiceNowの生成AI機能であるNow Assistをセットアップしてみましたので、その手順を簡単にご紹介します。 blog.usize-tech.com 2024.08.15 ここではシステムで一般的な要件として存在する、以下のシナリオを想定してコードを作成してみます。 セキュリティの観点から、一定期間ログインが無いユーザーを無効化したい 自動生成したコードは、非本番環境でレビュー・動作確認の上、本番利用してください。 コードのサジェスト まず始めにコードのサジェスト機能のご紹介です。 画像のようにCode with Now Assistダイアログボックスに、作成したいコードの説明を記載します。 「ユーザーテーブルを検索し、最終ログイン日が180日以上前のアカウントを非アクティブ化する」 次に記載した内容をSubmitすると、Now Assistが入力された内容をもとにコードをサジェストしてくれます。（ハイライト部分） サジェストされた内容で問題なければ、Acceptを選択することで自動生成されたコードが反映されます。 最後に、変数名やログ出力処理など、各開発チームが持つ開発標準に合わせて微修正して保存すれば作成完了となります。 実際に自動生成された処理を実行したところ正しく動作することが確認できました。   コードの補完 続いて、コードの補完機能のご紹介です。 ここではあえてコードを途中まで記載した状態からスタートします。 コメントで作成したいコードの説明を記載のうえ、右クリック→Auto-generate code completionを選択します。 すると画像のように残りのコードを補完してくれます。（グレーアウト部分） 補完された内容は、先ほどのサジェストされたコードと同じ内容であることが確認できます。   生成AIが考えたお題にチャレンジ シナリオ 弊社内で利用できる生成AIにシナリオを考えてもらい、Code generationでコードを作成してみようと思います。 （吉田） ServiceNowのスクリプティングを勉強しています。複数のテーブルからデータを取得して特定の条件でクエリするような、複雑なスクリプトのお題をください。 （生成AI） ServiceNowのスクリプティングを学ぶためのスクリプトの課題をご紹介します。 シナリオ：ユーザーのアクティビティを監視し、特定の条件に基づいて一覧を表示するスクリプトを作成します。 要件： １．ユーザーテーブルからアクティブなユーザーを取得します。 ２．ログイン履歴テーブルから、過去1週間以内のログイン履歴を取得します。 ３．各ユーザーのログイン回数を集計し、1回以上ログインしているユーザーのリストを表示します。 実践 まず始めにアクティブなユーザーをクエリするコードを作成します。 次に各ユーザーのログイン履歴を取得し、ログへ出力するコードを作成します。 最後に変数名などを分かりやすく修正した上で完成した処理がこちらになります。 実際にこの処理を動かしてみます。 過去1週間のうちにログインしているユーザーは、私自身のアカウントとテスト用ユーザーの2アカウントとなります。 なおテスト用ユーザーは非アクティブな状態に更新したため、ログは1件のみ出力されるのが想定している動作となります。 ログを確認すると、1件のみ出力されており、正しくコードを作成できていることが確認できました。   まとめ 今回は、Now Assist for Creatorの各機能のうち、コードを自動生成してくれるCode generationを使ってみました。 Code generationを使用すれば、ServiceNowの文法に沿った高品質のコードを簡単に作成することができ、また、手動でコードを書く時間を短縮できるので、開発者の業務効率を向上させることが可能な強力なツールと感じました。 Now Assist for Creatorにはその他の機能も用意されているので、今後ご紹介していきます。   最後に・・・ 弊社では、ITSMやCSM、ESGなど様々なServiceNow製品を扱っています。 以下から問合せ可能ですので、是非ご参照ください。 ServiceNow ServiceNowは、企業の生産性向上や業務プロセス改善を支えるサービスマネジメントクラウドソリューションです。従業員満足度・顧客満足度の向上、業務効率化を強力に支援します。 www.scsk.jp

こんにちは！Zabbixを担当している曽我です。 今回、Zabbixの 新しい構築サービス をリリースしましたので紹介いたします。 本サービスは、お客様からの導入時の以下の悩み事を解決できる内容になっています。 ・Zabbixの導入を依頼するといくら必要なの？ ・要件を満たすには、どんな構成でZabbixを構築する必要があるの？ ・導入後のサポートは何があるの？ Quick Start Package for Zabbixのサービス概要 本サービスは、弊社にて2017年よりZabbix構築サービスを提供してきた中で、よくある構築作業をパッケージ化したサービスです。 お客様のご要望に応じて、複数の選択肢を用意しており、それらを組み合わせることで、構築から、構築後のサポートまで提供します。 お客様は、以下の①～④のZabbix環境を構築する上で必要なコンポーネントより、要件にあったメニューを選択頂くことで、ご希望の 監視環境を得ることができます。 Quick Start Package for Zabbixの全体メニュー 以降で、①～④のコンポーネントについて説明します。 ①サーバ環境 Zabbixサーバの環境として、大きく3つの選択肢があります。 選択１）Zabbix Enteprise アプライアンス（監視対象数の目安：～1000台） Zabbix Enterprise アプライアンスは、ZS-5000シリーズ（監視対象数の目安：200台）と ZS-7000シリーズ（監視対象数の目安：1000台）の2種類があります。 機器の詳細については、こちらの リンク より確認してください。 ZS-5000 / ZS-7000シリーズ 選択２）仮想アプライアンス Zabbix Enteprise サポート契約者さま向けに仮想アプライアンスが提供されています。 対応している仮想基盤は、以下です。（2024/8/21時点） VMware 5.5/6.0/6.5/7.0/8.0 VirtualBox 必要なサーバスペックについては、 ご相談 ください。 選択３）物理サーバ/仮想マシン/クラウド 本サービス上は、お客様にてご用意頂いた物理サーバ/仮想マシン/クラウドにOS環境を ご用意頂き、Zabbixを導入させて頂く内容となっております。 ※もし環境の準備をご希望される場合は、別途ご相談ください。   ②構築サービス 構築サービスは、構築する環境に応じて3種類ご用意しております。 構築サービスメニュー 環境によっては、Zabbixプロキシが必要になり、上記の構築メニューでは不十分なケースが御座います。 その場合は、個別見積で対応させて頂きますので、ご相談ください。   ③オプション 構築オプションメニュー 構築サービスの内容に以下のオプションを追加で加えることが可能です。 構築オプションメニュー 運用支援オプションメニュー 構築後、Zabbixのサポートはあるけど、お客様自身だけでは不安な場合、導入後の支援をご依頼頂けます。 構築後支援メニュー ④Zabbixサポート 当社のサポートは全部で、5種類あり、一番お勧めは、問合せ無制限の「ゴールド」です。 以下、サービスメニューです。 赤い★マーク がついているところは、当社のオリジナルメニューです。 Zabbix Enterprise サポート ※ 1 平日営業時間内は日本時間月曜～金曜日(祝祭日、弊社規定休日を除く)9時～17時30分となります。 ※ 2 ご契約のZabbixサーバに接続されているZabbixプロキシの台数分プロキシオプションの契約が必要となります。サーバとプロキシのサポートレベルは同一であることが必須となります。 ※ 3 18時～翌9時まで、対応言語は英語のみとなります。 ※ 4 VALinux社提供のVAQuestサービスを利用しています。 ※ 5 本サポートをご契約頂けるお客様は、新規でサポートをご契約頂くお客様または他社様のZabbixサポートから乗り換えのお客様に限ります。 Zabbixアプライアンスのサポートには利用できません。   構築例 ①Zabbix Enteprise アプライアンス　ZS-5000シリーズ＋②構築サービス エントリー+③ Zabbix Enteprise サポート シルバーの場合 No 製品名 数量 価格 1 Zabbixアプライアンス　ZS-5000シリーズ 1 \298,000 2 構築サービス　エントリー 1 \100,000 3 Zabbix Enteprise サポート　シルバー　1年 1 \1,600,000 合計 \1,998,000 （税込\2,197,800)   まとめ 「Quick Start Package for 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  

こんにちは、SCSK株式会社の中野です。 Zabbixの脆弱性に関して、深刻な脆弱性が発表されましたので、本記事にて共有いたします。 Zabbixをご利用の方は一度ご覧いただき、対象の場合はアップデート等のご検討お願い致します。 Zabbix脆弱性情報 2024年8月9日（現地時間）にZabbix社は、監視ソリューション「Zabbix」に深刻な脆弱性があると以下URLにて公表しております。 ———————— CVE/Advisory number: CVE-2024-22116 Synopsis: Remote code execution within ping script Zabbix Security Advisories and CVE database ———————— この脆弱性が悪用された場合は、リモートコード実行の攻撃を受け、システム全体が危険にさらされる可能性がございます。 例えスクリプト実行を制限された権限を持つ管理者であっても、監視しているホストでスクリプト実行機能を悪用できる可能性があり、 scriptのパラメータはデフォルトでエスケープされていないため、攻撃者はping scriptを介して任意のコードを実行し、インフラ全体を侵害することが可能となります。 影響を受けるとされるZabbixのバージョンは以下となります。 ・Zabbix 6.4.0 ～ 6.4.15  ・Zabbix 7.0.0alpha1 ～ 7.0.0rc2  脆弱性を修正するためには、修正されたZabbixのバージョンへアップデートする必要がございますので 以下バージョンへのアップデートのご検討をお願い致します。 ・Zabbix 6.4.16rc1 ・Zabbix 7.0.0rc3 最後に 弊社では本件に関してのお問い合わせもお受けしております。 ご相談事項がございましたら、以下ページよりお問い合わせいただければと思います。 お問い合わせ 製品・サービスについて 入力 ｜ SCSK株式会社 また、以下Zabbixのイベントが直近で開催されます。 本件に限らずご質問をお受けする時間もございますので、ご興味がございましたら是非ご参加ください。 2024.8.23 (金) Zabbix全国5都市キャラバン2024　名古屋 2024.10.02（水） Zabbix7.0セミナー　～新機能とバージョンアップの要点～ 以上、最後までご覧いただきありがとうございました。

こんにちは。SCSKの吉田です。 今年リリースされたWashington DCバージョンから「Customized Metadata Detail」というテーブルが追加されていることを最近発見しました。 このテーブルを使用することで、インスタンスに加えたカスタマイズを簡単にトレースすることができるようになりました。 公式ドキュメントにはおそらく記載はなく（見逃していたらすいません）、あくまでも個人で調べた内容となりますが、共有させていただきます。 はじめに ServiceNowを導入する際は、OOTB（Out of the Box）と呼ばれる標準機能を利用して、カスタマイズを最小限に抑えることが推奨されています。標準機能を利用することで初期構築期間の短縮、システム稼働後のメンテナンスコスト削減などのメリットがあります。 その一方で、業務要件のためにカスタマイズが必要となる場面もあります。その際は以下の点を考慮する必要があります。 メンテナンス工数の増大 カスタマイズは自身でメンテナンスを行っていく必要があります。カスタマイズの程度にもよりますが、発生した問題の原因がカスタマイズの場合、サポート対象外となることがあります。 また、ServiceNowでは１年に１回はインスタンスのアップグレードを実施する必要があり、カスタマイズが多いほどリグレッションテストにかかる工数は増大します。 カスタマイズ箇所のブラックボックス化 もちろんですがカスタマイズで実装した内容は、公式ドキュメントに記載されていません。そのため、設計書に残していない場合、カスタマイズを実施した特定の開発者に属人化してしまいます。 また、きちんと引継ぎがなされないまま開発者が離任した場合、カスタマイズ箇所の特定が困難になります。 上記のことから、不要なカスタマイズを避けることが求められ、またカスタマイズを実施する場合は、設計書等にドキュメント化しておく必要があります。 しかし、ドキュメント化のルールを整備しないまま開発を進めてしまい、後からカスタマイズをトレースするのに苦労しているという方も多いのではないでしょうか。   カスタマイズをトレースする 以前までは、例えば以下のようにカスタマイズをトレースしていました。 テーブルに追加したカスタムフィールドを探す場合：sys_dictionaryテーブル上で名前が「u_」から始まるレコードを検索する カスタマイズしたBusiness ruleを探す場合：sys_scriptテーブル上で、作成/更新者、作成/更新日時、スクリプトの中身を確認してカスタマイズか否かを確認する このように、各テーブル上で、それぞれの探し方でトレースする必要がありました。 しかし、Washington DCからは、カスタマイズのトレースを簡単にする以下テーブルが追加されました。 Customized Metadata Detail[sys_metadata_customization] どのテーブル上のレコードを変更したかに関係なく、カスタマイズと分類される変更は、Customized Metadata Detailテーブル上にレコードとして格納されるようになったようです。 各テーブル毎に探す手間が省け、かつカスタマイズのみが格納されるテーブルの為、OOTBかカスタマイズかの判別も不要となりました。 また、Author Typeの値を使用することで、以下のように更に詳細な分類ができます。 「ServiceNow」の場合：OOTBのレコードに対して、変更を加えカスタマイズしている 「Custom」の場合：レコードを新規作成してカスタマイズしている 他にもAuthor Typeが「Unknown」や「ToBeDetermined」となっているレコードがありましたが、カスタマイズを特定する上では上記2つを確認するだけで問題なさそうです。   注意点として、Customized Metadata Detailに格納されるのは、 更新セットにキャプチャされる変更のみ のようです。 試しにScheduled Jobを作成しましたが、Customized Metadata Detailにはレコードが作成されませんでした。   最後に 今回は、Washington DCで追加されたテーブルを使用し、カスタマイズをトレースする方法をご紹介しました。 カスタマイズのトレースにお困りの方にとって、本記事が参考になれば幸いです。 また、弊社では豊富な構築・運用ノウハウにより、ServiceNow導入のご支援が可能です。 以下HPも併せてご参照ください。 ServiceNow ServiceNowは、企業の生産性向上や業務プロセス改善を支えるサービスマネジメントクラウドソリューションです。従業員満足度・顧客満足度の向上、業務効率化を強力に支援します。 www.scsk.jp

本記事は 夏休みクラウド自由研究 8/21付の記事です 。 クラウドサービスのオブジェクトストレージの利便性 便利なストレージサービス AWSのS3（Simple Storage Service）や、Google CloudのCloud Storage、Microsoft AzureのAzure Blob Storageなど、パブリッククラウド各社には代表的なオブジェクトストレージサービスが存在しています。これらは非常にシンプルで便利なストレージサービスです。とりあえずデータを入れておけば、連携するサービスや対応するソフトウェアが豊富にあり様々な活用ができます。さらに、ストレージ料金も非常に安価で、クラウド利用時のデータレイクとして最適です。 思わぬ課金項目に注意！ クラウド上のオブジェクトストレージは確かに便利ですが、その活用方法によっては想定に反して思わぬ請求が来てびっくりしてしまうケースが存在します。見落としがちな課金項目として挙げられるのが、クラウド外へのデータ転送課金です。 クラウド外へのデータ転送課金（ダウンロード課金）とは？ 主要なパブリッククラウドにはデータをクラウド外に送信する際に 従量 課金が発生します。一般的には Egress課金 やダウンロード課金と呼ばれます。 クラウド内や他のリージョンでのデータ送受信はゼロ円もしくは極めて安価でほとんど気にする必要はありませんが、他のクラウドやオンプレミス環境、またはクライアントへデータをダウンロードする際にはGBごとに課金が発生します。 この課金は単価が安いため見過ごしがちですが、使用量が増えるとコストがじわじわと上昇していきます。以下はあるオブジェクトストレージサービスにデータを保存してクラウド外に読み出しを行った場合の課金額シミュレーションです。読み出し量が多いと保存料金以上にダウンロード料金がかかることがわかります。   注意すべきユースケース 特に以下のようなユースケースでは、思いもよらなかった高額な課金になることがあります。 クライアント向けに頻繁にもしくは大量にデータ送信するケース ファイル配布、モジュール配信、ファイルサーバ利用など、様々なユースケースが考えられますが、データ量が大量になったり、データの送付先・配布先が大量になるケースは場合によって注意が必要です。 マルチクラウド環境でのデータ活用 パブリッククラウドの大手各社はデータ活用領域でも様々な魅力的なサービスを提供しています。各社の強味や特性を活かすために様々なクラウドサービスへデータを連携させていると、結果としてデータレイクやデータベースの存在するクラウドからのEgressトラフィックが増加します。 ハイブリッド環境でのデータ連携が多いケース 様々な理由があってパブリッククラウドとオンプレミスもしくはパブリッククラウド以外のクラウドサービスとの組合せ構成をとる場合。ある程度のEgress発生は想定内のはずですが、ハイブリッド構成をとるシステムが増えてくると意図せずEgressが多くなるケースが発生しえます。   解決策 この課金問題を回避するための方法をいくつか記載します。 解決策１：データ連携の多いシステムやサーバは同じクラウドに配置する 外に送るのにお金がかかるのなら送り先を中にしてしまおうという発想です。 クライアントなどもクラウド内に置いておけば追加のダウンロード料金が発生しません。 複数のクラウドを利用する必要がない場合は、これが最もシンプルな解決策です。 解決策２：ダウンロード課金がかからないサービスを活用する 複数のクラウドを使い分ける必要がある場合や、どうしても外部へ大量のデータを送らなければならない場合には、こちらの方法が適しています。Egress従量料金の代わりに固定の回線費用が発生する場合もありますので、扱うデータ量によって最適な構成の見極めが必要です。   まとめ ダウンロード課金による予想外のコスト増加を避けるためには、データの取り扱い方をあらかじめ計画し、最適な配置を行うことが重要です。 1つのクラウドですべてが完結する場合は問題ありませんが、複数のクラウドを利用する場合は特に注意が必要です。 オンプレ回帰は最適解か？ 最近「オンプレ回帰」というワードを良く耳にします。クラウド利用したは良いけど、様々な理由で効果が出ずクラウドの利用をやめてオンプレミスのシステムに戻るという動きです。オンプレ回帰の理由の1つにコストの最適化があげられます。課金の仕組みをただしく理解して最適なデータ配置をすれば、コスト上昇を抑えてパブリッククラウドを利用し続ける事も可能と考えます。先進的なサービスが次々と実装されるパブリッククラウドの利用をあきらめるのはDXを推し進める上でもデメリットと考えています。今回の記事が読者の皆様のDX推進の一助になればうれしいです。 最後に宣伝 SCSKではUSiZE（ユーサイズ）というプライベートクラウドを提供中です。 USiZEには今回の記事でテーマにしたダウンロード課金はありません。 またSCNXというパブリッククラウドとの優れた接続性を有するサービスとも直結しており、 これによりパブリッククラウドとの連携も低コスト、低遅延で行うことができます。 直近でデータの蓄積場所として活用いただけるクラウドストレージというサービスもリリースをしております。 今回の記事に該当するようなお悩みをもっている方は、是非選択肢の一つとして「USiZE」をご検討頂ければと思います。   関連情報 データ主権を担保したソブリンクラウド ユーサイズ│SCSK株式会社｜サービス｜クラウド移行だけでは描けない、理想のDXを実現する プライベートクラウド「USiZE」でクラウドストレージサービスを提供開始 ～データ転送料金不要の純国産サービスでコストダウン、海外法影響排除を実現～ SCSK Cloud netXchange マルチクラウド接続サービス｜SCSK株式会社

こんにちは、広野です。 本記事はシリーズもので、以下の記事の続編です。 Amazon Bedrock RAG 環境用 AWS CloudFormation テンプレート series 1 VPC 編 Agents for Amazon Bedrock を使用した最小構成の RAG 環境を構築する AWS CloudFormation テンプレートを紹介します。3部構成になっており、本記事は1つ目、VPC 編です。 blog.usize-tech.com 2024.08.01 以前、以下の記事で 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 に変更したり、モデルを Claude 3.5 Sonnet に変更したりしています。 本シリーズ記事では、環境構築用の AWS CloudFormation のサンプルテンプレートを 3 記事に分けて紹介します。説明を分割するため、テンプレートを3つに分けていますのでご了承ください。 2回目は Amazon Aurora Serverless v2 Postgresql 編です。 本記事で取り扱う構成 RAG 環境全体の構成 以下のアーキテクチャで RAG アプリケーションを構築しています。このうち、赤枠の部分が本シリーズ記事で取り扱う箇所です。series 2 Aurora 編では、Knowledge Base のベクトルデータベースとなる Amazon Aurora Serverless v2 Postgresql と、それに取り込むドキュメントを格納する Amazon S3 バケットについて説明します。 今回は Agents for Amazon Bedrock がアクセスするリソース、Amazon Aurora Serverless v2 Postgresql と Amazon S3 バケットをデプロイします。 Amazon S3 バケットは RAG の参照先にしたいドキュメントを放り込むだけなので、特別なオプションはありません。 Amazon Aurora の構成 (前回のおさらい含む) Amazon Aurora Serverless v2 をデプロイするためには 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 から取得します。Postgresql のマスターユーザのパスワードは自動で Secrets Manager に作成されます。Agents for Amazon Bedrock が使用するユーザを bedrock_user とし、パスワードは自動生成させています。自動生成にあたり、パスワードに使用できない記号が入ることを避けるため、ExcludePunctuation のオプションを true にしています。この CloudFormation テンプレートでは、bedrock_user は作成されません。作成されるのはパスワードです。後述する手動によるベクトルデータベース構築コマンド実行の際にユーザを作成します。 Amazon Aurora Serverless のキャパシティやメンテナンスの設定は適当に入れているので、適宜変更してください。 AWS CloudFormation テンプレート 図に掲載している Amazon VPC は前回のテンプレートで作成しています。Amazon Aurora Serverless で使用する RDS サブネットグループとセキュリティグループは 前回のテンプレート でエクスポートした情報をインポートしています。また、今回のテンプレートで、次のテンプレートで使用する Amazon Aurora、Amazon S3、IAM ロールの情報をエクスポートしています。 IAM ロールは Agents for Amazon Bedrock 用のものです。以下の許可が入っています。 Amazon Aurora、Amazon S3、Secrets Manager へのアクセス ドキュメントの内容をベクトルデータに変換する AI モデル (Amazon Titan Text Embeddings) へのアクセス AWSTemplateFormatVersion: 2010-09-09 Description: The CloudFormation template that creates an Aurora Serverless v2 cluster and a S3 bucket as a RAG Knowledge base. # ------------------------------------------------------------# # Input Parameters # ------------------------------------------------------------# Parameters: SubName: Type: String Description: System sub name of sample. (e.g. test) Default: test MaxLength: 10 MinLength: 1 Resources: # ------------------------------------------------------------# # S3 # ------------------------------------------------------------# S3BucketKbDatasource: Type: AWS::S3::Bucket Properties: BucketName: !Sub sample-${SubName}-kbdatasource PublicAccessBlockConfiguration: BlockPublicAcls: true BlockPublicPolicy: true IgnorePublicAcls: true RestrictPublicBuckets: true Tags: - Key: Cost Value: !Sub sample-${SubName} # ------------------------------------------------------------# # Secrets Manager for Aurora # ------------------------------------------------------------# SecretAurora: Type: AWS::SecretsManager::Secret Properties: Name: !Sub aurora-database-user-sample-${SubName} Description: !Sub Aurora database credential for sample-${SubName} GenerateSecretString: SecretStringTemplate: '{"username": "bedrock_user"}' GenerateStringKey: password PasswordLength: 28 ExcludePunctuation: true Tags: - Key: Cost Value: !Sub sample-${SubName} # ------------------------------------------------------------# # Aurora Serverless v2 PostgreSQL # ------------------------------------------------------------# AuroraDBCluster: Type: AWS::RDS::DBCluster Properties: DatabaseName: bedrockragkb DBClusterIdentifier: !Sub bedrock-rag-kb-sample-${SubName}-cluster Engine: aurora-postgresql EngineVersion: 16.2 EngineMode: provisioned DBSubnetGroupName: Fn::ImportValue: !Sub sample-${SubName}-PrivateSubnetGroupName MasterUsername: postgresql ManageMasterUserPassword: true ServerlessV2ScalingConfiguration: MinCapacity: 0.5 MaxCapacity: 2.0 EnableHttpEndpoint: true AutoMinorVersionUpgrade: true BackupRetentionPeriod: 1 CopyTagsToSnapshot: true DeletionProtection: true EngineLifecycleSupport: open-source-rds-extended-support-disabled NetworkType: IPV4 Port: 5432 PreferredBackupWindow: "15:00-18:00" PreferredMaintenanceWindow: "Sun:01:00-Sun:14:00" VpcSecurityGroupIds: - Fn::ImportValue: !Sub sample-${SubName}-AuroraSecurityGroupId Tags: - Key: Cost Value: !Sub sample-${SubName} AuroraDBInstance: Type: AWS::RDS::DBInstance Properties: Engine: aurora-postgresql DBInstanceClass: db.serverless DBClusterIdentifier: !Ref AuroraDBCluster DBInstanceIdentifier: !Sub bedrock-rag-kb-sample-${SubName} Tags: - Key: Cost Value: !Sub sample-${SubName} # ------------------------------------------------------------# # IAM Role for Bedrock KB # ------------------------------------------------------------# IAMRoleBedrockKb: Type: AWS::IAM::Role Properties: RoleName: !Sub AmazonBedrockExecutionRoleForKnowledgeBase_sample-${SubName} AssumeRolePolicyDocument: Version: 2012-10-17 Statement: - Effect: Allow Action: - sts:AssumeRole Principal: Service: - bedrock.amazonaws.com Condition: StringEquals: "aws:SourceAccount": !Sub ${AWS::AccountId} ArnLike: "aws:SourceArn": !Sub "arn:aws:bedrock:${AWS::Region}:${AWS::AccountId}:knowledge-base/*" Policies: - PolicyName: AmazonBedrockRDSClusterPolicyForKnowledgeBase PolicyDocument: Version: 2012-10-17 Statement: - Effect: Allow Action: - rds:DescribeDBClusters - rds-data:BatchExecuteStatement - rds-data:ExecuteStatement Resource: !GetAtt AuroraDBCluster.DBClusterArn - PolicyName: AmazonBedrockS3PolicyForKnowledgeBase PolicyDocument: Version: 2012-10-17 Statement: - Effect: Allow Action: - "s3:GetObject" - "s3:ListBucket" Resource: - !GetAtt S3BucketKbDatasource.Arn - !Sub ${S3BucketKbDatasource.Arn}/* Condition: StringEquals: "aws:PrincipalAccount": !Sub ${AWS::AccountId} - PolicyName: AmazonBedrockSecretsPolicyForKnowledgeBase PolicyDocument: Version: 2012-10-17 Statement: - Effect: Allow Action: - "secretsmanager:GetSecretValue" Resource: !Ref SecretAurora - PolicyName: AmazonBedrockFoundationModelPolicyForKnowledgeBase PolicyDocument: Version: 2012-10-17 Statement: - Effect: Allow Action: - "bedrock:ListFoundationModels" - "bedrock:ListCustomModels" - "bedrock:RetrieveAndGenerate" Resource: "*" - Effect: Allow Action: - "bedrock:InvokeModel" Resource: - !Sub arn:aws:bedrock:${AWS::Region}::foundation-model/amazon.titan-embed-text-v1 DependsOn: - AuroraDBCluster - S3BucketKbDatasource - SecretAurora # ------------------------------------------------------------# # Output Parameters # ------------------------------------------------------------# Outputs: # S3 KbDatasourceBucketName: Value: !Ref S3BucketKbDatasource KbDatasourceBucketArn: Value: !GetAtt S3BucketKbDatasource.Arn Export: Name: !Sub sample-${SubName}-S3BucketKbDatasourceArn # Aurora AuroraDBClusterArn: Value: !GetAtt AuroraDBCluster.DBClusterArn Export: Name: !Sub sample-${SubName}-AuroraDBClusterArn AuroraDBClusterIdentifier: Value: !Ref AuroraDBCluster Export: Name: !Sub sample-${SubName}-AuroraDBClusterIdentifier AuroraAdminUserSecretArn: Value: !GetAtt AuroraDBCluster.MasterUserSecret.SecretArn AuroraBedrockUserSecretArn: Value: !Ref SecretAurora Export: Name: !Sub sample-${SubName}-SecretAurora IAMRoleBedrockKbArn: Value: !GetAtt IAMRoleBedrockKb.Arn Export: Name: !Sub sample-${SubName}-IAMRoleBedrockKbArn ベクトルデータベース構築 (手動) 上述の AWS CloudFormation テンプレートを流しただけでは、Amazon Aurora Serverless の箱だけが出来上がった状態ですので、ユーザやテーブルがありません。Agents for Amazon Bedrock の Knowledge Base として使用できるようにするため、AWS 提供の手順を実行する必要があります。 Amazon Bedrock のナレッジベースとしての Aurora PostgreSQL の使用 - Amazon Aurora Aurora PostgreSQL をナレッジベースとして使用する方法について説明します。 docs.aws.amazon.com 私は AWS マネジメントコンソールの RDS の画面から該当の Amazon Aurora Serverless のインスタンスを選択して、Data API 経由で SQL を入力しています。 SQL を実行するにあたり、Postgresql の Admin ユーザを確認する必要があります。AWS CloudFormation で Secrets Manager 内にパスワードが自動生成されていますので、それを確認しておきます。 手順内で、bedrock_user を作成しますが、そのときのパスワードも Secrets Manager 内に自動生成されていますので、そちらも確認しておきます。いずれも、一度構築してしまえばほぼほぼ今後使用することはありません。 本記事の範囲はこれで終了です。 まとめ いかがでしたでしょうか？ Amazon Aurora Serverless 作成テンプレートはどこにでもある情報だと思いますが、一度できるようになると他の案件にも応用できるので便利です。 次回は Agents for Amazon Bedrock や周辺の AWS Lambda 関数のデプロイがテーマです。 本記事が皆様のお役に立てれば幸いです。 謝辞 本記事の構成作成にあたり、以下 AWS Ambassador 2 名の方のご知見が大変参考になりました。 ソニービズネットワークス 濱田様 サーバーワークス 福島様 濱田様には、以前お会いしたときに「RAG の Knowledge Base を最も安く構築するなら Aurora Serverless 一択ですよ、いろいろ検証してそれに落ち着きました」とお聞きして、私が OpenSearch から Aurora Serverless に乗り換えるきっかけになりました。 福島様には、Aurora Serverless v2 Postgresql でベクトルデータベースを構築する際の手順 (コマンド) が AWS の公式ドキュメントのままではエラーになってしまうところ、ドンピシャな回避策をブログ記事で紹介してくれていました。大変助かりました。おそらく SQL 実行時に途中でユーザを切り替えずにコマンドを実行すると権限不足のエラーになってしまうものと想像します。 濱田様には今度 AWS Ambassador コミュニティでお会いしたときに御礼を言いたいと思います。福島様にもそうしたいと思っていたのですが、AWS Ambassador をご勇退されていたことに気付き、直接御礼を言う機会がありません。この場を借りて、御礼申し上げます。 本当にありがとうございました。

今回は、Catoクラウドの機能を整理してご紹介したいと思います。 もちろん、すべての機能をブログに記載するのは難しいため、Catoクラウドに興味を持たれた方に向けて「現在のネットワークで使用している機能がCatoクラウドに移行しても使えるのか？」という視点から整理してみました。 また、CatoクラウドはSD-WANを利用しており、すべての設定はWeb管理コンソール（CMA）で行うため、オンプレミスの機器で構築されたネットワークと単純に比較することはできません。しかし、より具体的なイメージを持っていただくために、「拠点ネットワーク」「ネットワーク全体」「リモート接続」「セキュリティ」「運用」の5つのカテゴリに分類して説明します。少しでも「なるほど、Catoってこんな感じなんだ」と感じていただければ幸いです。 拠点ネットワーク編 まずはCato Socket周辺の機能です。ここでは拠点にルータを置いて回線と接続した場面を想定しています。Catoに切り替える場合はこのルータをSocketに入れ替える事になります。尚、Socketはサブスクリプションでの提供となります。 機能 対応有無 補足事項 Socketポート数 – シリーズ毎に以下のポート数（1000baseT）があります。 X1500：1GbE×4 X1600：2.5GbE×4、1GbE(RJ45/SFP)×2、10G SFP×2 X1700：1GbE×8（10Gカード別搭載） ラックマウント 〇 X1500：マウントキット別売り X1600：マウントキット別売り X1700：ラックマウントレール（標準） HA構成 〇 Act/SbyでのHA構成が可能です。lanポート同士をVRRPで制御してます。 回線冗長 〇 1台のSocketに複数回線を接続してAct/Actでの利用や、回線毎に重みづけを行い負荷分散させる事も可能です。 回線接続 〇 SocketのWAN接続は「DHCP・Static・PPPoE」の３つをサポートしています。デフォルトがDHCPなので、上位ルータからSocket wanポートのアドレスをDHCPで払い出す環境であれば完全なゼロタッチプロビジョニングが可能です。因みにSocketの上位機器がIPマスカレードでNATしている環境でも問題ありません。 ブリッジ接続 〇 wanポートとlanポートが同じセグメントでも問題ありませんが、ワンアーム接続は不可です。 IPv6回線接続 × Catoは今のところIPv6には対応していませんが、Socktの上位ルータがIPv4に変換する事でIPv6回線を使用する事は可能です。尚、最近のCatoのロードマップにはIPv6対応が追加されました。 IPsec接続 〇 Socketを使用せずオンプレルータとCatoクラウドをIPsecで接続できます。但しSocket利用時に比べると利用できる機能は制限されます。 スタティックルート 〇 LAN内の複数セグメント宛てにスタティックルート設定が可能です。 BGP 〇 LAN側のBGP機器とSocket間でBGPによるルート交換が可能です。 OSPF・RIP他 × Catoではサポートしていません。 タグ付きVLAN 〇 LAN側の接続機器と802.1QでTrunk接続が可能です。 またSocketの物理ポート毎にVLANを分けて、各L2スイッチと接続できます。 VLAN間アクセスリスト 〇 CatoのLANファイヤーウォールでセグメント間のパケットフィルタリングが可能です。その場合Socketで折り返しとなるので回線側に不要なトラフィックを流す事を回避できます。 DHCP 〇 Socket配下のPCなどにアドレスを払い出すイメージです。Socketで設定したVLAN毎にDHCPが利用できます。但し、除外設定はないので分割したアドレスレンジを設定する事はできません。 DHCPリレー 〇 問題なく使えます。 全体ネットワーク編 次にネットワーク全体の機能です。SD-WANとしてもっと細かい機能や設定は沢山あるのですが、お客様からのお問い合わせやその回答の中で話にあがる機能をピックアップしてみました。 機能 対応有無 補足事項 DNSキャッシュサーバ 〇 Catoが提供するDNSサーバがあります。このサーバを参照するのが推奨です。 社内サーバの名前解決 〇 CatoのDNSサーバのフォワーディング設定で、フォワード先に社内DNSサーバを指定する事で社内サーバの名前解決が可能となります。 固定グローバルアドレス 〇 Catoからインターネットに出ていく送信元アドレスを、お客様固有のグローバルアドレスに設定する事ができます。M365などのIPアドレスによるアクセス制限用として利用できます。尚、固定グローバルアドレスを使用しない通信は、Catoのランダムなアドレスでインターネットに出ていきます。 QoS（帯域制御） 〇 プライオリティ毎に帯域を占める割合（%）を設定し、常時その割合に制限するか？混雑時だけ制限するか？が選択できます。例えばWindows Update通信は常に帯域の10%にして業務通信に影響を与えない様にするなどの事例があります。 QoS（優先制御） 〇 プライオリティを各通信に割り当てる事で輻輳時の優先制御を設定できます。小さい値が優先度高になるので、Zoom会議はプライオリティ10、GCP宛て通信は20、通常のインターネット通信は255にしておけば、ネットワーク混雑時もWeb会議は安定して利用できます。 ルートピア 〇 これはSD-WANならではの機能ですが、インターネットへ出ていくPoPを指定する事ができます。例えばOCI東京リージョンに構築したシステムにベトナム拠点からアクセスする際、その通信の出口を東京PoPを指すればホーチミンPoPからCatoバックボーン経由で東京PoPから接続するので、低遅延で安定した通信が可能になります。 バックホーリング 〇 これもSD-WANならではの機能です。通常インターネット接続はCato PoPから出ていきますが、ある通信だけはCatoに接続しているデータセンター経由でインターネットに出したいという要件にも対応可能です。このケースはIPアドレスの問題やCato移行期間中の措置といたたケースが多いようですが、どうしてもホップ数が増えるのでパフォーマンスは落ちると思います。 NAT 〇 Catoに接続する拠点アドレスが重複する場合、サブネットごと別アドレスに変換する事ができます。 ダイレクトコネクト 〇 AWS・Azure・GCP・OCIとはCatoの「クラウド・インターコネクト」で専用接続が可能です。インターネット接続より低遅延/高帯域での通信が可能です。 ローカルブレークアウト △ いくつか方法はありますが、いずれも宛先はIPアドレス指定での設定しかできません。例としては、ドメイン指定でgoogle.comはCatoを通さないという設定は不可です。SASEのポリシーは「全ての通信をチェックする」というものなのでブレークアウトはあくまで例外設定という位置づけと思っていたのですが、最近のロードマップにはドメイン指定をサポートするという話がありました。 公開サーバ 〇 固定グローバルアドレスにアクセスしたトラフィックをNAT及びポート変換して、内部にあるサーバに転送させる事ができます。 モバイル接続編 次はモバイルアクセスです。従来のネットワークでは、データセンターにVPN装置を設置し、PCにVPNソフトをインストールして自宅や外出先から社内システムに接続する場面を想定しています。Catoの場合も同様で「Cato Client」をPCやスマートデバイスにインストールしてCatoクラウドにVPN接続します。尚、CatoではこのCato Clientで接続したユーザーを「SDPユーザー」と呼びます。 話はそれますが、これまで、オンプレミスのVPN装置を経由して社内システムに侵入され、ランサムウェアなどの被害に遭うケースが多数発生していました。その主な原因は、パッチの適用遅れや未適用です。脆弱性が発見されるとメーカーから修正パッチが配布されますが、そもそも脆弱性をチェックしていたのか？という点や、チェックをしていても、いざパッチを適用する際には業務時間外での作業となり、運用管理者に大きな負荷がかかっていたと思います。これは、クラウド利用時とは比較にならないほどの負担です。 機能 対応有無 補足事項 サイレント・インストール 〇 Cato Clientのインストールファイルをダウンロード後、コマンドの実行でインストールが可能です。グループポリシーを使用してインストールされているお客様の例があります。 インストール時の管理者権限 〇 Cato Clientのインストール時は管理者権限が必要です。その後の自動アップグレード時は必要ありません。 SDPユーザーのグルーピング 〇 部署やグループ会社毎にグルーピングし、作成したグループをファイヤーウォールやネットワークルールのオブジェクトに設定する事ができます。 アンインストール禁止 × 現状はユーザーによるアンインストールができてしまいます。「アンインストールすると結局業務ができませんよ」というスタンスのようです。ただし少し前のロードマップに「2024年中に実装予定」との内容が追加されていました。 バージョンアップ制御 〇 Cato Clientのバージョンアップはお客様の環境に合わせた制御が可能です。バージョンアップ操作を全てユーザーやらせるか、ダウンロードまで自動を行ってユーザーの都合のいいタイミングでアップデートさせるか、サイレントアップデートかを選択できます。 ユーザー割り当てアドレス 〇 SDPユーザー用のPoolアドレスレンジを設定しておき、接続にしたユーザーにはその中からアドレスを割り当てCatoに接続させます。また特定のSDPユーザーにはアドレス固定にする事も可能です。 オンプレADとのLDAP同期 〇 Catoからの到達性があるADサーバのOUやセキュリティグループのユーザー情報をCatoに取り込む事ができます。ユーザー管理はAD側で一元管理できます。 SCIMでのユーザープロビジョニング 〇 連携しているIdPサービスからユーザー情報をCatoに取り込む事ができます。ユーザー管理はIdPサービス側で一元管理が可能です。 シングルサインオン 〇 現在は計6つのIdpと連携しシングルサインオンが可能です。 ユーザー識別 〇 AD及びEntra IDとユーザー同期している場合、Catoの中でもユーザー名で識別が可能です。ログ上IPアドレスだけの表示だと誰なのか？確認するのが手間ですが、ユーザー名で表示されるので一目でどのユーザーがどんな通信をしているのかが判別できます。 デバイス証明書認証 〇 お客様で発行されたルートCA証明書をCatoクラウドにアップロードし、SDPユーザー端末にデバイス証明書を配布しておけば、証明書によるデバイス認証が可能となります。 デバイスポスチャ 〇 SDPユーザー端末の環境やステータスをチェックしてCatoへの接続を制限します。例えば会社指定のアンチウィルスソフトのバージョンいくつ以上が入っていて、且つデバイス証明書が入っている端末はCato接続を許可するといった事ができるので、BYOD利用の制限が可能となります。 スプリット・トンネル 〇 特定の宛先IPアドレスや送信元IPアドレスはCatoトンネルから除外する設定です。SDPユーザー端末からCatoに接続してない複合機を利用する場合など、複合機のIPアドレスを除外する事で利用が可能となります。 IPv6接続 〇 2024年8月に対応が可能になりましたが、利用するISPに条件があるようです。 セキュリティ編 次にセキュリティです。これまでも、データセンターに各種オンプレミス機器を積み重ねたり、各セキュリティサービスを契約することで、一通りのセキュリティ機能を実装することは可能でした。しかし、各機器やサービスはそれぞれ独自の仕様であり、ユーザーインターフェースも異なるため、各機能を習得するのが大変です。また、メーカーが異なるため、問い合わせも保守更新もそれぞれ別々に行わなければなりませんでした。Catoでは、必要なセキュリティライセンスを購入していただければ、あとは管理コンソール（CMA）で設定を行うだけで済みます。さらに、各セキュリティオプションのログもすべてCMAで確認できるため、運用管理にかかる工数を大幅に削減できるでしょう。 機能 対応有無 補足事項 インターネット・ファイヤーウォール 〇 インターネット通信を制御するファイヤーウォールです。レイヤ7でのフィルタリングが可能です。 URLフィルタリング 〇 インターネット・ファイヤーウォールで対応しています。他製品やサービスと同様、通信禁止になりそうなジャンルのカテゴリが用意されており、カテゴリ単位でブロック・プロンプト・許可が設定できます。またいつくかのカテゴリはデフォルトでブロック設定がされています。 WANファイヤーウォール 〇 Catoクラウド内の拠点間通信やSDPユーザー～拠点間通信用を制御します。 LANファイヤーウォール 〇 前述の「拠点ネットワーク編」に記載した「VLAN間アクセスリスト」です。 TLSインスペクション 〇 インターネットのHTTPSの暗号化通信を、復号化＞セキュリティチェック＞再暗号化する機能です。これを有効にしないと以降のセキュリティは機能しません。またこの動作を行うためにCatoに接続する各デバイスにはCatoの証明書をインストールする必要があります。インストールできないデバイスやTLSインスペクションで通信が阻害されるサイトはBypassで逃がす事になります。 アンチマルウェア 〇 シグネチャベースのアンチマルウェア機能です。 Threat Preventionというオプションライセンスが必要です。 ネクストジェネレーション・アンチマルウェア（NGAM） 〇 機械学習を用いた次世代のアンチマルウェア機能です。 Threat Preventionというオプションライセンスが必要です。 IPS 〇 所謂IPS機能です。 Threat Preventionというオプションライセンスが必要です。 コンテンツ制限 〇 本機能を有効にすると、インターネット検索エンジンと YouTube のコンテンツ検索時に適切なセーフサーチ設定が適用され、露骨な表現を含む結果がすべて削除されます。 CASB 〇 ユーザーのSaaSやアプリケーション利用を可視化し制御できます。シャドウIT対策もCASBの領域です。また「政府機関等の対策基準策定のためのガイドライン（令和5年度版）」にもCASB導入が推奨されており、今後はスタンダードなセキュリティ機能になるのではと考えられます。 CASBのオプションライセンスが必要です。 DNSプロテクション 〇 DNSで名前解決する時点で疑わしいドメインや公開されて日の浅いドメインをブロックする機能です。 CASBのオプションライセンスが必要です。 DLP 〇 機密情報や重要データの紛失や情報漏洩を防ぐ機能です。「Confidential」の文字が入ったファイルやマイナンバー情報のアップロードをブロックします。 CASBおよびDLPのオプションライセンスが必要です。 RBI 〇 Webブラウザの分離機能です。本機能を有効にすると疑わしいサイトへのアクセス時にはCatoのブラウザが代理アクセスして、お客様のPCへの感染ファイルのダウンロードを防ぐ事ができます。 RBIのオプションライセンスが必要です。 Sandbox × 隔離された環境で危険性のあるソフトウェアの実行し、実環境には影響を及ぼさないような機能はサポートしていません。 SaaS Security API 〇 ユーザーがCatoを経由せず直接アクセスするクラウドでの操作を監視し、設定したルールの違反状況などを可視化する事ができます。 SaaS Security APIのオプションライセンスが必要です。 Endpoint Protection Platform (EPP) 〇 所謂EPPでマルウェアの検出と駆除を行います。最大の特徴はEPPが検知するログもCatoコンソールで管理され、他のセキュリティ機能で検知したログを合わせて総合的な分析ができる点です。この分析とレポートは後述するXDRの機能となります。EPPのオプションライセンスが必要です。 Endpoint Detection and Response (EDR) × EDRは提供していません。但しその他セキュリティ機能(FirewallやNGAM、IPSなど)との組み合わせによるXDRの提供でよりトータルな分析・追跡を行っています。 XDR 〇 Cato上の様々なログを統合し総合的に分析したインシデント情報を提供します。インシデントは重要度でスコアリングがされますので、クリティカルなものを検知（通知も可能！）したら対応を行い、対応が済めばクローズしていくといサイクルで運用する事が可能になります。インシデントはドリルダウンしていくと発生要因や対策が提示されます。またXDRにはThreat Preventionのログの対象としたXDR Core（無償）と、イベントとトラフィックログにもとづく攻撃、通常とは違う振る舞いの検出を加えたXDR Proの2つがあります。 運用編 最後に運用編なのですが、こはシンプルな表にまとめるのが難しいため、内容をかなり省略させていただきました。Catoの料金体系は「接続帯域ライセンス」「Socket台数」「SDPユーザーライセンス数」「オプションライセンス」で構成されていますが、通知機能や通信の可視化、脅威分析などの多彩な運用機能は、すべて各ライセンス料金に含まれているため、非常にお得感があるのではないでしょうか。また、ログの形式や検索機能も見やすいとお客様に好評であり、Catoの導入により、運用レベルの向上と対応工数の削減が見込まれると思います。 機能 対応有無 補足事項 管理コンソールの日本語表示 〇 英語・日本語含め、2024年8月現在では11の言語に切り替えが可能です。 アラート通知 〇 EmailやWebhook、Slackに通知先を指定しておけば、各種システム通知・Socketの切断・セキュリティブロック通知などが可能です。 通信状況モニタリング 〇 ネットワークレイヤの状況はもちろん、利用アプリの状況、個々の通信の詳細から俯瞰的な視点から見た全体の傾向、各セキュリティ機能の活動状況、脅威ダッシュボードでの分析結果など、さまざまな角度から必要十分な情報を得ることができます。 SaaS・アプリケーションのスコアリング 〇 通信先となるSaaS・アプリケーションはCato独自のスコアリングがされており、お客様の利用状況とセキュリティ診断結果を常に確認できます。 監査ログの保存 〇 Catoコンソールの操作ログが保持されています。 自動設定チェック 〇 お客様が行うネットワーク設定やセキュリティ設定について、ベストプラクティスとのGAPを提示してくれます。多くの機能を使用すれば設定量も増え管理が大変ですが、本機能を活用する事で一定水準の品質が保たれるかと思います。 障害・メンテナンス情報の公開 〇 Catoが提供するWebサイトにて全世界のPoPの障害情報・メンテナンス情報を確認する事ができます。また日本のPoPに関する情報をEmailやWebhook、Slackなどで受信する事も可能です。 ログの外部保存 〇 APIによりCatoのログを外部ストレージなどに転送・保存する事が可能です。但しCatoの管理コンソールに戻す事はできません。 Catoサポートへの問い合わせ 〇 英語にはなりますが、Catoサポートに直接問い合わせする事が可能です。尚、SCSKではこれを日本語で受付け問い合わせ代行するサービスをご提供しています。 さいごに Catoは新しい機能やより利便性の高い機能が日々リリースされています。今回一旦まとめはしたものの、この先仕様が変わったりする可能性は大いにあり得ますので、正確な情報はCatoナレッジサイトでご確認いただくかお問い合わせいただくようお願いします。

本記事は 夏休みクラウド自由研究 8/20付の記事です 。 こんにちは、SCSK池宮です。 今年7月から、Visual Studioでも利用ができるようになったAmazon Q Developerはどんな機能があるのか…今回は色々な機能を試してみました。 Visual Studio IDE で Amazon Q Developer の一般提供開始 (GA) - AWS AWS の新機能についてさらに詳しく知るには、 Visual Studio IDE で Amazon Q Developer の一般提供開始 (GA) aws.amazon.com Amazon Q Developerとは？ AWSの生成AIアシスタントサービスの総称であるAmazon Qですが、中でもQ Developerは開発者向けに特化したサービスです。 AI コーディングアシスタント - Amazon Q Developer - AWS Amazon Q Developer は、AWS Well-Architected フレームワークのパターン、ベストプラクティス、ドキュメント、ソリューション実装に関するエキスパートです。これを利用することで、新しいサービスや機能の探索、な... aws.amazon.com 開発者がコーディングをする際のアシスタントを担ってくれるため、生産性の向上が期待できます。 今回は、コード提案をしてくれる前身サービス「Amazon CodeWhisperer」 から追加された機能を中心に見ていきたいと思います。 チャット機能を使ってみる Amazon Q Developerでは、統合開発環境（IDE）上でのチャット機能が追加されています。 （今回はVisual Studio Code（VSCode）上で試していきます！） VS Codeを立ち上げ、左側にある「Amazon Q」アイコンをクリックします。 右側にチャット画面が出てきました。ここでAmazon Qとやり取りができるようになります。 コード生成してもらおう！ このチャット欄に「変数Aと変数Bの合計を計算するコードを生成してください」と送ります。（現在チャット機能は英語のみ対応しています）   回答が返ってきました。 Pythonのコードとアウトプット、そしてどのようなコードなのかという説明を返してくれました。 Python以外の場合として、JavaScriptのコードも回答してくれています。（赤線部分） コードの説明をしてもらおう！ 次に、Q DeveloperのExplainの機能を試してみます。 以下のような「Redshiftテーブルを作成し、S3 バケットから CSV データをテーブルにコピーする」コードを用意して、読み取ってもらいます。 #Connect to the cluster and create a Cursor >>> import redshift_connector >>> with redshift_connector.connect(...) as conn: >>> with conn.cursor() as cursor: #Create an empty table >>> cursor.execute("create table category (catid int, cargroup varchar, catname varchar, catdesc varchar)") #Use COPY to copy the contents of the S3 bucket into the empty table >>> cursor.execute("copy category from 's3://testing/category_csv.txt' iam_role 'arn:aws:iam::123:role/RedshiftCopyUnload' csv;") ※以下ページを参考にしています。 Amazon Redshift Python コネクタの使用例 - Amazon Redshift Amazon Redshift Python コネクタの使用例をご覧ください。 docs.aws.amazon.com コード全体を選択し、右クリックで「Explain」を選択します。 すると、コードの説明が返ってきました。 内容も「このコードは Amazon Redshift クラスターに接続し、新しいテーブルを作成し、Amazon S3 バケットに保存されている CSV ファイルからそのテーブルにデータを入力します。」と、きちんと中身を読み取って回答を生成していることが分かります。 コードを改善してもらおう！ 最後に、コードをリファクタリングしてくれる機能を試してみます。 別の生成AIに「変数Aと変数Bの合計を計算するコード」を複雑に変換してもらいました。（本当に無駄が多い！） # 変数Aと変数Bを定義 A = 5 B = 10 # 無駄な変数を大量に使って中間処理を行う temp1 = A temp2 = B temp3 = temp1 temp4 = temp2 # 足し算をする前にさらに無駄な代入を行う step1 = temp3 + 0 step2 = temp4 + 0 # 不要な計算を追加 dummy_calculation1 = step1 * 1 dummy_calculation2 = step2 * 1 # 何度も再代入を行う intermediate_result = dummy_calculation1 intermediate_result2 = dummy_calculation2 # 無駄なリストを作成して値を追加 useless_list = [] useless_list.append(intermediate_result) useless_list.append(intermediate_result2) # 和の代わりにリストから値を取り出して計算 useless_var1 = useless_list[0] useless_var2 = useless_list[1] final_result = useless_var1 + useless_var2 # 再度無駄に別の変数に代入 output_result = final_result # 結果を出力 print("変数Aと変数Bの和は:", output_result) このコードを選択し、Amazon Q機能の「Refactor」をクリックします。 こちらも返答が返ってきました。 コードを簡潔に直したものが載っています。さらに、「元のコードには不要な変数の割り当て、冗長な計算、不要なリストの作成が多数あったため削除した」というような補足まで返してくれました。 このように、Amazon Q Developer では様々な「開発者にとって痒い所に手が届く機能」が追加されていることが分かりました。 現時点、チャットは英語対応のみですが、日本語利用もできるようになる日が待ち遠しいですね！ 最後までお読みいただきありがとうございました。

本記事は 夏休みクラウド自由研究 8/19付の記事です 。 残暑お見舞い申し上げます。 立秋とはいえ、連日の猛暑にいささか参っておりますが、皆様いかがお過ごしでしょうか。Masedatiです。 この記事は「 夏休みクラウド自由研究 」の一環として投稿しています。自由研究は小学生ぶりです。 ちなみに小学生のときの自由研究のテーマは「トルコアイスの仕組みと作り方」でした。 突然ですがヒエログリフをご存じでしょうか。ヒエログリフとは古代エジプトの象形文字のことで、 𓀁 ←こんなものです。 これには「eat, drink, speak, think」等の意味があるとのこと。ここから現在の文字に進化するのですから、人類ってすごい。 アイスを食べながら、ふと思いました。ヒエログリフの画像をFine-tuningしたら、存在しないヒエログリフをそれっぽく生成してくれるのではないかと。現在の文字(プロンプト)から象形文字を生成するので逆進化です。 今回、「 Amazon BedrockのFine-tuningでヒエログリフを創作する 」をテーマとして自由研究を行いたいと思います。 実は執筆時点でまだ試していないので、成功するのか失敗するのかわかりません。 でもやってみた結果、失敗でもいいのではないかなと思いました。それもまた自由研究だと思うので。 前提 以下でFine-tuningを実施しました。 リージョン：オレゴン モデル：Amazon Titan Image Generator G1 公式ドキュメントに沿ってFine-tuningを行います。 カスタムモデル - Amazon Bedrock モデルをカスタマイズして、特定のタスクや特定のドメインでの機能やパフォーマンスを向上させる方法について説明します。 docs.aws.amazon.com 手順 データセットの準備 Text-to-imageでは以下のJSONL形式でデータを準備する必要があります。 {"image-ref": "s3://bucket/path/to/image001.png", "caption": "<prompt text>"} {"image-ref": "s3://bucket/path/to/image002.png", "caption": "<prompt text>"} {"image-ref": "s3://bucket/path/to/image003.png", "caption": "<prompt text>"} S3にPNGもしくはJPEG画像を格納し、その画像のプロンプト(英語のみ)を記述します。 今回以下のように画像(512×512)をS3に格納し、プロンプトとしてそのキャプションを記載しました。 {"image-ref": "s3://bucket/image-train-data/ ", "caption": "Hieroglyphics of a man eating"} ※イメージです。 訓練データ一覧 以下のヒエログリフ50個を訓練データ(traindata.jsonl)として用意しました。 ランダムで人・体の部位・動物・物体のヒエログリフをピックアップしています。 {"image-ref": "s3://bucket/image-train-data/ 𓀁 ", "caption": "Hieroglyphics of a man eating"} {"image-ref": "s3://bucket/image-train-data/ 𓀌 ", "caption": "Hieroglyph of a seated man with an oar"} {"image-ref": "s3://bucket/image-train-data/ 𓀠 ", "caption": "Hieroglyph of a man with his hands raised"} {"image-ref": "s3://bucket/image-train-data/ 𓀥 ", "caption": "Hieroglyph of one man dancing"} {"image-ref": "s3://bucket/image-train-data/ 𓀫 ", "caption": "Hieroglyph of the man with the leopard's head"} {"image-ref": "s3://bucket/image-train-data/ 𓀿 ", "caption": "Hieroglyph on a reclining mummy"} {"image-ref": "s3://bucket/image-train-data/ 𓀬 ", "caption": "Hieroglyph of a man riding two giraffes"} {"image-ref": "s3://bucket/image-train-data/ 𓁃 ", "caption": "Hieroglyph of a man hoeing"} {"image-ref": "s3://bucket/image-train-data/ 𓁏 ", "caption": "Hieroglyph of a seated man with arms raised"} {"image-ref": "s3://bucket/image-train-data/ 𓁍 ", "caption": "Hieroglyph of a man holding a knife"} {"image-ref": "s3://bucket/image-train-data/ 𓁐 ", "caption": "Hieroglyph of a seated woman"} {"image-ref": "s3://bucket/image-train-data/ 𓁶 ", "caption": "Hieroglyph of head"} {"image-ref": "s3://bucket/image-train-data/ 𓁷 ", "caption": "Hieroglyph of face"} {"image-ref": "s3://bucket/image-train-data/ 𓁸 ", "caption": "Hieroglyph of hair"} {"image-ref": "s3://bucket/image-train-data/ 𓁹 ", "caption": "Hieroglyph of eye"} {"image-ref": "s3://bucket/image-train-data/ 𓁿 ", "caption": "Hieroglyph of eye with flowing tears"} {"image-ref": "s3://bucket/image-train-data/ 𓂂 ", "caption": "Hieroglyph of pupillary"} {"image-ref": "s3://bucket/image-train-data/ 𓂃 ", "caption": "Hieroglyph of eyebrow"} {"image-ref": "s3://bucket/image-train-data/ 𓂈 ", "caption": "Hieroglyph of ear"} {"image-ref": "s3://bucket/image-train-data/ 𓂋 ", "caption": "Hieroglyph of mouth"} {"image-ref": "s3://bucket/image-train-data/ 𓂎 ", "caption": "Hieroglyph of on upper lip with teeth"} {"image-ref": "s3://bucket/image-train-data/ 𓂧 ", "caption": "Hieroglyph of hand"} {"image-ref": "s3://bucket/image-train-data/ 𓂬 ", "caption": "Hieroglyph of fist"} {"image-ref": "s3://bucket/image-train-data/ 𓂭 ", "caption": "Hieroglyph of one finger"} {"image-ref": "s3://bucket/image-train-data/ 𓂮 ", "caption": "Hieroglyph of two finger"} {"image-ref": "s3://bucket/image-train-data/ 𓂯 ", "caption": "Hieroglyph of three finger"} {"image-ref": "s3://bucket/image-train-data/ 𓂰 ", "caption": "Hieroglyph of four finger"} {"image-ref": "s3://bucket/image-train-data/ 𓂱 ", "caption": "Hieroglyph of five finger"} {"image-ref": "s3://bucket/image-train-data/ 𓂲 ", "caption": "Hieroglyph of six finger"} {"image-ref": "s3://bucket/image-train-data/ 𓂳 ", "caption": "Hieroglyph of seven finger"} {"image-ref": "s3://bucket/image-train-data/ 𓂴 ", "caption": "Hieroglyph of eight finger"} {"image-ref": "s3://bucket/image-train-data/ 𓂵 ", "caption": "Hieroglyph of nine finger"} {"image-ref": "s3://bucket/image-train-data/ 𓂾 ", "caption": "Hieroglyph of leg"} {"image-ref": "s3://bucket/image-train-data/ 𓃀 ", "caption": "Hieroglyph of foot"} {"image-ref": "s3://bucket/image-train-data/ 𓃒 ", "caption": "Hieroglyph of bull"} {"image-ref": "s3://bucket/image-train-data/ 𓃟 ", "caption": "Hieroglyph of pig"} {"image-ref": "s3://bucket/image-train-data/ 𓃠 ", "caption": "Hieroglyph of cat"} {"image-ref": "s3://bucket/image-train-data/ 𓃡 ", "caption": "Hieroglyph of dog"} {"image-ref": "s3://bucket/image-train-data/ 𓃬 ", "caption": "Hieroglyph of lion"} {"image-ref": "s3://bucket/image-train-data/ 𓅓 ", "caption": "Hieroglyph of owl"} {"image-ref": "s3://bucket/image-train-data/ 𓆛 ", "caption": "Hieroglyph of tilapia"} {"image-ref": "s3://bucket/image-train-data/ 𓆤 ", "caption": "Hieroglyph of bee"} {"image-ref": "s3://bucket/image-train-data/ 𓆭 ", "caption": "Hieroglyph of tree"} {"image-ref": "s3://bucket/image-train-data/ 𓇯 ", "caption": "Hieroglyph of sky"} {"image-ref": "s3://bucket/image-train-data/ 𓇳 ", "caption": "Hieroglyph of sun"} {"image-ref": "s3://bucket/image-train-data/ 𓇼 ", "caption": "Hieroglyph of star"} {"image-ref": "s3://bucket/image-train-data/ 𓇿 ", "caption": "Hieroglyph of land"} {"image-ref": "s3://bucket/image-train-data/ 𓈌 ", "caption": "Hieroglyph of sun over mountain"} {"image-ref": "s3://bucket/image-train-data/ 𓉐 ", "caption": "Hieroglyph of house"} {"image-ref": "s3://bucket/image-train-data/ 𓏌 ", "caption": "Hieroglyph of pot"} S3の構成は以下のとおりです。 bucket ┣image-train-data ┃ ┣image001.png ┃ ┣image002.png ┃ ┣ ︙ ┃ ┗image050.png ┣traindata.jsonl ┗output-bucket 学習終了後、Fine-tuning中の推移データが出力されるので、「output-bucket」を用意してあげます。 （需要が謎ですが、おまけとしてヒエログリフ文字を画像に変換するコードを置いておきます。） from PIL import Image, ImageDraw, ImageFont import os def text_to_images(text, base_file_path, folder_path="train_data", image_size=(512, 512), font_size=300):   # フォントの設定   try:       font = ImageFont.truetype("NotoSansEgyptianHieroglyphs-Regular.ttf", font_size)  # Noto Sansフォントファイルを使用   except IOError:       font = ImageFont.load_default()   # フォルダが存在しない場合、作成   if not os.path.exists(folder_path):         os.makedirs(folder_path)   # 各文字ごとに画像を作成して保存   for i, char in enumerate(text):       # 画像を作成       image = Image.new('RGB', image_size, color=(255, 255, 255))       draw = ImageDraw.Draw(image)       # 文字のバウンディングボックスを測定       text_bbox = draw.textbbox((0, 0), char, font=font)         textwidth, textheight = text_bbox[2] - text_bbox[0], text_bbox[3] - text_bbox[1]       # 文字を中央に配置       x = (image_size[0] - textwidth) // 2         y = (image_size[1] - textheight) // 8       # 画像に文字を書き込む         draw.text((x, y), char, font=font, fill=(0, 0, 0))       # 画像を保存       file_path = os.path.join(folder_path, f"{base_file_path}{i + 1}.png")       image.save(file_path)         print(f"{file_path}に画像を保存しました。") # 文字入力例 text = "𓀁𓀌𓀠𓀥𓀫𓀿𓀬𓁃𓁏𓁍𓁐𓁶𓁷𓁸𓁹𓁿𓂂𓂃𓂈𓂋𓂎𓂧𓂬𓂭𓂮𓂯𓂰𓂱𓂲𓂳𓂴𓂵𓂾𓃀𓃒𓃟𓃠𓃡𓃬𓅓𓆛𓆤𓆭𓇯𓇳𓇼𓇿𓈌𓉐𓏌" base_file_path = "image"  # 連番の基本ファイル名 text_to_images(text, base_file_path) Fine-tuning 以下でFine-tuningを行いました。手順詳細については公式ドキュメントをご参照ください。 入力データ s3://bucket/traindata.jsonl ハイパーパラメータ(デフォルト値) ステップ：自動 エポック：5 バッチサイズ：8 学習率：0.00001 出力データ s3://bucket/output-bucket/ パラメータの値についてはガイドラインが掲載されています。 モデルカスタマイズに関するガイドライン - Amazon Bedrock モデルをカスタマイズする理想的なパラメータは、データセットと、モデルが対象とするタスクによって異なります。値をいろいろ試して、どのパラメータがお客様自身のケースで最も適切に機能するかを確認する必要があります。参考までに、モデル評価ジョブを実... docs.aws.amazon.com 結果 学習は 約 4 時間 で終了しました。この4時間、学習経過を確認できないのはムズムズしますね… リアルタイムで推移を観測できれば、Fine-tuningを途中でストップしたり、パラメータを調整できたりと便利なのですが。 学習がおわるとoutput-bucketに「training_artifacts/step_wise_training_metrics.csv」が格納されます。 格納された学習推移データをグラフ化したものは以下です。 ※こう見えて折れ線グラフです。 学習ステップをAutoにしたせいで、8000回も学習してしまっています。画像数が多くなると学習回数も増えます。 学習がうまくいっているのかの判別は、簡単に言えばtraining_lossがきれいに収束すればいいのですが、収束しているように見えませんね… 雲行きが怪しくなってきました。 では、さっそくFine-tuned modelを購入してモデルを使用してみます。 と思い、プレイグランドでいつものようにプロンプトを入力したところ以下のように怒られてしまいました。 Malformed input request, please reformat your input and try again. ドキュメントを確認しましたが、解決法がわからず…仕方ないので、Lambdaで実行します。 Lambdaでの実行方法は以下を参考にさせていただきました。ありがとうございます！ Amazon Titan Image Generator G1 を AWS Lambda から試してみた Amazon Titan Image Generator G1 を AWS Lambda から実行するときの手順を紹介します。 blog.usize-tech.com 2024.02.14 参考ブログではmodelIdとして”amazon.titan-image-generator-v1″を指定していますが、 Fine-tuned modelではプロビジョンドスループット購入後のARNを指定します。 データセットに存在するプロンプト まずは、データセットに存在するプロンプトの出力を確認します。 プロンプトに「 Hieroglyph of a man eating 」を入力しました。 上：Original model　下：Fine-tuned model まさかFine-tuned modelもカラーで出力されるとは思いませんでした。もとのmodelの影響を受けているのでしょう。 Fine-tuned modelでは、元データ「 𓀁 」に近いものが出力されることがわかります。絵柄はFine-tuningで変えることができるようです。 色々と他のものも試していくうちにうまく学習できるものと、できていないものがあることに気が付きました。 以下の「 Hieroglyph of star 」が失敗例です。 上：Original model　下：Fine-tuned model 他の学習データと比べて「 𓇼 」のヒエログリフ自体が異質なことが原因と考えられます。 データセットに存在するプロンプトを複数組み合わせる 次に、データセットに存在するプロンプトを複数組み合わせてみます。 プロンプトに「 Hieroglyph of a man eating a pig 」を入力しました。 上：Original model　下：Fine-tuned model データセットに存在する「Hieroglyph of a man eating」 𓀁 +「Hieroglyph of pig」 𓃟 が一緒に出力されました。 pigと戯れている男性にしか見えませんが、許しましょう。象形文字ですから。 データセットのpigは左向きですが、右向きにいい感じに修正してくれています。そっぽ向いてると寂しいですもの。 では数の概念は学んでいるのでしょうか？データセットには1~9本の指の画像が存在しています。 「 Hieroglyph of five pots 」を入力してみます。 ＿人人人人人人＿ ＞　　６個　　＜ ￣Y^Y^Y^Y^Y￣ データセットに存在しないプロンプト 最後にデータセットに存在しないプロンプトを入力します。 古代エジプトになかったであろう「エレキギター」を入力してみます。 上：Original model　下：Fine-tuned model エレキギターですね。こんなものが出土したらビックリです。 う～ん、データセットに存在しないものは全く変化ありませんでした。もう少し抽象的なものになるかと期待していました。 どうすれば期待した結果を得ることができるのでしょう…？ 皆様のご意見お待ちしております。 まとめ step_wise_training_metricsのグラフを見た時はどうなるかと思いましたが、一部うまく学習してくれてよかったです。 たまにtrain_lossが跳ね上がるのは、データ量が少ないのか、質が悪いのか、パラメータが悪いのか考えられる原因は多いですが、まだまだ実験が必要ですね。 余力と予算があれば、またチャレンジしたいと思います。 感想 これで夏休みの宿題は終わりです。これからBBQに行ってきます。

本記事は 夏休みクラウド自由研究 8/18付の記事です 。 こんにちは。SCSKのふくちーぬです。 2024/7/11に Amazon ECS のアップデートが発表されました。今回は、Amazon ECS においてローリングアップデート時のソフトウェアの一貫性が保証されるようになりましたので紹介します。 Amazon ECS でコンテナ化されたアプリケーションにソフトウェアバージョンの一貫性が強制されるようになりました 以前まではECSにおいてlatestタグを利用していた場合、latestタグの更新・タスクのスケールアウトのタイミング次第で、latestタグが参照するコンテナイメージが異なるため、サービス内でコンテンツが異なるタスクがデプロイされてしまう事象が発生していました。 Amazon ECS でコンテナ化されたアプリケーションにソフトウェアバージョンの一貫性が強制されるように - AWS AWS の新機能についてさらに詳しく知るには、 Amazon ECS でコンテナ化されたアプリケーションにソフトウェアバージョンの一貫性が強制されるように aws.amazon.com 2024/7/11のアップデートにより、イメージタグが更新された場合において、サービス内のすべてのタスクが同一であることを保証し、ユーザーに一貫性のあるアプリケーションを提供することが可能です。 以前までのデプロイ方式 実際にどのようなデプロイ方式であったか説明します。 以前の方式では、各タスク内でその都度コンテナイメージタグのイメージダイジェスト解決をしていました。 そのため、例えば以下のようなシナリオにおいてスケールアウトのタイミングでコンテンツが異なるタスクがユーザーに公開される可能性があります。 ①タスク定義内のlatestタグに従い,2つのタスクが起動 ②開発者がlatestタグを更新（latestタグを新しいコンテナイメージへ参照先を変更する） ③タスクのスケールアウトが発生し,タスク定義内のlatestタグに従い,1つのタスクが新規起動 このように、サービス内でタスク間で異なるイメージダイジェストを参照することで、意図しないWebコンテンツの公開が行われてしまいます。 Announcing software version consistency for Amazon ECS services | Amazon Web Services Introduction Container image tags offer a user-friendly way to manage and keep track of different versions of container ... aws.amazon.com 最新のデプロイ方式 最新のデプロイ方式では、一連のデプロイメントにおいて、ECSサービス内でコンテナイメージタグがイメージダイジェストに解決されて保存されます。よって、同じタスクをユーザーに公開することが可能になりました。 先程と同様のシナリオで違いをみてみます。 ①タスク定義内のlatestタグに従い,2つのタスクが起動 ②開発者がlatestタグを更新（latestタグを新しいコンテナイメージへ参照先を変更する） ③タスクのスケールアウトが発生し,タスク定義内のlatestタグに従い,1つのタスクが新規起動 Announcing software version consistency for Amazon ECS services | Amazon Web Services Introduction Container image tags offer a user-friendly way to manage and keep track of different versions of container ... aws.amazon.com 検証 今回のアップデートを早速検証してみます。イメージダイジェストに基づいてタスクが起動し、一連のデプロイでタスク間で同一のイメージダイジェストを参照していることを確認することがゴールとなります。 事前準備 VPC、サブネット、ルートテーブル、インターネットゲートウェイ、ネットワークACL、ECRが作成済みであることを確認してください。 ECRへコンテナイメージをpush nginx-helloリポジトリにイメージをpushします。 下記のdockerfileを利用して、コンテナイメージを作成します。 # ベースイメージとしてnginxの公式イメージを使用 FROM nginx:latest # "Hello, world!" を返すHTMLファイルを作成 RUN echo "Hello, world!" > /usr/share/nginx/html/index.html #80番ポートで公開 EXPOSE 80  Cloud9やCloudShell等のdockerインストール済みのサーバを用意して、上記のdockerfileをビルドします。 サーバのIAMロールには、下記の権限を付与しておいてください。 ・arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryPowerUser docker build . -t <AWSアカウントId>.dkr.ecr.ap-northeast-1.amazonaws.com/nginx-hello:latest ECRへログインした後に、ECRのリポジトリにコンテナイメージをpushします。 aws ecr get-login-password --region ap-northeast-1 | docker login --username AWS --password-stdin <AWSアカウントId>.dkr.ecr.ap-northeast-1.amazonaws.com docker push <AWSアカウントId>.dkr.ecr.ap-northeast-1.amazonaws.com/nginx-hello:latest 以下のように、ECRのリポジトリ内にコンテナイメージが1つ格納されます。 CloudFormationテンプレート 以下のテンプレートを使用して、デプロイします。 AWSTemplateFormatVersion: 2010-09-09 # --------------------------------- # パラメータ # --------------------------------- Parameters: Env: Type: String VpcId: Type: String PublicSubnetA: Type: String PublicSubnetC: Type: String MyIp: Type: String Resources: # ================================ # ECS (Cluster) # ================================ ECSCluster: Type: "AWS::ECS::Cluster" Properties: ClusterName: !Sub "ECS-${Env}-helloworld-cluster" ServiceConnectDefaults: Namespace: !Sub "ECS-${Env}-helloworld-cluster" CapacityProviders: - FARGATE # ================================ # ECS (Task Difinition) # ================================ ECSTaskDefinition: Type: "AWS::ECS::TaskDefinition" UpdateReplacePolicy: Retain Properties: Cpu: 256 ExecutionRoleArn: !Sub "arn:aws:iam::${AWS::AccountId}:role/ecsTaskExecutionRole" Family: !Sub "ECS-${Env}-helloworld-taskdef" Memory: 512 NetworkMode: awsvpc RequiresCompatibilities: - FARGATE ContainerDefinitions: - Name: helloworld Image: !Sub "${AWS::AccountId}.dkr.ecr.${AWS::Region}.amazonaws.com/nginx-hello:latest" LogConfiguration: LogDriver: awslogs Options: awslogs-group: !Sub "/ecs/ECS-${Env}-helloworld-service" awslogs-region: !Ref AWS::Region awslogs-stream-prefix: latest PortMappings: - AppProtocol: http HostPort: 80 Protocol: tcp ContainerPort: 80 Name: helloworld-8080-tcp ReadonlyRootFilesystem: false RuntimePlatform: CpuArchitecture: X86_64 OperatingSystemFamily: LINUX # ------------------------------------------------------------# # Security Group # ------------------------------------------------------------# ECSServiceSecurityGroup: Type: AWS::EC2::SecurityGroup Properties: GroupDescription: ecs security group VpcId: !Ref VpcId SecurityGroupIngress: - IpProtocol: tcp FromPort: 80 ToPort: 80 CidrIp: !Ref MyIp SecurityGroupEgress: - IpProtocol: -1 FromPort: -1 ToPort: -1 CidrIp: "0.0.0.0/0" # ------------------------------------------------------------# # ECS Service # ------------------------------------------------------------# ECSService: Type: AWS::ECS::Service Properties: Cluster: !Ref ECSCluster DesiredCount: 2 DeploymentConfiguration: DeploymentCircuitBreaker: Enable: TRUE Rollback: TRUE MaximumPercent: 200 MinimumHealthyPercent: 100 DeploymentController: Type: ECS LaunchType: FARGATE NetworkConfiguration: AwsvpcConfiguration: AssignPublicIp: ENABLED SecurityGroups: - !Ref ECSServiceSecurityGroup Subnets: - !Ref PublicSubnetA - !Ref PublicSubnetC PlatformVersion: 1.4.0 ServiceName: !Sub "ECS-${Env}-helloworld-service" TaskDefinition: !Ref ECSTaskDefinition # ------------------------------------------------------------# # ECS LogGroup # ------------------------------------------------------------# ECSLogGroup: Type: "AWS::Logs::LogGroup" Properties: LogGroupName: !Sub "/ecs/ECS-${Env}-helloworld-service"   Webサーバのコンテンツを確認 デプロイ済みのタスクのパブリックIPアドレスにアクセスして、コンテンツを確認します。 2つのコンテナどちらも”Hello, world!”が表示されます。 ECRへコンテナイメージを再push 下記のdockerfileを利用して、コンテナイメージを作成します。 # ベースイメージとしてnginxの公式イメージを使用 FROM nginx:latest # "Hello, world! Welcome" を返すHTMLファイルを作成 RUN echo "Hello, world! Welcome" > /usr/share/nginx/html/index.html #80番ポートで公開 EXPOSE 80  上記のdockerfileをビルドします。 docker build . -t <AWSアカウントId>.dkr.ecr.ap-northeast-1.amazonaws.com/nginx-hello:latest </awsアカウントid> ECRのリポジトリにコンテナイメージをpushします。 docker push <AWSアカウントId>.dkr.ecr.ap-northeast-1.amazonaws.com/nginx-hello:latest </awsアカウントid> 以下のように、ECRのリポジトリ内のlatestタグの参照先が更新されます。 タスクの再起動 今回は検証目的のため、タスクを手動停止することで新規タスクを起動させます。もしAuto Scalingが設定されていれば、スケールアウトでも同様に新規タスクを起動させることができます。 タスクを1つ選択後に、「選択されたものを停止」を押下します。 「停止」を押下します。 すぐにタスクが停止され、新規タスクの再起動が始まります。 Webサーバのコンテンツを再確認 新規に起動したタスクのパブリックIPアドレスにアクセスして、コンテンツを確認します。 こちらも”Hello, world!”が表示されます。コンテナイメージとしては、古いのバージョンのものを参照していますね。タスクの詳細を確認してみます。 新規に起動したタスクのイメージURIを確認すると、古いバージョンのもの(以前のイメージダイジェスト)を参照していることが分かります。 ソフトウェアバージョンの一貫性の挙動を確かめました。これによってユーザーには、同一のコンテンツを提供することが可能になります。 注意事項 ・実環境でECSプラットフォームバージョン1.3.0についても、ソフトウェアバージョンの一貫性がサポートされていました。つまり、現AWS環境ではECSプラットフォームバージョン1.3.0,1.4.0が利用できるため、全てソフトウェアバージョンの一貫性がサポートされることに注意してください。 Deploy Amazon ECS services by replacing tasks - Amazon Elastic Container Service When you create a service that uses the rolling update deployment type, the Amazon ECS service scheduler replaces the cu... docs.aws.amazon.com タスクを置き換えて Amazon ECS サービスをデプロイする - Amazon Elastic Container Service ローリング更新デプロイタイプを使用するサービスを作成すると、Amazon ECS サービススケジューラは現在実行中のタスクを新しいタスクに置き換えます。 docs.aws.amazon.com ※2024/8/13にて、本検証を行ったところ、1.3.0以上でもサポートされている挙動を確認したため、AWSサポートに問い合わせ、AWSドキュメントを修正いただいています。日本語ドキュメントでは、1.4.0以上でのみサポートされていると記述されておりますが、英語ドキュメントでは1.3.0以上でサポートしている旨に修正されています。   最後に いかがだったでしょうか。 コンテナでlatestタグを利用している場合でも、ECSでのデプロイがより快適なものになりました。 最新アップデートを鵜吞みにするだけではなくきちんと動作検証をすることで、AWSドキュメントの不備にも気づくことができました。 本記事が皆様のお役にたてば幸いです。 ではサウナラ～🔥

本記事は 夏休みクラウド自由研究 8/17付の記事です 。 こんにちは、SCSKでAWSの内製化支援『 テクニカルエスコートサービス 』を担当している貝塚です。 昨日の寺内の記事 で、VPC環境に AWS CloudShell を作成し、ネットワークまわりのテストにも使用できそうだという話が出ていました。本記事では、ネットワークテストツールとしてCloudShellを利用できるのか、という観点でもう少し考察してみることにします。 VPC環境にCloudShellを作成する手順については、上記記事をご覧ください。 ネットワークコマンドを試してみる さっそく、VPCに作成されたCloudShellで、代表的なネットワークコマンドを試してみることにします。 ping もちろん、インストールされています。 スクリーンショットを見ても分かるわけがないのですが、実はあて先のIPアドレスはもうひとつ起動したCloudShellです。 寺内の記事 にあった通り、VPC環境CloudShellはIAMユーザごとに2つまで作成できるので、CloudShellのみでエンド・トゥ・エンドの疎通確認を行うことが可能です。(セキュリティグループでpingを許可する必要がある点に注意) curl curlもインストールされています。 なお、CloudShellは、DNSとしてAmazon Provided DNSを参照しているので、DNS名前解決をすることができます。 dig dig はインストールされていません。また、nslookup もインストールされていません。EC2用のAmazon Linux 2023 AMIにはインストールされていましたので、CloudShell化の際に落とされてしまったコマンドなのでしょう。 DNS名前解決の動作確認は個人的には必須と思っているので、digが使えるように、リポジトリからパッケージをインストールしてあげることにします。 その他のコマンド EC2用Amazon Linux 2023には入っていた tcpdump は入っていませんでした。また、EC2用Amazon Linux 2023に入っていなかった telnet や nc (netcat)も、もちろん入っていません。 これらのコマンドも必要に応じてインストールできるといいですよね。 リポジトリにアクセスする方法を考える CloudShellの /etc/yum.repos.d/amazonlinux.repo を見ると、ミラーリストにcdn.amazonlinux.com が指定されています。これはインターネット上のサイトなので、CloudShellからインターネットへ接続できるようにする必要があります。 インターネットに接続する NATゲートウェイ経由 NATゲートウェイ経由でインターネットに接続可能なサブネットにCloudShellを作成した場合、特に考えることはありません。CloudShellもサブネットに設定されたルートテーブルに従って通信するため、NATゲートウェイ経由でインターネットに接続することができ、Amazon Linux 2023のリポジトリを参照することができます。 パブリックIPを持たせる パブリックサブネットにCloudShellを作成した場合ですが、CloudShell作成時に自動でパブリックIPが割り当てられることはありません。そのため、 寺内の記事 にある手順でCloudShellのENIを特定し、「アクション」→「アドレスの関連付け」からパブリックIPを関連付けてあげる必要があります。パブリックIPを関連付けると、インターネットに接続することができるようになり、Amazon Linux 2023のリポジトリを参照することができます。 S3 VPCエンドポイントに接続する 次に、インターネット接続が全くできないサブネットに配置したCloudShellを考えます。 通常のAmazon Linux 2023では、S3エンドポイント(s3.dualstack.ap-northeast-1.amazonaws.com など)に接続できればリポジトリにアクセスできるようになっていますが、前述の通り、CloudShellのリポジトリ設定では、cdn.amazonlinux.comを参照しており、S3エンドポイントを参照していません。 通常(EC2)のAmazon Linux 2023のリポジトリ設定 そこで、EC2 Amazon Linux 2023に設定された /etc/yum.repos.d/amazonlinux.repo の内容で、CloudShellの /etc/yum.repos.d/amazonlinux.repo の内容を置き換えてあげます。どちらもAmazon Linux 2023のリポジトリなので問題はないはず……と試してみると、問題なくリポジトリを参照することができました。 インターネットに接続できないサブネットに作成したCloudShellでも、S3 VPCエンドポイント(ゲートウェイ/インターフェイス)にアクセスできるようになっていればリポジトリへのアクセスは問題なさそうです。(※) (※)もしAWSサポートに問い合わせたら、想定していない利用方法ということで使用非推奨と答えられるかもしれませんが…… パッケージをインストールする リポジトリにアクセスできるようになったら、パッケージを入れていきます。 通常のパッケージインストールと何ら変わりないので、詳細は割愛しますが、bind-utilsパッケージをインストールすることでdigコマンドを(ついでにnslookupコマンドも)実行できるようになりました。 bind-utilsがdigを提供している digコマンド実行 制約事項の確認 ここからは、VPC環境CloudShellを使っていて分かった制約事項の類を解説していきます。 制約事項：インアクティブ状態になってから20～30分でセッションが終了する まず、VPC環境特有の話ではありませんが、CloudShellを使わずに20～30分おいておくと、セッションが終了します。セッション終了時の挙動が、通常のCloudShellとVPC環境CloudShellでは異なり、VPC環境CloudShellはだいぶ厳しい制約があることが分かりました。 セッションが終了すると変更したデータは初期状態に戻る 通常のCloudShellは、ホームディレクトリは永続ストレージになっておりセッションが終了してもデータは削除されませんが、VPC環境CloudShellではセッション終了時にホームディレクトリのデータも削除されます。 また、ホームディレクトリ以外の変更（例えば /bin にインストールしたコマンドなど）も元に戻ってしまいます。 そのため、せっかくパッケージをインストールしてもセッションが終了すると一からやり直しになります。 セッションが終了するとネットワークインターフェイス(ENI) IDが変わる/プライベートIPが変わる 一度セッションが終了し、CloudShellを再起動すると、ネットワークインターフェイスIDが変わってしまいます。また、プライベートIPも変わってしまいます。そもそもVPC環境CloudShellを作成するときにIPアドレスは指定できませんでした。 環境によっては、サブネットサイズよりも狭い範囲(例えば1 IP単位)で通信をフィルタリングしなければならないこともあると思いますので、この仕様はうれしくありません。 ただしこれについては、ENIにセカンダリIPを割り当てることができるので、明示的にアドレスを指定してセカンダリIPを割り当てたのちにOS側でIPアドレスを設定してあげれば、特定のIPアドレスを使って通信させることが可能です。 ENIとパブリックIPの関連付けが解除される セッションが終了したときにENIがなくなってしまっているので、CloudShellを再起動して新しいENIが作られたときにはパブリックIPが関連付けられていない状態になってしまいます。 面倒ですが、セッションが終了してしまった時にはおとなしく再設定してあげるしかなさそうです。 制約事項：ファイルのダウンロード/ファイルのアップロード機能がない デフォルトのCloudShellで使えたファイルのダウンロード/ファイルのアップロード機能が使用できません。 sftp/scpコマンド、CodeCommitを使うためのgitコマンド、S3を使うためのAWS CLIなどが入っているので、これらで代用することを考えましょう。 まとめ 本記事では、ネットワークテストツールとして使用するという視点でCloudShellを見てきました。 OSにAmazon Linux 2023を使っているだけあって、リポジトリにアクセスできてしまえば思う存分ネットワークテストに活用できそうですね。 一方、インターネットにもS3エンドポイントにもアクセスできない環境に作成する場合、ネットワークテストツールとして使うにはインストールされているコマンドが少なすぎる印象です。とはいえpingとcurlが使えて、pingに応答してくれるだけで十分助かる場面はありそうです。 また、永続ストレージがなくセッションが終了してしまうとディスクへの変更がすべて失われてしまうのは大きな制約と言えます。しかし永続ストレージについては今後の機能追加が期待できると思いますので、これについては時間の問題と言えるかもしれません。

こんにちは。SCSK株式会社の杉田です。 2024年4月～6月にかけて、 ServiceNow資格取得支援セミナー「Now Rally Season 3」 が開催されました。 SCSKからも5名参加いたしましたので、参加レポートをご紹介いたします。 Now Rallyとは 「Now Rally」とは、約 2 ヶ月間で ServiceNow® の認定技術資格を取得 することを支援するセミナーです ​。 Now Rallyの概要 本セミナーの概要に関しては以下の通りです。 2024 年4月 – 6 月にかけて開催（全8回のMTG） ​ 招待制の合同トレーニングコース 対象 ​ 資格試験合格にコミットし、業務として参加可能な人 ​ ServiceNow 認定技術資格に初めて挑戦する人 ​​ 内容 CSA 合格は必須要件であり、上位資格（ CDA 、または CIS ）の合格も 狙う ​ ServiceNow のメンバーによる勉強ガイドや Q&A だけでなく、オン ラインコミュニティでの参加者同士の交流なども通して、資格取得の 目標達成を支援 Now Rallyの特徴 認定資格取得をゲームとして楽しみながら、個人チャンピオンを目指します。 また、パートナー枠でチーム作成しチームチャンピオンを競い合います。 個人で上位３名、チームで上位３チームが表彰となります。 個人・チームでポイント数を競い合い、わくわくした気持ちでServiceNowに触れ合うことができることができました。  合格/不合格体験記の投稿、 Training コースの完了、認定資格の取得、外部Communityへの投稿、ミニクイズの順位など様々な場面でポイントを積み上げていくことが可能です。   Now Rallyに参加して 私はNow Rallyに参加以前は、ServiceNowの事前知識が殆どない状態でした。 このような状況で感じたメリットと、最終的な表彰結果をお伝えいたします。 メリット ServiceNow初学者として、私が感じたメリットは以下5点です。 ServiceNowを学習するにあたり、活用できるリソースを共有してくださる 毎MTGの最後に質問コーナーがあり、不明点を解消できる 参加者は私と同じようにServiceNow初学者が多く、周りに感化されながら学習に励むことができる チーム戦であるため、社内メンバとの交流が深まる 表彰と景品があるためやる気がでる！ セミナー主催の方々は非常に穏やかで優しく接してくださったため、安心してセミナーに参加することができました。 また、全8回のうち2回は対面で開催されたため、同じ目標を持つ方々と交流を持つことができたため自身のモチベーションを保つことができました。 表彰結果 なんと、SCSKチームは チーム総合1位 を獲得することができました！ また、 4名は資格取得も達成 し好調な成績を残すことができました。   最後に SCSKチームは、それぞれ既に案件を抱えており、業務の合間をぬって本セミナーに参加しておりました。 抱えている案件と本セミナーを両立させることは非常に難易度が高いものだったかと思いますが、最終的にServiceNowの基礎知識を得ることができ非常に良い経験となりました。 今後もNow Rally Season 4.5.6…と続いていくかと思いますので、気になる方はぜひ参加してみてください！ 最後に・・・ 弊社では、ITSMやESGなど様々なServiceNow製品を扱っています。 以下から問合せ可能ですので、ご参照ください。 ServiceNow ServiceNowは、企業の生産性向上や業務プロセス改善を支えるサービスマネジメントクラウドソリューションです。従業員満足度・顧客満足度の向上、業務効率化を強力に支援します。 www.scsk.jp

本記事は 夏休みクラウド自由研究 8/16付の記事です 。 どうも、相変わらずCloudShellの話題の寺内です。 時期を逸してしまいましたが、2024年6月26日に、AWS CloudShell が指定のVPC内で起動できるようになりました。 AWS CloudShell now supports Amazon Virtual Private Cloud (VPC) - AWS Discover more about what's new at AWS with AWS CloudShell now supports Amazon Virtual Private Cloud (VPC) aws.amazon.com 作成数の制約 ひとつのIAMユーザで作成できるVPC環境のCloudShell は2つまでです。 VPC環境のCloudShell を削除するには、削除したいCloudShellのコンソールを選択した後、アクションから「削除」を選択します。意外とわかりにくいですね。   作成 VPC環境のCloudShell を作成するには、CloudShell の「アクション」メニューから「Create a VPC environment (max 2)」 を選択します。 すると以下のようなVPCとサブネット、セキュリティグループを選択する画面がでますので、ここを指定するだけです。 ネットワークインターフェースの確認 このようにして作成したVPC環境のCloudShell のIPアドレスを確認してみましょう。 CloudShellを作成する以下の種類のVPCを指定します。 VPC環境ではない標準のCloudShell インタネットゲートウェイを持つパブリックサブネットのCloudShell インターネットゲートウェイを持たず外部接続できないCloudShell IPアドレスの値は、それぞれ指定したVPCとサブネットの設定に依存します。ここでは、その値そのものより、ネットワークインターフェースに注目します。 a. 標準のCloudShell [cloudshell-user@ip-10-132-71-142 ~]$ ip addr 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host noprefixroute valid_lft forever preferred_lft forever 2: ens5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc mq state UP group default qlen 1000 link/ether 0e:cb:3f:8e:55:d7 brd ff:ff:ff:ff:ff:ff altname enp0s5 altname eni-079c3fba4bc3a932d altname device-number-0 inet 10.132.71.142/19 metric 512 brd 10.132.95.255 scope global dynamic ens5 valid_lft 3445sec preferred_lft 3445sec inet6 fe80::ccb:3fff:fe8e:55d7/64 scope link valid_lft forever preferred_lft forever 4: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default link/ether 02:42:f8:e3:ca:72 brd ff:ff:ff:ff:ff:ff inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0 valid_lft forever preferred_lft forever b. インターネット接続可能なVPC [cloudshell-user@ip-10-1-1-46 ~]$ ip addr 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever 2: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default link/ether 02:42:4c:44:c6:9f brd ff:ff:ff:ff:ff:ff inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0 valid_lft forever preferred_lft forever 4: ens6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc mq state UP group default qlen 1000 link/ether 06:78:c6:7c:d0:c1 brd ff:ff:ff:ff:ff:ff altname enp0s6 altname eni-03e1af8560b73e6fe altname device-number-1 inet 10.1.1.46/24 scope global ens6 valid_lft forever preferred_lft forever 5: devfile-veth0@if6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether da:70:b4:10:58:d7 brd ff:ff:ff:ff:ff:ff link-netnsid 0 inet 192.168.0.2/32 scope global devfile-veth0 valid_lft forever preferred_lft forever c. クローズドVPC [cloudshell-user@ip-10-10-1-223 ~]$ ip addr 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever 2: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default link/ether 02:42:b8:b6:77:c8 brd ff:ff:ff:ff:ff:ff inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0 valid_lft forever preferred_lft forever 4: ens6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc mq state UP group default qlen 1000 link/ether 06:9e:3b:36:ff:bf brd ff:ff:ff:ff:ff:ff altname enp0s6 altname eni-0a72fb1c1bcc4d6c6 altname device-number-1 inet 10.10.1.223/24 scope global ens6 valid_lft forever preferred_lft forever 5: devfile-veth0@if6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether e2:d3:11:74:63:1f brd ff:ff:ff:ff:ff:ff link-netnsid 0 inet 192.168.0.2/32 scope global devfile-veth0 valid_lft forever preferred_lft forever いずれも以下の3つのネットワークインターフェースは持っていることがわかります。 lo docker ens ensのインターフェースを見ると、altname(別名)としてeni IDが記載されています。 CloudShell コンテナがAWSの基盤内で作られると、そのコンテナに対して利用者のAWSアカウント内の指定VPCにENIが作成され、そこと関連付けられる仕組みのようです。 確認のために、EC2のコンソールからネットワークインターフェース一覧を見てみてください。そこで、 ManagedByCloudShell というタグキーを持つENIを検索すると、上記の altname に記載されたENIがリストアップされます。 またVPC環境の CloudShell には上記に加えて、 devfile-veth0 というものを持っています。devfile というのは、CodeCatalyst などで使われる構成情報自動化のファイルなので、内部の自動構築を行うための専用の制御ネットワークがあるのかもしれません。これは推測です。 使いどころ このような仕組みで提供されるVPC環境のCloudShell ですので、使いどころを考えてみましょう。 いままで構築したEC2やRDSなどのVPC内リソースの動作確認に、テスト用EC2を立て、そこからping やtelnet、curl やmysql コマンドでテストをしていたのではないかと思います。 そうした一時的なテストでは、VPC環境のCloudShell が活用できます。 その他、ちょっとしたデータ加工の後のテストデータの作成とテストの実施などにも便利ですね。 注意すべきは、インターネット接続できないクローズドなVPCに作った場合です。インターネットのリポジトリへアクセスできませんので、追加のツールインストールができません。AWS APIへのアクセスもVPCエンドポイントがない限りはできません。 当然といえば当然ですが、VPC内のEC2やコンテナなどと同じネットワーク条件になるわけなので注意が必要です。 その他、従来のCloudShell の注意点である、以下も同じですのでお忘れなく。 1GBしか保存できない 120日間アクセスないとデータが消える 12時間でセッションが切れる ますます便利になったAWS CloudShell。これからも愛用していきたいと思います。なんせ無料なのがいい。ですが、VPC環境の場合データ通信量はかかります。

こんにちは。SCSKの吉田です。 前回の記事では、ServiceNowに関わる人たちの生成AIに対する熱気がとてもすごいとお伝えしました。 [ServiceNow] Knowledge 2024 現地体験レポート　～ 生成AIがすごい ～ ラスベガスで開催されるServiceNowの年次ビッグイベント「Knowledge 2024」に参加してきました！ 参加者全員のServiceNow、生成AIへの熱気が感じられる、非常に盛り上がったイベントでした。 今回は、現地での体験談をご紹介します。 blog.usize-tech.com 2024.07.19 そんなServiceNowでは、昨年リリースのVancouverバージョンからNow Assistと呼ばれる生成AI機能が導入されています。 今回は、ServiceNowのインスタンス上で実際にNow Assistをセットアップしてみましたので、その手順のご紹介となります。 Now Assistの各機能は次回以降紹介していこうと思います。 本記事は執筆（2024年8月）時点の情報です。最新の情報は製品ドキュメントを参考にしてください。   Now Assistとは 冒頭でお伝えした通り、Now AssistはServiceNowの生成AI機能となります。 Now Assistを活用することで、従業員、開発者、ヘルプデスク、顧客などの業務を効率化し、組織の生産性を向上させることが可能です。 様々な業務領域向けに機能が展開されており、現時点では以下が利用可能となります。 Now Assist for IT Service Management Now Assist for Customer Service Management Now Assist for HR Service Delivery Now Assist for IT Operations Management Now Assist for Strategic Portfolio Management Now Assist for Creator セットアップ手順 プラグインのインストール Now Assistを使用するために、必要なプラグインをインストールします。 対象のアプリケーションをServiceNow Storeでリクエストした後、Now Platform上の「All Available Applications」メニューからインストール可能となります。 インストールしたプラグインは、Now Assist Adminコンソールの「Settings」タブより確認できます。 ※Now Assist Adminコンソールは、Now Assistの各種設定、使用状況、パフォーマンスなど様々な情報を一元管理できる非常に便利なコンソールです。各機能の詳細については、別途ご紹介予定です。   Now Assistパネルの有効化 Now Assistパネルは、チャット形式で生成AIがNow Assistの利用をサポートしてくれる機能となります。 パネルを経由した会話形式での生成AI機能利用が可能になり、ユーザーの生産性向上に繋がります。 Now Assist Adminコンソールから、Settings > Now Assist panelと選択し、「Turn on」をクリックします。 Now Assistパネルが有効化されると画面右側にチャットが表示され、生成AIが利用可能なオプションを提示してくれます。 あとは会話形式でやり取りを進めていくことで、Now Assistの機能を利用することができます。 ここでは、画面に開いているインシデントレコードの要約をNow Assistに依頼しています。   各機能のアクティベート Now Assist Adminコンソールの「Now Assist Features」より、各生成AI機能のアクティベートができます。 利用したい機能を選び「View details」をクリックします。 「Activate skill」をクリックします。 次の画面では、機能を使うための必要な設定が一覧で表示されます。 例えば、この機能はどのロールを持つユーザーが使えるかなど、権限設定もこの画面で実施可能です。 あとはガイドに従って順番に必要な設定を進めていき、全て完了したら「Activate」をクリックして、セットアップは完了です。   感想 今回、Now Assistをセットアップしてみて「こんな簡単に生成AIを使い始められるのか」という感想を持ちました。 AIと聞くと設定が難しそうと感じてしまいますが、ServiceNowでは、ユーザーフレンドリーなインターフェースやガイドが用意されているため、AIを触るのが初めての人でもスムーズに設定を行うことができます。 次回以降は、Now Assistの各機能をご紹介していきたいと思います。     最後に・・・ 弊社では、ITSMやESGなど様々なServiceNow製品を扱っています。 以下から問合せ可能ですので、ご参照ください。 ServiceNow ServiceNowは、企業の生産性向上や業務プロセス改善を支えるサービスマネジメントクラウドソリューションです。従業員満足度・顧客満足度の向上、業務効率化を強力に支援します。 www.scsk.jp

CatoクライアントにはOffice Modeという動作があり、このモードになるとクライアントの画面に「Office Network」と表示がでます。特に設定しなくても動作するため、「オフィスにいると、いつの間にかOffice Modeになっている」ということも多いのではないでしょうか。 Office Modeとはそもそも何なのか? どう役立つのか? またこの機能の応用的な使い方についてもご紹介します。 Office Modeとは? Office Modeとは、 Catoクライアントが動作している端末を、すでにCatoに接続しているSite(拠点)内に接続した際に、二重接続にならないように Catoクライアントを自動切断する機能 です。 クライアントがOffice Modeになると、上記の図のように「 Office Network 」と表示され、切断状態になります。ただこれだけのシンプルな機能です。 Office Modeが動作することで、以下のような メリット があります。 Site内でさらにクライアントを接続してしまうと、二重トンネルとなり無駄なオーバーヘッドが発生するため、これを防ぐ。 Site内の機器同士がローカルネットワークで通信できるようにする。 もしクライアントを接続してしまうと、Site内での通信なのに、クライアントからCato PoPを通ってSocket経由で戻って来るという大回り通信になってしまいます。これを防いでローカルで通信するために、クライアントを切断する必要があります。 そのユーザが現在Site内にいるのか、リモートユーザなのかを判別できるようにする。 Catoクラウドでは、ユーザがSite内にいるのか・またはリモートユーザなのかによって通信ルールの制御ができるので、正しい判定は大切です。各種通信ログも、その通信がSite内からなのかリモートからなのかを記録しています。 特に、CatoクライアントのAlways-Onを有効にしている場合には、ユーザは自分でクライアントを切断・接続することが原則できないため、Site内ではOffice Modeで自動切断する必要があります。 Office ModeのTips Office Modeは全OSのCatoクライアント(Windows/MacOS/iOS/Linux/Android)で対応しています。 なお、Office Mode中でもCatoクライアントの接続ボタンを押すことで、リモートユーザとして接続/切断することも可能です。Always-Onが有効であっても、Office Mode中であればクライアントで接続/切断ができます。クライアントが接続されている間は、リモートユーザとして識別されます。 また、設定によっては、各ユーザがクライアント側の設定でOffice Modeを利用する/しないを選択できるようにもできます。(この設定の活用例が思いついた方はぜひ教えてください…!) Office Modeになる条件とは? では、Catoクライアントは一体何を条件に、自分がSite内にいると判定して、Office Modeになっているのでしょうか。 過去には動作が整理されていなかったのですが、現在はKnowledge Baseに条件が明記されています。 Configuring Office Mode | Cato Knowledge Base Office Modeが動作する条件 ローカルネットワーク上にて、下記2つのFQDNの名前解決ができ、両方とも指定のプライベートIPアドレス(※1)が返されること。 vpn.catonetworks.net ⇒ 10.254.254.5 tunnel-api.catonetworks.com ⇒ 10.254.254.3 以下の2つのIPアドレス範囲への通信が許可され、Catoクラウドを経由していること (※2) 管理IPアドレス範囲(10.254.254.0/24) (※1) 54.76.219.86 ※1. 管理IPアドレス範囲をCatoのデフォルトから変更している場合には、IPアドレスが異なります。詳しくはKnowledge Baseを参照ください。 ※2. 厳密にはOS・クライアントバージョンによって条件が異なりますが、このように設定しておけば、通常のSocket配下ではすべてのOSでOffice Modeが動作します。(2024年8月現在 ) 1の条件となっている2つのFQDNは、グローバルDNSにはグローバルIPアドレスで登録されているのですが、CatoのプライベートDNS(10.254.254.1)ではプライベートIPアドレスで登録されています。このためクライアントは、指定のプライベートIPが返ってきて、かつそのIPへの通信がCatoクラウドを経由している場合には、すでにCatoクラウドに接続された環境にいると判断し、Office Modeになります。 もし、Site内から参照するDNSをCatoのDNS以外に設定されている場合には、そのDNSサーバに条件となるAレコードを設定することで、同様にOffice Modeが動作します。 以上がOffice Modeの動作仕様でした。通常の構成で、Socket配下でクライアントを利用する場合には、ここまでの理解で全く問題ありません。 特殊な構成でのOffice Modeの応用 続いて、応用例をご紹介します。Office Modeの動作を利用して、例外的なネットワーク構成の環境でも、クライアントをOffice Modeにすることができます。 例えば、以前「Trusted Network」の説明で例に挙げた、 「Cato以外のセキュリティソリューションを入れているネットワーク内で、Catoクライアントを切断したい場合」 です。 【Catoクラウド】機能紹介 Trusted Networkとは? Cato移行時のお役立ち機能「Trusted Network」について、動作や利用例をご紹介します。 blog.usize-tech.com 2024.08.14 以下2点の設定を行うことで、Socket以外の出口から通信しているような特殊な環境でも、クライアントをOffice Modeにし自動切断できる場合があります。 社内DNSに前述のAレコード 2つを設定する Catoの管理IPアドレス範囲 10.254.254.0/24(※)と、54.76.219.86への通信がCatoクラウドへ向くよう、ルーティング・通信許可を設定する ※管理IPアドレス範囲をCatoのデフォルトから変更している場合には、そのレンジに読み替えてください。 上記は2024年8月時点での仕様に基づく情報となり、動作を保証するものではないことをご了承ください。 ところで、Office ModeとTrusted Network、どちらでもクライアントの自動切断ができるなら、こういった特殊例ではどちらを使うのが良いのでしょうか。比較をまとめます。 機能 対応OS 自動切断の条件 Office Mode 全OS ※注意あり、後述します 規定のドメインをDNS問い合わせし、指定のIPアドレスが返ってくること。 指定IPアドレスへの通信ができ、かつCatoクラウドを経由していること。 Trusted Network Windowsのみ ※Macは対応予定あり HTTPS/DNS/Pingのいずれかで自由に条件を設定可能。 管理IPアドレスへの通信可否は問わない。 切断条件としては、Trusted Networkのほうが柔軟です。すべてのOSのクライアントがTrusted Networkに対応するよう、Catoにプッシュしていきたいですね。 Office Modeを応用する場合の注意点 Office Modeにも注意点があります。全OSのクライアントで対応はしていますが、クライアントの動作はOSに依存する部分も多く、細かな違いがあるようです。 通常の利用方法では問題は発生しない問題ですが、前述の応用例の構成において、当社で以下の状況を確認しています。(2024年6月時点) iOSクライアントにおいて 、Officeモードが動作するために、以下の2つのURLへの通信が、Catoクラウドを通過している必要がある。 http://www.msftconnecttest.com/connecttest.txt http://www.appleiphonecell.com また、MacOS/Linux/Android クライアントについては、応用例の構成での検証が不十分です。恐れ入りますが、ご了承ください。 まとめ 普段特に意識せず使っていることの多いOffice Modeについて、あらためてまとめてみました。 Office Modeを活用することで、クライアントのAlways-On(常時接続)を有効化でき、Catoクラウドをよりセキュアに利用できます。 なお、 もし応用例のようなご利用方法をご検討の場合は、ネットワーク構成や利用OSにより意図通りにならないことも考えられるため、導入前に十分な検証を行われることをおすすめします。 当社では、豊富な導入・運用実績をベースとした、手厚いご支援が可能です。Catoクラウドをすでにご利用中のお客様も、構成変更等のご相談がありましたら、どうぞお気軽にお声がけください。

本記事は 夏休みクラウド自由研究 8/15付の記事です 。 どうも、Catoクラウドを担当している佐々木です。 Catoの導入支援や運用支援をしていると、特定のアプリケーションの利用制限やアクセス制御をしたいけど、どの機能を利用したらいいかわからない、という声をよく聞きます。 そこで今回は 「Microsoft Teams」を例に、 アプリケーションの利用制限や アクセス制御のユースケース  をご紹介します。   画⾯は2024年8⽉時点のものです。 機能アップデート等で変わる場合がありますので、あらかじめご了承ください。   どんな方法があるのか 特定のアプリケーションに対して、利用方法を制御したい場合、Catoの以下機能を利用することが多いです。 もちろん実現できることも違いますので、それぞれの機能毎にどんなことができるか簡単にまとめてみました。   No 機能名 できること/用途 1 Internet Firewall/ WAN Firewall 特定のアプリケーションに関するインターネットやWANへの通信を制御できます。 細かい動作の制限などはせずに、特定のアプリを使った通信をブロックしたい、といった場合に利用できます。 例えばTeamsを制御する場合、Teamsに関係するインターネットやWANへの通信がすべてブロックすることができるので、実質Teamsを利用禁止にできます。 2 App Control Cato の Cloud Access Security Broker (CASB) ソリューションの一つです。 アプリケーション単位で特定の操作だけ許可したり、禁止したりといった制御が可能です。 例えばTeamsを制御する場合、ファイルのアップロード、ダウンロード、メッセージの送信、削除、ビデオ通話などの制限ができます。 3 Header Injections これもCato の Cloud Access Security Broker (CASB) ソリューションの一つです。 テナント制御（会社や管理者が許可したアカウントのみWEBサービスを利用できるようにする）を実現する機能です。 例えばTeamsを制御する場合、自社のMicrosoftアカウントでの利用だけ許可して、個人アカウントや他社のアカウントでの利用を禁止するといった制御が可能です。 4 DLP 機密情報や個人情報の損失および情報漏洩を防ぐ機能のことです。 「機密」や「マイナンバー情報」などの情報が記載されているデータやチャットでの投稿などを検知してブロックすることができます。 こちらもアプリケーション単位で制御することが可能で、TeamsやSlack上で上記のような投稿を検知した場合、ブロックするといった制御が可能です。   同じようなことをできる機能もあれば、オンリーワンの機能もあるようですね。 そこで、次項では「やりたいこと」から何の機能を選べいいのか、 紹介していきます。   上記、機能のうち、利用にあたってセキュリティオプションの購入が必要なものがあります。 No2、3 ：セキュリティオプションの「CASB」が必須になります。 No4　　：セキュリティオプションの「CASB/DLP」が必須になります。 また、No２～4を利用するにあたり、TLSインスペクションを有効にする必要があります。   ケース① 細かいことは言わずに全部ブロックしたい Internet Firewallでアプリケーションを定義してブロックするのが最適だと思います。 ※他の機能でも制御可能ですが、細かく設定する必要があるので面倒です。   【設定方法】Microsoft Teamsの場合 「Security」＞「Internet Firewall」から以下のように設定しましょう。 ポイントは以下です。 「App/Category」で「Skype and MS Teams」を選択すること 「Action」を「Block」とすること   対象者を制限したい方は、「Source」で対象のユーザーやIPアドレスを設定ください。 この設定をすると、Teamsでチャットや会議、ファイルのアップロード、ダウンロードなどTeamsの機能が一切利用できなくなります。   ケース② ファイルのアップロード、ダウンロードを制限したい App Controlを利用することで実現可能です。 ※File Controlという機能でも実現可能ですが、ファイル種類の指定がマストになるので余計な設定が多くなりオススメしません。 【設定方法】Microsoft Teamsの場合 「Security」＞「Application Control」から以下のように設定しましょう。 ポイントは以下です。 「App Control Rule」を選択すること 「Activities」で「UploadとDownload」をORで選択すること 「App/Category」で「Skype and MS Teams」を選択すること 「Action」を「Block」とすること   対象者を制限したい方は、「Source」で対象のユーザーやIPアドレスを設定ください。   この設定をすると、Teamsですべてのファイルのアップロード、ダウンロードができなくなります。   ケース③ 閲覧だけさせたい これは難しいです。 App Control機能を利用することで、ファイルのアップロード、ダウンロード以外にもアクティビティを制限することは可能ですが、 閲覧以外のすべての機能を制限するという設定はありません。 また、アプリケーションによって制限できる動作が異なり、例えば、Teamsの場合、ファイルのアップロード、ダウンロード、 メッセージの送信、削除などを制限する設定があります。 ※随時アップデートされるため、何ができるかはCMAから都度確認いただくのが一番良いです。   【設定方法】Microsoft Teamsの場合 ファイルのアップロード、ダウンロード以外のアクティビティを制限する設定を紹介します。 設定はケース２とほぼ同じです。 「Activities」で制限したいアクティビティを選択するだけです。   同時に設定できるアクティビティは最大5つまでです。 「Any Granular Activity」という「すべてのアクティビティを選択する」項目を選択するとBlock設定ができなくなります。   ケース④ 個人アカウントや他社アカウントでの利用を禁止したい 以下の2つの方法で実現できます。 Header Injections Header Injection機能という設定した条件（アプリケーションやアカウント等）にマッチする通信が発生した際、パケットのヘッダーに任意の文字列を挿入する機能を利用することでテナント制御が可能です。 TechHarmony フリークの方はお気づきかもですが、つい先日本機能に関する記事を記載しましたので詳細はそちらをご確認ください。 Catoでやる「Microsoft 365」のテナント制御～「Header Injection」機能の紹介～ Catoの「Header Injection」機能を使って「Microsoft365」のテナント制御を実施する方法を紹介します。 blog.usize-tech.com 2024.07.12   App Control App Control機能でも実現可能です。 Teamsの場合、結局Microsoftのアカウントでログインすることになります。 App Control機能の「App/Category」でMicrosoft Loginを選択し、許可したいアカウントのドメインのみログイン可能とするような設定をすることで制御可能です。 詳細は以下のFAQに記載ありますのでご確認ください。 ※ご契約者様の場合、なんと手順書もございます！！ Microsoft365に対してアカウント毎の制御を行いたい | よくあるご質問 | Cato Cloud ケイトクラウド - SCSK Cato環境でもCASBのApplication Control Policyを利用することで、Microsoft365に対してアカウント毎の制御が可能となります。例えば、Outlook機能に対して、会社アカウントからのアクセスは... cato-scsk.dga.jp ※ログイン画面が表示されて該当のFAQを開けない方は、FAQサイトの検索ウィンドウで以下を検索ください。 「Microsoft365に対してアカウント毎の制御を行いたい」   どっちを使うのがいいの？ 利用するアプリに対応している機能であればどちらでも問題ないですが、それぞれ特徴があります。   Header Injectionの場合、どのアプリケーションで設定するのかを調べるのが大変です。 実際にログイン通信を発生させて、CMAのEventログからどのアプリケーションにマッチしているのか、を調べて、テストして、 という作業が必要になると思います。 ただ、対応しているアプリケーションはApp Controlにくらべて多いと思います。   App Controlの場合、アプリケーションによって設定できるアクティビティが異なりますので、ログイン制限ができるかどうかCMAから確認が必要です。 そして、対応していない場合、どうしようもできません。。 （Catoに追加を依頼して、待つしかないっす！）   ケース⑤ 機密情報のアップロード、ダウンロードを制限したい DLPを利用することで実現可能です。 こちらも過去にブログ記事となっておりますので、詳細は以下の記事を参考にください。 ※Slackでの実現方法が紹介されていますが、Teamsでも基本同じ設定で実現可能です。   CatoクラウドのDLPについて Catoクラウドの情報漏洩対策にあたる「DLP」について紹介していきます！ blog.usize-tech.com 2023.10.06   まとめ 「Microsoft Teams」を例にしてアプリケーション利用制限のユースケースを紹介してきましたが、 他のアプリケーションでも基本的には同じ設定で実現可能です。 ただし、App Controlなどアプリケーションの動作を制限する機能の場合、アプリケーションの種類によって制限できる動作が異なりますので、ご注意ください。   上記以外の情報についても弊社の 「Catoに関するFAQサイト」 に多数情報ございますのでご参考にください。 よくあるご質問 | Cato Cloud ケイトクラウド - SCSK Cato SASE Cloud Platform. powered by SCSK cato-scsk.dga.jp   最後に、SCSKではPoCから導入、運用まで幅広くCatoに関する支援を行っております。 本番構成への移行を見据えたPoC構成や、PoCでつまづきやすい点のサポートなど、豊富な導入実績を基にご支援いたします。 ぜひお声がけください！

突然ですが、Catoクラウドには「Trusted Network」という機能があることをご存知でしょうか? 「モバイルユーザは常時接続(Always-On)させたいけれど、オフィス内など特定の環境下では切断したい」 といった場合に役立つ機能です。本記事にて具体的な用途や動作仕様をご紹介します。 なお、後述しますが、Trusted Networkは2024年8月現在はWindowsでしか動作しないため、他OSも含めて上記の動作を実現したい場合には、Office Modeの応用など、他の方法を取る必要があります。Office Modeについては別記事にてご説明予定です。 Trusted Networkとは? Trusted Networkとは、 条件に一致したネットワークを「Trusted Network」(信頼できるネットワーク)とみなし、その環境下ではCatoクライアントの接続を自動切断する機能 です。詳細はCato Knowledge Baseもご参照ください。 Disable Always-On in Designated Trusted Networks | Cato Knowledge Base 利用シーンを図にしてみました。 社外ではCatoクライアントをAlways-Onとし、社内ではCatoクライアントを切断したい場合に、社内ネットワークを「Trusted Network」と定義して、自動切断させることができます。 なお、この構成は、リモートユーザのみがCatoを経由していることから変な構成に見えますが、既存ネットワークからの段階的な移行において、リモートユーザに先行して導入した場合など、一時的にはよくある構成です。 Trusted Networkの「定義」とは? では、「このネットワークはTrusted Networkである」というのは、どのように定義・識別するのでしょうか。 Catoクラウドでは以下の定義に対応しており、CMA(管理画面)から設定が可能です。 Type 動作 HTTPS Response HTTPSのURLを指定します。クライアントはURLにアクセスし、200 or 300 台の応答があればTrusted Networkの中にいると判定します。 DNS Resolving ホスト名とIPアドレスのセットを指定します。クライアントはローカルネットワークのDNSサーバ(※)へ問い合わせし、指定のIPアドレスが返ればTrusted Networkの中にいると判定します。 Ping Response Hostname HostnameまたはIPアドレスを指定します。クライアントは宛先に対しPingを実行し、応答があればTrusted Networkの中にいると判定します。 Ping Response IP Address ※CatoのDNSサーバではなく、端末が接続されている有線or無線ネットワーク上のDNSです。多くの場合、社内DNSサーバになるかと思います。 いずれの場合も、判定の通信はCatoクライアントの仮想アダプタではなく、端末が接続されているローカルネットワークのアダプタから行われます。 なお、条件としてPing Response IP Address でプライベートIPアドレスを指定した場合、社外で接続した場合に意図せず同じIPアドレスの機器が存在し、誤判定が起こる可能性があることにご注意ください。CatoはHTTPS Responseでの設定を推奨しています。 また、条件は複数設定が可能です。 複数条件を設定した場合にはOR条件 となり、どれか1つでも条件を満たせば Trusted Networkと判定されます。 動作を確認してみました 実際に、以下の設定で動作を確認してみました。 管理画面にてTrusted Networkの条件を設定します。今回はHTTPS Responseで社内WebサイトのURLを指定しました。 社外のネットワークに接続し、PCを起動します。Always-Onが有効なためクライアントが自動接続されます。切断はできません。(切断ボタンが無効になっています) 次に、社内ネットワークに接続しなおします。ネットワークが切れたことで通常は再接続が走りますが、以下の表示になり、クライアントが切断されました。Trusted Networkと判定され、Disconnectedになっていることがわかります。 なお、この状態で接続ボタンを押してCatoクライアントを接続することも可能です(※)。 Trusted Network内にいるときは、Always-Onが有効であっても、切断・接続をユーザが手動で行えます。 ※社内NWにてCatoクライアントの通信が許可されている必要があります。つまり、社内からはCatoクライアントを接続させたくない場合には、社内のファイアウォール等で通信を制限することで実現可能です。 Trusted Networkの制約・注意 Trusted Networkには、以下の機能制約があります。 Trusted Networkは、Windowsクライアントのバージョン5.8以降でのみ動作します。 2024年8月現在、残念ながらWindowsのみの対応です。将来的にMacOSへの対応予定があると聞いていますが、他OSについては未定です。 Catoクライアントに設定されているユーザが1つの場合のみ正常に動作します。 2つ以上のユーザが設定されていると、クライアントがTrusted Networkの中にいても、Trusted Networkと判定されない場合があることを確認しています。 なお、CatoクライアントでTrusted Networkの判定が成功したか失敗したかは、CMA(Cato管理画面)のEventsには記録されません。Trusted Network内ではCatoクラウドとは切断されている状態だからです。一方、Catoクライアントログには判定動作の詳細が記録されていますので、調査したい場合はクライアントログを参照することとなります。 また、Trusted Networkに限らずCatoクライアントのローカルな設定全般に当てはまる内容ですが、 CMAで設定した内容は、CatoクライアントがCatoに接続したときに反映される(設定がダウンロードされるイメージです)ので、未接続の状態では反映されません。 設定をCatoクライアントに反映するには、一度Catoクライアントを正常に接続する必要があります。 特に、Catoクライアントへの接続を制限している環境では、CMAで設定したTrusted Networkがクライアントに反映されないまま接続すると、Trusted Networkの判定が行われず、Always-Onを切ることもできず、全く通信できなくなるといったことも起こり得ます。もしそうなってしまった場合は、一度社外NWに繋いで、Catoクライアントを接続し数分置いておくと設定が反映され、問題が解消できます。 まとめ Trusted Networkは、主に既存ネットワークからCatoクラウドへの移行中の状況で、クライアントのAlways-Onと自動切断を制御できる機能です。 しかしながら、2024年8月現在ではWindowsしか対応していないため、もしiOSやMacなど他OSも含めて同じ動作をさせたいときには、別の方法が必要となります。 具体的には、Catoクライアントの「Office Mode」の動作を応用することで、制約はあるものの全OSの制御が可能です。次回、Office Modeとその応用についてご紹介予定です。

本記事は 夏休みクラウド自由研究 8/14付の記事です 。 Cato Socketを使用してCatoクラウドを利用しているお客様から、瞬断が発生したため原因を確認してほしいとのお問い合わせをいただくことがあります。 原因の一つとして、PoPのメンテナンスやSocketの再起動などによってSocketとPoP間の接続が一時的に切れていたというケースがあります。 SocketとPoPとの再接続が発生した場合、Cato Management Application(以下CMA)のEvents機能から、再接続のイベントやなぜ再接続が行われたのかを確認することができます。 今回は、SocketとPoPの再接続イベントと、その理由をEventsから確認する方法についてご紹介します！ 画⾯は2024年8⽉時点のものです。 機能アップデート等で変わる場合がありますので、あらかじめご了承ください。 SocketとPoPとの接続イベントについて 一般的に、SocketがPoPに接続されると[Connected]、切断されると[Disconnected]のイベントが生成されます。そのため、切断イベントから再度接続された場合、基本的にこれらのイベントはペアで生成されます。 ただし、PoPとの接続が切断されてから ２.５分以内 に再接続した場合は、上記２つの代わりに[Reconnected]のイベントが生成されます。 ※接続するPoPが変わる場合は「Changed PoP」のイベントが生成されます。 次にSocketとPoPの再接続イベントをEventsから確認する方法についてご説明します。 ※Eventsの操作方法や見方について不安の方はまず以下のブログを参照ください！ Catoクラウド Eventsの確認方法 CatoクラウドのEvents画面の見方、ログの絞り込み方について解説します。 blog.usize-tech.com 2023.08.22 Eventsを使った再接続イベントの確認方法 はじめに、イベントを確認したいSiteと日時を絞りましょう。 この時に、以下 青枠 の[Connectivity]以外のチェックを外すと接続イベントのみ確認できるようになります。 次に[Fields]から[Sub-Type]を展開し、[Connected]や[Reconnected]の接続イベントがないか確認しましょう。 以下の画像では[Reconnected]が確認できましたね。[+]をクリックしてさらに絞り込みます。 次に表示されたイベントの[+]をクリックして詳細を展開します。 そして[Event Message]からReconnectedされた理由を確認しましょう。 上記[Event Message]には「Reconnected due to Socket restart (5)」と記載されていました。 つまりSocketの再起動によりReconnectedが発生したことがわかります。 Event Messageの詳細 上記の項目で紹介した[Event Message]では、SocketがPoPに再接続された理由を確認することができます。 もちろん再接続の理由によって[Event Message]に表示される内容は変わります。 すべての[Event Message]とその詳細説明につきましては、以下CatoのKnowledgeサイトに記載されていますので、詳細の確認にご活用ください！ Just a moment... support.catonetworks.com アラートメールからもEvent Messageが確認できる [Connected]のイベントに限りですが、Catoのアラートメールから[Event Message]を確認することができますので原因の確認や切り分けにご活用ください。 まとめ 本投稿では、SocketがPoPに再接続した際のイベントの確認方法についてご紹介しました。 なぜ再接続されたのかという疑問が、この記事により少しでも解消することができましたら幸いです。 なお、弊社の FAQ サイトでは 、よくあるご質問やCato クラウドのアップデート情報を公開しておりますので、是非ご参照ください！ よくあるご質問 | Cato Cloud ケイトクラウド - SCSK Cato SASE Cloud Platform. powered by SCSK cato-scsk.dga.jp

こんにちは。SCSＫ三上です。 今年も、インフォマティカ・ジャパンが主催するデータマネジメントカンファレンス「 Informatica World Tour 2024 」が開催されます！ このイベントは、AIを活用したクラウドデータ管理の最新テクノロジーとデモンストレーション、ユーザー導入事例、パートナーソリューションなど、多彩なプログラムが用意されています。高品質なデータに基づくAI活用の最新像をご体感ください。 Informatica World Tour 2024概要 開催日： 2024年9月13日（金） 会場： 大手町プレイス ホール＆カンファレンス この度当社は、ゴールドスポンサーとして出展いたします！ミニセッションでの登壇、ブース出展予定です。 講演では、基調講演やユーザの事例紹介、スポンサー各社によるデータマネジメントのセッション、 ブースでは、インフォマティカ社による生成AI対応のデモや、DXを推進するデータ連携・利活用導入事例やサービス紹介を行います。 この機会をぜひご活用ください。     ご登録がお済でない方は、こちらからご登録ください。↓↓ イベントの見どころ Informatica World Tour 2024では、AIを活用したクラウドデータ管理の最新テクノロジーとデモンストレーション、ユーザー導入事例、パートナーソリューションなど、多彩なプログラムが用意されています。 ☁基調講演 インフォマティカ・ジャパン株式会社 代表取締役社長によるデータが切り拓く生成AIの未来を紹介します。 データから価値を生み出しビジネスに変革をもたらすインフォマティカの戦略とデータの力により進化する世界をご紹介します。 ☁特別講演 イベント最後には、株式会社SUBARU「SUBARU流 全社データ活用で笑顔を 作る「モノづくり革新」と「価値づくり」」について講演いただきます。先行事例をぜひお聞きください。 ☁インフォマティカブース 生成AI対応のデータ管理のクラウドプラットフォーム IDMC(Intelligent Data Management Cloud)をご紹介いたします。ソリューション全体の機能やユースケース、データ統合・品質管理・データカタログ・データガバナンス・マスタデータ管理、最新のCLAIRE GPTなどについてデモを交えて専門スタッフがご紹介します。 ☁スポンサーブース スポンサー各社による、お客様の課題解決となる多彩なソリューションをご覧いただけます。   SCSKのセッションとブースのご紹介 SCSKセッションのご紹介 開始日時：14:40 ～15:10 タイトル： DX成功のカギ！データをスピーディーな意思決定に活かすには 【概要】 データをスピーディーな意思決定に活かせていますか？データの効果的な活用は迅速な意思決定に繋がり、そのためにはデータマネジメントが不可欠です。本セッションでは、データマネジメントの重要性とその課題、そしてそれに対する解決策をご紹介します。 取り上げる主なサービス  Informatica Cloud Data Integration（CDI） Informatica Cloud Data Governance and Catalog（CDGC） ※予告なく変更する場合がございます。 「データ活用を始めたけれど、いまいち成果が出ない」「データマネジメントで何をすべきか分からない」といったお悩みをお持ちの方、ぜひご参加ください。 SCSKブース SCSKのブースでは、 インフォマティカ認定技術者数国内トップクラスであるSCSK がインフォマティカとGoogle Cloud、AWS、Snowflakeなどあらゆるクラウドサービスと組み合わせ、 社内外のデータを迅速な意思決定に繋げるサービス をご紹介します。 デモも実演 予定です！ さらに、 PowerCenterのクラウド移行をご検討の方には、最適なアプローチをご提案 します。 お客様の課題解決をご支援します。ぜひ、お立ち寄りください。 Informatica World Tour 2024を楽しみにお待ちください。 当日はSCSKミニセッションならびにブースへの来場をお待ちしております！