Catoクラウドへの移行を検討されるお客様よりよく聞かれる事の1つに「Cato移行後も、データセンターのDMZにある公開サーバを提供する事ができるか？」というのがあります。答えはYesですがその注意点について記載します。 方法は2つ。Remote Port Forwarding と Local Port Forwarding Catoで内部のサーバを外部に公開するにはPort Forwarding機能を使用します。Port Forwardingという名前からイメージできるかと思いますが、インターネット上に公開するグローバルアドレスとポート番号を内部サーバのプライベートアドレスとポート番号に変換する機能です。これはアプライアンスのFirewall等でもよくある機能で私も利用した経験があります。 Catoの場合はRemote Port Forwarding と Local Port Forwarding の2つの方法がありますので、その違いを構成例を図1に示します。 図1. Remote Port Forwarding と Local Port Forwarding の”イメージ” 2つの大きな違いはCatoを通過するかしないかです。Local Port ForwardingだとCatoを通過しないので、当然Catoのセキュリティチェックは効かず通信ログも記録されません。2つの違いを表1に纏めました。 表1. Remote Port Forwarding と Local Port Forwarding の比較 項目 Remote Port Forwarding Local Port Forwarding グローバルIPアドレス IP Allocationで取得したアドレス ISPから払い出されたSocketのwan1のアドレス セキュリティチェック 可能 不可 通信ログ出力 可能 不可 設定箇所 Network >Remote Port Forwarding Site Configuration > Local Port Configuration 注意点 ・グローバルアドレス個数問題（※1） ・ Port forwardingの通信の優先度（※2） ・中国のPoPは非サポート（※3） ・IPsec Siteでは非サポート ・NAT環境では不可（※4） （※1）IP Allocationで取得したアドレスのうち、例えばOffice365用の固定アドレスを公開サーバ用に使用する事も可能ですが、 アドレスを分けたい場合追加取得が必要になります。4つ以上は有償になります。 （※2） Port forwardingの通信はQoSの優先度で最も低い255が自動的に割り当てられ、且つ変更ができません。 （※3） 中国のPoPに割り当てたIPは設定する事が出来ません。 （※4）上位にルータがあって、Socketのwan1ポートがプライベートアドレスの環境では利用できません。要するにwan1が固定グローバルアドレスの環境でないとLocal Port Forwardingは使えないという事です。尚、PPPの場合はアドレスが変わらなければ出来るかもしれませんが試せてません。 2つの内容を見ると、セキュリティチェック及び通信ログの出力ができる点においてRemote Port forwarding が推奨という事になります。またCatoのナレッジにも「可能な限りRemote Port Forwardingを使う事」という記載があります。 逆にLocal Port Forwardingを使用する例を考えると、公開サーバ設置拠点のトラフィック量が多く、Remote Port forwardingだと優先度が低いせいで公開サーバ宛ての通信が破棄されてしまうケースでしょうか。（上記「表1」の注意点※2です） この場合、Cato契約帯域を増速すればRemote Port Forwardingを選択できる解決策はありますが、勿論コスト増となってしまうので、そこはLocal Port Forwardingのデメリットとのトレードオフになるかと思います。 外部アクセスを許可するリスク 公開サーバを設置するDMZとは、DeMilitarized Zoneの略で「非武装地帯」という意味です。 DMZはインターネットからのアクセスが許可された外部と内部のネットワークの中間にあるセグメントなので、内部ネットワークとの間には当然何らかのセキュリティ対策が施される事が前提とされています。(以前は「DMZの公開サーバが乗っ取られたらそこから社内ネットワークに侵入されるのでFirewallでDMZ→Tru st間はAll Denyにしよう」という話をよく聞いたものでした) したがってCato Socket配下のサーバをインターネットに公開する場合、同じSocket配下にいる社内サーバやクライアントPCとの間にセキュリティを施す必要があります。ではそのセキュリティ対策は何をどこまで行えばよいのでしょうか？ 考えられる事は山ほどありますし完璧な対策を行う事が難しい事はご存じの通りです。また、せっかくCatoを導入する事でこういったところのコストや運用負荷から解放されるはずが、逆戻りとなるのは明らかです。 Catoクラウドはフラットでシンプルなネットワークという志向なので、セグメントの階層化や通信経路が複雑化する設計は避け、例外通信を極力なくす事がより安全で且つ運用負荷を軽減できると思います。 よって社内ネットワークにDMZを残すという考えは捨て「公開サーバはCatoとは別のクラウド（AWSなど）に置く」「公開サーバのセキュリティはAWSサービスを利用する」事とし、万が一公開サーバが攻撃を受けた場合も社内ネットワークには影響がない状態にしておくのが得策かと考えます。 尚、Catoのナレッジには、 本機能を使用する場合は「 外部の送信元アドレスを制限する」ことが強く推奨 されていますが、公開サーバはだいたい不特定多数のアクセスを許可しているので「分かっちゃいるんだけど仕方ないんだよ」という声が聞こえてきそうです。 まとめ Catoクラウドへの移行後も社内ネットワークにある公開サーバを継続利用する事は可能ではありますが、その拠点をCato Socketにした構成でその他サーバやクライアントPCとの境界のセキュリティを考える事が必要となってきます。 尚、2023年前半に「LAN Firewall」機能が追加されていますので、構成によってはこちらを活用できるかもしれません。

Catoクラウドでは、各端末にインストールするクライアントソフトは、利用者にて特に操作を行う必要なく、自動で最新版にアップグレードされます。これにより常に最新の状態が維持され、お客様ネットワークのセキュリティを保つことができます。 しかしながら、端末運用の都合で以下のようなご要望をいただくことがあります。 「運用ポリシー上、ソフトウェアアップデートはすべて端末管理システムから配信したいので、自動アップデートさせたくない」 「最新版で不具合を踏むのが怖いので、テスト端末でテストしてから展開したい」 できます！ Catoクラウドの機能で制御可能です。 以前より機能としては存在しましたが、2023年8月に「 Client Rollout 」として機能強化されていますので、ご紹介します。 Client Rollout とは？ Catoクライアントのアップデート状況を確認したり、OS毎のアップデート方法を設定できる機能です。 Catoクラウドの管理画面(Cato Management Application)の、Access > Client Rollout から確認できます。 Rollout Status の見方 Client Rolloutを開くと、まず「Rollout Status」が表示されます。クライアントの配信情報を確認できるページです。 Windows, macOS, Linux の各クライアントの状況が表示されています。 なお、iOS(iPhone/iPad)に関しては、クライアントのアップグレードはCatoからではなく App Store から行われるため、この画面からは制御できません。 主要な表示項目を説明します。 1) 最新のクライアントバージョン 現在このアカウントに提供されている最新のバージョンです。 Catoクライアントは、最新バージョンのリリース後各アカウントに順次展開されるため、 リリース情報が出た後アカウントに配信されるまで、1～2週間かかる場合があります。 この画面に最新バージョンが反映されると、端末への展開が開始されます。 2) 最新にアップグレード済みのクライアントの割合 直近48時間で 接続のあったクライアントのうち、最新バージョンのクライアントの割合です。 3) 最新バージョンの展開状況 現在の展開状況です。 Available to Pilot Group : パイロットグループ(後述します)にのみ最新版が配信される状態です。 Gradual Rollout : 各端末に順次配信中の状態です。 Available to all Users   : すべての端末に最新版が配信される状態です。 最初のスクリーンショットの例ですと、Windows と mac は全クライアントが最新版を利用できる状態で、Linuxは最新版がパイロットグループにのみ配信されています。 何らかの理由でこの配信を止めたいとき(例として、パイロットグループでアップグレード後の不具合が発生し、他端末に配信したくないとき)は、「Pause Rollout」ボタンを押すことで、以下のように展開を停止することができます。 配信を再開する際は「Resume Rollout」を押します。 Upgrade Policyの設定 「Upgrade Policy」タブは、実際のアップデート動作の設定画面です。 OSごとにアップデートの方法を指定できます。 Policy Catoからのアップグレード配信を行うかどうかを設定できます。 Automatic by Cato : Catoからクライアントのアップグレードを配信します。 Managed by Admin : Catoはアップグレードを一切配信しません。 クライアントを最新バージョンにするには、端末管理システムから配布したり、ユーザがインストーラーを使ってインストールする必要があります。 Managed by Adminを選択すると、次の設定項目である「Mode」は選択できなくなります。また、前述の Rollout Status も以下のように表示されなくなります。 Mode クライアントのアップグレード方法を選択できます。 Silent : Catoクラウドへの接続時にバージョンチェックが行われ、新しいバージョンが配信されている場合には、自動でアップグレードが行われます。アップグレード中、ユーザには以下のような通知画面が表示されます。アップグレードには(端末性能やインターネット接続状況にもよりますが)3～4分かかり、この間Catoへの接続は切断されます。 User Managed : 上記と同様ですが、ユーザにアップグレードするかしないかの選択が表示されます。「GET IT LATER」を選んだ場合にも、12時間以上経過後に同じ選択画面が表示されます。「GET IT NOW」を選んだ場合は、Silentと同様にアップグレードが走ります。 なお、このアップグレード動作には、端末の管理者権限は必要ありません。ユーザ権限でアップグレード可能です。 パイロットグループの設定 「Pilot Group」の画面から、先行して最新版を配信するパイロットグループの設定が可能です。対象とするSDPユーザを指定し設定します。 たとえば情報システム部門のメンバのみを入れておき、アップグレード時の動作検証を行うなどの用途に利用します。 最後に Catoクライアントは、バージョン毎に細かな不具合修正や機能追加がありますので、常に最新バージョンにしていただくことをお勧めしております。 お客様の端末管理ポリシーに合わせ、Client Rollout の各機能をご活用ください。 クライアント含め、Catoクラウドの週次アップデート情報を、当社「よくあるご質問」の「リリースノート」にて公開しておりますので、あわせてご参照ください。 よくあるご質問 | Cato Cloud ケイトクラウド - SCSK Cato SASE Cloud Platform. powered by SCSK cato-scsk.dga.jp

こんにちは。SCSK石原です。 AWSを中心にデータ基盤を作成されている場合、AWS Glueが登場する機会が多いのではないでしょうか。AWS Glueには、ETL機能はもちろん、 システムメタデータ を管理できるAWS Glue Data Catalogがあります。 AWS Glue Data CatalogにはCrawlerという強力な機能があり、自動でスキーマを構成可能です。 また、インフォマティカ（Informatica）では、クラウドデータマネージメントプラットフォームとして「Intelligent Data Management Cloud（IDMC）」があり、その中の一つとして「Cloud Data Governance and Catalog（CDGC）」というデータカタログ機能を含むサービスあります。このサービスは システムメタデータ と ビジネスメタデータ の双方を管理できるものです。 Cloud Data Governance and Data Catalog – 予測データインテリジェンス | Informatica Japan Cloud Data Governance & Data Catalogは、データの探索と理解、信頼性とアクセス性を改善することで、意思決定の向上とアナリティクスの統制を実現します。 www.informatica.com 今回は AWS Glueをより活用するため に、 ETL情報をCDGCで抽出しリネージュを取得、カラムレベルでのデータの流れを把握できる ことを検証します。 全体概要 検証環境の全体概要について、インフラ視点とデータ視点で説明します。 インフラ構成図 インフラ構成は以下の通りです。Amazon EC2にはSecureAgentというランタイム環境をインストールします。EC2からインターネット経由でIDMCに接続します。 VPC外には、データストアとしてAmazon S3、ETL及びデータカタログとしてのAWS Glue、クエリエンジンのAmazon Athenaを利用します。このほかにも、IAMなどのサービスを利用しますが下記図では割愛します。   データ遷移図 コンポーネント間のデータの流れを整理します。AWS GlueにてETLを実行します。ソースシステムとターゲットシステムにはAmazon S3を利用します。 Amazon S3に格納したデータに対してAWS GlueのCrawlerを利用して、AWS Glue Data Catalogにシステムメタデータを登録します。 IDMCからは、Amazon Athena及びAWS Glueの接続コネクタを利用して、スキーマやテーブル情報などのシステムメタデータやカラムレベルのリネージュ情報を取得します。 今回は、Kaggleのチュートリアルで利用するTitanicのデータセットを利用させていただきました。 Titanic - Machine Learning from Disaster | Kaggle Start here! Predict survival on the Titanic and get familiar with ML basics www.kaggle.com   AWS側の準備 AWSの設定を行います。 AWS Glue Data Catalogの設定 Amazon S3にTitanicのデータ（CSVファイル）を格納しましたので、AWS Glue Data Catalogに登録します。 AWS Glue Data Catalogのデータベース作成 AWS Glue Classifiersの設定 AWS Glue Crawlerでテーブルを作成 今回の設定値は以下の通りです。 データベース名 ishihara-db テーブル名 titanic AWS GlueによるETLジョブ作成 後ほどリネージュを確認するために、2つのデータソースを結合してAmazon S3にファイルを出力するETLジョブを作成します。 結合に利用したデータは下記のとおりです。 Survived_id Survived_name 0 dead 1 survival ETLジョブ実行後に、出力されたデータに対してAmazon Athenaでクエリできることを確認しておきます。 正常にクエリができていますので、AWS側の設定は完了です。 もし、Amazon Athenaでクエリに失敗した場合は、「age」列を確認してみてください。クローラー実行後はdouble型で定義されていましたが、欠損値があり異なる型が含まれると判断されて、クエリに失敗する事象が発生しました。一つの手段として、欠損値が許容される型（String型など）に手動でスキーマを変更すると実行できるようになります。 フィールド X で「HIVE_BAD_DATA: フィールド X のフィールド値の解析エラー: 入力文字列: "12312845691"」という Athena のエラーを解決します Amazon Athena でデータをクエリすると、次のいずれかのようなエラーが表示されます： 「HIVE_BAD_DATA: フィールド X のフィールド値の解析エラー: 入力文字列: "12312845691"」 「HIVE_BAD_DATA: 列 '0' の解析エラー: ターゲットスケールはソーススケールより大き... repost.aws   IAMユーザの準備 Amazon Athenaの接続設定をするためには、AWS IAMのユーザが必要になります。下記のドキュメントに従って適切なポリシーを保持したユーザを作成したのち、アクセスキーを発行します。 POST data docs.informatica.com ドキュメントにアクセスするためにはインフォマティカアカウントにログインが必要です。   IDMC側の準備 次にCDGCからAWSの各種サービスへメタデータスキャン設定を行います。 Amazon Athenaへの接続 接続設定 接続設定は以下の通りです。先ほど作成したアクセスキーを利用します。 検証中に下記のエラーが出力されました。こちらはIAM権限不足によるエラーであり、CloudtrailにAccessDenyのエラーが出力されます。今回の場合では、コンソールアクセス用のIAMユーザで発行したアクセスキーを利用しており、MFAを通さない限りほとんどの操作がDenyされるポリシーが付与されていたことが原因でした。 CON_Athenaのテスト接続に失敗しました。[SDK_APP_COM_20000] error [error [java.sql.SQLException: [Simba][AthenaJDBC](100071) An error has been thrown from the AWS Athena client. You are not authorized to perform: athena:StartQueryExecution on the resource. After your AWS administrator or you have updated your permissions, please try again. [Execution ID not available]]] カタログソース設定（Amazon Athena） Amazon Athenaのカタログソースを構成します。下記のマニュアルを参考に進めます。 POST data docs.informatica.com ドキュメントにアクセスするためにはインフォマティカアカウントにログインが必要です。   事前定義されたカタログソースのうち「Amazon Athena」を選択して、設定します。  先ほど定義した「接続」を使用します。テスト接続が成功することを確認して次に進みます。 まずはメタデータの抽出が有効になっていることを確認して、保存します。 カタログソース設定が完了したのち、実行すると以下のジョブ画面を確認することができます。今回はフィルタ設定をしていないため、今回用に作成したAWS Glue Data Catalog以外のテーブルやスキーマも取り込まれています。 カタログソース設定（AWS Glue） AWS Glueのカタログソースを構成します。下記のマニュアルを参考に進めます。 POST data docs.informatica.com ドキュメントにアクセスするためにはインフォマティカアカウントにログインが必要です。 2023年9月現在、AWS Glueのコネクタはプレビュー版です。 カタログソース設定をしたのち、実行した結果は下記のとおりです。 カタログソース設定（Amazon S3） Amazon S3のカタログソースを構成します。下記のマニュアルを参考に進めます。 POST data docs.informatica.com ドキュメントにアクセスするためにはインフォマティカアカウントにログインが必要です。 カタログソース設定をしたのち、実行した結果は下記のとおりです。 接続の割り当て Amazon Athena,AWS Glue,Amazon S3のメタデータ抽出が完了したのち、関連する情報のマッピングを行います。 Amazon Athena（S3__ishihara-techharmony-01-bucket）はAWS Glue Data Catalogを参照しており、実データはAmazon S3に存在するため、Amazon AthenaのカタログソースとAmazon S3のカタログソースをマッピングします。 AWS Glue（S3__ishihara-techharmony-01-bucket）はAWS Glue Data Catalogを参照しており、実データはAmazon S3に存在するため、AWS GlueのカタログソースとAmazon S3のカタログソースをマッピングします。 AWS Glue（ATHENA-H_ATHENA-DB）はAWS Glue Data Catalogを参照しているため、Amazon Athenaのカタログソースとマッピングします。 AWS Glue Data CatalogはAmazon Athenaのカタログソースとして登録されているように見受けられます。 オブジェクトの一致率が100%になっていない箇所があります。Amazon S3のカタログソース設定で、不要なファイルをスキャンしていることが原因です。また、Amazon Athenaの場合は当方で作成していないリソース（AWS Glue Data Catalog）の情報もスキャンされているためです。 結果 AWS GlueをCDGCでスキャンすることで、 カラムレベルでデータの流れを確認することができるようになりました 。データの流れを可視化できることにより、データの透明性を高めることができます。 大規模なデータ基盤となれば、データリネージュが必要になると考えております。この記事が役に立てば幸いです。

Catoクラウドのダッシュボード機能のひとつ、 MITRE ATT&CK ダッシュボード をご存じでしょうか。 お客様ネットワークのセキュリティ対策にぜひご活用ください。 そもそもMITRE ATT&CKとは? MITRE ATT&CKとは、米国の非営利団体であるMITRE(※)が公開している、 サイバー攻撃の戦術や手法に関するフレームワーク です。 ※脆弱性情報の識別番号であるCVEを管理運営している組織です。 2013年に考案された後、4半期に一度以上アップデートされ、現在まで常に最新の脅威情報や防御策などが追加され続けています。 MITRE ATT&CKは、以下のWebサイトにて公開されています。 MITRE ATT&CK® attack.mitre.org 一番上の列(Reconnaissance, Resource Development, Initial Access…)が攻撃の Tactics(戦術) で、表の左から右に向かって進行します。 各戦術を簡単に解説します。 Tactics 意味 概要 Reconnaissance 偵察 攻撃者が攻撃を計画するための情報を収集しようとしている Resource Development リソース開発 攻撃者が攻撃に必要なツールや環境を作成しようとしている Initial Access 初期アクセス 攻撃者が標的へのアクセスを試みている Execution 実行 攻撃者が悪意のあるコードを実行しようとしている Persistence 永続化 攻撃者が不正アクセスし続ける環境を確保しようとしている Privilege Escalation 権限昇格 攻撃者がより高いレベルの権限を取得しようとしている Defense Evasion 防衛回避 攻撃者が検知されないようにしている Credential Access 認証情報アクセス 攻撃者がアカウントやパスワードを盗もうとしている Discovery 探索 攻撃者がアクセス先の環境を調査している Lateral Movement 水平展開 攻撃者が環境内の他の標的へ移動しようとしている Collection 収集 攻撃者がデータを収集しようとしている Command and Control C&C 攻撃者がCommand&Controlサーバとのアクセスを確立しようとしている Exfiltration 持ち出し 攻撃者がデータを持ち出そうとしている Impact 影響 攻撃者がシステムを操作、中断、または破壊しようとしている 各戦術の下にあるのが、 Techniques(技術) です。その戦術を行うために使われる「やり方」です。 たとえば、Reconnaissanceの下にある “Active Scanning” は、対象システムに対するポートスキャンなどを指します。 また、各Tactics(戦術)は TAxxxx、各Techniques(技術)は Txxxx という固有の識別番号が付与されています。 MITRE ATT&CK は、これに沿って各Techniquesへの対策を考えたり、サイバー攻撃の訓練シナリオを計画したり、また実際に不審なアクセスを検知した際に、攻撃の段階や目的を特定して対処を行うために利用されます。 CatoクラウドのMITRE ATT&CK ダッシュボードとは CatoクラウドのMITRE ATT&CK ダッシュボードは、お客様のCatoクラウド内の通信について、IPSの検知状況をMITRE ATT&CKのフレームワークに沿って整理したものです。 このダッシュボードを見ることで、指定の期間内に自社ネットワークに対してどのような攻撃や攻撃予兆があったのかを知ることができます。 MITRE ATT&CK ダッシュボードは、Cato Management Application の Monitoring > MITRE ATT&CK から表示できます。他のダッシュボード等と同様に、表示期間の指定が可能です。 上記の例ですと、Tactics「Collection(攻撃者がデータを収集しようとしている)」に該当する通信が、360件検知されています。 その内訳を見ますと、Techniques「Data from Local System(ローカルシステムからのデータ収集)」に該当する通信が、4つの端末から、360件発生している、となっています。 なお、TacticsのTAxxxx や TechniquesのTxxxx の識別番号は、MITRE ATT&CKで定義されているものと同一です。 「Data from Local System」の箇所をクリックすることで、さらに詳細が表示されます。当該Tactics・Techniqueの詳細や、発生件数のグラフ、通信元IPアドレス、OS等です。 また、SourcesのIPアドレスをクリックすると、その端末について検知したIPSのEventsが表示されます。ダッシュボードからすぐログ調査に移ることができるため便利です。 この例では、Eventsを見ると、Catoクラウドの拠点内の端末から海外の不審なドメインのWebサイトに対しPOST通信が行われ、IPSでBlockされていました。この動作が、Tactics「Collection(攻撃者がデータを収集しようとしている)」の、Techniques「Data from Local System(ローカルシステムからのデータ収集)」と判定されています。納得です。 上記は検証環境のものですが、実際にお客様環境でMITRE ATT&CK ダッシュボードを確認すると、意外に検知件数が多く、驚かれたかもしれません。 このダッシュボードはCatoクラウドのIPS機能での検知を表したものですが、IPSでBlockした通信だけでなく、Monitorしただけの通信も含まれているため、攻撃でない通信を過検知し表示している場合があります。 ダッシュボードの右上にて、「Monitor & Block」「Block」「Monitor」と検知種別を絞ることができますので、「Block」のみにしてみると、実際にCatoクラウドが通信をBlockした、危険度の高い内容のみを確認することができます。 検知にどう対処したらよいか MITRE ATT&CK ダッシュボードで検知があった際は、通常のIPSでのインシデント検知と同様に、お客様のセキュリティポリシーに沿ってご対処ください。 一般的には、以下のような対応が多いかと存じます。 対象の通信元の IPS等セキュリティログを確認し、問題のある通信かどうかを調査する。 意図しない通信である、不審な通信である場合には、その通信元端末をネットワークから遮断し、ウィルスチェック等の調査を行う。 不審な通信であった場合には、MITRE ATT&CK に沿って、どの Tactics のどの Techniques が行われたのかを確認し、影響を調査する。 MITRE ATT&CK をもとに、再発を防止する対処を検討する。 また、このダッシュボードを活用し、以下のような運用を継続して行うことで、攻撃に繋がる可能性のある通信を防ぎ、ご利用環境のセキュリティを強化していくことが可能です。 MITRE ATT&CK ダッシュボードにて、Monitor として検知されている内容を確認する。 Tactics と Techniques ごとに、Eventsログで通信の詳細を確認し、不審な通信が無いかを調査する。 不審な通信があった場合は、Internet Firewall などで Block するルールを追加する。 最後に MITRE ATT&CK ダッシュボードの詳細については、下記の Catoクラウドナレッジベースも合わせてご参照ください。 Working with the MITRE ATT&CK® Dashboard 日本国内では知名度が低めの MITRE ATT&CK ですが、米国企業においてはすでにこのフレームワークを用いたセキュリティ対策が広く取り入れられています。 お客様のネットワークをよりセキュアに運用するため、Catoクラウドの MITRE ATT&CK ダッシュボードをぜひご活用ください。

どうも、Catoクラウドを担当している佐々木です。 今回は、CatoクラウドのQoSについて設定方法と仕様を紹介します。 ※画⾯は2023年9⽉時点のものです。機能アップデート等で変わる場合がありますので、あらかじめご了承ください。 CatoクラウドのQoSについて CatoクラウドにもQoS機能があります。一般的なネットワーク機器と同じように帯域制御も優先制御も実施可能です。 Catoクラウドユーザーでは、以下の用途でよくQoSを利用されています。 Catoクラウドの契約帯域を圧迫しないようWindows Update通信で利用できる帯域を限定する 音声（IP電話）やWEB会議の通信を優先する   QoSはSocket、Catoクラウド内の両方で動作しております。 Socket配下のユーザーからの通信の場合、原則SocketでQoSに関する制御を実施します。   SDPユーザーの場合、Catoクラウド内で設定したQoSに基づいた制御は行われますが、 Catoクラウド内だけで動作するため実質意味がありません。 ※SDPユーザーではQoSはかからない、と思っていただいてOKです。   また、CatoクラウドのQoSは、 デフォルト設定だと契約帯域の1.2倍以上の通信が発生した時のみ優先制御と帯域制御を行います。 つまり 「Cato経由のトラフィックに余裕がある時は、特に通信制限されない」 ということです。   ※設定で常時動作させることも可能です。 ※細かい仕様は、複雑な話になりますので、文末の 「CatoクラウドQoSの仕様」 に記載します。   CatoクラウドのQoS設定方法 設定方法の前に、CatoクラウドのQoSの重要概念であるプライオリティについて説明します。   プライオリティについて CatoクラウドのQoSでは、各ネットワーク・フローに「P値（プライオリティ）」という パラメーターをタグ付けします。 「P値」を利用してQoSの優先制御を実施しており、「P値」が低いほど優先度高く処理されます。 「P値」は2～255の値を設定でできます。 ※0 と 1 は Cato 管理トラフィック用に予約されています。   プライオリティのデフォルト値 「P値」はデフォルトで以下の通り設定されています。 要件に応じて変更可能ですが、 デフォルト値はそのまま利用し、必要に応じてルールを追加しているユーザーが多いです。 P10：WANまたはインターネット経由の音声トラフィック P20：WANまたはインターネット経由のリモート デスクトップ (RDP) P30：WANまたはインターネット経由のファイル共有 (SMB) P40：上記以外のWANトラフィック  P255：デフォルト – 上記外のインターネットトラフィック   設定方法 QoSを利用するためには、以下2つを設定する必要があります。 Bandwidth Management ：P値やP値毎に利用可能な帯域幅を割り当てるための設定です。 Network Rules ：上記で設定したP値をどのようなトラフィックに割り当てるかの設定です。   Bandwidth Managementの設定方法 Bandwidth Managementは、アカウント全体に共通のルールを設定する方法とサイト単位で設定する方法があります。   ▼アカウント全体に共通のルールを設定する方法 CMAにログインし、 「Network」 ＞ 「Bandwidth Management」 を選択します。 新しいプライオリティルールを追加する場合は、右端の 「New」 をクリックすると、設定ウィンドウが表示されます。 ※既存のルールを設定する場合は、該当のルールをクリックください。     Priority ：任意のP 値を入力（2～254まで）   各プライオリティで利用可能な帯域幅について「制限するか」「制限しないか」を設定します。 プルダウンから以下が選択できます。 No limit ：帯域幅を制限しません。つまり、混雑時に該当プライオリティの通信帯域幅を無制限に確保するということです。 Always limit ：常に帯域幅を制限します。 QoSを常時稼働させる場合、この設定にする必要があります。 Limit only when line is congested ：混雑時のみ帯域幅を制限します。   混雑時＝Cato契約帯域の1.2倍のトラフィックが発生した時になります 優先度の高いルールを「No limit」で設定すると、混雑時に下位のルールで帯域が確保されなくなります   アップロード/ダウンロード時にそれぞれ確保する帯域幅を設定します。 帯域幅は、Catoへの接続ライセンスに対する割合（％）か、スループット（Mbps）で設定できます。   この項目は帯域幅制限の有無を「Always limit」「Limit only when line is congested」にした時だけ設定可能です アカウント全体に設定する場合、％で設定することを推奨します（サイトによって契約帯域が異なるため）   ▼サイト単位で設定する方法 サイト単位で設定する場合、アカウント全体に設定したポリシーを上書きする（Override）といった動作になります。 そのため、アカウント全体の設定ポリシーにない新規ルールを追加すること、もしくは削除することはできません。   拠点単位で適用ルールを変えたい場合は 「Network Rules」 で制御可能です（詳細はNetwork Rule設定方法に記載）   CMAにログインし、 「Network」 ＞ 「Sites」 から設定したいサイトを選択します。 「Site Configuration」 ＞ 「Bandwidth Management」 を選択します。 あとは、設定を上書きしたいポリシーを選択し、 「Override」 をEnableにしてから設定を変更ください。   Bandwidth Managementの設定イメージ 上記設定の場合、以下のように動作します（Catoの契約帯域を100Mbpsとして考えます）。   P10 ：常時、契約帯域幅の50％（＝50Mbps）を確保します。 50Mbps以上の通信が発生した場合、パケットは破棄されます。 ※すべてのCatoトラフィックが契約帯域以下でも、P10として50Mbps以上の通信が発生するとパケットは破棄されます。   P20/P30 ：混雑時のみ契約帯域幅の15％（15Mbps）を確保します。 混雑時に15Mbps以上の通信が発生した場合、パケットは破棄されます。 ※すべてのCato経トラフィックが契約帯域以下の場合、15Mbps以上の通信が発生してもパケットは破棄されません。   P40 ：常時、利用可能な帯域を確保しません。 混雑時は、P10～30で利用していない帯域分の通信が可能です。   Network Rulesの設定方法 Bandwidth Managementで作成したプライオリティをどのようなトラフィックに定義するのか設定します。   CMAにログインし、 「Network」 ＞ 「Network Rules」 から右端の 「New」 をクリックします。 ※既存のルールに適用する場合は、該当のルールを選択ください。   「Source」や「App/Category」などプライオリティを適用したい通信要件を設定いただいたうえで、 「Configuration」 の 「Bandwidth Management」 で任意のプライオリティを定義ください。   Network Rulesの設定イメージ 送信元IP 192.168.1.0/24のVoip通信はプライオリティをP10にする、という設定になります。 「Source」をサイトで設定すれば、特定のサイトの特定の通信のみプライオリティを定義することも可能です。   QoSに関する設定は以上です。   QoSの確認方法 「Priority Analyzer」 でQoSの動作状況を確認できます。   まず、CMAにログインし、 「Network」 ＞ 「Sites」 から設定したいサイトを選択します。 「Site Monitoring」 ＞ 「Priority Analyzer」 を選択すると、以下のようにステータスが表示されます。   各プライオリティの「＋」マークをクリックすると以下のように詳細な情報を確認できます。   なお、以下のように「Usage & Health」のバーが黄色、もしくは赤色の時は注意が必要です。 黄色 ：通信状況に問題が発生していることを示しています（輻輳などが原因でパケット送信に遅延が出ているなど） 赤色 ：帯域がひっ迫し、パケットを破棄している状態 黄色や、赤色が多くみられる場合は、QoS設定の見直しをご検討ください。   Windows Update通信を制限する設定 毎月のWindows UpdateがCatoの帯域を使い切ってしまって困っている、、、 というお問い合わせをよくいただきます。 CatoのQoSで、Windows Updateに関する通信を制限する設定サンプルを共有します。 ※実環境での設定は、お客様通信要件や「Priority Analyzer」などで状況確認したうえで、ご検討ください。   設定イメージ ▼Bandwidth Management ▼Network Rules   Bandwidth ManagementでP254の通信帯域は常に10％に制限する、というプライオリティを定義しました。 そのうえで、Windows Updateの通信がP254となるようNetwork Ruleを設定しています。   この場合、Windows Updateに関する通信は常時帯域の10％までになるので、 業務中にWindows Updateの通信が原因で輻輳が発生するという問題は少なくなると思います。   この設定でも輻輳が発生する場合は、Windows Update関係なく、業務トラフィックが想定以上に発生していることになりますので、 Catoの利用帯域そのものを見直したほうがよいかもしれないですね。   CatoクラウドのQoS仕様 CatoクラウドのQoSでは、 契約帯域の1.2倍 以上の通信が発生した時のみ優先制御と帯域制御を行います。   詳しく説明します。 まず、CatoクラウドではLeaky Bucketアルゴリズム ※1 を利用して、帯域幅とバースト性の限界を測定しています。 ※1：Leaky Bucketとは・・・ シェーピングなどで利用するアルゴリズムのことです。 底に穴の開いたバケツに水を注ぐと常に一定量漏れ出すという概念のアルゴリズムで、 ネットワークに置き換えると、バケツの底の穴からパケットが一定の速度で流れ出すモデルになります。   つまり、Catoクラウドでは、バケツが満杯になるかを常に監視しています。 このバケツは容量が決まっており、Catoの契約帯域x1.2倍になります。 ※例えば、Catoの契約帯域が100Mbpsの場合、120Mbpsがバケツの容量です。   通常のフロー バケツが満杯にならない限り、QoSのプライオリティに関わらず、パケットは届いた順に送信されます。 バケツが満杯になると、パケットはキューに格納され、キューの優先度（P値）に従い順番に送付されます。 キューが満杯になると、パケットは破棄されます。 キューのサイズは「Bandwidth Management」で定義した帯域幅になります。 帯域幅を定義していない場合、「契約帯域幅 – 優先度の高い他のキューの合計」がキューのサイズになります。       例外 ただし、上記には例外があります。 「Bandwidth Management」で 「Always limit」 を設定した場合、バケツが満杯にならなくてもキューに格納され、 キューが満杯になるとパケットが破棄されてしまいます。   まとめ QoSは難しく考えられがちですが、設定はシンプルです。 帯域を有効活用するためには必須な機能になりますので、お困りの方はぜひ導入をご検討ください。   「QoS」について弊社の 「Catoに関するFAQサイト」 にも多数情報ございますのでご参考にください。   よくあるご質問 | Cato Cloud ケイトクラウド - SCSK Cato SASE Cloud Platform. powered by SCSK cato-scsk.dga.jp   最後に、SCSKではPoCから導入、運用まで幅広くCatoに関する支援を行っております。 本番構成への移行を見据えたPoC構成や、PoCでつまづきやすい点のサポートなど、豊富な導入実績を基にご支援いたします。 ぜひお声がけください！

  Catoクラウドの「 CASB 」について解説します。 CASBは、Catoクラウドでは標準搭載機能ではなくセキュリティオプションとなります。サービス体系については以下を参照ください。 Catoクラウドのサービス体系について Catoクラウドのサービス料金を含むサービス体系、オプションやマネージドサービスについて紹介します。 blog.usize-tech.com 2023.08.17   CASBとは CASBとは、 Cloud Access Security Broker の略称で、SaaSやクラウド・アプリケーションと利用者（エンドユーザー）の間に位置するのがCASBとなります。クラウドベースのアプリケーションとのやりとりをすべてモニタリング（監視）し、企業のセキュリティ・ポリシーを適用します。 いまや、すべての企業において、SaaSやクラウドアプリケーションの採用が急激に拡大する中、CASBは企業のセキュリティ・ポリシーに必要不可欠な機能となっています。 CASBが無い場合は、IT部門やセキュリティ部門の許可なく、従業員によって利用されているアプリケーション、 シャドーIT が数多く存在します。シャドーITとは、企業のIT部門やセキュリティ部門が把握または認知していない、従業員によるIT利用を意味します。 IT部門やセキュリティ部門が許可していない（場合によっては認知ができていない）アプリケーションは、当然のことながらアクセス制御は行えず、脅威やリスクから適切な保護を行うことができません。また、企業の機密情報や知的財産のやり取りが含まれている可能性もあります。さらに、未認可（未承認）のアプリケーションには、脆弱性があり、サイバー攻撃の標的になる可能性や、情報漏えいのリスクも考えられます。 このような脅威やリスクに対処するためのソリューションがCASBとなります。 CASBは、このようなシャドーITの可視化から、未承認（未認可）のアプリケーションだけではなく、承認済（認可済）のアプリケーションについてのアクセスもより詳細に制御し、許可されたユーザのみが、許可された認証情報を用いてアクセスを行えるようにするものです。 CASBは、以下の4つの基本機能があります。 可視化（Visibility） アセスメント（Assessment） 強制（Enforcement） 防御（Protection） それでは、それぞれの機能について解説を行います。   可視化（Visibility） シャドーITに対処する最初のステップとなり、SaaSやクラウドアプリケーションの使用状況を可視化します。 Catoクラウドでの可視化は、SaaSやクラウドアプリケーションの使用状況を表示する “ Cloud Appsダッシュボード “を提供します。 Cato Management Application（以下、CMA） [Monitoring]>[Cloud Apps] 特に何も新たな設定を行う必要はなく、CASBのセキュリティオプション契約を行うことで、ダッシュボードが表示され、すぐに利用することができます。 ・発見されたアプリケーション、リスクの高いアプリケーション ・利用ユーザ数、利用トラフィック量 ・Topアプリケーション（認可/未認可別、リスクスコア別）、Topカテゴリ ・アプリケーションリスク比率、認可/未認可アプリケーション比率・ユーザ比率 ・地理ロケーション情報（アプリケーションの本社所在地） アセスメント（Assessment） 次のステップは、特定アプリケーションを分析し、脅威やリスクを適切にアセスメント（評価・分析）することです。 CatoクラウドのCASBアセスメントでは、独自の Application Credibility Engine（ACE） を利用しています。 ACEは、データ収集を自動化し、各アプリケーションのプロファイルを迅速・正確に評価し、リスクスコアを提供します。 リスクスコアは、全10段階で 1-3：Low 、 4-6：Medium 、 7-10：High となります。 CatoクラウドのACEは、 クラウドアプリケーションカタログ（App Catalog） で確認することができます。また、アプリケーション毎に、Sanction（認可）を行うことも可能です。 CMA [Assets]>[App Catalog] ・評価されたアプリケーション：タイプ別、カテゴリ別、リスクスコア別、ステータス別、本社所在地別 ・アプリケーション毎情報：コンプライアンス（ISO、PCI-DSS、SOC等）、セキュリティ（SSO、MFA等） CatoクラウドのCASBは、2022年2月にリリースされています。ACEに登録されているクラウドアプリケーションカタログ（App Catalog）の数が、CASBを選ぶ上での重要なポイントになります。 以下は、直近半年間のApp Catalogの推移状況は以下になります。 リリース以降、昨年度までは日本の登録サイト数が非常に少ない状況でしたが、ACEへの登録が進んでおり、先月（2023年8月）に日本のサイト数が1,000を超過し、企業利用におけるSaaSやクラウド・アプリケーションについては、徐々にカバーできつつあります。 CASBの登録サイト数は、単純に登録数が多いだけで判断することなく、お客様が実際に利用されているSaaSやクラウド・アプリケーションをどの程度カバーしているかが重要になります。特に、最新で利用されているサイトが常に追加・更新されているかがポイントとなりますので、PoC（概念検証）等にて、Catoクラウドであれば、Cloud Appsダッシュボードで分類・未分類の比率を確認されることを推奨します。 また、未登録のサイトがあれば、Cato社へ登録申請を行うことも可能で、申請後、約2～3週間でACEへの登録が可能となっております。   強制（Enforcement） アセスメントによる評価・分析を実施した後は、各アプリケーション毎に必要なアクセスポリシーを自社内で決定し、そのポリシーを適用します。 Catoクラウドでは アプリケーション制御（Application Control） でポリシーを作成して、適用することができます。 CMA [Security]>[Application Control] 特定のアプリケーション/アプリケーションカタログ毎に、アクセス元（拠点やユーザなど）やデバイスポスチャなどを利用して、アクションを設定することが可能です。 例えば、Dropbox（Gmail）のダウンロードは許可するが、アップロードは許可しない。M365は、企業テナントIDでのみログイン可能とする（個人IDでのログインは許可しない）などです。 多くのお客様では、CASBで、いきなりアプリケーションを制限（Block）するのではなく、まず最初はモニタリング（MonitorおよびEvents）を行い、ユーザの利用状況を確認した上で、社内通知を行い、制限される場合が事例が多いです。 ここでは紹介しませんが、DLPのセキュリティオプションも同じアプリケーション制御（Application Control）にてポリシー設定を行います。   防御（Protection） 最後に、企業のセキュリティを危険にさらす可能性のある脅威やリスクからの防御についてです。 Catoクラウドでは、CASBだけではなく、統合された以下の各種セキュリティ機能を利用して、すべてのSaaSやクラウドアプリケーションを包括的に防御を行います。 次世代型ファイアウォール（NGFW） セキュア Web ゲートウェイ（SWG） 次世代型アンチマルウェア（NGAM） 不正侵入検知防御（IPS） 情報漏えい対策（DLP） リモートブラウザ分離（RBI） SaaS Security API 上記のセキュリティ機能・ツールを組み合わせることで、さまざまな脅威から包括的に保護することが可能となります。   まとめ 今回は、Catoクラウドのセキュリティオプション CASB および4つの基本機能である「可視化（Visibility）」「アセスメント（Assessment）」「強制（Enforcement）」「防御（Protection）」について解説を行いました。 SCSKでは、2021年からSASEの主要ソリューションを一同に紹介を行うオンラインセミナー「SCSK SASE Solution Summit（通称 S4）」を定期的に開催しております。次回は2023年10月に開催を予定しております（2023年9月時点） Catoクラウドは、2019年より取り扱いを開始し、すでに多くのお客様の導入/運用をご支援させていただいております。 Catoクラウドの知名度向上に向けて、お客様導入事例の制作や、以下のFAQサイト運営を行っておりますが、この技術ブログ（TechHarmony）で、さらに皆様のお役に立て、Catoクラウドの知名度UPに少しでも貢献できればと考えております。 よくあるご質問 | Cato Cloud ケイトクラウド - SCSK Cato SASE Cloud Platform. powered by SCSK cato-scsk.dga.jp

こんにちは、広野です。 Amazon DynamoDB は大量データからのキーバリューマッチングは超高速で素晴らしいのですが、クエリにかなりの制約があるので扱いが非常に難しいです。 実はセカンダリインデックスを使ったデータ削除もクエリ一発でできないので、スクリプトを組む必要があります。 今回はそんなスクリプトの紹介をしたいと思います。 やりたいこと 以下のサンプル DynamoDB テーブルがあるとします。 通常、category, user, id, checked の 4つの情報を元に検索をしています。※今回の説明で直接的に必要ない他の属性は割愛 categoryuser パーティションキー checkedid ソートキー id 属性(グローバルセカンダリインデックスのパーティションキー) AAA#user1 checked#001 001 AAA#user1 unchecked#002 002 AAA#user2 unchecked#001 001 AAA#user2 checked#002 002 AAA#user3 checked#005 005 ここで、以下のように id が 002 のデータだけを 削除 したいとします。 categoryuser パーティションキー checkedid ソートキー id 属性(グローバルセカンダリインデックスのパーティションキー) AAA#user1 unchecked#002 002 AAA#user2 checked#002 002 パーティションキーに格納されている category や user は大量にパターンがあるため、パーティションキー、ソートキーによる検索は難しい状況です。そのため、id をパーティションキーにしたグローバルセカンダリインデックスを作成し、該当のデータを削除したいと思います。 ところが、仕様上、 セカンダリインデックスで条件を指定したデータを 1本のクエリで削除することができません。 削除するには、一旦削除対象のデータを取得し、メインのパーティションキー、ソートキーを条件にしてベタに削除処理をループさせることになります。 上の例では、以下 2 つの条件で削除クエリをかけます。 categoryuser が AAA#user1 で、checkedid が unchecked#002 であるもの categoryuser が AAA#user2 で、checkedid が checked#002 であるもの さらに、追加要件として削除したい対象の id が複数件(大量)にあったとしましょう。上の例では id は 1件でしたが。 それをコードで一気に処理するには、以下のアルゴリズムが例なります。 削除対象の id をファイルにリストアップさせ、スクリプトに読み込ませる リストアップされた id 分、削除処理をループさせる 1つの id から取得したデータに含まれている categoryuser, checkedid のリストに対して、データを削除する（1件1件なのでループ) 言葉で書いてもわかりにくいので、以降はコードを見て頂いた方が早いと思います。 つくったもの 以下の Python スクリプトです。以下、パラメータは適宜修正してください。 TableName は DynamoDB テーブル名 FileName は 読み込みたいファイル名 DynamoDB に対してアクセスできること、Python、boto3 がインストールされていることが実行環境として必要です。必要に応じて DynamoDB のリージョン名は変更します。 import json import boto3 import decimal from boto3.dynamodb.conditions import Key dynamodb = boto3.resource("dynamodb", region_name="ap-northeast-1") table = dynamodb.Table(" TableName" ) # JSONファイルを読み込む with open(" FileName ") as f: data = json.load(f, parse_float = decimal.Decimal) # JSONデータの各行から指定した id のデータを取得する for row in data: id_value = row.get("id", None) if id_value: print(f"Searching for items with id: {id_value}") output = table.query(IndexName="id-index", KeyConditionExpression=Key("id").eq(id_value)) # 該当する項目があれば削除する for item in output.get("Items", []): print(f"Found item: {item}") # categoryuser がパーティションキー、checkedid がソートキー res = table.delete_item( Key = { "categoryuser": item["categoryuser"], "checkedid": item["checkedid"] } ) print(f"Deleted item: {item}") ※エラー処理は省略しています。 削除対象とする id は JSON データで以下のフォーマットでファイルとして用意します。実際に使ったときには他のデータも入っていたため JSON にしましたが、id だけなら単純な配列の方が適切だと思います。 [ {"id":"002"}, {"id":"005"}, {"id":"006"} ] これで、 削除したい id をファイルにリストアップすれば、DynamoDB に対してセカンダリインデックスベースで削除をかけられるようになりました。 まとめ いかがでしたでしょうか？ 本件、急ぎで必要になったため同僚や ChatGPT の助けも借りて即席でつくったものなんです。一応動いていますので、参考になるかと思います。 本記事が皆様のお役に立てれば幸いです。

どうも、最近AIという言葉に食傷気味な寺内です。 Github Copilot が発表されてからそろそろ一年となりました。コーディング支援AIが開発の助けになるのは確かですが、プログラマが不要になるなんてことはもちろんありません。 AWSを使っているのであれば、コーディング支援サービスである Amazon CodeWhisperer も使っていきたいところです。 Amazon CodeWhisperer については、GA前の時点で以下の記事でご紹介しております。 コーディング支援AI AWS CodeWhispererを使ってみた コーディング(プログラミング)を支援するAIサービス AWS CodeWhisperer が発表され、プレビューになっています。それを試してみましたので、使い勝手を共有いたします。 blog.usize-tech.com 2022.10.21 Amazon CodeWhisperer を使うときの利用者IDパターン さて、このAmazon CodeWhisperer は、一般GAされたとはいえ、使い始めるためのID登録がわりと面倒です。使うための条件を見てみましょう。 Getting started - CodeWhisperer Getting started with CodeWhisperer docs.aws.amazon.com 上記のGetting Startedによると、以下の3つの使い方があります。 1. CodeWhisperer for professional developers VS Code とJetBrains の中でAmazon CodeWhisperer を組織的に使うには、この使い方となります。この場合、 AWS Organization と IAM Identity Center を使いID管理をする必要があります。 2. CodeWhisperer for individual developers 個人開発でVS Code とJetBrains の中でAmazon CodeWhisperer を使うには、この使い方となります。この場合、 AWS Builder ID を無料で取得しそのIDを使用します。 3. CodeWhisperer within the IDE AWS のサービス内の以下のIDE を使うときに、Amazon CodeWhisperer を有効化し使うことができます。 Amazon SageMaker Studio JupyterLab AWS Glue Studio AWS Lambda AWS Cloud9 最も簡単にコーディング支援を体験することができますのでオススメです。 ここではAWS Cloud9 でAmazon CodeWhisperer を使ってみましょう。 まずはCloud9 のIDE環境を起動しておきます。 IAMロールでAmazon CodeWhisperer の権限設定 Cloud9 でAmazon CodeWhisperer を使用するには、以下のドキュメントにあるように利用権限ポリシーを付与します。 Setting up CodeWhisperer with AWS Cloud9 - CodeWhisperer For CodeWhisperer to provide recommendations in AWS Cloud9 console, you must enable the correct IAM permissions for either your IAM user or role. You must add t... docs.aws.amazon.com { "Version": "2012-10-17", "Statement": [ { "Sid": "CodeWhispererPermissions", "Effect": "Allow", "Action": ["codewhisperer:GenerateRecommendations"], "Resource": "*" } ] } このポリシーは、IAMユーザに付与してください。 Cloud9 の環境を作成したばかりの状態では、AWS APIを呼び出すときのアクセスキーは、STSを使って生成されたAWS マネージド一時認証情報が使用されます。その認証情報は、Cloud9 内のファイルシステムで ~/.aws/credentials のファイルの中を見ることで確認できます。この認証情報は5分に一度自動で更新されます。 この一時認証情報機能をOFFにし、クレデンシャルファイルに自分で使うアクセスキーを設定します。 一時認証情報機能をOFFにするには、Cloud9 のPreference で以下のように AWS managed temporary credentials をOFFにします。 その上で、以下の2つのファイルに使用するIAMユーザのアクセスキーとシークレットキー、使用リージョンなどを記載してください。 ~/.aws/config ~/.aws/credentials ファイルの書き方は以下のページを参照してください。 設定ファイルと認証情報ファイルの設定 - AWS Command Line Interface 頻繁に利用される構成設定および認証情報を AWS CLI が維持するファイルに保存することができます。 docs.aws.amazon.com 正常に認証情報を記載できたかの確認は、ターミナル上でaws cli が使えるかで確認することができます。 aws s3 ls と入れて、S3バケットリストが得られれば成功です。 もしdefault 以外のprofile を指定してアクセスキーを選択する場合は、以下のようにCloud9 の画面左端下にprofile を選択する箇所がありますので、そこで指定しておいてください。 Amazon CodeWhisperer の有効化 次にCloud9 でAmazon CodeWhisperer を有効化します。 Cloud9 の画面左端下に CodeWhisperer の有効化チェックマークがあります。 初期では以下のように切断されていますので、そこをクリックして有効化してください。 Amazon CodeWhisperer の使い方 いよいよエディタ画面にコードを書いていきます。 Windowsであれば書いている途中で Alt+c 、MacOSなら Option + c  を押すと、CodeWhisperer が反応し続きのコードをサジェスチョンしてくれます。 サジェスチョンを受け入れて、そのコードを採用するなら TAB を押します。 採用しないなら ESC を押します。 出力されたコードはしっかり読み解き、自分が意図したものであるかどうかはしっかり判断しましょう。 料金 AWSサービスのインコンソールでAmazon CodeWhisperer を使用するのは無料です。 おわりに 普段インフラエンジニアをやっていると、あまりコードを書く機会は少ないかもしれません。 いざコード書こうとなったとき、「アレ、Python のif 分で値の一致を判定するのは = はひとつだっけふたつだっけ?」みたいな、ちょっとしたことが思い出せないことがあります。毎日書いていればそんなことないのに、時々しかやらないからこその面倒さです。 Javascript とPython を行ったり来たりしているときもありますね。 そんなときに、こうしてサジェスチョンしてくれるのはとても助かります。

こんにちは、SCSK青木です。 前回に引き続きVertex AI Search and Conversationを触っていこうと思います。 前回はSearchを触り、以下ブログに流れを書いております。 Vertex AI Search and Conversationが一般提供されたので触ってみました【Search編】 SCSK青木です。今回はGoogle CLoud Next'23で一般提供されたVertex AI Search and ConversationのSearchを触ってみました。 blog.usize-tech.com 2023.09.05 本日はConversationの機能を試してみました！ 触ってみる Searchにてコンソールは見つけたので、以下にアクセスします。 Google Cloud Platform Google Cloud Platform lets you build, deploy, and scale applications, websites, and services on the same infrastructure as Google. console.cloud.google.com 「新しいアプリ」を押すと以下のようにSearchやConversationを選ぶ画面になります。 今回はConversationですので、「チャット」を選択します。 何やら、Agentの設定画面になりました。 どうやらチャットを作るためにエージェントの名前等を決めるようですね。 会社名を埋め、「続行」に進みます。 データストアでは今回用にバケットを作っていきたいと思います。 「CREATE NEW DATA STORE」に進みます。 今回は弊社のリクルートサイトよりデータを取得し、構造化されたデータを使用したデータストアを作っていこうと思います。 「Cloud Storage」を選択していきます。 以下でバケットを選べる画面になるので、「参照」を押して進みます。 「＋」を押して、バケットを作成する画面に進みます。 バケット情報は以下のように入力しました。   バケット作成後、ＣＳＶデータをバケットに置きました。 おいたファイルを選択します。 ちなみにＣＳＶの構造は以下のようになっています。 今回はCSVで作成された構造化ファイルのため、「CSV for structured FAQ data」を選択します。 その後「続行」で進みます。 データストア名は以下のように設定して、「作成」に進みます。 作成したデータストアを選択して、「作成」に進みます。 （これでChat Appができるはず！） 作成完了すると以下のような画面になりました。 Searchのようにプレビューを押してみます。 なにやらDialogflow CXのコンソールに飛びました！ ドキュメントにもプレビューはDialogflow CXで確認できると書いてありますね。 https://cloud.google.com/generative-ai-app-builder/docs/agent-usage#create_an_agent Start Pageを開いてみると、「Data stores」という項目が出現しています。 これは以前はなかったものなので、今回のＧＡのタイミングでリリースされたようです。 Dialogflow CXのTest Agentを使用して、会話してみました。 Google Cloud Next’23現地で聞きましたが、このData storesはまだ日本語対応されておらず、 Dialogflow CXの言語設定が「en」になっている必要があるようです。 ちなみにData storesの評価順序ですが、ドキュメントに記載がありました。 https://cloud.google.com/dialogflow/cx/docs/concept/generative-agent#evaluation-order Parameter input while form filling. Intent matches for  routes in scope . Data store handler with FAQ data store content. Data store handler with unstructured data store content. そのため、FAQのような問い合わせに対してData storesで対応し、重要な問い合わせ等はインテントで拾うように設計してあげる必要があるようです。 さいごに 今回はGoogle Cloud Next’23にてリリースされたVertex AI Search and ConversationのConversationを使用してみました。 簡単に指定したリソースに関するチャットを作れるのは便利ですね。 ドキュメントを読むとまだまだ深そうですので引き続き調査してみたいと思います。

Catoクラウドの「 Cato SSE 360 」について、きちんと解説されている記事がなかったので改めて解説をします。 Cato SSE 360 のプレスリリース Cato Networksが、新SSEプラットフォーム「Cato SSE 360」と、その一機能として「Smart DLP」を発表 Cato Networks株式会社のプレスリリース（2022年7月26日 09時30分）Cato Networksが、新SSEプラットフォームと、その一機能としてを発表 prtimes.jp まず、「Cato SSE 360」は、昨年2022年7月にリリースされたのですが、その時のプレスリリース内容が、 Cato Networks、すべてのアプリケーションへのアクセスを保護および最適化する初のSSEプラットフォーム「Cato SSE 360」とその一機能として「Smart DLP」を発表 Cato DLP（Data Loss Prevention）は、レガシーDLPの実装や運用に伴う煩雑性を解消します。 Cato SSE 360は、WAN、クラウド、インターネットトラフィックを完全に可視化、最適化、制御する初のSSEプラットフォームです。 と、そもそも”SASE”や”SSE”自体の認知度が低く、さらに上記内容の発表のため、さっぱり中身が伝わっていませんでした。 そのため、当社のお客様からも多くの問い合わせがありました。 まず、リリースの内容をきちんと説明すると Catoクラウドの 新しいセキュリティオプション「DLP」をリリース Catoクラウドの 新しいライセンス体系「Cato SSE 360」をリリース の2つになります。 この2つを同時にリリースしたので、ややこしくなってしまったと考えています。 1.のDLPについての説明は割愛します。以下の記事をご参照ください。 Catoクラウドのサービス体系について Catoクラウドのサービス料金を含むサービス体系、オプションやマネージドサービスについて紹介します。 blog.usize-tech.com 2023.08.17 新しいセキュリティオプションのリリースで、CASBは2023年2月にリリースされ、DLPが7月にリリースされました。 それでは、2.の「Cato SSE 360」について説明します。 Cato SSE 360 について まず、Catoクラウド（Cato Cloud/Cato SASE Cloud）は、当たり前ですが、 SASE（Secure Access Service Edge） です。 Cato Networks社のCatoクラウドは、ガートナーが2019年にSASEを定義する以前（4年前）から、SASEのアーキテクトでサービスを開始していたため、世界初のSASEプラットフォームと言われています。 SSE（Secure Service Edge） については、Catoでは以下のように定義しており、あくまでも SSEは、SASEのサブセット（一部分）で「Cloud SWG」「ZTNA/VPN」「CASB/DLP」のみの機能に限定されたもの としています。 ※ちなみに、ガートナーのSSE定義は「SWG」「CASB」「ZTNA」の3機能で、「DLP」やその他の機能（FWaaS等）は含みません。 それでは、名前が”SSE”ではない”SSE 360″について、Catoの定義は、 Cato SSE 360≠SSE →SSE 360は、そもそもSSEとは異なる。明確にSSEではないと言っています。 従来のSSEでは対処できないことをカバー →つまり「SWG」「ZTNA/VPN」「CASB/DLP」以外の機能も提供する（つまり、SSE < SSE 360） Cato SSE 360によりすべてのトラフィック、ユーザー、ロケーション、クラウド、アプリケーションの完全な可視化と制御 →ZTNA/VPN（モバイルユーザ）だけでなく、拠点接続もカバーする（つまり、SASEです） Catoクラウド（SASE）と「Cato SSE 360」は何が違うのか？になりますが、 違いは「Socket/vSocketを使わない」ということだけ です。 「Cato SSE 360」は、AWS、Azureなどのクラウドを含む拠点接続において、SocketおよびvSocketを利用しない場合にのみ適用されるより安価な価格体系のことを意味しています。 Socket/vSocketを利用しないということは、ルータやファイアウォール（UTM）でのIPsec接続を行うと言う事になります。 複数拠点の内、1拠点だけ「Cato SSE 360」を適用することも可能です。 ※Catoクラウドの最小構成は、1 拠点（Site）ライセンス、10 SDPユーザとなります。 Catoクラウドは「 SASEライセンス 」となり、Cato SSE 360では「 SSEライセンス 」となります。 もちろん、SSEライセンスでは、Socket/vSocketで拠点（Site）を構成することはできません。 サービス契約（利用）中に、拠点がIPsecからSocket/vSocketを利用することも可能ですが、その際にはサービス契約が「Cato SSE 360」の適用除外となり、その時点から通常のCatoクラウド（SASE）の価格体系が適用されることになります。 結局「Cato SSE 360」って何なのか？になりますが、繰り返しになりますが” 「Cato SSE 360」は、SSEではなく、SocketおよびvSocketを一切利用しない場合にのみ適用されるCatoクラウドのライセンス体系 “のことです。 プレスリリースが、セキュリティオプションのDLPを同時にリリースしたため、ややこしくなりましたが「Cato SSE 360」は単純に条件付きの安価なメニューとなります。 実際にどれくらい価格が違うのかについては、契約帯域により割引率が大きく異なります。定価ベースで、3～4割安価にある帯域がありますが、殆ど価格が変わらない帯域もあります。狭帯域（低速の帯域）の場合にメリットはありますが、広帯域では殆ど価格は変わりません。 ちなみに、Catoクラウドの”定価”については、Cato Networks社の公式サイトでは価格を公開しておらず（つまり、”参考小売価格”が存在しません）、メーカの”希望小売価格”となります。（”オープン価格”ではありません） 以前の記事に記載していますが、Catoクラウドの最大のメリットの１つが、Socket/vSocketにあると考えていますので、IPsec接続は、既存ルータやファイアウォールの流用であれば良いですが、新たに拠点エッジを手配する場合は、コスト面で「Cato SSE 360」を選ばれるのではなく、本来のCatoクラウド、つまりSASEライセンスを選択されることを推奨します。 Socket/vSocketとIPsecの比較 Socket/vSocket IPsec Socketには、最適化されたPoP選択機能が実装されており、ネットワーク遅延を最小限に抑えることができる最適なPoPに自動で接続することができます。 Socketは、現在のPoPで接続性問題が発生した場合、別のPoPに自動的に再接続を行います。 Socketには、QoSサービスが含まれます。 CatoクラウドからのSocketの管理機能とリモート管理機能が含まれます。 Bypass、Local Port Forwarding、LAN Firewall機能が利用可能。 ラスト・マイル・モニタリングとトラブルシューティングツールが利用可能。 IPSec接続は、特定のPoPに静的に割り当てられます。PoPへの接続性に問題がある場合、接続断が発生する可能性があります。別のPoPへの自動的に再接続する機能がありません。 IPSecプロトコルは、実装ベンダーが異なるため、IPSecの実装が切断される可能性がある（責任分界点が異なります） 別途、固定IP（IP Allocation)が必要となる。 インターネット回線のActive/Activeの設定を行うことができない。 Socketの機能（Bypass、Local Port Forwarding、LAN Firewall等）が利用できない。 まとめ 毎度のことですが、SCSKでは、2021年からSASEの主要ソリューションを一同に紹介を行うオンラインセミナー「SCSK SASE Solution Summit（通称 S4）」を定期的に開催しております。 次回は2023年10月に開催を予定しております（2023年9月時点） Catoクラウドについては、お客様導入事例の制作や、FAQサイトの運営を行っております。 よくあるご質問 | Cato Cloud ケイトクラウド - SCSK Cato SASE Cloud Platform. powered by SCSK cato-scsk.dga.jp この技術ブログ（TechHarmony）で、さらに皆様のお役に立て、Catoクラウドの知名度UPに少しでも貢献できればと考えております。

こんにちは、SCSKの青木です。 今回は先日のGoogle Cloud Next’23にて一般提供されたVertex AI Search and Conversationを触ってみました。 サービス概要はこちらをご覧ください。 Vertex AI Search and Conversation is now generally available | Google Cloud Blog Vertex AI Search and Conversation is now generally available. Build and deploy search engines and chatbots quickly and responsibly. cloud.google.com 本サービスはEnterprise Search on Generative AI App Builderとしてプレビューでリリースされておりましたが、今回のGoogle Cloud Next’23にサービス名を改め、一般提供されたようです。 社内ではいろいろ検証が進んでいるようですが、私は半年以上育児休業をしていたため、技術キャッチアップすべく触ってみました まずはSearchだけですがブログに残させていただきます。 触ってみる まず、コンソールから探してみます。 サービス名がVertex AIなので、Vertex AIのコンソールに最初に行ってみます。   むむむ、残念ながらSearchやConversationぽいものが見当たりません。 よく見るとVertex AI の下にGen App Builderが残っているのでこちらをクリックしてみました。   以下のようにAPI有効に関する画面が現れました！ 有効にしますと、しばらくたつと以下のような画面が現れたので 今回は検索のほうをクリックしてみます。 エディションやLLMに関する設定とエンジン名、リージョンを決める必要がありましたので今回は以下の設定値で進めます。 Enterprise edition features: on Advanced LLM features: on エンジン名: aoki-first-engine リージョン: global 続行を押すとデータストアを設定する画面が出てきました！ 今回は比較的サクッと設定できそうなCrawlerを試していきたいと思います 「CREATE NEW DATA STORE」押します。 ソースタイプとして「Public Web Content Crawler」を選択します。 そして対象のWebサイトでは弊社の技術ブログサイト全体を指定してみました。 データストア名を設定して「作成」を押します。 データストアが出来上がると、Appのデータストア選択欄に作成したデータストアが出てきました。こちらを選択します。 これでAppは出来上がったようです！ 最後にその機能を試してみたいと思います。 左のペインから「プレビュー」を選び、検索したい文字列を入力してみました。 今回は手始めに「gcp」と入力してみます。 無事にサイト内検索ができました。 ほかにも以下のようなキーワードではない検索をやってみました。 さいごに 今回はGoogle Cloud Next ’23で発表されたVertex AI Search and ConversationのSearchを触ってみました。 次回はConversationを触ってみたいと思います。

既存ネットワークからCatoクラウドへの移行の際に、お客様からのご要望が多いロンゲストマッチの原則を利用する方法をご紹介します。 Catoはアドレス重複登録ができない Catoで拠点（サイト）登録していくにあたり、ネットワークアドレス/サブネットが重複した拠点を登録する事はできません。全く同じサブネットの拠点を2つ登録できないのは理解できますが、サブネット長が異なっていても登録ができません。図1では、DC拠点のサブネットは「/24」ですが、将来のアドレス拡張を見越してCatoは「/16」で設定しています。その上で拠点Aに、DC拠点のサブネットに内包されるアドレスレンジを登録しようとすると「Site range overlaps with site ‘xxxx’ range」の様なエラーとなって登録する事ができません。という事はCatoでは、ネットワークの世界では一般的なロンゲストマッチの原則を活かした設計ができないという事になります。                                         図1.アドレスレンジの重複設定が不可     ロンゲストマッチが使えない事で生じる問題 ロンゲストマッチが使えない事で生じる問題として、既存ネットワークからCato移行時のケースを図2に示します。 DC拠点をHUBにして拠点Aを既存ネットワークからCatoに切り替えその後も他拠点と通信する場合、DC拠点のNetworksの設定は図2の通り192.168.0.0/16を分割して8つのサブネットを登録する必要があります。要するにロンゲストマッチが使えないので拠点Aのアドレス（192.168.10.0/24）を除いたサブネットを設定する必要があるのです。(ここではStaticルートを前提としています）                                        図2. サブネットが被らない様にルートを設定 拠点Aの切り替え後、次に拠点Bの切り替える際は、今度は拠点Aと拠点Bを除いた設定に変更しなければなりません。100拠点が繋がるネットワークだとしたら毎回毎回サブネットを計算して変更を繰り返す必要があるという事です。 IP Overlappingを有効化にする IP Overlappingを有効化にする事でこの問題を回避する事ができます。IP Overlappingを有効にした後のDC拠点のNetworksの設定は図2の通りRoutedは1行で済み、拠点の切替えの度に設定変更する必要がなくなります。                                        図3. IP Overlappingを有効化した時のルート設定 従来の物理ルータ等で構成したネットワークだと当たり前の事かもしれませんが、Catoの場合は注意が必要です。 IP Overlappingの設定方法 IP Overlappingは、以下の設定箇所でIP Overlappingを有効化します。(以前はCatoに申し込みが必要でした） Administration >System Settings > IP Overlapping（2023年8月現在）                                       図4. IP Overlapping設定箇所 要注意！ ～一度有効化したら戻せない～ IP Overlappingを有効化する上で重要な注意事項が4つあります。 IP Overlappingを有効化するとStatic Range Translation機能が使えなくなります。 Static Range Translationは、拠点のアドレスが重複すると分かっている場合PoPにてサイトのアドレスを丸ごと変換する機能です。 設定箇所：Administration>System Settings>Static Range Translation 一度有効化にすると元には戻せません。”戻す” イコール “テナントの作り直し” です。 Catoの管理アドレスレンジ（10.254.254.0/24）はロンゲストマッチの対象外。 既存ネットワークのアドレスにクラスA（10.xx.xx.xx）を使用している場合、上記図2のDC拠点のNetworksの設定は、10.254.254.0/24を除いた設定にしなければなりません。 SDPユーザー用のPoolアドレスレンジもロンゲストマッチの対象外。 同様にSDPユーザー用のPoolアドレスレンジもロンゲストマッチの対象外です。よって上記の構成例の様にクラスC（192.168.xx.xx）を使用しているのであれば、SDPユーザーのPoolアドレスはクラスB（172.16.xx.xx）等にした方が良いかもしれません。 特に1と2については影響が大きいので、IP Overlappingを有効化する前に現状のアドレス体系を十分に確認しておく事と、有効化した後は「アドレスが被る拠点が出てきた場合はアドレスを変更して接続する」というポリシーを定めておく必要があります。 最後に SCSKは既存ネットワークからCatoクラウドへの移行についても豊富な経験があります。もし今のネットワークからの移行に不安があれば、是非SCSKにご連絡下さい。

先日 （2023年8月9日）当社が独自調査した「 国内企業における SASE に関する実態調査結果 」を公開しました。 https://www.scsk.jp/news/2023/pdf/20230809i.pdf 上記リンクに記載の通りですが、企業のネットワークは、これまでの境界型防御からゼロトラストに向けた大きな変革期を迎えており、「ゼロトラスト」概念のネットワークおよびセキュリティを具現化するために、ネットワークとセキュリティを統合したクラウドサービスである SASEが注目されています。 ※ SASE （Secure Access Service Edge、サッシー、サシー、サーシ）･･･ガートナーが2019年8月発行したレポート「 The Future of Network Security Is in the Cloud（ネットワーク・セキュリティの未来はクラウドにある） 」において提唱した、新たなネットワークセキュリティフレームワーク。 SASE に関する実態調査の背景 SASEに関する説明は、今回は割愛しますが、SCSKでは、2021年よりSASEの主要なソリューションを一同に紹介を行うオンラインセミナー「SCSK SASE Solution Summit(通称 S4)」をこれまで 12 回開催しており、直近の2023年6月の開催では200名以上、これまでは延べ 1,000 名以上の方々にご参加を頂いております。 この S4 セミナーを通じて多くの参加者の皆さまからのアンケートを集めると、SASEに関する世間で類似の調査結果（例. SASE導入着手企業が6割、導入済み企業が4割など）よりも、実際の認知度や導入企業数はもっと低いのではないかという仮説が上がっていました。 SASEについては、2023年度から本格的な普及期に入ることが予測されていることもあり、このたび外部調査企業の協力を得て、国内企業（n=339 社）への実態調査を 2023年6月に実施し、その調査結果（レポート）を無料で公開したものになります。 詳しい調査結果（レポート）については前述のリンクより是非ダウンロードください。 結論から言いますと、当社の仮説が正しく、SASE認知度および導入企業率は大きく異なっていました。 「 SASE についてご存知ですか？ 」という質問に対して、「よく知っている」と答えた企業はわずか 5.9% にとどまっています。「ある程度知っている」と答えた企業も 25.7% にすぎず、「あまり知らない」は 42.5% 、「全く知らない」は 26.0% に上っており、 全体の 7 割近い企業で SASE の認知・理解がされていない ことが分かりました。 次に「 SASEの導入状況について教えてくださ い」という質問に関しては、 「すでに導入済み」はわずか 10.0% で、「現在導入中」が3.5%、「導入計画中」が15%であり、「導入を予定していない」が32.7%、「全くわからない」が38.6%となっています。 しかしながら、「導入済み（10%）」「現在導入中（3.5%）」「導入計画中（15%）」の合計が 28.5% となっており、キャズム理論においては、イノベーター（市場全体の2.5%）、アーリーアダプター（市場全体の13.5%、累計16.0%）から、アーリーマジョリティ（市場全体の34%、累計50%）への SASE 採用がすでに開始、あるいは計画されおり、 キャズムを超え、市場の普及が進んでいる ことが分かりました。 つまり、2023年、または2024年が、本格的な SASE 普及の年になるのは間違いないことが分かりました。   Cato クラウドの認知度について 一方で、Cato Networks社 の Catoクラウド（Cato Cloud/Cato SASE Cloud）の認知度についてです。 実は、先にご紹介した調査結果（レポート）には掲載をしていませんが、Catoクラウド個別の認知度調査結果があります。 「 Catoクラウドをご存知ですか？ 」という質問に関しては、「よく知っている」については、わずか 1.8% で、「ある程度知っている」についても9.7%、「あまり知らない」が23.9%、「全く知らない」が64.6%で、Catoクラウドについてご存知ない方が、なんと88.5%という結果になりました。 つまり、SASEの普及期に関わらず、 9割の方がCatoクラウドを知らない という結果になったので、Catoクラウドの認知度向上のために、この度、技術ブログ（TechHarmony）を新たに開始することにしました。   まとめ 前述しましたが、SCSKでは、2021年からSASEの主要ソリューションを一同に紹介を行うオンラインセミナー「SCSK SASE Solution Summit（通称 S4）」を定期的に開催しており、次回は2023年10月に開催する予定です（2023年8月時点） それ以外にも、Catoクラウドのお客様導入事例の制作や、以下のCatoクラウドのFAQサイトの運営を行っております。 よくあるご質問 | Cato Cloud ケイトクラウド - SCSK Cato SASE Cloud Platform. powered by SCSK cato-scsk.dga.jp この技術ブログ（TechHarmony）で、さらに皆様のお役に立て、Catoクラウドの知名度UPに少しでも貢献できればと考えております。

はじめに Catoクラウドの拠点構成として、以下の表に記載の構成パターンがございますが、 本投稿では、Socket1台・インターネット回線2本構成とSocket2台・インターネット回線2本構成について解説していきたいと思います。   ▼表1.Catoクラウドの拠点構成一覧 Socket インターネット回線 本記事にて解説する構成 1台 1本   1台 2本 〇 1台 3本以上   2台 1本   2台 2本 〇 2台 3本以上     Cato Cloudについての詳細はこちらをご参照ください！   Catoクラウド 変化する働き方に必要な「ゼロトラスト」を実現する「ネットワークとセキュリティを統合したクラウドサービス(SASE)」であるCatoクラウドをご紹介しています。 www.scsk.jp   Cato Socketについて まずはCato Socketについてご紹介です。 今回使用したのはX1500というモデルで、外観はこのような感じです。 このモデルはスループット(上下の通信の合計値)が最大500Mbpsですが、これより広帯域が必要な場合は、X1500より上位のX1600やX1700から選択することができます。 今回の検証では500Mbpsで十分なのでX1500を使用しました。 また、X1500は4ポートのギガビットイーサネットを搭載しており、左からWAN×2ポート、LAN×2ポート、コンソール×1ポートという並びになっています。 その他特徴は以下にまとめました。 ▼表2.X1500の仕様 寸法 W:165mm×D:105.5mm×H:43mm or W:180mm×D:130mm×H:30mm （dual rack mount available） CPU Intel® Atom™ processor システムメモリ 4GB ストレージ 16GB Ethernetポート 4×1GbE スループット 500Mbps   構成例 続いて、本投稿にて解説する3つの構成についてです。 構成1. Socket1台 インターネット回線2本構成 構成1は、インターネット回線2本を1台の Socket で直接終端する構成です。 インターネット回線はActive/ActiveまたはActive/Passiveにて設定が可能ですが、本投稿ではActive/Passiveとした場合について解説します。 構成2. Socket2台 インターネット回線2本構成 構成2は、Socket2台・インターネット回線2本の構成で、2パターン解説します。 パターンA パターンAの構成は、Socket1台に対しインターネット回線を2本接続し、Internet回線とSocketを冗長化した構成です。 インターネット回線はActive/ActiveまたはActive/Passiveとすることが可能ですが、本投稿ではActive/Passiveとした場合について解説します。 SocketはActive/Passive のみ可実装可能です。 パターンB パターンBの構成は、Socket1台に対しインターネット回線を1本接続し、Internet回線とSocketを冗長化した構成です。 インターネット回線はSocke1台に対してインターネット回線1本のためActive設定とします。 またSocketは前述の通り、Active/Passive のみ実装可能です。 障害時の通信フロー ここで、各構成で障害を発生させた際の通信フローについて解説していきたいと思います。 障害パターンは以下4パターンの想定です。 障害パターン Socketの筐体障害 SocketのLAN側切断 Socket と Catoクラウド PoP間のVPN切断 インターネット回線品質低下（SLA閾値を下回る） 構成1 障害パターン1・2発生時 Socketおよびインターネット回線の切り替わりは発生しませんでした。 構成1は、図からもわかる通り Socketが1台のみの構成です。 そのため、Socketの筐体障害およびLAN切断時のSocketの切り替わりが不可となり、通信を継続させることができません。 障害パターン3・4発生時 インターネット回線の切り替わりが発生し、通信を継続させることができました。 Socketがwan1側のVPN切断やActive回線の品質低下を検知すると、wan2インターフェイスのステータスをPassiveからActiveに変更し、wan2経由で通信を継続します。 この時、TCPコネクションは継続され、Socket配下の端末から接続先アプリケーションへの通信は継続することが可能です。 さらに、Socketがwan1側のVPN接続やActive回線の復旧を検知すると、自動的にwan1経由の通信へと切り戻ります。 まとめ 筐体障害やLAN切断発生時、通信が全断する可能性があります。 VPN切断や回線品質低下による、インターネット回線の切り替わりは可能です。 VPN切断や回線品質低下による、インターネット回線切り替わりの際、TCPコネクションは継続されます。 VPN接続や回線品質復旧時、通信は自動で元の通信経路に切り戻ります。 各障害発生時の切り替わり可否や切り替わり時間についてまとめると下表のようになります。 ▼表3.構成1における各障害発生時の切り替わり可否と切り替わり時間 障害パターン 障害時の切り替わり 復旧時の切り戻り １ 筐体障害 × × ２ LAN側切断 × × ３ VPN切断 〇：インターネット接続が10秒以上断 〇：wan1側が復旧後即時で切り戻り ４ 回線品質低下 〇：SLA閾値を下回る状態が130秒以上継続 〇：10分毎にSLA条件を再評価し問題ない場合切り戻り 構成2(パターンA) 障害パターン1・2発生時 Socketの切り替わりが発生し、通信を継続させることができました。 Socket(Passive)はSocket(Active)の筐体障害およびLAN切断を検知すると、SocketHAステータスをPassiveからActiveに変更し、Socket(Passive)経由で通信を継続します。 この時、TCPコネクションは継続され、Socket配下の端末から接続先アプリケーションへの通信は継続することが可能です。 さらに、Socket(Passive)がSocket(Active)の筐体およびLANの復旧を検知すると、自動的にSocket(Active)経由の通信へと切り戻ります。 障害パターン3・4発生時 インターネット回線の切り替わりが発生し、通信を継続させることができました。 Socket(Active)は、wan1インターフェイス側のVPN切断およびActive回線の品質低下を検知すると、wan2インターフェイスのステータスをPassiveからActiveに変更し、Socket(Active)のwan2経由で通信を継続します。 この時、TCPコネクションは継続され、Socket配下の端末から接続先アプリケーションへの通信は継続することが可能です。 さらに、Socketがwan1側のVPN接続やActive回線の復旧を検知すると、自動的にSocket(Active)のwan1経由の通信へと切り戻ります。 まとめ 全障害パターンで切り替わりが発生し、通信を継続させることができます。 切り替わりの際、TCPコネクションは継続されます。 復旧時、通信は自動で元の通信経路に切り戻ります。 各障害発生時の切り替わり可否や切り替わり時間についてまとめると下表のようになります。 ▼表4.構成2(パターンA)における障害発生時の切り替わり 障害パターン 切り替わり時間(障害時) 切り替わり時間(復旧時) １ 筐体障害 〇：VRRPハートビート1秒×3回断 〇 ２ LAN側切断 〇：VRRPハートビート1秒×3回断 〇：lan1が復旧後即時で切り戻り ３ VPN切断 〇：インターネット接続が10秒以上断 〇：wan1側が復旧後即時で切り戻り ４ 回線品質低下 〇：SLA閾値を下回る状態が130秒以上継続 〇：10分毎にSLA条件を再評価し問題ない場合切り戻り 構成2(パターンB) 障害パターン1・2・3発生時 Socketの切り替わりが発生し、通信を継続させることができました。 Socket(Passive)はSocket(Active)の筐体障害およびLAN切断を検知すると、SocketHAステータスをPassiveからActiveに変更し、Socket(Passive)経由で通信を継続します。 また、Socket(Active)のVPN切断時についても同様に、Socket(Passive)はSocket(Active)のwan1インターフェイス側のVPN切断を検知し、SocketHAステータスをPassiveからActiveに変更することで、Socket(Passive)経由で通信を継続します。 この時、TCPコネクションは継続され、Socket配下の端末から接続先アプリケーションへの通信は継続することが可能です。 さらに、Socket(Passive)がSocket(Active)の筐体・LAN復旧およびVPN接続の復旧を検知すると、自動的にSocket(Active)経由の通信へと切り戻ります。 障害パターン4発生時 Socketおよびインターネット回線の切り替わりは発生しませんでした。 Socket(Active)側の回線品質が低下しても、 Socket(Passive)はSocketHAステータスをPassiveからActiveに変更することはできないため、Socketの切り替わりは発生しません。 さらに、構成2(パターンB)は、図からもわかる通りSocket1台に対しインターネット回線を1本接続した構成です。 そのため、Socket(Active)でwanインターフェイスの切り替えができず、Socket(Active)のwan1経由で通信を継続します。 つまり、不安定な通信が継続される可能性があるといえます。 まとめ 回線品質低下による切り替わりを考慮しない場合のみ、有効な構成です。 ※回線品質劣化による切り替わりを考慮する場合は、構成2(パターンA)が推奨です。 筐体障害やVPN切断、LAN切断による、Socketの切り替わりの際、TCPコネクションは継続されます。 筐体・LAN復旧およびVPN接続の復旧時、通信は自動で元の通信経路に切り戻ります。 各障害発生時の切り替わり可否や切り替わり時間についてまとめると下表のようになります。 ▼表5.構成2(パターンB)における障害発生時の切り替わり 障害パターン 切り替わり時間(障害時) 切り替わり時間(復旧時) １ 筐体障害 〇：VRRPハートビート1秒×3回断 〇 ２ LAN側切断 〇：VRRPハートビート1秒×3回断 〇：lan1が復旧後即時 ３ VPN切断 〇：インターネット接続が10秒以上断/VRRPハートビート1秒×3回断(最大13秒) 〇：wan1側が復旧後即時で切り戻り ４ 回線品質低下 × × 構成比較検討 最後に、通信の継続性の観点から3つの構成を比較した結果です。 通信の継続が構成検討時の必須条件である場合、構成2(パターンA)が推奨ですが、 Socketの切り替わりを考慮しない場合は構成1、回線品質低下による切り替わりを考慮しない場合は構成2(パターンB)でも実装が可能です。 ▼表6.構成比較表 Socket インターネット回線 構成例 継続性 1台 2本 構成1 △：一部継続不可 2台 2台 構成2(パターンA) 〇：継続可能 2台 2台  構成2(パターンB) △：不安定な通信が継続される可能性あり   まとめ 本投稿では、Catoクラウドの拠点内構成のうち、冗長構成について説明いたしました。 Catoクラウド導入や拠点展開のご検討時にお役に立てば幸いです。 なお、本投稿はCatoのナレッジベースを参考に作成しています。 SocketのHA構成についての詳細はこちらをご参照ください！ ソケット高可用性(HA)とは – Catoナレッジベース (catonetworks.com) なお、弊社の FAQ サイトでは 、よくあるご質問やCato クラウドのアップデート情報を公開しておりますので、是非ご参照ください！ よくあるご質問 | Cato Cloud ケイトクラウド - SCSK Cato SASE Cloud Platform. powered by SCSK cato-scsk.dga.jp

ログ保管期間の課題 2023年8月現在、Cato クラウドのイベント (Events) ログは Cato 側で6か月間保存されており、その期間内であれば Cato Management Application (CMA) でログの内容を確認できます。また、 Guide to Cato Data Lake Storage (EA) の記事にて、将来的には3か月間だけ無償で保存されるようになるものの、別途契約すれば6か月または1年間保存できるようになるとアナウンスされています。 しかし、ユーザ様企業によっては、監査やセキュリティインシデント対応などの目的で、ユーザやセキュリティ関連のログを1年を超えて保管する必要があり、ログの保管期間が課題になるという方も多いのではないでしょうか。 CMA の画面にはイベントログをエクスポートして手元に保存する機能が用意されていますが、ひと月当たり数億～数十億件のログが出力されることもあり、量が膨大でエクスポートするのは困難です。また、イベントログを取得する API もありますが、一度に取得できるログの件数の制限やその他原因により、全てのログを取得することもできません。 別の機能として、Cato クラウドにはイベントログを Amazon S3 に出力してくれる機能がありますので、これを使って課題を解決してみます。 機能概要 今回利用するのは Integrating Cato Events with AWS S3 に記載されている機能です。 この機能は、ユーザ自身で Amazon Web Services (AWS) の S3 Bucket をあらかじめ用意し、Cato に対して適切な権限を与えることで、あとは Cato が自動的にイベントログを S3 Bucket に出力し続けてくれるというものです。 ログの保管にかかる Amazon S3 の利用料金はユーザ側で負担する必要がありますが、ログの保管期間をコントロールできるようになりますし、任意のサービス・ソフトウェアを用いて分析できるようになるというメリットもあります。 イベントログの出力設定 イベントログを Amazon S3 に出力するための設定手順は Integrating Cato Events with AWS S3  に詳しく記載されていますので、その内容に従って設定を行いましょう。 AWS 環境の準備 まず、AWS 上では次のリソースを用意する必要があります。 S3 Bucket (イベントログが格納される場所) IAM ポリシー (S3 Bucket の操作権限の定義) IAM ロール (IAM ポリシーで定義した権限を Cato に付与する設定) S3 Bucket を作成するリージョンは任意に選択して良く、日本のユーザであれば東京または大阪リージョンを選択することが多いと思います。S3 上のログの分析を AWS 上で行うのであれば、費用の安い米国東部や米国西部リージョンを選択しても良いと思います。 CMA の設定 CMA の設定もドキュメントの手順に記載の通り、”Administration” – “API & Integrations” 画面の “Events Integration” タブで設定できます。 イベントログの出力先のフォルダ名や出力対象のイベントのフィルタ設定は、ひとまず空欄のままでも良いと思います。これについては後述の通り工夫の余地があります。 イベントログの出力結果の確認 ログ内容の確認 正しく設定ができていれば、数分後から Amazon S3 にイベントログが続々と出力されます。 また、S3 Select を用いればイベントログのファイルの中身を簡易的に確認できます。 S3 Select の入力設定では次のように指定してください。 形式 : JSON JSONコンテンツタイプ : 行 圧縮 : GZIP 上図では JSON 形式で全てのフィールドを表示していますが、特定のフィールドのみを CSV 形式で表示することもできます。 わかったこと 弊社の検証用の Cato アカウントで試した結果ですが、この機能について次のことがわかりました。 1分間に1,2回の頻度でイベントログのファイルが S3 Bucket に作成される ドキュメントでは60秒ごとまたはデータファイルが10MBを超えたらアップロードすると書かれているが、実際の頻度はそれより多い ファイルのストレージクラスは Standard ログファイルは GZIP 圧縮されている ログファイルの中身は、1つのイベントを1つのJSONとして表し、1行ごとに1つのJSONが記載されたテキストデータ {"event_count":1,"internalId":"xxxxxxxxxx","event_type":"Security","event_sub_type":"Internet Firewall","time":1691628724649,...その他フィールド} {"event_count":1,"internalId":"yyyyyyyyyy","event_type":"Security","event_sub_type":"Internet Firewall","time":1691628724649,...その他フィールド} {"event_count":1,"internalId":"zzzzzzzzzz","event_type":"Security","event_sub_type":"Internet Firewall","time":1691628724649,...その他フィールド} ... ファイル名は “${UNIX秒}-${UUID}.log.gz” という形式 例 : 1691628848-9170c8f4-3088-4ee8-ba7c-a5abcb3e4613.log.gz UNIX秒の部分はそのファイルが生成された時刻で、S3 Bucket にアップロードされた時刻とほぼ一致する イベントが発生してから2,3分程度遅れで S3 Bucket にアップロードされる 実際にどの程度の時間遅れるかは仕様として記載されていないため、もっと遅れる可能性もある 複数のイベントが1つのイベントログ (event_count が1よりも大きな値) として記録されることもある CMA 上でこの機能を有効にしている期間のイベントのみ出力される この機能を設定する前や、無効にしている間のイベントのログは出力されない また、イベント数の少ない検証用アカウントで試したため精度は低いですが、設定してから2週間ほど経過したあと、実際に出力されたログのデータ量は次のようになっていました。 イベント行数 : 61,010 件 ファイル数 : 28,415 個 GZIP 圧縮済のファイルサイズの合計 : 16.23 MB GZIP 展開後のファイルサイズの合計 : 69.23 MB なお、1つのファイルに記録されているイベントが少ないため GZIP の圧縮効率が低くなっておりますが、参考までに全イベントを1つのファイルにまとめて GZIP 圧縮すると 3.42 MB にまで減りました。 ログ分析における課題 ログを長期に保管しなければならないという課題をクリアできると、次はログを分析する必要が出てくるときに備えて目的のログを抽出する方法を考えないといけません。 ログファイルの形式は明確になっていますので、ログファイルを手元にダウンロードし、全ファイルを読み込んで目的のログを抽出するプログラムを書くという方法が挙げられます。しかし、ファイル数は比較的多く、全体のファイルサイズも大きくなりますので、ログのダウンロードやプログラムの実行部分で相当の時間がかかるものと思います。 別の方法として、Amazon Athena を利用して分析するという方法が挙げられます。Athena を利用すれば、ログを手元にダウンロードすることなく SQL とほぼ同じクエリを用いてログを分析できますし、分散処理によってクエリの実行時間の短縮も図られます。 Amazon Athena とは - Amazon Athena 標準 SQL を使用して、Amazon S3 に保存されているリレーショナルおよび非リレーショナルデータに対してアドホッククエリを実行し、数秒で結果を取得します。 docs.aws.amazon.com サービス別資料 | AWS クラウドサービス活用資料集 アマゾン ウェブ サービス (AWS) は安全なクラウドサービスプラットフォームで、ビジネスのスケールと成長をサポートする処理能力、データベースストレージ、およびその他多種多様な機能を提供します。それらを活用するために役立つ日本語資料、動画コンテンツを多数ご提供しております。 aws.amazon.com 稀にしかログの抽出を行わないのであればあまり気にしなくてもよいのですが、Athena でログを頻繁に分析して活用しようとすると次のような新たな課題も出てきます。 全期間の全てのファイルが S3 Bucket の1つのフォルダの下に保存されるため、クエリを実行するたびに全てのデータが読み込まれて時間と費用がかかる 1つ1つのファイルサイズが小さいため、Athena 内部の分散処理のオーバーヘッドが大きく、実行に時間がかかる 1つ目の課題については、CMA でイベントログの出力先のフォルダ名や出力対象のイベントのフィルタ設定を工夫することで、部分的に解決できます。例えば、イベントタイプごとに出力先のフォルダに変える、あるいは比較的ログの多いイベントサブタイプ (Internet Firewall や WAN Firewall など) だけ異なるフォルダにするといった工夫が考えられます。この場合、イベントタイプやイベントサブタイプが将来増える可能性を忘れずに考慮する必要もあります。 本格的に解決して効率よく分析できるようにするは、ログの分析でよく用いる検索キー (タイムスタンプ、イベントタイプ、イベントサブタイプ、サイト、ユーザIDなど) でパーティショニングしたり、複数のファイルを 128MB 以上 (Athena の推奨サイズ) にまとめたりするのが望ましいです。これについては AWS の利用に関する知識やログの分析ノウハウだけでは実現できず、多少なりともプログラムや分析システムの開発が必要になってくるため、分析の目的が明確になってからでも良いと思います。 まとめ 本記事では Cato クラウドのイベントログを Amazon S3 に自動的に出力する機能について検証し、課題について整理しました。 AWS を利用中のユーザ様であればすぐにでも利用できますので、まずはイベントログを保管するところから始めてみてはいかがでしょうか。そうしておけば、監査やセキュリティインシデント対応のために後から過去のログが必要になったとしても、ログを追跡できる状況を確保しておけます。 また、弊社が用意する AWS 環境でログを保管し、ユーザ様からの要求に応じてログを抽出してお渡しするといった対応ができるかもしれませんので、お気軽にご相談いただければと思います。

Catoクラウドをご紹介した際に、最初にご質問をいただく中の一つに、小規模拠点にはSocketを設置せず、SDPユーザ（※）だけで利用して良いか？という質問をいただきます。 (※)SDP･･･Software Defined Perimeter（ソフトウェア定義境界）はZTNAの別名です。従来型のリモートアクセスソリューションとは異なり、ゼロトラストの原則に則ったセキュアなリモートアクセスソリューションを意味します。Catoクラウドでのリモートアクセス、モバイルアクセスを意味します。 Socketを設置しない理由（メリット）はコスト です。 拠点（Site）は、PoP接続帯域（最小25M～最大5,000M）のSiteライセンス契約と、Socketの契約が必要となります。vSocketやIPsec接続の場合は契約は不要です。 SDPユーザの契約を想定している場合は、SiteライセンスとSDPユーザライセンスと二重で課金が発生しているように捉えられる場合があり、小規模拠点にはSocketを設置しない方針で検討されるお客様がいらっしゃいます。 そもそも、Catoクラウドでは、サーバやシステムが設置されている拠点は、ユーザからの拠点（Site）へのアクセスがあるため、Socket/vSocketの設置（またはIPsec接続）によるSite登録は必須となります。 システムが設置されていない拠点、つまり利用者（エンドユーザ）しかいない拠点については、Socketの設置は必須ではないため、コストの観点でSocketの設置を悩まれる場合があります。   Socketを設置しないデメリット それではユーザしかいない拠点を前提に、Socketを設置しないデメリット（5つ）を解説していきます。 本記事の内容は2023年8月28日時点のものです。各種機能が随時アップデートされておりますので、最新情報と異なる可能性があります。 1) QoSによる帯域制限が行えない これが一番大きなデメリットになります。 拠点にインターネット回線があり、拠点内のユーザがインターネット回線を共有利用する場合の帯域制御の課題です。 CatoクラウドのQoS（Quality of Service）は、Bandwidth ManagementとNetwork Rulesでの設定となり、トラフィック優先度（Priority：2～254）、帯域幅制限（常に制限する、混雑時のみ制限する等）にて制御を行います。 多くのお客様では、Web会議（Teams、Zoom）は最も高い優先度とし、その次の優先度はお客様により異なりますが、基幹系システム → メールやスケジューラ（Microsoft365、Google Workspace）→ オンラインストレージ（Dropbox、Box、OneDrive、Google Drive）やWindowsファイル共有（SMB）を設定され、最も優先度が低いのは、Windowsアップデート（Windows Update）とされている場合が多いです。 Socketが設置されていれば、50MbpsのSiteライセンス契約であれば50Mbpsを上限として、それ以上の帯域要求があった場合は、QoS設定に基づき、優先度の低い通信から順次破棄（Discard）が行われます。 Socketが設置されていない場合は、このQoS機能がないため、Windowsアップデートが大量トラフィックを専有すると、ネットワークの輻輳や遅延が発生し、Web会議ができない、システムが利用できない等が発生する可能性があります。 また、Socketが設置されていないため、拠点で流れている通信が、Windowsアップデートなのか？誰が何のトラフィックを流しているのか？などは分かりません。 Socketが設置されていれば、リアルタイムで見るだけはなく、過去に遡って確認することも可能となります。 2) ユーザのアクセス元による制御が行えない Catoクラウドの”ユーザ”概念は、リモートアクセスの”SDPユーザ（SDP User）”と、拠点（Site）のSocket配下に居る”ユーザ（User）”とに区別されています。 Catoクライアントソフトには、Identity Agentの機能があり、Socket配下のPCにインストールを行うことで、ユーザを識別（User Awareness）することができます。Catoクライアントをインストールするだけであれば、SDPユーザライセンスは必要ありません。 また、Catoクライアントは、拠点（Site）のSocket配下に接続されると自動的にSocket配下であることを認識します。Socket配下では、クライアントは”Officeモード”となり、二重のVPNを行いません。 例えば、在宅や社外からのリモートアクセス時には、人事システムにはアクセスをさせないようにして、本社・事業所などの拠点に居る場合には、人事システムへのアクセスを可能とする場合は、”SDPユーザ”はブロック（Block）、”ユーザ”を許可（Allow）にて制御を行うことができます。 つまり、Socketを設置しない場合は、拠点の配下でも（Socket配下ではないので）”SDPユーザ”となりますので、”ユーザ”と区別したより厳格な制御は行えないことになります。 3) 個別設定により運用が煩雑化する 運用管理上は、これが一番問題になります。 拠点にSocketを配置した場合は、拠点のセグメントは、Catoクラウドへ自動登録（または手動登録）で認識が行われます。 拠点内で、Catoクライアント接続時は、同一LANセグメントであれば特段何の設定も必要なくアクセス可能ですが、同じ拠点内でも異なるセグメントとの通信については、すべてCatoクラウド（PoP）経由での通信を行うこととなります（SocketのLAN Firewall機能利用を除く） 拠点にSocketを設置しない場合ですが、拠点内のプリンタやファイルサーバ（NAS）等が別のセグメントに存在する場合に、Catoクライアントが直接通信を行うためには、Split Tunnel(※)機能を利用する必要があります。 (※)Split Tunnel･･･SDPユーザでCato PoP経由を除外する機能 Split Tunnelは、アカウント全体設定が可能ですが、この場合は、各拠点毎の設定となりますので、Catoクライアント端末側の設定、またはSDPユーザ毎で設定行う必要がありますので、運用管理が煩雑になります。 また、Always-OnやLAN Blockingなどのクライアント制御機能も同様です。 企業のITガバナンスとして、Catoクライアントの常時起動（Always-On/Never-Off）や、デバイス証明書認証（Device Authentication(※)）、デバイスポスチャ（Device Posture(※)）を利用されるお客様が殆どです。 (※)Device Authentication･･･端末証明書による接続制御 (※)Device Posture･･･端末の状態チェックによる接続制御（ウィルス対策/Firewall/HDD暗号化等をチェック） Always-Onを利用している場合、クライアント接続時のID認証～Device Authentication～Device Posture等の一連のセキュリティチェックで何かしらの失敗（エラー）が発生し、さらにLAN Blocking機能を利用している場合は、対象デバイスは、Catoクラウドに接続できず、拠点のローカルセグメントにも接続ができなくなります。 LAN Blockingを例に挙げていますが、前述の通り、Catoクライアントは、拠点（Site）のSocket配下ではOfficeモードとなる機能がありますが、Officeモード時はLAN Blockingは無効化されます。Socketを設置しない場合は、LAN Blockingをアカウント全体設定を実施し、SDPユーザ毎で解除する設定を行う必要になるため、同じように運用管理が煩雑になります。 そのため、Socketを設置しない場合、運用上の理由でこれらの制御機能の一部を採用されない場合があります。 4) Socketの機能が利用できない 当たり前ですが、Socketを設置しないので、Socketの機能が一切利用できません。 Socketには、DHCP、MACアドレス認証（MAC Authentication）等の様々な機能があります。 特に「Socket Web UI」というユーザインタフェースがあり、拠点に設置いたSocketの各種状況（Status）確認、各種設定（Network Setting/Cloud Connection Setting）、各種ツール（Tools）、トラフィックキャプチャ（Traffic Capture）などの機能があります。 各種ツール（Tools）については、SocketからPing、Tracerouteを始め、Speedtest、iPerf等を実施することができ、拠点内での通信トラブルが発生した場合の原因究明に非常に便利な機能です。 また、Scoketには、LAN Firewallの機能もあり、拠点内の異なるVLAN間のトラフィックのローカルでのブロック（Block locally）、許可（Allow locally）制御を行うことができます。不要なトラフィックをCato PoP（Socketがない場合はインターネット）へ流すことが減りますが、こちらもSocketを設置しない場合には利用できません。 5) 既存NW機器の保守運用が残る 最後は、Catoクラウドとは直接の関係はないのことになりますが、Socketは、メンテナンスフリーで、ファームウェアへのパッチ適用やアップグレードはクラウド側ですべて制御を行い、自動適用されます（メンテナンス時間の設定は可能です） 拠点にSocketを設置しない場合には、ルータやFirewall（UTM）など何らかの機器が必要となりますが、その機器の保守運用が残ることになります。 機器の保守切れを含むライフサイクル対応はもちろん、セキュリティホールや脆弱性などからセキュリティインシデントにつながることが多いため、ゼロトラスト、およびZTNA（Zero Trust Network Access）の概念においては、常に最新のファームウェアにアップグレードされるSocketの設置を推奨しています。   まとめ 今回は、Socketを設置しない場合の主な留意点・デメリット5つを解説しました。Catoクラウド独自用語を多用したため、ご不明点やご質問事項があれば、当社まで遠慮なくお問い合わせください。 結論としては、Socketなし（SDPユーザユーザのみ）は、 拠点のユーザが数名（5～10名？）程度 拠点内のローカルLANセグメントが一つ（プリンタ・NASも同一セグメント） インターネット接続はキャリアのホームゲートウェイのみ などの条件であれば大きな問題はないかと思いますが、全拠点の一元管理（ポリシー管理およびログ管理を含む）や、運用管理の煩雑さ、全体の運用負荷を考慮すると、SCSKでは、Socketあり、Socket設置を推奨しています。 また、今回の解説は、Socket/vSocketとIPsec接続との比較（メリット/デメリット）で同様の部分があります。 Socket/vSocketとIPsec接続の違いについては、PoP IP（IP Allocation）が別途必要であることや、PoP障害時に切り替わりが行われないなどがありますので、SSE360（ライセンス）を含めて別途記事にしようと考えています。 最後に、SCSKでは、2021年からSASEの主要ソリューションを一同に紹介を行うオンラインセミナー「SCSK SASE Solution Summit（通称 S4）」を定期的に開催しており、次回は2023年10月に開催する予定です（2023年8月時点） それ以外にも、Catoクラウドのお客様導入事例の制作、FAQサイト運営を行っております。 よくあるご質問 | Cato Cloud ケイトクラウド - SCSK Cato SASE Cloud Platform. powered by SCSK cato-scsk.dga.jp このTechHarmony（技術ブログ）で、さらに皆様のお役に立て、Catoクラウドの知名度UPに少しでも貢献できればと考えております。

どうも、Catoクラウドを担当している佐々木です。 Catoクラウドで、Catoクライアントソフトの常時起動設定、いわゆる「Always-On」に関する問い合わせをよくいただきます。 この記事では、「Always-On」の設定方法と動作について簡単にご紹介します。 ※画⾯は2023年8⽉時点のものです。機能アップデート等で変わる場合がありますので、あらかじめご了承ください。 Always-Onとは SDP ユーザーのインターネットセキュリティを強化するための機能です。 Catoのセキュリティ機能として多くのユーザーで利用されています。   「Always-On」を使用すると、CatoクライアントのON/OFFをユーザー側で制御することができなくなり、 SDPユーザーからのトラフィックが常に「Catoクラウド」を通過するようにできます。 ※ユーザーがこっそりCatoをOFFして、セキュリティポリシーで禁止していることをやっちゃう、を予防できます。   Always-On設定方法 「Always-On」の設定方法は簡単です。 CMAで「Always-On」を利用したいユーザーを定義するだけです。   1.CMA上の設定画面選択 CMAにログインし、 「Access」 ＞ 「Always-On Policy」 を選択します。 右端の 「New」 をクリックすると、設定ウィンドウが表示されます。 2.パラメータ設定 以下の画面にて各設定項目を入力ください。 Name ：任意のルール名を入力 Rule Order ：「Always-On」ルールの設定順番を入力 ※末尾のConnected（動作設定）が「On-Demand」の設定がない限り、デフォルト設定で問題ありません。   「Alaways-On」を利用するユーザーの設定です。プルダウンから以下を選択します。 Any ：すべてのユーザーで「Alaways-On」を利用する場合に選択　※デフォルト設定 SDP User ：「Alaways-On」を利用したいユーザーを選択 User Group ：「Alaways-On」を利用したいユーザーグループを選択　※事前にUser Groupを定義する必要があります。   「Alaways-On」を利用する端末を限定する設定です。 同じユーザーでもWindowsPCでは有効にするが、iPhoneでは無効にするといったことが可能です。 プルダウンから以下を選択します。 Any ：すべての端末で「Alaways-On」を利用する場合に選択　※デフォルト設定 Operating System ：「Alaways-On」を利用する端末を限定する場合に選択（WINDOWS/macOS/IOS/Android） ※OS以外に端末を限定する方法はありません。   「Always-On」の動作設定です。プルダウンから以下を選択します。 Always-On ：「Alaways-On」を 利用する 場合に選択 On-Demand ：「Alaways-On」を 利用しない 場合に選択 On-Demandは、特定のユーザー以外は全員「Alaways-On」を有効にする、といった場合などに利用します。 例）Rule1：「Alaways-On」を利用しないユーザーを「On-Demand」で設定する Rule2：ユーザーを「Any」にし、「Alaways-On」で設定する   最後に「Apply」と「Save」をクリックすれば設定完了です。   設定イメージ   Always-On動作確認 「Alaways-On」が有効な場合、ユーザー自身でCatoへの接続解除ができなくなります。 以下のようにCatoクライアントで「Alaways-On is enabled」と表示されます。 真ん中の緑色のボタンをクリックしても反応しなくなります。   一時切断してみた 一時的にクライアントを切断したい場合、以下の方法で切断可能です。 CMAにログインし、 「Access」 ＞ 「Always-On Policy」 を選択します。 「Setting」 タブを選択し、 「Show bypass code」 もしく 「Show QR code for authentication app」 をクリックします。 Show bypass code ：切断用のワンタイムパスワードが表示されます。 Show QR code for authentication app ：切断用のQRコードが表示されます。   上記パスコードをCatoクライアントに入力すれば一時切断可能です。 入力方法は以下の通りです。 Windows ：PCのタスクトレイからCatoクライアントを右クリックし 「Temporary Bypass」 を選択。 mac ：PCのタスクトレイからCatoクライアントを右クリックし 「Temporary Bypass」 を選択。 iOS ：クライアントのクライアント ホーム画面で 「Bypass Always-On」 を選択。 Android ：クライアントのサイド メニューから 「Temporary Bypass」 を選択。   例：Windowsの場合 タスクトレイから 「Temporary Bypass」 を選択します。   ワンタイムパスワードの入力画面が表示されます。入力ください。     切断されるとクライアントが以下のようになります。   なお、 一時切断は最大15分間 です。   クライアント認証に失敗してみた 「Alaways-On」が有効の状態でクライアント認証に失敗すると、 インターネットアクセスがすべてブロック されます。 今回は「Device Posture」機能を利用して、意図的にクライアント認証を失敗させ、どのような動作になるか確認しました。   検証条件 「Device Posture」で適当なセキュリティソフトを利用中の端末じゃないとCatoに接続できないよう設定 上記セキュリティソフトを未利用の端末からCatoに接続 クライアントは「Windows（Ver：5.7.20）」 ※「Device Posture」は「Client Connectivity Policy」でデバイスの要件を定義するルールを作成し動作させます。 ※今回のテーマは「Always-On」のため、設定方法などは別の機会に記事にします。   検証結果 認証に失敗すると、クライアントが以下のような状態になります。   そして、インターネットにはアクセスできなくなりました。   LAN内のローカル環境にはアクセスできました。   「Alaways-On」で認証に失敗したユーザーは、インターネットに通信できなくなるが、LANにはアクセスできる   ちなみに、 タスクマネジャーからCatoに関するタスクをすべて終了すると、インターネット向けの通信が復活しました。。 これをやられたくない方は、Windwos機能でタスクマネージャーの起動を禁止するなどした方がよいかもしれません。 ※もちろん、 Catoへの接続はNGなので社内へのアクセスできません！   ついでにLAN Blockingも試してみた 先ほどの検証では、インターネットへの通信はブロックされましたが、LANにアクセスできていました。 「LAN Blocking」を利用すると、LANへのアクセスもできなくなります。   LAN Blockingの設定方法 ▼アカウント全体に設定する場合 CMAにログインし、 「Access」 ＞ 「Client Access」 を選択します。 「Split Tunnel」 タブを選択し、 「LAN Blocking」 をチェックします。 アカウント全体に設定する場合、SDPユーザー全員がLANに接続できなくなるので注意ください   ▼特定のユーザーのみに設定する場合 CMAにログインし、 「Access」 ＞ 「Users」 から対象のユーザーを選択します。 「User Configuration」 ＞ 「Split Tunnel」 を選択し、 「 Override account settings」 と 「LAN Blocking」 をチェックします。   検証条件 「Device Posture」で適当なセキュリティソフトを利用中の端末じゃないとCatoに接続できないよう設定 上記セキュリティソフトを未利用の端末からCatoに接続 クライアントは「Windows（Ver：5.7.20）」 「LAN Blocking」 を有効   検証結果 認証に失敗して、インターネットにアクセスできないまでは先ほどと同じです。 そのうえで、LAN内のローカル環境にもアクセスできなくなりました！   「Alaways-On」と「LAN Blocking」を組み合わせると、認証に失敗したユーザーはどこにも通信できなくなる   オプション機能 「Alaways-On」には以下のオプション機能があります。   Connect on Boot 端末ブート時（起動時）にクライアントも一緒に起動してくれます。 この設定はSDPユーザー単位で指定できず、全員有効か、全員無効か、の2択になります。   Start minimized Catoクライアント起動時にクライアントが最小化します。 この設定はSDPユーザー単位で指定できず、全員有効か、全員無効か、の2択になります。   設定画面 どちらの機能も同じ場所で設定可能です。 CMAにログインし、 「Access」 ＞ 「Always-On Policy」 を選択します。 「Setting」 タブを選択し、下の方にある各機能にチェックを入れて「Save」すれば有効化されます。   まとめ 「Always-On」 は設定も簡単で、セキュリティ強化に有効な機能です。 特に 「Device Posture」「LAN Blocking」 と組み合わせることで、特定のセキュリティソフトがインストールされていない端末は CatoにもインターネットにもLANにも接続させないようにする、といった強めのセキュリティ対策も可能になります！   「Always-On」を使用すると、CatoクライアントのON/OFFをユーザーが制御できなくなる CMA上の「Access」＞「Always-On Policy」で一通り設定可能 「Always-On」利用中も、一時的に無効にすることが可能 「Always-On」有効時に、認証に失敗するとインターネットに接続できなくなる（リカバリー可能）   「Always-On」について弊社の 「Catoに関するFAQサイト」 にも多数情報ございますのでご参考にください。 よくあるご質問 | Cato Cloud ケイトクラウド - SCSK Cato SASE Cloud Platform. powered by SCSK cato-scsk.dga.jp 最後に、SCSKではPoCから導入、運用まで幅広くCatoに関する支援を行っております。 本番構成への移行を見据えたPoC構成や、PoCでつまづきやすい点のサポートなど、豊富な導入実績を基にご支援いたします。 ぜひお声がけください！

Catoクラウドの Cross Connect について解説します。 世界初のSASEプラットフォーム Catoクラウドとは？ Cato Networks社 の Catoクラウド（ケイトクラウド）についてご紹介します。 Catoクラウドは世界初のSASEのサービスであり、強固なセキュリティとシンプルな運用管理を実現します。 blog.usize-tech.com 2023.08.15 「世界初のSASEプラットフォーム Catoクラウドとは？」で拠点（Site）がCatoクラウドにへ接続する方法としては、 物理エッジデバイス Scoket （X1500、X1600、X1700） 仮想エッジデバイス vSocket （AWS、Azure、VMware）※GCPは対応予定 既存機器 IPsec の3つと解説しましたが、もうひとつ、4つ目の拠点（Site）の接続方法「Cross Connect」について解説します。 Cross Connect とは、Catoクラウドへの新たな接続方式となり、以下クラウドとの専用線接続となります。 AWS Direct Connect Azure Express Route Google Cloud Interconnect OCI Fast Connect サービスとしては、Catoとは、別のサービスプロバイダー（Cross Connect Partner Provider）を介した提供となり、CatoのすべてのPoPで提供が可能ではなく、提供可能なPoPが限定されています。 日本国内については、東京、大阪いずれのPoPにおいてもサービス利用が可能となっています。 東京、大阪ともに、 エクイニクス社の「Equinix Fabric（旧称：Equinix Cloud Exchange Fabric）」 を利用することになります。 海外PoPでは、デジタル・リアルティ（Digital Realty）等の提供もあります。 つまり、実際には専用回線での接続ではなく、日本の場合はエクイニクス社のデータセンター内の構内LAN接続となります。 また、物理的な工事が発生するので、サービスの依頼から提供までにリードタイムが掛かります。   Cross Connectを採用する理由・メリット 完全なプライベート接続（インターネット（IX）を経由しない） vSocket、IPsecより高パフォーマンス、低レイテンシーが必要な場合 固定課金、広帯域でのコスト最適化 現在 vSocket が提供されていないクラウド（GCP、OCI）との接続 注意点としては、 最小契約帯域は501Mbps以上 となります。   Socket/vSocket、IPsec、Cross Connectとの比較 拠点（Site）接続の比較表   Cross Connectの冗長構成（Cross-location HA） Cross Connect が提供可能な複数PoPを利用したHA構成（Cross-location HA）も可能です。 まとめ CatoクラウドのSocket/vSocket、IPsec以外の拠点接続方法である Cross Connect についてご紹介しました。 既存のレガシーネットワーク・セキュリティから、SASE、Catoクラウドへ移行されたお客様の多くは、サーバ・ストレージについても、クラウドへの移行を進められている（または、完了されている）場合が殆どで、クラウドとの接続帯域はどんどん増えていく傾向にあります。 クラウドとの接続に、広帯域（500Mbps以上）、低レイテンシーが求められる、あるいはデータ転送量（いわゆる、エグレス料金）の抑制、従量→固定課金が必要となる場合には、この Cross Connect が選択肢の一つになるかと考えています。 最後に、SCSKでは、2021年からSASEの主要ソリューションを一同に紹介を行うオンラインセミナー「SCSK SASE Solution Summit（S4）」を定期的に開催しており、それ以外には、Catoクラウドのお客様導入事例の制作、FAQサイト運営を行っております。 TechHarmony（技術ブログ）で、さらに皆様のお役に立て、Catoクラウドの知名度UPに少しでも貢献できればと考えております。

お疲れ様です。SCSK三上です。 先日参加した Amazon QuickSight Roadshowイベント でご紹介いただいた、AWSを利用する方のコミュニティ、JAWS-UGのランチ会に初めて参加してみました！内容と感想共有します。 8/4開催！Amazon QuickSight Roadshowイベントレポート オンサイト開催のAmazon QuickSight Roadshowイベントに参加したのでレポートアップします！ やはりオンサイトのイベントは他社の方との交流含めてテンションが上がりますね～ オフィスはもちろん、ドリンクやお菓子のサービス、お弁当まで大変豪華でした！ blog.usize-tech.com 2023.08.15 JAWS-UGとは？ JAWS-UGとは、 AWS (Amazon Web Services) が提供するクラウドコンピューティングを利用する人々の集まり（コミュニティ） です。 一人ではできない学びや交流を目的としてボランティアによる勉強会の開催や交流イベントなどを行なっています。 私たちは日本全国に「支部」の形でグループを持ち、それぞれのテーマに基づいて活動を行なっています。 このコミュニティーは、非営利目的で活動しています。 JAWS-UGとは JAWS-UGとは、AWS (Amazon Web Services) が提供するクラウドコンピューティングを利用する人々の集まり（コミュニティ）です。 jaws-ug.jp   JAWS-UG東京 ランチタイムLT会#2 項目 内容 開催日 2023年8月22日 12:00~13:00 開催場所 Youtube Live イベントHP JAWS-UG東京 ランチタイムLT会 #2 – connpass それでは、今回登壇いただいた4つのLTを簡単にご紹介いたします！   LT① インフラ未経験でAWSを触って感じたこと しろみさん 居酒屋で働いたのちに、半年間学校に通いインフラ技術者になったとのことで興味深々でした！ 感動したこと・大変だと感じたこと共通の「組み合わせ方が自由」というのがとても共感できました。 アップデートが早いからこそ、常に情報を追いかけてベストプラクティスを見つけていかなければならないですね。 AWSの使っていく中での感動したこと 組み合わせ方が自由 要件に合わせてサービスを組み合わせて柔軟に対応ができる ユースケースごとにサーバレスパターンが存在する 手軽に作成ができる 検証したい環境を手軽に構築できる 試したいサービスがあったときに手軽に利用することができる。まるで試食コーナー！ あらかじめ確認しないとコストがかかることも！！ 新サービスのリリース、アップデートが早い！ AWSを触れていく中で大変だと感じたこと インフラ・開発の基礎知識が必要 基礎知識があると理解が捗ると感じた 例 OSI参照モデル、TCP/IP、CDN、DNSの仕組み CPU、メモリ、ストレージ SQLインジェクション、CSRF、XSS 組み合わせ方が自由 多数あるサービス、頻繁に行われるアップデート どの組み合わせにしたらいいのか？今の組み合わせ方が正しいのか？ 選択肢が多い、自由であるほど検討するときに悩む。 まとめ インフラの基本的知識があると捗る！どんな選択肢が良いのか？ なぜその組み合わせなのか？考えることは必要だが、まずはスモールスタートで始めることが大切！   LT② AWS Community Builder? 何それオイシイの？ 3年目CBが語るLessons learned from CB coosukeさん AWS Community Builderという言葉、初めて聞きました！その他にも3つほど、グローバルコミュニティ支援プログラムがあるんですね。資格だけでなくモチベーションや自信につながるプログラムだと思いました！ AWSのグローバルコミュニティ支援プログラム AWS Community Builder AWSが展開しているグローバルコミュニティ支援プログラム すべてで4つ！その中の一つが、AWS Community Builder。 AWS Community Builder 知識の共有や技術コミュニティとの連携に熱心なAWS技術愛好家や新興のソートリーダーに、技術リソース、教育、ネットワーキングの機会を提供するプログラム 半期に1度の自薦 AWS コミュニティビルダー｜ワールドワイドのクラウドコミュニティ｜AWS デベロッパーセンター AWS コミュニティビルダーズプログラムは、知識の共有や技術コミュニティとの連携に熱心な AWS 愛好家や新興のソートリーダーに、技術リソース、メンターシップ、ネットワーキングの機会を提供するプログラムです。 aws.amazon.com   何がオイシイの？ インプットの場が増える 人脈がスケールアウト、スケールアップ プロダクトリームによるセッション AWSサービスのセミナーが毎週のように開催 サーバレスサービスのロードマップ セキュリティセミナー β版へのアーリーアクセス AWSクレジットや割引などのサポート アウトプットの場が増える テクニカルブログ APJ Open Mic APJのCBがあるまって月一で開催されるLT大会 Swag 更新のたびに、Swagがもらえる！   LT③ 競争的研究費でクラウド利用を読み解こう 小寺加奈子さん 研究における、クラウドの使いやすさについてご説明いただきました！ 競争的研究費という言葉も初めて聞いたのでとても勉強になりました。研究にクラウドを利用することがしやすくなったとのことで、更にクラウド利用が進む気がしました🎵 競争的研究費とは？ 大学、研究開発法人、民間企業等において府省等の公募により競争的に獲得される経費のうち、研究に係るもの。従来、競争的資金として整理されてきたものを含む。 何が変わったの？ 今回変更になったのは、「競争的研究費における各種事務手続きに係る統一ルールについて」 ⇒ クラウド利用料が明確に記載！ つまり、競争的研究費を用いて、クラウド利用ができるようになった！実際の事例も！以下参照。 理化学研究所によるバーチャル富岳×クラウド　AWS社が語る生成系AI×教育　大学・研究室関係者向け無料フォーラム8月24日(木)東京、8月28日(月)大阪にて開催 ■基調講演：理化学研究所計算科学研究センター センター長　松岡 聡(東京) ■注目講演：「生成系 AI の課題と解決策-学術・研究機関ユースケースからのAWSの考察」アマゾン ウェブ サービス ジャ… www.atpress.ne.jp   LT④ BLEA for FSIワークショップから学ぶ金融レベルのガバナンス 石倉幸さん（シンプレクス株式会社） お恥ずかしながらBLEAという言葉も初めて来ました…！金融のお客様に向けてお話する際は、キーワードになると思いました！ BLEAとは？ B ase l ine E nvironment on A WS の略 ⇒ AWSセキュリティのベストプラクティスを実装した環境を迅速に実現可能！ B ase l ine E nvironment on A WS for F inancial S ervices I nstitute の略 ⇒ BLEAに、FISC準拠の観点から不足分を追加 BLEA for FSIでできること クラウド上で構築するならやるべきこと 金融システムならやるべきこと/よくあること ⇒ これをBLEA for FSIがカバー！ BLEAとBLEA for FSIを比較 基本のつくり（共通） ガバンスベースライン セキュリティ面、システム全体統一してガバナンスをきかせるための実装 ワークロード よくある実装のサンプルコード ガバンスベースライン 項目 BLEA BLEA for FSI Cloud Trail S3データイベント記録 なし あり SSMセッションマネージャーログのS3出力 なし あり 大阪リージョンへのガバナンスベースデプロイ なし あり IAM Identity CenterのMFA設定 なし あり ワークロード BLEA BLEA for FSI ECSパターン EC2パターン サーバレスパターン ⇒ アーキテクチャカット 勘定系 顧客チャネル オープンAPI マーケットデータ データ分析プラットフォーム ⇒ 業務カット その他ドキュメント系（ BLEA for FSIのみにあるもの ） Cloud Towerコントロールで有効にすべきもの 動作：プロアクティブ、ガイダンス：必須を除くコントール（全205種）のうち、FISC観点で導入が推奨される70種を抽出 FISC実務基準対策一覧 各ワークロードのどの実装が、どの実務基準に即しているかのまとめ BLEAの個人的な価値 お客さんへの説明が楽になる 金融機関では特に、「国が認めている」「AWSが認めている」というのは強い！   JAWS-UG東京 ランチタイムLT会 今後の予定 次回からは、 毎月第四火曜日開催とのことです！　 次回、 9/26(火)12:00~ ぜひ皆さんも参加してみてください！

こんにちは、SCSK株式会社の中野です。 前回は「 AWSをZabbixで監視してみた 」の投稿でAWSの監視を試してみましたが、今回はAzureをZabbixで監視してみたいと思います。 皆様はAzure上に構築したシステムを監視するために、どの監視ツールを利用していますでしょうか。 Azureが提供している監視サービス「Azure Monitor」を利用している方も多いと思います。 本記事では「Azure Monitor」ではなく、オープンソースの統合監視ツールである 「Zabbix」 を用いて、Azureのサービスを監視してみます。 Zabbixとは Zabbixは、エンタープライズ対応のオープンソース統合監視ツールです。 サービスやそれを支える ITシステム(サーバ、ネットワーク機器等)の状態を把握し、障害の予兆やサービスへ影響を及ぼす事象が発生した際に、システム管理者やオペレータに通知を行うオープンソースの統合監視ソリューションです。 数万デバイス規模のエンタープライズ環境でも多数の稼動実績を誇っています。 Zabbixの詳細情報については、下記リンクよりご確認ください。 Zabbixとは｜SCSK Plus サポート for Zabbix 世界で最も人気のあるオープンソース統合監視ツール「Zabbix」 www.scsk.jp Zabbixには、Azureの各種サービスを監視するための設定をまとめた9つのテンプレートが用意されています。 （2023年8月時点） ・Azure by HTTP ・Azure Cosmos DB for MongoDB by HTTP ・Azure Microsoft SQL Database by HTTP ・Azure Microsoft SQL Serverless Database by HTTP ・Azure MySQL Flexible Server by HTTP ・Azure MySQL Single Server by HTTP ・Azure PostgreSQL Flexible Server by HTTP ・Azure PostgreSQL Single Server by HTTP ・Azure Virtual Machine by HTTP ※ Azureテンプレートを利用するためには、Zabbix 6.0.13 以上のバージョンが必要です。 今回は「 Azure Virtual Machine by HTTP 」テンプレートを利用してAzureのサービス（Virtual Machines）を監視していきたいと思います。 監視してみた（事前準備編） ZabbixでVirtual Machinesを監視するために、Azure側で以下２つの対応が必要になります。 ・Azureサブスクリプションに対してのAzureADアプリケーション（サービスプリンシパル）を作成 Azure CLIでの作成例） az ad sp create-for-rbac --name zabbix --role reader --scope /subscriptions/<subscription_id> ・監視対象リソースに対しての読み取り権限（reader）を付与 Azure側の作業は以上になります。 監視してみた（設定編） それではZabbixで監視するために、対象ホストをZabbixへ登録していきます。 Zabbix登録画面では、ホスト名やＩＰアドレスを設定して、テンプレートは「Azure Virtual Machine by HTTP」を選択します。 次に以下５つのホストマクロに対して、変数を設定します。 ・{$AZURE.APP.ID}　：　アプリケーションID ・{$AZURE.PASSWORD}　：　パスワード ・{$AZURE.TENANT.ID}　：　テナントID ・{$AZURE.SUBSCRIPTION.ID}　：　Microsoft AzureサブスクリプションID ・{$AZURE.RESOURCE.ID}　：　Virtual MachinesのリソースID そのほか必須ではございませんが、必要に応じて以下３つのホストマクロも設定します。 ・{$AZURE.PROXY}　：　HTTPプロキシの値を設定（空の場合はプロキシ使用なし） ・{$AZURE.DATA.TIMEOUT}　：　APIのレスポンスタイムアウト値 ・{$AZURE.VM.CPU.UTIL.CRIT}　：　CPU使用率のしきい値 あとは「追加」または「更新」ボタンを押すだけで、Zabbixでの監視が開始されます。 データ取得まで数分待つと、以下の通りNWやディスク等の監視アイテムを取得することができました。 グラフも問題なく、作成されていることを確認できました。 最後に ZabbixでAzureを監視してみた結果、簡単に監視データを取得することができることが分かりました。 しかし、AWSを監視してみたときに出た結論と同様に「Azure Virtual Machine by HTTP」のテンプレートだけでは、インスタンスOS内部リソース・ログ監視は実施不可のため、Zabbixエージェントが導入できない場合以外はVirtual MachineにもZabbixエージェントを導入し、両方での監視を実施する必要がありそうだと感じました。 今回はVirtual Machineのみに絞って監視を試してみましたが、今後は別のリソースの監視もしたいと思います。 最後まで読んでいただき、ありがとうございました！！ AWSをZabbixで監視してみた オープンソースの統合監視ツールである「Zabbix」を用いて、AWSのサービス（EC2）を監視してみました。監視してみて感じたことや、監視手順をご紹介させていただきます。 blog.usize-tech.com 2023.05.29