本記事は 夏休みクラウド自由研究 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ミニセッションならびにブースへの来場をお待ちしております！

本記事は 夏休みクラウド自由研究 8/13付の記事です 。 Catoクラウドの記事は、8月7日から15日までの9日間連続投稿となります。 「夏休みクラウド自由研究」についてChatGPTに尋ねたところ「夏休みのクラウド自由研究は、クラウドコンピューティングを利用して実施する自由研究のことです」とのことで、研究テーマ（例）としては以下のような回答でした。 天気予報データの分析 ･･･気象データをクラウドサービスから取得し、データを分析して気温や降水量の変動をグラフ化する。 IoTデバイスとクラウドの連携 ･･･自宅にあるIoTデバイス（例：温度センサー、湿度センサー）をクラウドに接続し、データをリアルタイムで収集・表示する。 画像認識AIの構築 ･･･クラウドの機械学習サービスを利用して、簡単な画像認識モデルを作成し、動物や植物の画像を分類する。 ChatGPTとの壁打ちで色々自由研究のテーマを考えていたのですが、Catoクラウド他の担当者が、技術系記事を投稿するので、少し違う観点でのテーマを検討した結果、SASE、Catoクラウドに移行されたお客様が、移行前には何を利用していたのかを記事にすることにしました。 つまり、 Catoクラウドへ移行する以前のネットワーク（WAN）は何を利用していたのか？ Firewallは？ リモートアクセス（VPN）は？ URLフィルタリングは？ について、実際に当社での導入実績（40社以上）を集計し、トップ3までを記事にする ことにしました。 ただし、実績が1-2社しか無い場合には、順位をつけるのはやめています。 お客様からも、自社で使っているサービスや機器からCatoクラウドへの移行実績（事例）があるのか？と聞かれることが多いので、現時点の導入実績をもとに集計をしています。 あくまでも、当社（SCSK）導入事例の集計となり、Catoクラウド全体（全世界2,500社+、日本国内350社＋※2024年8月時点）の実績を集計したものではありません。 また、当社導入実績が50社や100社になった際に、また改めて集計して記事にしようと思います。   ネットワーキング/WANサービス 1 KDDI – Wide Area Virtual Switch 2（WVS/WVS2） 2 ソフトバンク – SmartVPN（スマートVPN） 3 ドコモビジネス・NTTコミュニケーションズ（以下、NTTコミュニケーションズ） – Arcstar Universal One（UNO） その他の通信キャリアや、インターネットVPNからの移行事例もあります。 お客様によっては、主回線/副回線と複数の通信キャリアで冗長化されているケースについては、それぞれを1事例としてカウントしています。   リモートアクセスサービス 1 KDDI – Flex Remote Access（FRA） 2 ソフトバンク – セキュアリモートアクセス 2、3 3 NTTコミュニケーションズ – Flexible Remote Access（FRA） WANと同じ順位となりました。   インターネット接続サービス 1 KDDI – Flexible Internet 2 ソフトバンク – Smart Internet 3 NTTコミュニケーションズ – Flexible InterConnect（FIC） WAN、リモートアクセスと同じ順位となりました。   SD-WAN機器/ルータ YAMAHA、Cisco Meraki、Fortinet FortiGate、VMware SD-WAN（VeloCloud）、Aruba SD-WAN（Silver Peak）からの移行事例がありますが、それぞれの事例が少なく、順位が正確ではないため掲載をとりやめました。 オンプレミス機器で、自前でインターネットVPNを構築し、運用をしてたが、ネットワーク管理者の離職に伴い、管理ができなくなって、Catoクラウドに乗り換えた事例もあります。   Firewall/NGFW/UTM機器 1 Fortinet FortiGate 2 Palo Alto Networks PAシリーズ 3 Cisco ASA その他に、Check Point、Barracuda、SonicWall からの移行事例もありました。 オンプレミス機器のセキュリティパッチ適用や、ファームウェアアップデートが頻繁に発生するため、管理負荷の増大から、Catoクラウドに乗り換えた事例が幾つかあります。   リモートアクセス/VPN機器 1 Pulse Secure（現：Ivanti） 2 Cisco AnyConnect 3 Fortinet FortiGate その他に、VMware Horizon、Citrix NetScaler からの移行事例があります。 Firewall/UTM機器と同じですが、 オンプレミスのVPN機器のセキュリティパッチ適用やファームウェアアップデートが頻繁に発生するため、管理負荷の増大から、Catoクラウドに乗り換えた事例が幾つかあります。 リプレースのタイミングではなく、実際に、セキュリティインシデント（不正侵入）が発生したので、乗り換えた事例もあります。   ロードバランサー/負荷分散装置 1 A10 Networks Thunder A10 Thunder以外にも幾つか製品がありましたが、実績数が少なく、順位が正確ではないため2,3位の掲載はとりやめました。 A10 Thunderについては、Microsoft 365、Google Workspace、Boxなどのクラウドサービス利用時の Proxyサーバの迂回（ローカルブレイクアウト）が主な利用用途です。   URLフィルタリング 1 デジタルアーツ株式会社 i-FILTER（i- フィルター ） i-FILTER（i- フィルター ）以外については、UTM機器を利用されている場合や、事例が1-2社だけのもの多く、順位が正確ではないため掲載をとりやめました。 ちなみに、i-FILTERで設定されている定義のCatoクラウドへの移行は、お客様自身で実施されている例が殆どです。   SSE（クラウドProxy/ZTNA） 1 Zscaler – Zscaler Internet Access（ZIA） 2 Netskope Palo Alto Networks（Prisma Access）やCloudflare、その他サービスからの移行実績がありますが、事例が1-2社だけのもの多く、順位が正確ではないため3位の掲載はとりやめました。 セキュリティ・サービス・エッジ（SSE）からの移行の大きな要因は、契約更新時の大幅な価格変更（値上げ）で、Catoクラウドを検討される事例が増えてきています。 また、既存WAN と SSE だけでは、いわゆる ラテラル ムーブメント（ 水平移動 ）の防御が行えないことから、拠点間通信におけるセキュリティ強化（WAN Firewall）を目的に、改めて SASE を検討されるお客様が増えてきています。   その他 その他の CASB 、 DLP 、 RBI 、 SaaS Security API については、SSE からの移行を除くと、Catoクラウドの移行前に利用しているお客様は殆ど存在せず、Catoクラウド採用時に新たに利用されるお客様が殆どでしたので、順位付けはやめました。 また、Catoクラウドでは、 EPP （Endpoint Protection Platform）や、 XDR （Extended Detection and Response）もサービス提供しているため、今後は EPP/EDRや、XDR（SEIM）からのリプレース実績も出てくると思いますので、改めて記事にしようと思います。   まとめ Cato Networks社 の Catoクラウド は、2024年7月にガートナーの シングルベンダーSASE の マジック・クアドラント で、リーダーに選出されています。 Cato Networks社が 2024年 ガートナーのマジック・クアドラントのシングルベンダー SASE でリーダーに認定 Cato Network社 Catoクラウドが 2024年最新版 ガートナー マジック・クアドラントのシングルベンダー SASE でリーダーに認定されました blog.usize-tech.com 2024.07.22 しかしながら、日本国内では、Cato Networks社、Catoクラウド（Cato Cloud/Cato SASE Cloud）自体の知名度は、まだまだ低い状況です。 SCSKは、2019年よりCatoクラウドの取り扱いを開始し、すでに40社以上のお客様にご契約をいただいております（2024年8月時点） SASEやCatoクラウドを紹介するセミナーを数多く開催しておりますので、以下のまとめ記事を是非ご覧ください。 Catoクラウド エンジニアブログまとめ記事 Catoクラウドのエンジニアブログ（TechHarmony）でのまとめ記事となります。 blog.usize-tech.com 2024.02.27 Catoクラウドに少しでも興味をお持ちになられた方は、遠慮なく当社まで お問い合わせ ください。

本記事は 夏休みクラウド自由研究 8/12付の記事です 。 Catoクラウドの導入ご支援をさせていただく中で、DNSにおけるご質問を多くいただきます。 今回はDNSについて説明します。 CatoクラウドのDNSの仕組み CatoクラウドではDNSサービスを提供しています。 まずはCatoクラウドのDNSの仕組みについて説明していきます。 Catoクラウドの各PoPにはDNSサーバが存在しており、デフォルトでSocket配下の端末やモバイルユーザの端末はこのDNSを参照します。 CatoのDNSは「10.254.254.1」と決められており、端末はこのアドレス宛にDNSリクエストを送ります。 また、CatoのDNSはキャッシュサーバとして機能しており、端末からDNSリクエストを受け取るとDNSキャッシュを使用して名前解決を試みます。この時、DNSキャッシュエントリがない場合はグローバルDNSサーバ（Google社のDNS「8.8.8.8」など）にリクエストを転送し、グローバルDNSサーバからのレスポンスをキャッシュに保存しています。 上記を踏まえ、設定画面を見ていきます。 アカウントのDNS設定 DNS設定はアカウント単位、サイト単位、ユーザ・ユーザグループ単位で設定することができます。 まずはアカウントの設定についてご説明します。 設定方法 CMAにログインし、Network ＞ DNS Settings ＞ Settings ＆ Suffixを開きます。 開くと” Primary DNS ”と” Secondary DNS ”の設定箇所があります。 ここで、PrimaryとSecondaryの2か所に設定をすることで、DNSサーバに冗長性を持たせることができます。 PrimaryのDNSサーバが利用できない場合に、SecondaryのDNSサーバを利用します。 デフォルトではどちらも空欄になっているため、設定が入っていない？と思われる方も多いと思いますが、実は”Primary DNS には「10.254.254.1」が、Secondary DNS には「8.8.8.8」が設定されています。 Catoに接続する端末はここに設定されたDNSを参照するため、デフォルトではCatoのDNSを参照し、CatoのDNSで名前解決ができない場合にGoogle社のDNSにて名前解決が行われるということになります。 (補足) カスタムレンジの場合 CatoのDNSサーバのアドレスは「10.254.254.1」であるとご説明しましたが、カスタムレンジを利用される場合は第4オクテットが”3”のアドレスに変更されます。例えば、カスタムレンジを「X.Y.Z.0/24」とした場合は「X.Y.Z.3」になるということです。 ここで、カスタムレンジとは？という方向けに補足します。 ご存知の方は飛ばしてください！ Catoクラウドでは、あらかじめ以下のIPアドレスレンジが管理アドレスレンジとして予約されています。 よって、通常はお客様のネットワーク環境にてこのアドレスレンジを利用いただくことはできません。 Catoクラウド管理アドレスレンジ：10.254.254.0/24 但し、既にお客様ネットワークで上記のアドレスレンジを利用しており重複してしまう場合は、/24で任意のアドレスレンジにCato側のアドレスレンジを変更することができます。 このように、Catoのアドレスレンジを変更しカスタムレンジを利用する場合は、DNSサーバのアドレスも第4オクテットが”3”のアドレスへ変更されることになります。 DNS Suffix 設定方法に話を戻します。 同ページにはDNS Suffixという設定項目がありますので、続いてDNS Suffixという機能をご紹介します。 DNS Suffixの設定を行うと、ユーザーが入力したドメイン名に任意のSuffixを付与してDNSサーバーへ名前解決のリクエストを送ります。 例えば、ユーザーが「storage. myorganization.local」というサーバーへアクセスをしようとした場合です。 図のようにDNS Suffixに「myorganization. local」を登録しておくと、ユーザーが「storage」という名前のサーバーにアクセスしようとした際に、OSは「storage. myorganization.local」という名前の名前解決リクエストをDNSサーバへ送ります。 上記の例ではSuffixを1つ登録していますが、複数登録も可能です。 例えば、「myorganization.local」と「myorganization.com」をこの順番で登録した場合、順にDNSサーバへSuffixを付与して名前解決のリクエストを送り、それでも接続が確立しなかった場合に 「storage」の名前解決のリクエストを送ります。 推奨設定 Catoクラウド導入をご検討中のお客様からは「プライベートDNSに上書き設定できないか？」というご質問をいただくこともございます。 答えは「可能です」なのですが Cato社は デフォルト設定のままCatoのDNSサーバを利用することを推奨 しています 。 主な理由ですが、プライベートDNSを利用した場合Catoクラウドの一部サービスが利用できなくなるためです。 現在わかっている範囲では、DNS Protectionの機能やNetworkRuleおよびFirewallのFQDNベースの制御がきかないといったことがCato社のドキュメントにも記載されています。 さらに、 ビルの法定点検などによる停電 によりプライベートDNSが利用できなくなると、Socket配下のユーザーはもちろんですがモバイルユーザも通信影響を受けますので注意が必要です。 なお、前述の通りCatoのDNSサーバはDNSレスポンスをキャッシュに保存するため、DNSの応答時間は非常に速くDNSの遅延が短縮されるというメリットもあります。これらの理由から、 デフォルト設定のままCatoのDNSサーバを利用することを推奨しています。 上記Cato社の推奨設定をご理解いただいたうえで、プライベートDNSご利用いただく必要がある場合は、次のDNS レコードをプライベートDNSに追加いただく必要があります。 vpn.catonetworks.net – > 10.254.254.5 (カスタムレンジをご利用の場合は「 X.Y.Z.2 」IP アドレス) tunnel-api.catonetworks.com – > 10.254.254.3 (カスタムレンジをご利用の場合は 「X.Y.Z.7」IP アドレス) DNS Forwarding CatoのDNSサーバ の利用を推奨するとお伝えしましたが、 CatoのDNSサーバ はインターネットの名前解決しかできません。 また、Secondaryに設定されているGoogle社提供のDNSサーバも同様です。 では「社内ドメインを持っている場合はどうしたらよいのか？」というご質問をよくいただきます。 もちろん社内ドメインの名前解決を実現するための機能がCatoクラウドにはございます。それがDNS Forwardingです。 DNS Forwardingの設定をすると、 CatoのDNSサーバ 「10.254.254.1」に届いた名前解決のリクエストをプライベートDNSへ転送させることができます。 ざっくりとしたイメージはこんな感じです。 端末からCatoのDNSサーバに名前解決のリクエストを送る リクエストを受け取ったCatoのDNSサーバから プライベートDNS にリクエストを転送する プライベートDNS が社内ドメインの名前解決を行い、CatoのDNSサーバに対してレスポンスを行う。 プライベートDNS からの返答を受け取ったCatoのDNSサーバが端末に対してレスポンスを行う 設定方法 DNS Forwardingの設定方法をご説明します。 まずCMAにログインし、Network ＞ DNS Settings ＞ DNS Forwardingを開きます。 Newを開き、Domainと転送先となる プライベートDNSの アドレスを設定するだけで設定完了です。 注意点 ここで注意すべき点は以下3つです。 アカウントレベルのDNS設定を上書きした場合、DNS Forwardingはサポートされない 転送先のプライベートDNSはSocket配下にある必要がある DNS Forwardingの設定を行った場合、CatoのDNSサーバはキャッシュ保存をしない 前述の通り、このDNS Forwardingという機能は CatoのDNSサーバに届いた名前解決のリクエストを任意の DNSサーバ に転送させる機能であるため、CatoのDNSサーバを使用している必要があります。 さらに、 転送先のプライベートDNS に対してCatoから疎通性がある必要があるということになります。 拠点のDNS設定 次に、拠点のDNS設定についてご説明します。 設定方法 CMAにログインし、Network ＞ 対象サイトを選択 ＞ Site Configuration > DNSを開きます。 拠点のDNS設定画面はアカウントの設定画面と同様に、Primary/Secondary DNSサーバとDNS Suffixの設定ができます。 アカウントと拠点でそれぞれDNSの設定を構成していた場合は 、 拠点の設定が優先されます 。 モバイルユーザのDNS設定　～DNS Settings Policy～ 次に、モバイルユーザのDNS設定に関するご説明です。 モバイルユーザのDNS設定はアカウントや拠点の設定方法と異なり、ルールベースに変更されました。（2024年7月末現在） 既存の設定方法と比べて、ぱっと見の変更点はこのくらいでした。 1つの画面で設定が完結する ユーザーやユーザグループに加えてOSの指定ができる 詳しく見ていきます。 設定方法 CMAにログインし、Access ＞ DNS Settings Policy を開きます。 Newを開くと以下の設定項目がありました。 General：ルール名やルールの順番を指定する User ＆ Groups：対象のユーザやユーザグループを指定する Platform：OSを指定する DNS Settings：DNSの設定をする DNS Settingsでは、下図の通り「Setup marually」と「Assign Account DNS Settings」の２つの選択項目があります。 ここで「Setup marually」を選択するとPrimary・SecondaryDNSサーバとDNS Suffixの設定ができます。 また、「Assign Account DNS Settings」を選択すると、アカウントの設定を適用させることができます。 注意点 最後に、DNS Settings Policyを設定するうえでのポイントをまとめてみました。 順序付けられたルールベースである。 オフィスモードの場合は拠点のDNS設定が適用される。 DNS Settings Policyで設定されたDNS設定は、DNS Forwardingルールよりも優先される。 それぞれ簡単にご説明します。 順序付けられたルールベース DNS Settings PolicyはFirewallやClient Connectivity Policyなどと同様に順序付けられたルールベースとなっています。つまり、上位のルールから順にチェックが行われ、一度ルールにヒットすると以降のルールはチェックされません。また、一番下には暗黙のルールがデフォルトで設定されており、上位に設定したルールにヒットしなかった場合は暗黙のルールが適用されアカウントのDNS設定が適用されます。 これまでは、ユーザとユーザグループでそれぞれDNSの設定を構成していた場合、ユーザの設定が優先されておりましたがDNS Settings Policyとなった現在(2024年7月以降)は、設定次第ということになります。 よって、ルールを設定する際は上記の仕様を踏まえ設定を行う必要があります。 オフィスモードの場合 モバイルユーザーは、Cato SocketまたはIPsecサイトの配下からCatoクラウドに接続した場合オフィスモードになります。 この時、DNS Settings PolicyのDNS設定ではなく拠点のDNS設定が優先されます。 DNS Forwarding機能を利用する 前述の通り、DNS Forwardingルールを適用させたい場合はCatoのDNSサーバを使用している必要があります。 DNS Settings PolicyでプライベートDNSを設定した場合はDNS Forwardingルールを適用させることができないため注意が必要です。 まとめ 今回はDNSの設定方法や設定いただく際の注意点についてご説明しました。 設定方法に迷われている方のお役に立てれば幸いです。

本記事は 夏休みクラウド自由研究 8/11付の記事です 。 本記事は、 これだけは知っておこう ～Catoクラウドに関連するIT用語まとめ～ 【ネットワーク編】 – TechHarmony (usize-tech.com) の続編になります。 今回は【セキュリティ編】と題して、Catoクラウドにまつわるセキュリティ用語を取り上げてご説明していきます。 そもそもSASEとは、Catoクラウドとは何か、が知りたい方は以下の記事をご覧いただければと思います。 ・ 世界初のSASEプラットフォーム Catoクラウドとは？ – TechHarmony (usize-tech.com) それでは早速、用語解説していきます。 Firewall(ファイアウォール) Firewall(ファイアウォール)とは、ネットワークの境界に設置し、ネットワーク内外の通信を遮断・監視するソフトウェアやハードウェアのことを言います。 一般的には、内部(LAN)と外部(WAN・インターネット)の境界に設置し、内部から外部への通信を必ずファイアウォールを通過するように構成します。ファイアウォールを通過する通信を、あらかじめ定めたルールに従って制御します。 ルールは主に、プロトコル(TCP/UDP/ICMPなど)、送信元/先のIPアドレスとポート番号を指定し、通信を制御することになります。 また、ファイアウォールには、次世代型ファイアウォールと呼ばれる、アプリケーション層でも制御可能なファイアウォールがあります。 IPアドレスが変更されるような宛先への通信が、アプリケーションとして識別され制御可能になります。 ファイアウォールの2つのリスト型 ファイアウォールのルールの設定方針には、ブラックリスト型とホワイトリスト型の2種類があります。 ブラックリスト型 ブラックリストとは、不適切と判断する通信を拒否するルールのみを記載するリストのことです。 ファイアウォールでは、ブラックリストで運用されることが多いです。 次世代型ファイアウォールでは、不適切な通信として、暴力やギャンブルなどのカテゴリでまとめて一律拒否するルールを記載して運用することが多いです。 ホワイトリスト型 ホワイトリストとは、ブラックリストとは反対に、適切な通信を許可するルールのみを記載したリストのことです。 何も設定していない初期設定ではすべての通信が拒否されています。 そのため、セキュリティレベルは高いですが、ファイアウォール導入開始まもなくは、適切な通信を許可しきれていないとブロックされてしまう場面が発生してしまうことに注意が必要です。 Catoのファイアウォール Catoでは、インターネットへのファイアウォールはブラックリスト型、WAN内のファイアウォールはホワイトリスト型と分かれています。 インターネットへのファイアウォールでは、ブラックリスト型で運用され、上述したようなカテゴリを指定して通信拒否する運用が可能です。また、カテゴリは随時Cato社によって更新されております。 WAN内の通信は原則拒否し、必要な通信のみを随時許可するホワイトリスト型の運用となります。 これはゼロトラストの考え方をもとにしており、たとえ企業内の通信であっても信頼せず、事前定義した通信のみを許可するホワイトリスト型となっています。 デジタル証明書 デジタル証明書とは、その証明書の所有者がどのような存在かを証明する電子文書のことです。 TLSなどの暗号化通信の中で利用されることが多いです。そのほかに、本人確認やデジタル署名などでも利用されます。 デジタル証明書は、認証局(CA)と呼ばれる機関が発行します。 クライアントは信頼する認証局自身の証明書をあらかじめ保持しています。 証明書が信頼する認証局によって署名されたものかどうか、検証することでクライアントは証明書の正当性を確認できます。 また、TLS証明書には公開鍵が含まれています。 公開鍵は、秘密鍵と組み合わせることで、公開鍵暗号方式を実現できます。 この公開鍵暗号方式を利用して、TLS通信を実現できます。 TLS TLSとは、Transport Layer Securityの略称で、トランスポート層の上で暗号化通信を行うための通信プロトコルのことです。 仮に通信している間に盗聴されても、TLSで通信していれば暗号化されているため、通信の解読防止の役割を果たします。 クライアントとサーバ間での通信において、TLSを利用することでサイトへのログイン情報や個人情報のような機密性の高いデータを安全にやり取りすることが可能です。 IDSとIPS IDSは、Intrusion Detection Systemの略称で、「不正侵入 検知 システム」と和訳されます。 ネットワーク上のトラフィックを監視しており、悪意のあるトラフィックを検出するとシステム管理者等へ通知します。 IPSは、Intrusion Prevention Systemの略称で、「不正侵入 防止 システム」と和訳されます。 その名の通り、IPSでは検知のみですが、IDSの場合はネットワーク上の通信を監視して不正なアクセスをブロックします。 2種類の検知方法 IDSとIPSが悪意のあるトラフィックとして検知する方法は、シグネチャ型とアノマリ型の2種類あります。 シグネチャ型 悪意のあるトラフィックは、シグネチャと呼ばれる、不正なアクセスパターンとして事前に登録されたリストをもとに判断されます。 登録したパターンのみを検知するため、誤検知は起きづらいですが、未知の脅威を見逃す可能性が高くなります。 アノマリ型 アノマリ型はシグネチャ型とは反対に、事前に正常なアクセスパターンを登録したリストをもとに判断されます。 こちらは未知の脅威に対して効果がありますが、一方で業務内容等の変化に応じてリストを更新していないと、誤検知が起きやすくなります。 なお、Catoでは、セキュリティオプションにてIPS機能が提供されています。Catoクラウドを通過したトラフィックをシグネチャ型で検知・防御する機能があります。 まとめ いかがでしたでしょうか。 本記事では、ネットワーク設計・運用において、セキュリティ分野に着目して特に重要な用語を取り上げています。 Catoクラウドの初期設定や障害調査において用語の意味が理解できない場面で、ぜひ本記事に立ち戻ってご活用いただければ幸いです。 今後続編として、【応用編】の投稿も予定しています。

本記事は 夏休みクラウド自由研究 8/10付の記事です 。 Catoクラウドの導入を検討されているお客様から「Catoモバイルに接続した状態で複合機は使用できるか？」というご質問を大変よくいただきます。普段は自宅や外出先からCatoモバイルで接続していて、Cato Socketを設置していないオフィス等で複合機を使用したいというシチュエーションかと思われます。これを実現するには 「Split Tunnel」 機能を使用します。 Split Tunnelは、オンプレのVPN装置でもある機能なのでご存じの方も多いと思いますが、簡単に言うと「特定の宛先や送信元のIPアドレスはVPNトンネルを通さず通信させる」といった機能です。せっかく用意したVPNトンネルから除外するわけですからセキュリティレベルは低下してしまいます。ただ宛先が信頼できるサイトでどうしてもパフォーマンスが必要とか、帯域の逼迫を回避したい場合など、例外設定としてSplit Tunnelを活用する例は少なくないと思います。 CatoのSplit Tunnelには状況に応じたいくつかの設定パターンがあるので、今回はその辺りの活用方法を整理しつつSplit Tunnel の設定事例をご紹介します。 CatoのSplit Tunnelで出来ること 2024年7月現在Catoの Split Tunnel の動作設定としては以下の4つが可能です。 尚、表中の「LAN ACCESS」について少し補足しておきます。この設定の動作は後述します。 「Split Tunnel OFF」と「Exclude specific IPs」を選択した時だけ「LAN ACCESS」の設定が可能 「LAN ACCESS」欄にチェック無し：Catoクライアントと同一セグメント宛の通信を許可（デフォルト値） 「LAN ACCESS」欄にチェック有り：Catoクライアントと同一セグメント宛の通信をブロック No 設定 Split Tunnel を使用した動作 LAN ACCESS 1 Split Tunnel OFF （デフォルト） 全てのトラフィックはCatoのVPNトンネルを通す 設定可能 2 Exclude specific IPs 特定のIPアドレスはCatoトンネルから除外し、残りのトラフィックはCatoトンネルを通す 同上 3 Include specific IPs 特定のIPアドレスのみCatoのトンネルを通し、残りのトラフィックはCatoトンネル外にルーティングする 設定不可 4 End-user defined エンドユーザーで定義する 同上 Split Tunnelのユースケースは、Cato Knowledge Centerにも「サブネット重複の回避策」や「ITチームが業務通信に影響がないようセキュリティ検証する」といった話が掲載されていますが、身近な例としては以下の様なものがあります。 Cato Client PCとは別セグメントにある複合機のIPアドレスをCatoトンネルから除外 グループ会社のシステムを利用するには指定のVPN経由でないと接続できないので、VPN接続先のIPアドレスを除外 業務で使用する通信がTLSインスペクションやIPSでブロックされる為、宛先IPアドレスを除外 情シス担当が社内にあるFirewall等のネットワーク機器にログインするため、対象のIPアドレスを除外 Catoとは別のクラウド型セキュリティサービスの接続先IPアドレスを除外 IP電話サービスのSIPサーバやクラウドPBXの通信先IPアドレスを除外 尚、これらの事例では全て上表No2の「Exclude specific IPs」を使用しています。 では、Catoに接続した状態でオフィス内の複合機を利用する場面を例にして、 Split Tunnelを使用した時PC側で何が起きているのか？ という側面からその動作を見てみましょう。   Catoモバイル接続時の複合機の利用 PCと同一セグメントの複合機の場合 まず、 PCと同一セグメントの機器には、 CatoモバイルでCatoに接続した状態でも疎通が可能です。 これはCatoに接続したPCの「ipconfig」の結果を見ていただければ分かるのですが、PCのローカルNICとは別にCatoの仮想NICが追加されており、CatoにはこのNICから接続しています。（図.1） ただ、PCのローカルNICも生きておりそのセグメント上にある機器はARPテーブルにも存在するので疎通は可能です。（図.2） よって PCと同一セグメントにある複合機は利用が可能 という事になります。 図.1 Catoモバイル接続時のipconfig 図.2 ARPテーブルと同一セグメント内IPアドレスへの疎通 PCと別セグメントの複合機の場合 次に、複合機が別セグメントにある場合、今度はルーティングの話になってきます。Catoモバイル接続時の「route print」の結果をみると、デフォルトルートが2つできており Catoのメトリックが「0」、ローカルNICのメトリックが「35」 なので、Catoのルーティングが優先される状態になっている事が分かります。（図.3） この状態で別セグメントにある複合機に疎通しようとしても、パケットは Cato側にルーティングされるので複合機には到達できません 。（※メトリック値が小さい方が優先されます） 図.3 Cato接続時のルーティング そこで複合機が別セグメントにある場合は、Split Tunnel の「Exclude specific IPs」で複合機のアドレスをCatoトンネルから除外する設定を行います。 例として、複合機のアドレス（192.168.100.1）を除外した設定時のPCのルーティングを見てみると新たなルートが追加されており、 追加された方の GatewayはCatoではなくローカルNICと同じ宛先に、且つメトリックはローカルNICのデフォルトルートと同じ「35」 になっていました。 同じメトリックでデフォルトルートと個別ルートがある場合はロンゲストマッチの原理で個別ルートが優先されるので、 別セグメントの複合機が利用できる という訳です。（図.4） もちろん複合機のセグメントにはL3スイッチ等でルーティングされている事が前提です。 図.4 Split Tunnel設定時のルーティング   LAN ACCESSによるローカルセグメントアクセスのブロック 「Split Tunnel OFF」と「Exclude specific IPs」の選択時のみ「LAN ACCESS」の設定が可能となります。これにチェックを入れると PCと同一セグメントの機器への疎通もブロックされるようになります 。 試しに「LAN ACCESS」にチェックを入れた時の「route print」を見ると、PCセグメントのルーティングがそれぞれ1行ずつ追加され、 ゲートウェイとインターフェースがCatoのアドレスになり、メトリックは「0」 になっていました。 前述のデフォルトルートと同様、同じ宛先のルーティングが2つある場合はメトリックが小さい方が優先されるので、同一セグメント宛ての通信もCato側にルーティングされてしまい同じセグメントであっても到達できないという仕組みです。 図.5 LAN ACCES設定時のルーティング ちょっと見にくいので、赤枠部分を抜き出し比較してみました。緑の行が追加されているルーティングです。 つまり「Split Tunnel OFF」でLAN ACCESSにチェックを入れると、ホントにCato以外は何も接続できないPCの提供が可能という事になります。ユースケースとしては、在宅環境で自宅にある他のPCやNAS等にネットワーク越しでデータをコピーさせないという事でしょうか。   Split Tunnel設定例 ここで、別セグメントにある複合機の利用を可能にするCatoの設定例をご紹介します。構成としては図.6のようなシチュエーションを想定しています。 図.6 複合機が別セグメントにある構成 では、実際のCato Management Application（CMA）で設定してみます。 １．IPレンジで除外アドレスの登録 設定箇所：Netwok >IP Ranges →任意の名前をつけて除外するIPアドレスを登録します。IP Rangeは「192.168.10.0/28」のようにサブネットで登録する事も可能です。 図.7 IP Rangesの設定 ２．Split Tunnel Policyでルールの設定 設定箇所：Access > Split Tunnel Policy →ルールの設定項目は以下の通りです。 ルールの名前 ：任意の名前をつけます。図8のように日本語も可能です。 ユーザー/グループ ：特定のユーザーを限定したり、複数ユーザーをグループ化してグループを登録する事も可能です。ここではAny。 プラットフォーム ：OSの指定が可能です。Windows・macOS・iOS・Android・Linuxから複数登録も可能です。ここではAny。 国 ：国の指定が可能です。ここではAny。 Split Tunnel ： Exclude specific IPsにチェックを入れると、IP Rangeで登録したものがリストで出てくるので、ここでは「Server Room Printer01 」を選択します。 図.8 Split Tunnel Policyのルール設定 「Apply」をクリックすると以下の画面になり、右上の「Save」をクリックして設定反映となります。（図.9） このようにしてルールを追加していきます。 図.9 Split Tunnel設定結果   その他の設定例 「Include specific IPs」の利用 動きとしては「特定のIPアドレスのみCatoのトンネルを通し、残りのトラフィックはCatoトンネル外にルーティングする」というものですが、よほど変わった使い方でない限りこの設定の利用例は無いかと思われます。 以前のネットワークなら「自宅や外出先からVPNで接続する際に社内ネットワークのアドレスはVPNトンネルを通し、インターネット通信は直接接続させる」という例はありましたが、今のSASEの概念とは相反しますね。 「End-user defined」の利用 トンネルから除外させたりトンネルに含めたりするルールをユーザーで定義するという設定です。 試した事はありませんがCatoナレッジをみると「テキスト ファイルをクライアントにアップロードして、どのトラフィックを Cato Cloud 経由でルーティングし、どのトラフィックを Cato Cloud 経由で除外するかを設定できる」とあります。またテキストファイルの書き方も掲載されているので参考にして下さい。 試しに「End-user defined」の設定にしてCato接続してみたところ、Cato Clientにテキストファイルをアップロードできる表示が追加されました。（図.10） 図.10 End-user defined設定時のCato Client さいごに Split Tunnelについては、お客様から「除外したい宛先IPアドレスが数が多いとかアドレスが変更になるのでドメイン指定ができないか？」という話もよく伺います。 現在、CatoのSplit TunnelではIPアドレス指定でしか設定ができませんが、最近発表されたロードマップの中にドメイン指定を可能とする内容が追加されていました。 仮に各拠点の複合機が共通のドメインで管理されていれば、1つ1つIPアドレスを設定しなくて済むので非常に便利になるかと思います。 ただ、従来のローカルブレークアウト的な発想で特定のクラウドやSaaSのドメインで除外する事も可能になるので「Cato経由だとうまく繋がらないからこのドメインは除外してしまえ」とかになると、せっかく導入したSASEの効果が失われてしまう事になります。この点はくれぐれもご注意下さい。

こんにちは。SCSKの山口です。 今回は、Cloud Functions とData Fusionを組み合わせて、下記のパイプラインを構築してみたいと思います。 Cloud Functions のEventarc トリガーでGCSバケットへのファイル配置・更新を検知する Cloud Functions からDataFusionパイプラインを起動し、データ加工とBigQuery へのデータ格納を行う 特定のバケットにファイルが置かれた際に、それを検知してData Fusion起動→BigQuery テーブルへデータ格納。といった流れです。 Data Fusion パイプライン作成 今回は、下記のブログで作成したパイプラインを再利用します。 【GCP】Cloud Data Fusion で Wrangler を柔軟に使い倒す Google CloudのData Fusionでパイプラインを構築する機会が多くあり、その中でも「Wrangler」のプライグインを多く使用したので、その際に便利だった機能をご紹介します。 blog.usize-tech.com 2024.08.06 CSVファイル内の ハイフン付きの電話番号 から ハイフンを取り除き 、BigQuery テーブルへ格納するパイプラインです。 Wranglerプラグインを直感的に操作する方法を紹介しています。本ブログのメインではないので詳細は省きます。気になる方はぜひご覧ください。   Cloud Functions ファンクション作成 次にファンクションを作成し、デプロイします。 構成 下記構成で作成します。 基本 環境：第2世代 関数名：yamaguchi-test-datafusionkick リージョン：asia-northeast1（東京） トリガー トリガーのタイプ： Cloud Storage イベントタイプ： google.cloud.storage.object.v1.finalized バケット： yamaguchi_test_20240806 イベントタイプの「google.cloud.storage.object.v1.finalized」については、下記ブログの「Cloud Storageトリガーとは？」で紹介してあるのでこちらをご覧ください。 Cloud FunctionsのCloud Storageトリガーをフォルダレベルで指定したい！！ 先日、Dialogflow CXのAgentからのテストケース作成を自動化していて、「あるフォルダにファイルがアップロードされたら起動するCloud Functionsを作りたい」とふと思いました。そこで今回はバケットレベルで指定するCloud Storageトリガーをどうにかしてフォルダレベルで指定できないか調べてみました。 blog.usize-tech.com 2024.08.05 今回は、「yamaguchi_test_20240806」バケットを対象とし、バケットレベルで更新を検知する設定とします。 コード 今回作成したコードは下記のとおりです。 main.py import functions_framework import os import requests from google.cloud import data_fusion_v1 from google.auth import compute_engine from google.auth.transport.requests import Request @functions_framework.cloud_event def call_datafusion(cloud_event):   # Data Fusionクライアント生成     DataFusion_client = data_fusion_v1.DataFusionClient()   # アクセストークン取得　→{access_token}   credentials = compute_engine.Credentials()   credentials.refresh(Request())     access_token = credentials.token   # Data Fusionパイプライン呼び出し用の認証ヘッダ設定　→{auth_header_fusion}     auth_header_fusion = {'Authorization': f'Bearer {access_token}'}   #パラメータ設定   namespace = 'default'   app_name = 'yamaguchi_test_20240805'   workflow_name = 'DataPipelineWorkflow'   #CDAPのエンドポイントを取得(gcloudコマンド無し)　→{cdap_endpoint}   set_request = data_fusion_v1.GetInstanceRequest(       name="projects/scsksdv-dev-XXXXXXXXX/locations/asia-northeast1/instances/test-df-02",   )   get_prm = DataFusion_client.get_instance(request=set_request)     cdap_endpoint = get_prm.api_endpoint   # CDAP APIにリクエストを送信   url = f'{cdap_endpoint}/v3/namespaces/{namespace}/apps/{app_name}/workflows/{workflow_name}/start'     response = requests.post(url, headers=auth_header_fusion)   # レスポンスを確認   if response.ok:       print(f'パイプライン呼び出しは正常に処理されました。ステータスコード： {response.content.decode()}')       print(f'IDトークン: {ID_token}')       print(f'アクセストークン: {access_token}')   else:       print(f'パイプライン呼び出しでエラーが発生しました。ステータスコード: {response.content.decode()}')     return ("END") requirements.txt functions-framework==3.* google-cloud-storage google-auth google-cloud-data-fusion pandas requests 以上でファンクションは完成です。   ファンクションのコードに関しての備忘（※読み飛ばしても問題ないです） コードを作成するにあたっていくつかの壁に当たったので備忘として残しておきます。 今回パイプラインを起動するコードの作成にあたって、下記の方法（コマンド実行）でパイプラインが起動できることをはじめに確認しました。 POST -H "Authorization: Bearer ${AUTH_TOKEN}" "${CDAP_ENDPOINT}/v3/namespaces/namespace-id/apps/pipeline-name/workflows/DataPipelineWorkflow/start" 上記コマンドでは、認証とパイプライン起動のために「AUTH_TOKEN」、「CDAP_ENDPOINT」を必要とします。 この「2つのトークンの取得 → CDAP APIへリクエスト送信」のコードをCloud Functions で実行したところ、下記のエラーにあたりました。 errorとなる部分 error内容 500 Internal Server Error: The server encountered an initial error and was unable to complete your request. 詳細を調べたところ、Cloud Functions内で 「gcloud」のコマンドが実行できず 、 「CDAP_ENDPOINT」が正常に取得できていないこと が原因でした。 対応策 上記の対応策として、 「gcloudコマンドを使わないコードに置き換える」 手段を取りました。 下記ライブラリリファレンスから代替ライブラリを探し、 「CDAP_ENDPOINT」を正しい形で取得できるよう コードを修正しました。 API と Python ライブラリ  |  Google Cloud cloud.google.com →CDAP_ENDPOINTの欲しい形は「https://…」 →怪しいライブラリを発見 →コピペして実行してみると、欲しい形「https://…」でCDAP_ENDPOINTが取得できた   実践 ファンクションとパイプラインが準備できたので、ここから実践に入ります。 まず、今回やりたいことをおさらいします。   Cloud Storageバケットの変更、更新をCloud FunctionsのCloud Storageトリガー出検知 Cloud FunctionsからData Fusionのパイプラインをキック Cloud Storage上のファイルをBigQueryテーブルに取り込む 仰々しく図式化しましたが、やりたいことはシンプルです。   今回使用する、データ取り込み先のテーブルは下記です。 また、GSCに配置する（テーブルに取り込む）CSVファイルの中身はこんな感じになっています。   それではファイルをバケットに配置してみます。  バケットにファイルを配置すると、 パイプラインが起動されました。（Provisioning状態） しばらく待つと、 パイプライン処理が完了し、BigQueryテーブルにレコードが追加されました。大成功です。   最後に 今回はCloud FunctionsのCloud Storageトリガーでバケットの変更を検知し、Data Fusionパイプラインを起動してみました。 バケット単位での変更検知ができるとなると、次にやりたいのは 「フォルダ・ファイル単位」の変更検知 ですよね。 実は、 フォルダ・ファイル単位の検知トリガーはまだ実装されていません 。（なんてことだ・・・） しかし、Cloud Functions内のコードに処理を寄せることで、 疑似的に実現することは可能 です。 こちらについては下記ブログで詳細な方法が紹介されているのでぜひご覧ください。（先を越されてた・・・） Cloud FunctionsのCloud Storageトリガーをフォルダレベルで指定したい！！ 先日、Dialogflow CXのAgentからのテストケース作成を自動化していて、「あるフォルダにファイルがアップロードされたら起動するCloud Functionsを作りたい」とふと思いました。そこで今回はバケットレベルで指定するCloud Storageトリガーをどうにかしてフォルダレベルで指定できないか調べてみました。 blog.usize-tech.com 2024.08.05

本記事は 夏休みクラウド自由研究 8/9付の記事です 。 はじめに Cato クラウドのネットワークに AWS や Azure などのパブリッククラウドを接続する場合、vSocket という仮想マシンイメージ形式で提供されるアプライアンスを利用するのが一般的ですが、IPsec やインターコネクト (AWS Direct Connect など) で接続することもできます。 vSocket は機能面や管理の手間という点で断然メリットが多いものの、アプライアンスの中身のソフトウェアがブラックボックスであるという点は、エンジニアとして少しだけ不安な要素でもあります。やはり通信は標準化されたプロトコルで行い、実際に見える形にして安心したいという思いがあります。 そこで、アプライアンスやルータ機器などを用いず、Linux サーバから IPsec で Cato クラウドに接続してみたいと思います。今回のブログは「 夏休みクラウド自由研究 」の一環ですので、自身の探求心に従い自由気ままにやっていきましょう。 今回試した構成 今回はシンプルに次のようなネットワーク構成で試しました。 Linux サーバはオフィスやパブリッククラウド上のネットワークの中にある想定で、次の前提・想定を置いています。 Linux サーバからインターネットに任意にアクセスできる Linux サーバは NAT (IPマスカレード) を行うルータの内側に存在し、グローバルIPアドレスを持たない ゲートウェイのグローバルIPアドレスは固定ではない 要するにこの Linux サーバは一般的なネットワーク環境にある1端末という位置づけです。このサーバと Cato PoP との間で IPsec 接続を試しました。 実際は AWS 環境上で環境を構築しており、Linux サーバをプライベートサブネットに配置し、NAT Gateway 経由でインターネットにアクセスするような構成としています。 Cato 側の設定 まずは CMA 上で IPsec 接続用の検証用 Site を作成します。 IPsec 接続に関する設計ポイントや具体的な設定方法は、 弊社の別記事 や Cato クラウドのドキュメント に詳しく記載されています。 【Catoクラウド】YAMAHAルータでIPsec接続 YAMAHAルータをCatoへIPsec接続する際の、Config例や注意点をご紹介します。 blog.usize-tech.com 2024.02.02 今回は次の設定で Site を作成しました。 Site Name : Linux IPsec Test Site Type : Branch Connection Type : IPsec IKEv2 Country : Japan Timezone : Tokyo City : Tokyo License Type, License : 適切なもの Native Range : 192.168.200.0/24 (Linux サーバの LAN のレンジ) 作成した Site の IPsec の設定は次のようにしました。 Connection Mode : Responder Only Authentication Identifier : FQDN Primary Destination Type : FQDN Cato FQDN : 自動で割り当てられる PoP Location : 空欄 Public Site Identifier : 自動で割り当てられる Private IPs : Cato, Site ともに空欄 (今回はBGPを利用しないため) Last-mile Bandwidth : License と同じ帯域幅 Primary PSK : 事前共有鍵 (64文字以下の任意の英数字) Secondary : 設定しない Init Message Parameters : 変更しない (Responder Mode では設定できない) Auth Message Parameters : 変更しない (全てデフォルトのまま) Routing : 設定しない 上記設定のポイントは3か所あります。 今回のネットワーク構成では NAT のせいで Cato PoP から Linux サーバに対して IPsec 接続を開始できないため、 Connection Mode を “Responder Only” とすることで Cato PoP から IPsec 接続を行わないようにしています。 Destination Type についてですが、”IPv4″ にすると IP Allocation 機能で確保した特定 PoP に紐づくIPアドレスを指定する必要があり、その PoP で大きな障害が起きてサービスダウンが発生すると IPsec 接続が行えなくなってしまいます。そうなっても困らないようにするために、通常は Secondary も指定して2本目の IPsec 接続を行って冗長化する必要があります。しかし、 Destination Type を “FQDN” を選択して PoP Location を空欄 にしておけば、PoP でサービスダウンが発生しても別の正常な PoP に接続するよう名前解決が自動で切り替わり、数分間の通信断を許容できるのであれば IPsec 接続を冗長化しなくても済むという特徴があるので、今回採用してみました。 Authentication Identifier は “IPv4″ (プライベートIPアドレスを指定する) としても問題はないのですが、Cato 側にピアのIPアドレスを意識させたくなかったため、”FQDN” としました。 Linux サーバの設定 OS・ネットワークの確認 今回は Linux サーバのOSとして、Red Hat Enterprise Linux 9 と互換性の高い AlmaLinux OS 9 を採用しました。 $ cat /etc/redhat-release AlmaLinux release 9.4 (Seafoam Ocelot) $ uname -a Linux alma 5.14.0-427.26.1.el9_4.x86_64 #1 SMP PREEMPT_DYNAMIC Wed Jul 17 15:51:13 EDT 2024 x86_64 x86_64 x86_64 GNU/Linux ネットワークインターフェースやルートテーブルなど、関連する設定は次のようになっていました。 $ 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 valid_lft forever preferred_lft forever 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc mq state UP group default qlen 1000 link/ether 06:0c:19:8a:6a:b5 brd ff:ff:ff:ff:ff:ff altname enp0s5 altname ens5 inet 192.168.200.132/28 brd 192.168.200.143 scope global dynamic noprefixroute eth0 valid_lft 2102sec preferred_lft 2102sec inet6 fe80::40c:19ff:fe8a:6ab5/64 scope link valid_lft forever preferred_lft forever $ ip route default via 192.168.200.129 dev eth0 proto dhcp src 192.168.200.132 metric 100 192.168.200.128/28 dev eth0 proto kernel scope link src 192.168.200.132 metric 100 $ ip rule 0: from all lookup local 32766: from all lookup main 32767: from all lookup default ネットワーク的にはインターフェースを1つだけ持つシンプルなマシンです。 Libreswan のインストール・設定 Linux サーバで IPsec 接続を行う場合、OSS ですと Libreswan, strongSwan, Openswan といったソフトウェアを使うことになりますが、今回は RHEL で採用されている Libreswan を使っていきます。 インストールは libreswan パッケージを dnf でインストールするだけです。 $ sudo dnf install libreswan $ ipsec --version Libreswan 4.12 次に Libreswan の設定ですが、 ipsec.conf(5) や ipsec.secrets(5) のマニュアルを参考に次の内容で作成し、/etc/ipsec.d/ ディレクトリに配置しました。 $ sudo vim /etc/ipsec.d/cato.conf $ sudo cat /etc/ipsec.d/cato.conf conn cato left=192.168.200.132 leftid=@XXXXXXXXXX.YYYY.catonetworks.com leftnexthop=192.168.200.129 right=ZZZZZZZZZZ.ipsec.catonetworks.net rightid=@ZZZZZZZZZZ.ipsec.catonetworks.net leftsubnet=0.0.0.0/0 rightsubnet=0.0.0.0/0 ipsec-interface=yes encapsulation=yes authby=secret ikev2=insist auto=start $ sudo vim /etc/ipsec.d/cato.secrets $ sudo cat /etc/ipsec.d/cato.secrets @XXXXXXXXXX.YYYY.catonetworks.com @ZZZZZZZZZZ.ipsec.catonetworks.net : PSK "事前共有鍵" $ sudo chmod 600 /etc/ipsec.d/cato.secrets left は Linux サーバ側、right は Cato PoP 側を表す設定項目です。また、”XXXXXXXXXX.YYYY.catonetworks.com” と “ZZZZZZZZZZ.ipsec.catonetworks.net” は、Cato 側の IPsec の設定で自動で割り当てられた Public Site Identifier および Cato FQDN の値です。 left や leftnexthop には Linux サーバのプライベートIPアドレスやゲートウェイのIPアドレスを指定しています。 今回は IPsec 接続の認証IDとして FQDN を利用しますので、FQDN の先頭に “@” を付けた文字列を leftid や rightid に指定する必要がありました。 IPsec にはポリシーベースとルートベースの2種類がありますが、ルートベースのほうが扱いやすいため、そうするため leftsubnet, rightsubnet, ipsec-interface を上記のように指定しています。また、Linux サーバは NAT (IPマスカレード) を行うルータの内側に存在するので、NAT トラバーサルを有効にするため “encapsulation=yes” としています。 今回の検証において、ちゃんと動作する Libreswan の設定を作るのが一番大変でした…。 IPsec 接続 Libreswan の設定を配置したら、IPsec 接続をして確認していきます。 その前に、Cato PoP の接続先の FQDN を名前解決してみると次のような結果となりました。 $ dig +noall +answer A ZZZZZZZZZZ.ipsec.catonetworks.net ZZZZZZZZZZ.ipsec.catonetworks.net. 30 IN A 150.195.218.109 150.195.218.109 というIPアドレスは東京にあるいずれかの PoP のものですね。Socket や Cato Client による PoP 接続とは異なり、いくつかの接続先の候補が提示されて近いものを選択するという仕組みではないようです。Site の設定で場所を東京としていましたので、その設定をもとに近い PoP が自動で選択されたものと思います。 DNS レコードの TTL は30秒となっており、IPsec の接続先が切り替わったときに素早く反映されるようになっていますね。 それでは IPsec 接続を開始してみます。systemctl で ipsec サービスを起動すれば接続が行われます。 $ sudo systemctl start ipsec 無事にうまく接続されれば、ipsec1 というインターフェースが作成されているはずです。 $ 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 valid_lft forever preferred_lft forever 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc mq state UP group default qlen 1000 link/ether 06:0c:19:8a:6a:b5 brd ff:ff:ff:ff:ff:ff altname enp0s5 altname ens5 inet 192.168.200.132/28 brd 192.168.200.143 scope global dynamic noprefixroute eth0 valid_lft 2987sec preferred_lft 2987sec inet6 fe80::40c:19ff:fe8a:6ab5/64 scope link valid_lft forever preferred_lft forever 3: ip_vti0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN group default qlen 1000 link/ipip 0.0.0.0 brd 0.0.0.0 5: ipsec1@eth0: <NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000 link/none inet6 fe80::4e73:f3e6:521e:1678/64 scope link stable-privacy valid_lft forever preferred_lft forever journalctl で接続時のログも見てみましたが、Child SA も確立して問題なく接続できているようです。 Jul 29 17:19:34 alma pluto[1480]: "cato": added IKEv2 connection Jul 29 17:19:34 alma pluto[1480]: listening for IKE messages Jul 29 17:19:34 alma pluto[1480]: Kernel supports NIC esp-hw-offload Jul 29 17:19:34 alma pluto[1480]: adding UDP interface eth0 192.168.200.132:500 Jul 29 17:19:34 alma pluto[1480]: adding UDP interface eth0 192.168.200.132:4500 Jul 29 17:19:34 alma pluto[1480]: adding UDP interface lo 127.0.0.1:500 Jul 29 17:19:34 alma pluto[1480]: adding UDP interface lo 127.0.0.1:4500 Jul 29 17:19:34 alma pluto[1480]: adding UDP interface lo [::1]:500 Jul 29 17:19:34 alma pluto[1480]: adding UDP interface lo [::1]:4500 Jul 29 17:19:34 alma pluto[1480]: loading secrets from "/etc/ipsec.secrets" Jul 29 17:19:34 alma pluto[1480]: loading secrets from "/etc/ipsec.d/cato.secrets" Jul 29 17:19:34 alma pluto[1480]: "cato" #1: initiating IKEv2 connection Jul 29 17:19:34 alma pluto[1480]: "cato" #1: sent IKE_SA_INIT request to 150.195.218.109:500 Jul 29 17:19:34 alma pluto[1480]: "cato" #1: received anti-DDOS COOKIE response, resending IKE_SA_INIT request with COOKIE payload Jul 29 17:19:34 alma pluto[1480]: "cato" #1: sent IKE_SA_INIT request to 150.195.218.109:500 Jul 29 17:19:34 alma pluto[1480]: "cato" #1: sent IKE_AUTH request {cipher=AES_GCM_16_256 integ=n/a prf=HMAC_SHA2_256 group=DH19} Jul 29 17:19:34 alma pluto[1480]: "cato" #1: initiator established IKE SA; authenticated peer using authby=secret and ID_FQDN '@ZZZZZZZZZZ.ipsec.catonetworks.net' Jul 29 17:19:34 alma pluto[1480]: "cato" #2: route-client output: leftsubnet == rightsubnet = 0.0.0.0/0 cannot add route Jul 29 17:19:34 alma pluto[1480]: "cato" #2: initiator established Child SA using #1; IPsec tunnel [0.0.0.0-255.255.255.255:0-65535 0] -> [0.0.0.0-255.255.255.255:0-65535 0] {ESPinUDP=>0x42a73e98 <0x32b41687 xfrm=AES_GCM_16_256-NONE NATD=150.195.218.109:4500 DPD=passive} Jul 29 17:19:34 alma pluto[1480]: netlink_expire got message with length 116 < 232 bytes; ignore message Jul 29 17:19:34 alma pluto[1480]: netlink_expire got message with length 116 < 232 bytes; ignore message Jul 29 17:19:34 alma pluto[1480]: netlink_expire got message with length 116 < 232 bytes; ignore message Jul 29 17:19:34 alma pluto[1480]: netlink_expire got message with length 60 < 232 bytes; ignore message ネットワーク関連の設定も見てみると、ポリシーベースルーティングにより IPsec の通信は50番のルーティングテーブルを参照し、Cato PoP 宛の通信は Linux サーバがあるネットーワークのゲートウェイ経由で行われるようになっていました。 $ ip route default via 192.168.200.129 dev eth0 proto dhcp src 192.168.200.132 metric 100 192.168.200.128/28 dev eth0 proto kernel scope link src 192.168.200.132 metric 100 $ ip rule 0: from all lookup local 100: from all fwmark 0x1 lookup 50 32766: from all lookup main 32767: from all lookup default $ ip route show table 50 150.195.218.109 via 192.168.200.129 dev eth0 もしも ipsec1 というインターフェースが作られていなかった場合、設定の不備や不整合により IPsec 接続に失敗しています。この場合、設定を変更して再接続を試してみるわけですが、CMA 上の設定変更が反映されるまで5分程度時間がかかったり、接続失敗を何度も繰り返していると一定期間は接続拒否されたりするため、試行錯誤が大変でした…。 ルーティング変更 IPsec 接続に成功したら、次はルーティングを変更して Cato 側にトラフィックが流れていくようにします。 デフォルトルートを IPsec のインターフェースに向けつつ、Linux サーバがある LAN やリンクローカルのネットワーク宛のトラフィックは Cato 側に流れないようにしました。 $ sudo ip route add 192.168.200.0/24 via 192.168.200.129 dev eth0 # LAN $ sudo ip route add 169.254.0.0/16 via 192.168.200.129 dev eth0 # リンクローカル $ sudo ip route add default dev ipsec1 $ ip route default dev ipsec1 scope link default via 192.168.200.129 dev eth0 proto dhcp src 192.168.200.132 metric 100 169.254.0.0/16 via 192.168.200.129 dev eth0 192.168.200.0/24 via 192.168.200.129 dev eth0 192.168.200.128/28 dev eth0 proto kernel scope link src 192.168.200.132 metric 100 これでOKと言いたいところですが、これではまだ Cato 経由でのインターネットとの通信が期待通り動作しませんでした。また、この状態では Cato PoP 側からの IPsec 接続の生存確認も失敗するため、すぐに接続が切れて再接続が必要となってしまいます。 rp_filter 変更 前項のルーティング変更後、インターネット上のサーバ (Google Public DNS) に対して ping を打っても成功せず、tcpdump でパケットキャプチャを眺めてみると次の結果となりました。 17:22:25.383815 ipsec1 Out IP 192.168.200.132 > 8.8.8.8: ICMP echo request, id 1, seq 1, length 64 17:22:25.383858 eth0 Out IP 192.168.200.132.4500 > 150.195.218.109.4500: UDP-encap: ESP(spi=0x42a73e98,seq=0x2), length 120 17:22:25.388051 eth0 In IP 150.195.218.109.4500 > 192.168.200.132.4500: UDP-encap: ESP(spi=0x32b41687,seq=0x2), length 120 17:22:26.442569 ipsec1 Out IP 192.168.200.132 > 8.8.8.8: ICMP echo request, id 1, seq 2, length 64 17:22:26.442606 eth0 Out IP 192.168.200.132.4500 > 150.195.218.109.4500: UDP-encap: ESP(spi=0x42a73e98,seq=0x3), length 120 17:22:26.445991 eth0 In IP 150.195.218.109.4500 > 192.168.200.132.4500: UDP-encap: ESP(spi=0x32b41687,seq=0x3), length 120 ICMP パケットは ipsec1 インターフェースに向けて送信 (1,4行目) され、eth0 インターフェースで IPsec のパケット (UDP でカプセル化された ESP パケット) が Cato PoP に向けて送信 (2,5行目) されています。また、おそらく ping の戻りの ICMP パケットをカプセル化した IPsec のパケットを Cato PoP から受信 (3,6行目) しているようですが、ICMP echo reply は受信できていません。 eth0 インターフェースで IPsec パケットを受信しているのに、ipsec1 インターフェースからカプセル化を解除したパケットが出てきていないということは、受信した IPsec パケットが Linux カーネルで破棄され、Libreswan のプロセスに渡っていないということです。思い当たる心当たりとしては rp_filter ですね。 rp_filter - INTEGER 0 - No source validation. 1 - Strict mode as defined in RFC3704 Strict Reverse Path Each incoming packet is tested against the FIB and if the interface is not the best reverse path the packet check will fail. By default failed packets are discarded. 2 - Loose mode as defined in RFC3704 Loose Reverse Path Each incoming packet's source address is also tested against the FIB and if the source address is not reachable via any interface the packet check will fail. Current recommended practice in RFC3704 is to enable strict mode to prevent IP spoofing from DDos attacks. If using asymmetric routing or other complicated routing, then loose mode is recommended. The max value from conf/{all,interface}/rp_filter is used when doing source validation on the {interface}. Default value is 0. Note that some distributions enable it in startup scripts. ※ https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt より引用 端的に説明すると、rp_filter というカーネルパラメータが1の場合、FIB (どのIPアドレス宛のパケットをどのインターフェースから送信するかを示すテーブル) によって選択されるインターフェースと、パケットを受信したインターフェースが異なると、パケットを破棄するというものです。 実際、eth0 インターフェースの rp_filter の値は1でした。 $ sudo sysctl -a | grep "\.rp_filter" net.ipv4.conf.all.rp_filter = 0 net.ipv4.conf.default.rp_filter = 1 net.ipv4.conf.eth0.rp_filter = 1 net.ipv4.conf.ip_vti0.rp_filter = 1 net.ipv4.conf.ipsec1.rp_filter = 1 net.ipv4.conf.lo.rp_filter = 1 FIB を参照すると Cato PoP (150.195.218.109) から来るパケットはデフォルト経路により ipsec1 インターフェースで受信されるべきですが、eth0 インターフェースで受信しているため破棄されているのですね。 このような場合、Cato PoP のIPアドレス宛の通信を eth0 インターフェースから送信する経路をデフォルトのルーティングテーブルに追加 ( “sudo ip route add 150.195.218.109/32 via 192.168.200.129 dev eth0” ) すれば解決できますが、Cato PoP のIPアドレスを明確に意識しなければならなくなるため、この方法は避けたいです。 そこで、rp_filter を緩めることにしました。 $ sudo sysctl net.ipv4.conf.eth0.rp_filter=2 これで ping も正常に通るようになりました。 $ ping 8.8.8.8 PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data. 64 bytes from 8.8.8.8: icmp_seq=1 ttl=122 time=3.63 ms 64 bytes from 8.8.8.8: icmp_seq=2 ttl=122 time=3.55 ms 64 bytes from 8.8.8.8: icmp_seq=3 ttl=122 time=3.41 ms ^C --- 8.8.8.8 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2004ms rtt min/avg/max/mdev = 3.411/3.531/3.634/0.091 ms 17:23:07.224050 ipsec1 Out IP 192.168.200.132 > 8.8.8.8: ICMP echo request, id 2, seq 1, length 64 17:23:07.224087 eth0 Out IP 192.168.200.132.4500 > 150.195.218.109.4500: UDP-encap: ESP(spi=0x42a73e98,seq=0x5), length 120 17:23:07.227627 eth0 In IP 150.195.218.109.4500 > 192.168.200.132.4500: UDP-encap: ESP(spi=0x32b41687,seq=0x5), length 120 17:23:07.227664 ipsec1 In IP 8.8.8.8 > 192.168.200.132: ICMP echo reply, id 2, seq 1, length 64 17:23:08.225956 ipsec1 Out IP 192.168.200.132 > 8.8.8.8: ICMP echo request, id 2, seq 2, length 64 17:23:08.225994 eth0 Out IP 192.168.200.132.4500 > 150.195.218.109.4500: UDP-encap: ESP(spi=0x42a73e98,seq=0x6), length 120 17:23:08.229374 eth0 In IP 150.195.218.109.4500 > 192.168.200.132.4500: UDP-encap: ESP(spi=0x32b41687,seq=0x6), length 120 17:23:08.229454 ipsec1 In IP 8.8.8.8 > 192.168.200.132: ICMP echo reply, id 2, seq 2, length 64 17:23:09.227701 ipsec1 Out IP 192.168.200.132 > 8.8.8.8: ICMP echo request, id 2, seq 3, length 64 17:23:09.227736 eth0 Out IP 192.168.200.132.4500 > 150.195.218.109.4500: UDP-encap: ESP(spi=0x42a73e98,seq=0x7), length 120 17:23:09.231011 eth0 In IP 150.195.218.109.4500 > 192.168.200.132.4500: UDP-encap: ESP(spi=0x32b41687,seq=0x7), length 120 17:23:09.231065 ipsec1 In IP 8.8.8.8 > 192.168.200.132: ICMP echo reply, id 2, seq 3, length 64 良い感じです。 MTU 変更 IPsec 接続による作られた ipsec1 インターフェースの MTU は 1500 となっていました。 IPsec 接続時のログを見ると “AES_GCM_16_256” アルゴリズムで接続されており、今回のインターネット回線の MTU は 1500 ですので、IPsec のインナーパケットの最大長は 1438 バイトのはずです。 ※計算式 : rounddown((1500 – 20 – 8 – 8 – 8 – 16) / 4, 0) * 4 – 2 回線MTU : 1500 IPヘッダ長 : 20 (IPv4) UDPヘッダ長 : 8 (NATトラバーサル用) ESPヘッダ長 : 8 ESP初期化ベクトル : 8 (AES-GCM) ESP認証データ : 16 (AES-GCM) ESPトレーラ : 2 ブロックサイズ : 4 実際、1438 バイトのパケット (ペイロードが 1410 バイトの ping) は送信でき、1439 バイトのパケットは送信できませんでした。 17:26:54.130174 ipsec1 Out IP 192.168.200.132 > XXX.XXX.XXX.XXX: ICMP echo request, id 13, seq 1, length 1418 17:26:54.130210 eth0 Out IP 192.168.200.132.4500 > 150.195.218.109.4500: UDP-encap: ESP(spi=0x57179fd4,seq=0x1f), length 1472 17:26:54.138973 eth0 In IP 150.195.218.109.4500 > 192.168.200.132.4500: UDP-encap: ESP(spi=0xb3a32ad4,seq=0x22), length 1416 17:26:54.138973 eth0 In IP 150.195.218.109.4500 > 192.168.200.132.4500: UDP-encap: ESP(spi=0xb3a32ad4,seq=0x23), length 112 17:26:54.139047 ipsec1 In IP XXX.XXX.XXX.XXX > 192.168.200.132: ICMP echo reply, id 13, seq 1, length 1360 17:26:54.139047 ipsec1 In IP XXX.XXX.XXX.XXX > 192.168.200.132: ip-proto-1 17:26:58.465889 ipsec1 Out IP 192.168.200.132 > XXX.XXX.XXX.XXX: ICMP echo request, id 14, seq 1, length 1419 17:26:58.465922 eth0 Out IP 192.168.200.132.4500 > 150.195.218.109.4500: UDP-encap: ESP(spi=0x57179fd4,seq=0x21), length 1476 17:26:58.466157 eth0 In IP 192.168.200.1 > 192.168.200.132: ICMP 150.195.218.109 unreachable - need to frag (mtu 1500), length 36 そのため、ipsec1 インターフェースの MTU を 1438 に変更しておきましょう。 $ sudo ip link set dev ipsec1 mtu 1438 なお、1438 バイトのパケットは送信できているものの、戻りの 1438 バイトのパケットはIPフラグメント化されて受信しています。これは過去の検証の通り、Cato PoP 経由でのインターネットとの通信の MTU が 1383 であることと一致していました。 Cato Client を用いた通信における MTU の調査 Cato クラウドの PoP 経由で通信する場合の MTU の値を調査・検証してみました。 blog.usize-tech.com 2023.11.30 接続確認 CMA 上での接続確認 CMA 上では、Site 画面で今回の IPsec 接続用の Site の状態を確認できますが、無事に Connected となっており、Tokyo PoP に接続されていました。新しい Tokyo_DC2 や Tokyo_DC3 PoP に接続されるとは限らないようです。 また、Site の IPsec の設定画面で「Connection Status」ボタンを押せば IPsec 接続の状態を確認できます。 この内容に特に見どころはありませんが、IPsec 接続で利用されている暗号スイートぐらいは確認しておくと良いですね。 さらに、Events 画面を見てみると、IPsec 接続が成功したときのログや、接続確認時の ICMP (ping) のログもちゃんとイベントとして記録されていました。(接続確認より前に NTP の通信も行われていました。) CMA で見れる内容としては問題なさそうです。 Linux サーバ側の接続確認 Linux サーバからインターネットに通信してみて、ちゃんと Cato PoP を通っているのか確認してみます。 今回は「確認くん」の Web サイトにアクセスし、インターネット側から見えるグローバルIPアドレスを確認してみました。 $ curl https://www.ugtop.com/spill.shtml <!DOCTYPE html> <html lang="ja"> (中略) <th>あなたのＩＰアドレス(IPv4)</th> <td><font size=+2 color=blue>150.195.218.108</font></td> <tr> <th>ゲートウェイの名前</th> <td><font size=+1 color=red>(none)</font></td><tr> (後略) 自マシンのIPアドレスは 150.195.218.108 として見えているようであり、これは Cato の東京の PoP のものですので、問題なさそうですね。 その後 CMA で Events を見てみると、もちろん上記のアクセスも記録されていました。 まとめ Linux サーバから Cato クラウドに問題なく IPsec 接続を行えることが確認できました。IPsec は標準化されたプロトコルですし、流れるパケットも手軽に見れるので良い感じです。 vSocket を用意したりクラウドの IPsec サービスを利用したりしなくても、軽いノリで Cato クラウドに接続できるのも良い点です。Cato クラウドを Pooled ライセンスで利用しているのであれば、今回のように気軽に Site を立てて利用するといったこともできますので、ライセンスは余剰分を確保しておきたいですね。 ただし、今回はあくまでも IPsec 接続できるかを検証したものであり、本番環境用途で利用するためには次のようなことも追加で検証・構築する必要があります。 同じネットワーク上の他のマシンから今回の Linux サーバを介して Cato クラウドに接続する IPsec 接続時に手動で行っている内容 (ルーティングや MTU の変更) を自動で行う Linux サーバ側からも IPsec 接続の生存確認を行い、生存が確認できなければ自動で再接続する 高い可用性が必要なら、IPsec 接続を冗長化 (Secondary 接続や Linux サーバを複数用意) する この中でも4つ目は検証も構築も大変なので、本番環境用途を考えるなら間違いなく vSocket やパブリックラウドが提供する IPsec サービスなどを利用することを推奨します。vSocket や IPsec サービスなどを利用できないような環境で Cato クラウドに接続する手段の1つとして本記事を参考にしていただければと思います。

本記事は 夏休みクラウド自由研究 8/8付の記事です 。 AWS/Azure等のパブリッククラウドをCatoクラウドへ接続する方法には、以下の3つがありますが、このうち最も手軽で多く利用されている方法がvSocketです。   接続方法 対象環境 主な利用シーン 1 vSocket AWS/Azure/VMware ESXi 通常の場合 2 Cloud Interconnect (旧名称:Cross Connect) AWS/Azure/GCP/Oracle Cloud 高スループット・低遅延な通信を必要とする場合 3 IPSec すべての環境 1および2が利用できない・用途にマッチしない場合 vSocketは、VPC/VNET内に仮想マシンを構築しSocketとして動作させるもので、物理Socketと同等の機能が利用できます。AWS/Azure環境を物理的な拠点と同等にCatoクラウドへ接続でき、とても便利です。 実際のご利用環境では、複数のAWS VPC や Azure VNetが存在することがほとんどかと思います。このような場合のCatoクラウドへの接続構成について、よくご質問をいただくため、本記事にて構成例をご紹介します。 AWS 複数VPCを接続する際の構成 AWSで複数VPCを接続する方法としては、以下2つの構成パターンがあります。 パターン1 VPCごとにvSocketを構築する 各VPCにvSocketを作成し、それぞれCatoクラウドに接続する構成です。 メリット 各VPCが完全に独立してCatoクラウドへ接続します。Catoクラウド上でも、それぞれのVPCが独立したSiteとして表示されますので、通信量・通信内容の確認や、管理がSiteごと(=VPCごと)に可能です。 デメリット 接続するVPCごとに、Catoクラウドライセンスが必要です。図の例ですと、3つのVPCに対し合計3つのSiteライセンス契約が必要です。また、VPCごとにvSocketの構築が必要です。 パターン2 複数VPCをTransit Gatewayで接続し、1つのVPCからCatoへ接続する Transit Gatewayを構築してVPCを相互接続し、1つのVPCのみCatoクラウドへ接続する構成です。 なお、VPC同士をVPC Peeringで接続する構成は利用できません。AWSのVPC Peeringは、接続先のVPCより先のNWには通信できないという制約(2hop制限)があるためです。 メリット Catoクラウドのライセンス契約は1Site分のみ必要となります。またvSocketの構築も1セットのみです。 デメリット Catoクラウドへのすべての通信が、Transit Gateway および vSocketのVPCを経由することとなります。各VPCのセキュリティ要件上問題ないか、ご検討が必要な場合があるかもしれません。 また、この構成では、Catoクラウド上ではすべてのVPCがあわせて1つのSiteとして扱われますので、VPCごとの通信量を確認するなどができません。Siteご契約帯域も、すべてのVPCを合算した通信量にてご契約頂く必要がございます。 もしvSocketや、そのVPC内に障害が発生した場合、すべてのVPCでCatoクラウドへの通信が不可となります。 パターン2の構成の詳細 Transit Gatewayを使用する場合、各SubnetとTransit Gatewayのルートテーブルで、もれなくルートの設定が必要です。設定のポイントを上記の図にまとめましたので、ご参照ください。 構築後、通信が通らない場合、よくある原因に以下の2つがあります。うまく行かない場合は見直してみてください。 上記図内の①～③のルートテーブルに、ルートが足りていない。※特にCatoモバイルユーザのルートを設定し忘れがちです 通信先のAWSリソース(EC2等)で、セキュリティグループやOSのFirewallが設定されていて、CatoのSiteやモバイルユーザのIPアドレスレンジからの通信が許可されていない。 Transit Gatewayを使用した構成については、Cato Networksのナレッジベースにも解説がありますので、合わせてご参照ください。 How to Implement Cato vSocket in AWS Multiple VPCs Environment | Cato Knowledge Base Azure 複数VNetを接続する際の構成 Azureで複数のVNetをCatoへ接続したい場合、同様に2つのパターンがあります。 パターン1 VNetごとにvSocketを構築する AWSの例と同様です。VNetごとに個別に管理できますが、SiteライセンスがVNetの数だけ必要です。 パターン2 複数VNetをVNet Peeringで接続し、1つのVNetからCatoへ接続する Azureの場合は、VNet PeeringでVNet間を接続します。 メリット・デメリットはAWSと同様です。 パターン2の詳細 複数VNetを接続する場合、Peeringを作成の上で、各Subnetのルートテーブルでルートの設定が必要です。設定のポイントを上記の図にまとめましたので、ご参照ください。 構築後、通信が通らない場合、よくある原因はAWSと同様です。サーバが所属するルートテーブルや、セキュリティグループを確認します。また、Peeringのオプション「Allow forwarded traffic」が有効になっているかも合わせて確認します。 Peeringを使用した構成については、Cato Networksのナレッジベースにも解説がありますので、合わせてご参照ください。 How to Use a vSocket in Azure Multiple VNets Environment | Cato Knowledge Base まとめ AWS、Azureともに、複数環境を個別にCatoクラウドへ接続する方法と、まとめて接続する方法があります。メリット・デメリットを確認の上、接続方法をご選択ください。 もちろん、環境分離したいVPC/VNetは個別に接続し、その他はまとめて接続するといった構成も可能です。 SCSKでは、Catoクラウドとパブリッククラウドの両方に精通したエンジニアが多数在籍しており、最適な構成のご提案が可能です。お悩みの点などありましたら、ぜひご相談ください。

Prisma Cloudは、クラウド環境のセキュリティとコンプライアンスを一元管理するツールで、リアルタイムの脅威検出やリソースのチェックが可能です。 今回は、クラウドアカウントをアカウントグループに追加し、重要度の高いポリシー違反を通知するためのアラートルールを設定する手順を紹介します。また、他の運用例についても簡単に触れます。 用語の説明 設定手順の説明の前に、アカウントグループとアラートルールの簡単な説明をします。 アカウントグループとは アカウントグループ は、複数のクラウドアカウントをまとめて管理するための論理的なグループです。これにより、複数の部門や事業単位、開発や本番などの環境単位でのアカウント管理を行うことができます。 アラートルールとは？ アラートルール は、特定の条件が満たされた場合に通知を送信するための設定です。これにより、異常な活動や特定のポリシーやコンプライアンス違反を監視することができます。条件の設定では、特定のポリシーセットを選択する方法のほか、リソースタグによって識別された特定のクラウドリソースにルールを絞り込むことも可能です。 アカウントグループとアラートルールの関係 クラウドアカウントとアカウントグループ、アラートルールの関係は以下のようになります。 ・同じクラウドアカウントを複数のアカウントグループに含めることができます。 ・複数のアラートルールをアカウントグループに適用できます。 ・複数のアカウントグループに同じアラートルールを適用できます。 PrismaCloudでの設定方法 アラートルールをアカウントグループに適用することで、選択したアカウントグループで発生した特定のポリシールール違反の通知だけを受け取るような運用をすることができます。 以下に、例としてクラウドアカウントをアカウントグループに追加し、重要度の高いポリシー違反を通知するためのアラートルールを設定し、作成したアカウントグループに適用する手順を紹介します。 アカウントグループの作成とクラウドアカウントのアタッチ 1). Prisma Cloudアカウントにログインし、「Settings」を押下します。 2).　左ペインの「Account Groups」を選び、「新しいアカウントグループを作成」を押下します。 3). 以下項目を入力し、「Save」を押下します。 Name：アカウントグループ名 Cloud Account：アタッチするクラウドアカウント 4). 一覧にアカウントグループが追加されたことを確認したら完了です。 アラートルールの作成とアカウントグループへの適用 1). Alertsページの「View Alert Rules」を押下します。 2). 「Add Alert Rule」を押下します。 3). 以下項目を入力し、「Next」を押下します。 Name：アラートルール名 AUTOMATIONS (OPTIONAL)：今回はメール通知させるので、「Alert Notifications」を選択します 4). 以下項目を入力し、「Next」を押下します。 Select the account ~ this alert rule：「Account Groups」を選択します Account Groups：先ほど作成したアカウントグループを選択します 5). 監視するポリシーを選択します。今回は重要度がHighまたはCriticalのポリシーをすべて選択するためにフィルター機能を使います。 「Add filter」でPolicy Severityを選択します。 6). Policy Severity横の「Select」を押下し、Highを選択します、同様にCriticalを選択します。 7). 「Include all ~ filter criteria」にチェックして、フィルター条件に合致するすべてのポリシーを選択し、「Next」を押下します。 8).  以下項目を入力し、「Next」を押下します。 Emails：通知先のメールアドス Enable：チェックします 9). アラートルール名やアカウントグループ名、フィルターしたポリシー、「Configured Channels」にメールのマークが表示されているかなどの設定値を確認し、「Save」を押下します。 10). アラートルールの作成が成功したメッセージを確認したら、PrismaCloudの設定は完了となります。 PrismaClodでアラートの確認をしてみる 実際に確認してみましょう。 1). アラートルールの設定後、該当ポリシーの違反が検知されると設定した連絡先に以下のようなメッセージが送信されます。 検知アラート数や対応状況、ポリシー名やポリシー違反したリソースなどがこのメッセージからわかりますが、赤枠の検知数を押下することでPrisma Cloud に飛び、詳細を確認できます。 2). このようにPrisma Cloud コンソールのAlertsページに遷移し、該当アラートが表示されますので、Alert IDを押下することでアラートの概要や推奨される対応などを参照できます。 他の運用例の紹介 例1: 環境ごとのアカウントグループとアラートルール 開発、テスト、本番環境に応じたアカウントグループを作成し、それぞれに適したアラートルールを設定します。 開発環境 : 緩やかなポリシー設定。 本番環境 : 厳格なポリシー設定。 例2: 地域ごとのセキュリティ管理 異なる地域のクラウドアカウントをグループ分けし、地域の規制に応じたセキュリティポリシーとアラートルールを適用します。 EUリージョン : GDPRに準拠したアラートルールを設定。 まとめ 今回は、Prisma Cloudにおいてアカウントグループとアラートルールを使用して、セキュリティ監視を強化する基本的な設定方法を紹介しました。これにより、効率的かつ一貫したセキュリティ運用が可能になります。 この記事でPrisma Cloudの導入イメージや使用感などが少しでも伝われば嬉しいです。 Prisma Cloudにはアラートの可視化など他にもクラウド環境設定のセキュリティチェックに便利な機能がありますので、他の記事でまたご紹介できればと思っています。 また、当社では、複数クラウド環境の設定状況を自動でチェックし、設定ミスやコンプライアンス違反、異常行動などのリスクを診断するCSPMソリューションを販売しております。ご興味のある方はお気軽にお問い合わせください。リンクはこちら↓ マルチクラウド設定診断サービス with CSPM｜ SCSK株式会社 マルチクラウド環境のセキュリティ設定リスクを手軽に確認可能なスポット診断サービスです。独自の診断レポートが、運用上の設定ミスや設計不備、クラウド環境の仕様変更などで発生し得る問題を可視化し、セキュリティインシデントの早期発見に役立ちます。 www.scsk.jp

こんにちは。SCSKの山口です。 今回は、BigQueryで ウィンドウ関数（分析関数） を使ってデータを集約してみたいと思います。 テーブル全体ではなく、 特定の実行範囲（パーティション）での処理 が実行できる便利な機能です。ぜひご覧ください。   ウィンドウ関数とは（イメージ） ウィンドウ関数とは、一言で言うと「行のグループ単位で計算を行い、 行ごとに一つの結果を返してくれる 」ものです。 似た言葉で、「集約関数」がありますが、ウィンドウ関数の有無で違う挙動を示します。 おそらくこの説明では？？？な方が多いと思うので、集約関数を使用する際、ウィンドウ関数がある場合とない場合に分けて図で説明します。   以下、 テスト結果のクラスごとの平均点数を算出する例 で説明します。 集約関数のみ 集約関数（avg）のみを使用した場合は上図のようになります。 テーブル全体に対して、「クラス」カラムでGroup byし、「クラス」ごとに平均点を算出して結果を返します。 上図を見てわかる通り、「グループ（クラス）ごとの出力」となり、「氏名」の情報は欠落します。 ウィンドウ関数＋集約関数 ウィンドウ関数と集約関数を組み合わせた場合は上図のようになります。 集約関数のみの場合と異なり、 行ごとの出力 となっています。 また、 元テーブルの情報を欠落させることなく出力 することも可能です。 実践：ウィンドウ関数を使った集計 ここから実際にウィンドウ関数を使用してデータを分析してみます。 利用データ 今回は、下記情報を持つテーブルデータを使用してウィンドウ関数を使ってみます。 ユーザID ユーザ名 アクション タイムスタンプ やりたいこと 今回は上記テーブルから、 各ユーザが実行した最終アクション を、 元テーブル情報（カラム）を維持したまま 抽出します。 集約関数を使用する場合と、使用しない場合の2パターンで抽出してみます。 せっかくなので 「Geminiを使用してSQLを生成」 してみます。 下記の鉛筆のようなマークをクリックし、実現したい内容を書くとSQLを生成してくれます。 Gemini in BigQuery の Gemini の概要  |  Gemini for Google Cloud Gemini in BigQuery で利用できる機能の概要。 cloud.google.com ①集約関数のみ Geminiが生成したSQLは下記です。 -- 分析関数を使わずに、user_action_allテーブルから、各userIDの最新のデータを全カラムSELECT SELECT user_action_all.* FROM `evocative-entry-277709.yamaguchi_test.user_action_all` AS user_action_all INNER JOIN ( SELECT   userID,   MAX(timestamp) AS max_timestamp FROM   `evocative-entry-277709.yamaguchi_test.user_action_all` GROUP BY   1 ) AS latest_user_action ON user_action_all.userID = latest_user_action.userID   AND user_action_all.timestamp = latest_user_action.max_timestamp; 下記2データをINNER JOINすることで実現しています。 テーブル全量 userIDでGroup byし、MAX関数でtimestampを集約したデータ 上記SQLでも、抽出したいデータを得ることはできました。（ちょっとメンドクサイSQLですが。） ②ウィンドウ関数＋集約関数 Geminiが生成したSQLは下記です。 -- 分析関数を使って、user_action_allテーブルから、各userIDの最新のデータを全カラムSELECT SELECT   * FROM   (     SELECT         *,         ROW_NUMBER() OVER(PARTITION BY userID ORDER BY timestamp DESC) AS rn       FROM         `evocative-entry-277709.yamaguchi_test.user_action_all`   ) AS t   WHERE t.rn = 1; 先ほどよりスッキリしたSQLですが、 実はさらにスッキリさせることができます（詳細は後述） 。 SELECT *, ROW_NUMBER() OVER(PARTITION BY userID ORDER BY timestamp DESC) AS rn FROM `evocative-entry-277709.yamaguchi_test.user_action_all` QUALIFY   rn=1 実行するとこちらも抽出したいデータを得ることができました。 よく見ると、SQLに見慣れない一文があります。 ROW_NUMBER() OVER(PARTITION BY userID ORDER BY timestamp DESC) AS rn この部分です。 ここがウィンドウ関数の正体 です。 ここからは章を分けて、ウィンドウ関数について詳細を見ていきます。   ウィンドウ関数とは（詳細） 先ほどはウィンドウ関数について、図を使ってイメージを把握していただきましたが、ここからもう少し詳しく見ていきます。 ウィンドウ関数の「ウィンドウ」は、 結果セットの中の特定の一部分 のことを指します。 下図のような、 「窓越しに風景の一部を見る」 絵を想像していただけるとわかりやすいかと思います。 またまたイメージの話になってしまいましたが、本題に移ります。 ウィンドウ関数を使用するには、 「OVER句」 が必要になります。このOVER句内の 3要素 によって、ウィンドウを細かくコントロールすることができます。 パーティション：データを分割 オーダー：パーティション内の結果に順序付け フレーム：現在の行に対して相対的に移動するスライディングウィンドウフレームを指定可能（※今回は省略） 今回、実践で使用したデータに当てはめてみます。 ROW_NUMBER() OVER(PARTITION BY userID ORDER BY timestamp DESC) AS rn PARTITION BY userID：userIDごとにデータを分割 ORDER BY timestamp DESC：userIDごとのデータをtimestampで降順にソート ここまでで、下記のデータが取得されます。 上記結果を見ると、一番右の「rn」列でタイムスタンプをもとにランク付けがされていることがわかります。 今回のケースでは、ウィンドウ関数で取得したそれぞれのユーザのデータから、ランク（rn）が「1」のものを取得することで各ユーザの最新のデータを取得することができます。 ウィンドウ関数の結果を絞り込みは、 QUALIFY を使用して実現することができます。 QUALIFY   rn=1   先ほど実践にて「 実はさらにスッキリさせることができます（詳細は後述） 」と、せっかくGeminiが生成したSQLに少しケチをつけてしまいましたが、ウィンドウ関数の結果を絞り込む際は QUALIFY を使用することをオススメします。 QUALIFYを使用することで、今回のケースのように 「サブクエリが削減できる」 等のメリットがあります。 WHEREで絞り込み QUALIFYで絞り込み SELECT     *   FROM     (       SELECT           *,           ROW_NUMBER() OVER(PARTITION BY userID ORDER BY timestamp DESC) AS rn         FROM           `evocative-entry-277709.yamaguchi_test.user_action_all`     ) AS t   WHERE t.rn = 1; SELECT   *,   ROW_NUMBER() OVER(PARTITION BY userID ORDER BY timestamp DESC) AS rn FROM   `evocative-entry-277709.yamaguchi_test.user_action_all` QUALIFY   rn=1   レガシー SQL 関数と演算子  |  BigQuery  |  Google Cloud cloud.google.com Query syntax  |  BigQuery  |  Google Cloud cloud.google.com Window function calls  |  BigQuery  |  Google Cloud cloud.google.com   まとめ 今回は、ウィンドウ関数を使ってデータを分析してみました。 ウィンドウ関数を使用することで少ない文量のSQLで、元テーブルのデータを欠落させることなくデータが取得できました。 調べていく中で「スライディングウィンドウ」が気になったので、機会があれば詳しく調べてみたいと思います。 最後に、 やっぱりGeminiって便利ですね、、、

本記事は 夏休みクラウド自由研究 8/7付の記事です 。 こんにちは！SCSKの中山です。   少し前のアップデートにて、Cato Clientのセッション強制切断(Revoke Session)機能が実装されました。 こちらの機能は名前の通り、Cato Clientで接続しているSDPユーザをCMA上から切断することができる機能になります。 今回はこの機能を使い方や検証した内容を書きつつ、実際に運用における利用シーンを考えてみようと思います。 本記事は2024/7/31時点で作成した記事になります。 機能アップデート等で仕様や画面が変わる可能性がございますので、予めご了承ください。   Revoke Session機能について まず「Revoke Session」機能について、最初にお伝えしておくと、本機能のメインはあくまで 再認証を強制する機能 になります。 こちらのCatoのナレッジにも記載がありますが、「Revoke Session」はクライアント側に再認証を求め、ユーザ側で10分以内に認証しない場合に接続を切断する仕様になっております。 そのため、”切断”という観点では対象のユーザをCatoから切断するために10分程度時間がかかるという仕様になってます。 Cato KnowledgeBase(Revoking a Remote User’s Session) 実施手順 ①CMAにより、「Access」>「Users」>「User Directory」より切断したいユーザを選択します。 ②右上の「Actions」>「Revoke sessions」をクリックすると確認画面が出てくるので、「Confirm」を押します。   画面上部に「Sessions revoke successfuly」とポップアップが出てきたら、セッションの切断が成功しております。   実際にセッション切断をやってみた まずは、セッション切断時にClient利用者側の画面・表示はどのようになるかを試してみました。 今回はWindows のCato Clientのセッション切断を実施しました。   ▼セッション切断後のCato Clientの画面 「Revoke Sessions」押下後、2,3分後にCato Clientでは上記のログイン画面が再度表示されておりました。 今回は検証にあたりClientの確認を続けていたので気づきましたが、何か作業中に切断された場合には、気づかないかもです。。   ログイン画面が表示された時点でCMAの「Topology」を確認すると「Revoke Session」を実施したユーザが表示されており、Eventsを見てもまだSDPユーザで接続されているログが残っておりました。 ▼Cato Client側がログアウト画面になった時のCMAの「Topology」画面   その後、「Topology」から表示が消え、セッションの切断が確認できたのは「Revoke Sessions」押下後、約10分後ぐらいでした。 ⇒Catoの仕様通りではありますが、個人的にはセッション切断というと即時で切断できる機能かと思ったので、ここら辺感覚と違う人も多いのでは？と思います。なので運用にあたっては注意が必要かもです。   ちなみに、Cato Clientではログアウト画面、「Topology」上には表示がある状態で再度接続を試してみました。   接続時間が継続していたため、Cato Clientでログイン画面が表示された状態は、あくまで再認証が求められている状態なだけでセッション自体は続いていることがClient側でも確認できました。   ユースケースを考えてみた まずは端末を紛失した場合ですかね。 こちらはCatoのナレッジの使用例にもあったケースでCato Clientのセッションが残ってしまっている状態で端末を紛失してしまった場合、その端末からは社内NWに入ることができてしまいます。 それをセッション切断を行うことで、正規の利用者以外はログインできないため第三者が社内NWに侵入することを防ぐことができ、情報漏洩のリスクを削減することができます。こちらは端末紛失時の運用に組み込めば、実運用でも使えそうです。 ナレッジの使用例だと「Stories Workbench」で大量アップロードしているユーザを特定し、そのユーザのセッションを切断するケースが紹介されておりました。正当な利用者であるか否かを選別できるのはメリットですが、業務で短期的に大量データをやり取りする場合と区別が難しいと思いますので、実運用に組み込む際には注意が必要かなと思います。 他にも何かを検知してセッションを切断するというケースがあるかと思ったのですが、現状の機能だと向いてない気がします。 あくまで再認証を求める機能で、検証した通りセッションが切断されるまでに約10分ほどかかっておりましたので、ウイルスやマルウェアを検知した時に運用側で対応するのでは対応が遅くなってしまうかと思います。 また、ユーザ制御の観点でセッションを切断する場面があるかもと考えましたが、現状では利用者本人であればセッションを切断しても再ログインできてしまうので、正当な利用者の行動を制限することは難しそうです。 上記の例にも書いた通り、Clientの正当な利用者か否かを選別したいという場面では、一応使えそうではあります。   まとめ 今回はCato Client接続のセッション切断機能について記事を書いてみました。 ユースケースでも運用と絡めて記載をしておりますが、セッション切断機能は実際の運用に関わる機能なので、使用にあたってはしっかりと運用ルールを決める必要があります。運用ルールを決めて使えばとても有用な機能になりますので、本機能のリリースと合わせて運用ルールも見直してみては如何でしょうか。

こんにちは。SCSKの江木です。 Google Cloud Next Tokyo ’24に参加してきたので、インベントの様子や感想を投稿します。 Google Cloud Next Tokyo ’24とは？ Google Cloud Next Tokyo ’24は2024年8月1日・2日にパシフィコ横浜ノースで開催されたGoogle Cloudのカンファレンスイベントです。 本イベントは主に以下の内容で構成されています。 基調講演 セッション Innovators Hive Expo スポンサーブース 基調講演と各セッションではGoogle Cloudの最新情報や技術動向、国内外の企業での活用事例が紹介されます。Innovators Hiveではデベロッパーやエンジニア向けに、Google Cloudのデモ体験や認定資格のクイズチャレンジなどができます。ExpoではGoogle Cloudの最新サービス・ソリューションのデモを体験できます。スポンサーブースではGoogle Cloud パートナー企業によるソリューション展示やデモを体験することができます。（弊社も出展しておりました！！） 昨年同様、Google Cloudの最新情報を知れるだけでなく、パートナーや資格取得者同士の交流を深められるイベントになっております。 昨年のNext Tokyoについて知りたい方は以下を参照ください。 Google Cloud Next Tokyo '23に参加してみた Google Cloud Next Tokyo '23に参加したので、イベントの内容と感想を投稿します。 Google Cloud Next Tokyo '23は2023年11月15日・16日に東京ビッグサイトで開催されたGoogle Cloudのカンファレンスイベントです。 blog.usize-tech.com 2023.12.02 会場の様子および全体的な印象 基調講演開始の1時間ほど前の会場入り口の様子。空いているのかなと思いきや、建物内にはすでにたくさんの方がいらっしゃいました。 かなりの方が参加しており、大盛況でした！！   Google Cloud Next ’24の印象をまとめると、以下の通りです。 出展内容の7割ほどが生成AI絡み 昨年よりも生成AIの出展が増えている気がします… イベント参加者が昨年より多いように感じた 会場の広さが影響しているのかもしれません… グッズをもらいやすくなった 今年はスタンプラリーがあった（私が参加しようと思った頃には売り切れでした…） 参加レポート 今回はDay1基調講演を聞いた後、Innovators Hive、Expoを生成AI周りを中心に見学してきました。それぞれの内容を紹介してきます。 Day1基調講演 生成AIの活用事例紹介、AIの新サービスの発表が行われました。新サービスにはGeminiの新しいモデルやGemini for Google Cloud Service Level Agreement(SLA)などがありました。 基調講演の詳しい内容は以下のブログを参照ください。（弊社の出展についても掲載しているので、ぜひご覧ください！！） 【現地速報】Google Cloud Next ’24 Tokyo Keynoteまとめ。/スポンサーブースにも出展中!!!!!! Google Cloud Next '24 Tokyo「Day 1 開幕速報」として、Day 1 Keynoteまとめ、弊社SCSKの展示ブース、現地の最新情報を共有します。 blog.usize-tech.com 2024.08.01 Innovators Hive 体験型デモ Google Cloudのサービスを面白いデモを使って、遊び感覚で学べるエリアになります。体験型デモでは「Instant Web with Gemini」と「Beat Google at Load Balancing」を体験してきました。 Instant Web with Gemini Webサイトのインターフェースを自分で描き、描いたものを画像認識で読みこみ、HTMLなどのプログラムを出力するといったデモでした。 自分が描いたインターフェースをそこそこの精度でプログラムにしてくれました。 ※左が読み込んだWebサイトのインターフェース、右がHTMLのプログラム Beat Google at Load Balancing Load Balancingと負荷分散能力を競うというデモでした。デモ内容としては、迫りくるパケットを4つのボタンを押して、バケットを分散させるというものです。 惜しくも負けてしまいました… Quiz Challenge Google Cloudのクイズに挑戦できるエリアになります。ジャンルとしては、AI、データ、クラウドアーキテクチャ、アプリ開発、DevOps、セキュリティの6分野ありました。 私の所属がAI専門部隊ということで、AIの試験を受けてみました！ すると、70点/ 100点！　うーん…、微妙ですね…。 ですが、70点以上だったので、以下のアクリルスタンドをもらいました。 Vertex AIと書いてますね！かっこいい！！ 認定者ラウンジ   Google Cloud認定資格を取得している人だけが入れる認定資格者ラウンジに行ってきました。 ラウンジに行くと、以下のボールペンをもらえました！また、エンジニア性格診断を受けると、可愛いバッチをもらうことができました！ また、私はGoogle Cloud認定資格を全冠しているので、オリジナルのSWAGをもらうことが決まりました！（後日もらえるとのことなので、楽しみです！！） 全冠について知りたい方は以下のサイトをご参照ください。 Google Cloud 認定資格を全冠したので軌跡をまとめてみる Google Cloud認定資格を全冠しました。私が実際にどのように学習を進めてきたのか、具体的な勉強法や感想をお伝えしていきます。 blog.usize-tech.com 2024.06.11 Expo Google Cloudの最新技術に触れることができるブースになっています。今回は生成AIに関連が深い、「AI Innnovation」と「Google Workspace」の２つのエリアを見学してきました。 AI Innovation   AI Innovationという名前の通り、AIに関するデモを紹介していました。その中でも特に興味深いと感じたデモを2つ紹介します。 画像編集の新体験 Imagen 3.0× Flutter × Gemini Imagen3.0による画像編集能力とGeminiのマルチモーダル対応能力を利用したデモでした。具体的な内容としては、Imagen 3.0で画像を生成・編集し、その画像に対してGeminiでタイトルを生成するというものでした。ついにAIだけで画像を自由にカスタマイズできる時代が来ましたね！ Geminiによる生成的推薦とRAG ある画像を検索すると、その画像に近い画像を推薦するといったデモでした。検索対象画像をエンベディング(ベクトル化)し、画像のデータベースに対して、ベクトル検索をかけることで実現しているそうです。ベクトル検索は文章にも画像にも使えるので、かなり便利だということを再認識しました！！ Google Workspace   Google Workspaceについて紹介するエリアで、主にGeminiとのコラボレーションを紹介するといった内容でした。 見学してきたGemini機能の中でとても面白い機能があったので、1つ紹介します。 AIで動画制作をスマートに Geminiを使って、動画制作をする機能になります。この機能のどこがすごいのかといいますと、「 docxやpptxの資料から動画制作できる 」という点です。つまり、人間の思考・手を介さずに、プレゼン動画を作成できるということになります。（そうは言っても、もちろん人の思考・手による修正は必要です。） 現在は英語版のみ対応とのことですが、2024年末までに日本語対応するそうです。日本語化が楽しみですね！！！ 感想 いかがだったでしょうか。Google Cloud Next Tokyoの現地の様子をお届けしました。 昨年に引き続き、Google Cloud Next Tokyoに参加してみて、「AIを試す時代から使う時代になった」と改めて感じました。また、本イベントの参加が生成AI活用について考えるヒントになったとも思っています。 今後もGoogle Cloudの最新情報を常にキャッチアップし、より深く学んでいきたいと考えています。 最後まで読んでいただき、ありがとうございました。

本記事は 夏休みクラウド自由研究 8/6付の記事です 。 こんにちは。SCSKの山口です。 最近、Google CloudのData Fusionでパイプラインを構築する機会が多くあり、その中でも「Wrangler」のプライグインを多く使用したので、その際に便利だった機能をご紹介します。 ※本ブログではData Fusionパイプラインの基本的な構築方法については言及していませんので、構築方法等については下記をご参照ください。 Cloud Data Fusion のドキュメント  |  Cloud Data Fusion Documentation  |  Google Cloud Google Cloud Platform でデータ パイプラインのビルドと管理を行うための、CDAP を基に構築されたフルマネージド サービス。 cloud.google.com Cloud Data Fusion 概要 まずData Fusionについて簡単にご説明します。 Data Fusionは、 データパイプラインを素早く構築、管理できる、クラウドネイティブのフルマネージドサービス です。 フルマネージドサービスなので、インフラの管理なしでパイプラインを構築することが可能です。 そして、何より マウスだけで視覚的にパイプラインを構築すること が可能なため、直感的な操作で、コードを意識することなくETLパイプラインをデプロイすることができる点が長所です。 Cloud Data Fusion | Google Cloud Cloud Data Fusion は、ETL および ELT のデータ パイプラインを効率的に構築して管理できる、フルマネージドでコードを意識させないデータ統合サービスです。 cloud.google.com 利用できるプライグイン プラグインとは、Data Fusionの機能を拡張するために使用できるカスタマイズ可能なモジュールのことです。 下記の種別のプラグインが用意されています。 ソース 変換 集計 シンク エラーコレクタ アラートパブリッシャー アクション かなり数があり、一つひとつ説明すると膨大な文量になるので詳細は下記ドキュメントをご覧ください。 Cloud Data Fusion のプラグイン リファレンス | Google Cloud お客様がデジタル トランスフォーメーションに乗り出したばかりでも、あるいはすでに進めている場合でも、Google Cloud は困難な課題の解決を支援します。 cloud.google.com   実践：WrangerプラグインでGCSのファイルを加工してBigQueryテーブルに取り込む 実現したいこと 今回実現したいことは以下の内容です。 下記「member」テーブルに、氏名と電話番号（ ハイフンなし ）のデータをロードします。 データのインポート元はGCSファイルに置いているCSVファイルです。 「member」テーブルの電話番号カラムには ハイフンなしの番号（最大長：11） をロードしたいですが、GCS内のCSVファイルにはハイフンが含まれています。 GCSからCSVファイルをBigQueryテーブルにインポートする際に、 「電話番号」カラムのハイフンを取り除きたい です。 これを、Data Fusion（Wrangerプラグイン）で実現します。 パイプライン構築 では早速パイプラインを構築していきます。 Source 今回はデータソースとして「GCS」プラグインを選択します。 左ペインから「GCS」を選択し、パイプライン構築画面に表示されたGCSアイコンから「Properties」を設定します。 今回は、インポート対象のCSVファイルを「BROWSE」より検索し、選択します。 Transform 今回は変換のプラグインとして「Wrangler」プラグインを使用します。（本ブログのメイン） propertyを開き「Directives」の「WRANGLE」ボタンを押下します。 今回のソースファイルを選択します。 インポートしたいファイルが表示されたら準備OKです。   さて、今回やりたいことをおさらいします。 やりたいことは、「telephone_number」カラム内のハイフンを取り除くことです。 この作業を実際にWRANGLE画面でやってみます。 対象カラム「telephone_number」の横のプルダウンを開き。「Find and replace」を選択します。 下記を入力します。 Find：-（ハイフン） Replace with：（何も入力しない） Replace Allを押下すると、ハイフンが削除されていることがわかります。 ここまでは何の驚きもないかもしれませんが、画面右ペインの「Transformation steps」をクリックすると、先ほどやった作業のレシピを記述してくれています。 さらに、右上の「Apply」ボタンを押下すると、 「Directives」の「Recipe」に先ほどの内容を記述してくれています。 つまり、 実際のデータを見ながら手で作業した内容を自動的にレシピに反映してくれている。 というわけです。 レシピに直接コードを入力することなく、やりたい変換処理を実際に行うだけで自動的に記述してくれる 大変便利な機能です。 Sink さあ仕上げです。データの最終的な出力先（sink）に「BigQuery」プラグインを選択し、宛先テーブルを指定します。 以上でパイプライン構築は完了です。 豆知識 プラグインをつなげていくと、矢印がジグザグになったりと画面が煩雑になることがあります。 このような場合は、プラグインを全選択し、画面右ペインの「Align」をクリックすると、プラグインを綺麗に整列してくれます。 以上、A型の筆者からの豆知識でした。 パイプライン デプロイ・起動 パイプラインをデプロイし、起動（Run）します。 パイプラインは無事成功しました。最後に出力先のテーブルを確認します。 電話番号のカラムにハイフンなしのデータが取り込まれています。大成功です。   まとめ 今回はData FusionでWranglerプラグインを活用してパイプラインを構築しました。 最初にも述べた通り、Data Fusionを使用するメリットの一つは、 視覚的・直感的な操作でパイプラインが構築できる点 です。 今回紹介したWranglerプラグインの使い方は、そのメリットを最大限活用したものだと思います。 また、Wranglerプラグインでは正規表現を使用した変換等も可能なので、柔軟なデータ加工が可能です。 皆さんも是非ご活用ください。

こんにちは！SCSKの江木です。 先日、Dialogflow CXのAgentからのテストケース作成を自動化していて、「あるフォルダにファイルがアップロードされたら起動するCloud Functionsを作りたい」とふと思いました。（テストケース作成自動化について知りたい方は以下のブログを参照ください。） Dialogflow CX Agentからの単体テストケース作成を自動化してみる 今回はテストケース作成の時間を削減すべく、グラフ理論を使って、単体テストケース作成を自動化する方法を実装してみました。このグラフ理論の考え方は他にも使えると思うので、ぜひご覧ください。 blog.usize-tech.com 2024.08.02 そこで今回はバケットレベルで指定するCloud Storageトリガーをどうにかしてフォルダレベルで指定できないか調べてみました。 Cloud FunctionsとCloud Storage まずはCloud FunctionsとCloud Storageについて簡単に紹介します。 Cloud Functionsとは？ Cloud Functionsは、サーバーレスコンピューティングプラットフォームであり、コードを記述してデプロイすることで、イベントに応じて自動的に実行される関数を作成することができます。サーバーの準備や管理を行う必要がなく、コードを記述してデプロイするだけで、スケーラブルかつ高可用性のインフラストラクチャ上でコードを実行することができます。 バージョンは第1世代と第2世代があります。第2世代はCloud RunとEventarcに構築されており、処理速度の向上や多くのイベントへの対応を図っています。（第2世代のCloud Functionsを作成すると、Cloud Runのリソースも作成されます。） 今回は性能がよい第2世代のCloud Functionsを扱います。 より詳しい内容は公式ドキュメントを参照ください。 Cloud Functions の概要  |  Cloud Functions Documentation  |  Google Cloud cloud.google.com Cloud Storageとは？ Cloud Storageはオブジェクトストレージサービスで、容量無制限で非構造化データを安全に保存し、世界中どこからでも高速アクセスできるサービスです。データのアーカイブ、バックアップ、コンテンツ配信、ビッグデータ分析、機械学習など、幅広いユースケースに対応できます。また、従量課金制でコストを抑え、ニーズに合わせて柔軟に拡張できます。 より詳しい内容は公式ドキュメントを参照ください。 Cloud Storage のプロダクト概要  |  Google Cloud cloud.google.com Cloud Functions（第2世代）のCloud Storageトリガーとは？ Cloud Functionsのトリガーとは？ Cloud Functionsではトリガーを指定することで、イベントに応じて自動実行できるようになります。 このトリガーにはどのような種類があるのか、公式ドキュメントでは以下のように記述されています。 トリガーは次の 2 つのカテゴリに分類されます。 HTTP トリガー 。HTTP(S) リクエストに応答し、 HTTP 関数 に対応します。 イベント トリガー 。Google Cloud プロジェクト内のイベントに応答し、 イベント ドリブン関数 に対応します。 Cloud Functions（第 2 世代）では、次のタイプのトリガーがサポートされています。 HTTP トリガー イベント トリガー: Pub/Sub トリガー Cloud Storage トリガー Firestore トリガー 汎用の Eventarc トリガー Eventarc でサポートされているすべてのイベントタイプをサポート（Cloud Audit Logs を介した 90 以上のイベントソースを含む） 様々なトリガーがありますね！今回はこの中でもCloud Storageトリガーに着目します。 Cloud Storageトリガーとは？ 公式ドキュメントによると、Cloud Functions(第2世代)のCloud Storageトリガーは以下のイベントタイプがサポートされています。 イベント イベントタイプ 説明 オブジェクトのファイナライズ google.cloud.storage.object.v1.finalized （Eventarc 経由） 新しいオブジェクトが作成されるか、既存のオブジェクトが上書きされ、そのオブジェクトの新しい世代が作成されると送信されます。 オブジェクトの削除 google.cloud.storage.object.v1.deleted （Eventarc 経由） オブジェクトが完全に削除された場合に発生します。 オブジェクトのアーカイブ google.cloud.storage.object.v1.archived （Eventarc 経由） オブジェクトのライブ バージョンが非現行バージョンになると送信されます。詳細については、オブジェクトのバージョニングをご覧ください。 オブジェクト メタデータの更新 google.cloud.storage.object.v1.metadataUpdated （Eventarc 経由） 既存オブジェクトのメタデータが変更された場合に送信されます。 「あるフォルダにファイルがアップロードされたら起動するCloud Functionsを作りたい」という用途ですと、「 google.cloud.storage.object.v1.finalized 」が最適ですね。 Cloud Storageトリガーの仕様(2024年7月現在) Cloud Storageトリガーの説明は公式ドキュメントでは以下のように記載されています。 Cloud Functions では、Cloud Storage トリガーによって、Cloud Storage の変更に応じて関数を呼び出すことができます。関数に Cloud Storage トリガーを指定するときに、イベントタイプを選択して Cloud Storage バケットを指定します。この関数は、 指定されたバケット内のオブジェクト（ファイル） が変更されるたびに呼び出されます。 赤字箇所にありますように、Cloud Storageトリガーは バケットレベルでのファイルの変更にのみ 対応しています。 つまり、「以下のようなバケットの構造を考えたとき、フォルダAにファイルがアップロードされたときのみ関数が実行されるトリガーを作ることができない」ということになります。困りました… フォルダレベルでのCloud Storageトリガーを実装してみる 先ほど、フォルダレベルでのファイル変更に対応したCloud Storageトリガーはないことがわかりました。そこで、Cloud Functionでの処理を工夫することで、フォルダレベルでのCloud Storageトリガーを使っているかのように見せたいと思います。 今回実装するのは、hogehogeフォルダとfugafugaフォルダをバケットに作り、hogehogeフォルダにファイルがアップロードされたときのみ、ログにメッセージを出力する簡易的なシステムです。 バケットの作成 まず、バケットを作成します。以下のような設定でバケットを作成します。 次にフォルダを作成していきます。hogehogeフォルダとfugafugaフォルダを作成します。 これでバケットの作成は完了です。 Cloud Functionsの作成 それではCloud Functionsを作っていきます。以下のような第2世代の関数を作ります。 Cloud Storageトリガーのイベントタイプは google.cloud.storage.object.v1.finalized 」を設定します。 コーディングをしていきます。言語はPython3.12を使います。 hogehogeフォルダにファイルが格納されたときのみ、ログにメッセージを出力するようにします。 import functions_framework # Triggered by a change in a storage bucket @functions_framework.cloud_event def hello_gcs(cloud_event):   data = cloud_event.data   bucket = data["bucket"]     name = data["name"]   folder_name = data["name"].split("/")[-2]     file_name = data["name"].split("/")[-1]   print("これから処理を行います")   if folder_name == "fugafuga":       return   elif folder_name == "hogehoge":         print(file_name+"が格納されました！") コーディングが行いましたら、デプロイし、実装完了です。 実装結果 それでは実際にフォルダにファイルを格納して、動作確認をしていきます。 まず、hogehogeフォルダにtest.txtというファイルをアップロードします。 すると、以下のように「test.txtが格納されました！」というメッセージがログに出力されました。 一方で、fugafugaフォルダにtest.txtをアップロードしてみるとどうなるでしょうか？ メッセージが出力されませんでした。 うまく実装することができました！ しかし、トリガーで関数が実行されてしまっているので、あくまで疑似的なフォルダレベルのトリガーです。 おわりに 今回はフォルダレベルでのCloud Storageトリガーはないということがわかったので、疑似的なフォルダレベルのCloud Storageのトリガーを実装してみました。 フォルダレベルでのCloud Storageトリガーがない理由ですが、オブジェクトストレージであるがゆえにフラットな階層になっていることが原因であると私は考えています。 しかし！最近、Google Cloudより以下のブログが出ました！ 階層名前空間によって Cloud Storage にファイル システム最適化をもたらす | Google Cloud 公式ブログ 新しい階層名前空間機能は、Cloud Storage バケットにファイル システム最適化をもたらします。 cloud.google.com このブログによると、Cloud Storageが階層名前空間（HNS）に対応するになるようです！ ということはフォルダレベルでのCloud Storageトリガーが実装される日が近いのかもしれません… 以上、Cloud Storageトリガーのお話でした！！ 最後まで読んでいただき、ありがとうございました。