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

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

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

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

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

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

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

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

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

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

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

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

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

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

本記事は 夏休みクラウド自由研究 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つとして本記事を参考にしていただければと思います。