本記事は TechHarmony Advent Calendar 2024 12/13付の記事です 。 SCSK 技術ブログ「TechHarmony」で今年も12月1日から25日までのアドベントカレンダー企画が開催されており、Catoクラウドチームは、12/5から12/14の10記事を担当しています。ちなみに、昨年（2023年）は、7記事を担当しました。 さて、今回は比較的問い合わせが多い、SOC、つまりCatoクラウドにおけるセキュリティ監視、運用についての記事となります。   SOCについて まず最初に、 SOC（Security Operation Center） は、皆さんご存知の通り 24時間365日体制でシステムやネットワークを常時監視を行い、サイバー攻撃を含む異常な動作の検出や、インシデント兆候をいち早く検知し、検知した脅威について、専門知識を有するセキュリティアナリストが調査、分析を行い、発生状況、影響範囲の特定を行い、速やかに CSIRT（Computer Security Incident Response Team） などと連携（通知・通報）を行う組織のことです。 場合によっては、SOC で原因の特定や、対応策のアドバイスまでを行うこともありますが、多くの場合 SOC は脅威の検知検出から通知を行うまでが役割で、その後の対応については、CSIRT が担います。 CSIRT が、インシデントからの復旧、原因追跡、再発防止策の策定などを担当します。 昨今、サイバー攻撃の高度化・巧妙化により、侵入から被害を受けるまでの時間が極端に短くなっているため、いち早く検知を行うためには 24時間365日のセキュリティ監視、つまり SOC が不可欠になって来ています。 特に、標的型メールやランサムウェア、サプライチェーン攻撃の被害が年々増加しており、自社だけではなく、セキュリティレベルが高くない海外拠点や委託先企業を経由した攻撃（ サプライチェーン攻撃 ）からも自社を守る必要性が高まっています。また、IoTデバイス普及により、IoT/OTのセキュリティリスクも高まってきています。 さらに、サイバー攻撃者も生成AIをフル活用しており、攻撃が多様化・複雑化しているため、セキュリティ製品で検知されたログやアラート分析においても、最新の専門知識を有するセキュリティアナリストが必須となっており、調査・分析レベルも飛躍的に上がってきています。   Catoクラウドにおけるセキュリティについて Catoクラウドは、 SASE（Secure Access Service Edge、サッシー） であるため、サイバーセキュリティフレームワーク（CSF）を例にとると、”識別”、”防御”から一部”検知”までをカバーしています。 Catoクラウドの標準サービスに含まれるセキュリティ機能は、 FWaaS（Firewall-as-a-Service） と SWG（Secure Web Gateway） の機能に限定されますので、マルウェア対策や、ランサムウェアを含むサイバー攻撃の検出・防御を行うには、セキュリティオプションである Threat Prevention を選択する必要があります。 セキュリティオプションの Threat Prevention には、パターンファイルマッチングの アンチマルウェア（Anti-Malware） 、機械学習エンジンを用いた振る舞い検知を行う 次世代型アンチマルウェア（Next Generation Anti-Malware） 、Catoクラウドで最もセキュリティ効果が高い IPS 、不正なドメインへのアクセスをブロックする DNS Protection 、不審なアクセスをモニタリングする Suspicious Activity Monitoring（SAM） 、Threat Intelligence、インライン AI/ML、アンチフィッシングなどの基本的な脅威対策がすべて含まれています。 標準サービスである FWaaS、SWGと、セキュリティオプションである Threat Prevention（AM/NGAM/IPS/DNS Protection/SAM等）が、CSFにおける”識別”、”防御”を担いますが、この”防御”の結果が、Catoのログ（Event）として出力されることになります。   Catoクラウドのセキュリティ検知（確認）について 検知について、より具体的な例を含めてご紹介します。 標準サービスであるFWaaS、SWGについては、Catoクラウドでは、Internet Firewallのセキュリティポリシー設定になります。 ※ちなみに、CatoクラウドのFWaaSは、3つのFirewall（Internet Firewall/WAN Firewall/LAN Firewall）があります。 あくまで一例となりますが、Internet FirewallでCatoクラウドのデフォルトポリシー設定で、Tor Network のブロックがあります。 Tor（トーア）とは、インターネット上で高度な匿名性を実現する通信システムのことです。Tor Browserを利用し、複数サーバ（ノード）を経由させることで、発信元を秘匿することが可能となります。 Tor の自体は、一部の国では利用が制限されていますが、日本を含め多くの国では合法です。しかしながら、匿名性を利用し犯罪が行われることが多く、また、ダークウェブへのアクセスが可能なため、不正なサイトやマルウェアに感染するリスクが高まります。 つまり、企業での利用は禁止すべきであると言えます。 そのため、Catoクラウドのデフォルトのポリシー設定で禁止（Block）され、ログ（Event）出力が行われています。 ポリシーのトラッキング（Track）をログ出力でなく、管理者へのメール通知に変更することも可能ですが、Firewallログをメール通知するのはあまり得策であるとは言えません。 つまり、このログ（Event）をどのようなタイミング（リアルタイム、日次、週次、月次など）で確認するかがポイントとなります。   次に、SWGについても同じです。 SWGは、デフォルトポリシー設定で、各カテゴリーが、注意喚起（Prompt）と禁止（Block）に分類されています。 これも一例となりますが、SWG のカテゴリである「 Anonymizers 」の中には、先程のTorに関する”Tor Project”が含まれているのはもちろんのこと、Ultrasurf や Surfshark と言った様々なVPNサービスも含まれています。 これら VPN サービスをユーザが利用するとCatoクラウドのセキュリティ検査を回避することになるため、企業での利用は禁止すべきであると言えます。 つまり、Catoクラウドのデフォルトの SWG ポリシー設定で注意喚起（Prompt）または禁止（Block）され、ログ（Event）出力が行われていますので、これらのログ（Event）についても、何らかのタイミング（リアルタイム、日次、週次、月次）で確認する必要があるということになります。   セキュリティオプションであるThreat Prevention（AM/NGAM/IPS/DNS Protection/SAM等）についても同様です。 Threat Preventionは、さきほどのFirewallポリシーとは異なり、IPSについては、検知時にメール通知する設定を行っているケースが多いですが、AM、NGAM、DNS Protection、SAMなど、Catoクラウドでは検知件数が多いので、ログ出力のみとしているケースが殆どです。 従業員 2,000名規模の企業で1ヶ月間で発生しているログ件数を以下に示します。 Event Type Event Sub Type 発生件数（月間） Security Anti Malware 5,000,000～10,000,000 件 NG Anti Malware 500～1,000 件 IPS 5,000～10,000 件 DNS Protection 100～500 件 Suspicious Activity 100,000～500,000 件 上記には許可（Allow）も含まれていますので、実際の禁止（Block）や、リスクレベルが高い（High）の件数は、それほど多くはありませんが、一定の企業規模を超えると、メール通知が可能な件数ではないことをご理解いただけると思います。 AM 、 NGAM は、マルウェアを検知し、禁止（Block）したログを確認する必要があるのは言うまでもありません。 IPS については、ほぼ禁止（Block）のログのみとなりますので、それぞれ確認が必要となります。IPSのBlockは、シグニチャID（Signature ID）から確認を行います。Catoクラウドでは、Signature IDは、cid_***、sid_***、feed_***と言ったシグニチャIDが割り振られています。 一例ですが、 cid_heur_suspicious の場合は、CatoクラウドのIPSが不審なボットネットへのアクセスと認識（シグニチャ一致）し、通信の遮断をしていますので、アクセス先のドメインの調査が必要です。Threat Name、Threat Referenceを確認し、外部情報等から、マルウェアが利用しているサイトである場合は、そのアクセス元のユーザ（端末）を確認する必要があり、そのユーザが意図した操作によるものなのか？もしそうでない場合は、端末のウィルススキャンを実施するなどが必要になります。 DNS Security は、Catoクラウドで、禁止（Block）、許可（Allow）が自動で実施されています。IPSと同じく、シグニチャID（Signature ID）が割り振られていますが、DNS Securityについては、DNS Protection Categoryを確認する必要があります。頻繁にBlockされているURL（Webサイト）に問題がないか？フィッシングサイトではないか？もし問題があった場合には、そのWebサイトへ何度もアクセスを実施しているユーザ（端末）を確認する必要があります。 一例ですが、Signature ID: cid_dns_feed_block_newly_registered_domains 、DNS Protection Category が Newly Registered Domains の場合は、最近（過去2週間以内）に取得された新しいドメインへのアクセスであるため（マルウェアサイトである可能性があるので）通信が遮断されていますので、そのドメインへのアクセスがユーザが意図したものであるかどうかの確認が必要になります。 Suspicious Activity （不審な行動）についても、IPSやDNS Securityと同様ですが、基本的には、 Suspicious Activity “Monitoring” なので、禁止（Block）等は行われず、モニタリング（Monitoring）のみとなりますので、定期的な確認のみが必要になります。 いずれにせよ、何らかのタイミングでログの確認が必要である、ということはご理解いただけたのではないかと思います。   検知（確認）のタイミングについて Catoクラウドが、”識別”、”防御”を実施し、ログ出力を実施しますので、そのログをどのようなタイミングで人間が”検知”、つまり確認・判断をするかがポイントになります。 もちろん最も良いのは、24時間365日のリアルタイム、つまりSOCとなりますが、それが難しい場合は、24時間毎（日次、あるいは営業日）、週に1度（週次）、月に1度（月次）などになりますが、 少なくとも、1ヵ月に一度は確認をすべき と考えています。   また、Catoクラウドでは、前述の FWaaS、SWG、Threat Prevention は、すべてリアルタイム防御となっていますが、検知については、ネットワークのトラフィックや、エンドポイントの振る舞いなどの各種ログを、独自の AI や機械学習アルゴリズムによって分析し、セキュリティ上の攻撃や脅威を自動的に検知する機能もすでに提供されています。 XDR (Extended Detection and Response)  と呼ばれており、問題を早期に発見・対処することを目的として、検知された問題を確認するダッシュボードやそれを分析するための一連のツールが用意されています。 XDRについては、以下のご覧ください。 Cato クラウドの XDR 活用に向けた初めの一歩 Cato クラウドでは、ネットワークのトラフィックやエンドポイントの振る舞いなどの各種ログを Cato 独自の AI や機械学習アルゴリズムによって分析し、セキュリティ上の攻撃や脅威を自動的に検知する XDR 機能が提供されています。 blog.usize-tech.com 2024.04.26 Catoクラウドでが、セキュリティインシデントとして判断したものを「 ストーリー（Stories） 」と呼びます。 1つのストーリーは、基本的に異なるセキュリティ上の問題を示していますので、ストーリー単位で運用を行っていくことになります。 以下は、ストーリーのダッシュボード（Stories Overview）です。 [HOME]>[Stories Overview]（旧CMA：[Monitoring]>[Stories Dashboard]） Catoクラウドがストーリーと判断したインシデントが発生した際にメール通知をする機能もありますので、まずは、Catoクラウドのストーリーを自社のセキュリティ運用へ組み込むことが効率的であると言えます。 また、XDRは、追加オプション（ XDR Security Pro ）で、Catoクラウドの各セキュリティ機能（EPPを含む）のログはもちろん、外部のEDR（Microsoft Defender、CrowdStrike、SentinelOne）とのログ連携も可能となり、さらに、AIベースの脅威ハンティング（ Threat Hunting ）や、ユーザー行動分析（ User Behavioral Analysis ）が行われ、インシデントライフサイクル管理が可能となります。 将来的には、Microsoft Defender for Office 365や、CSPMソリューションとの連携も予定されています。 Catoクラウドでは、AIの活用が進んでおり、ストーリー発生時に、過去の同様のストーリーを自動で抽出して表示する機能や、生成AIを利用しストーリーのサマリー情報を表示する機能もすでに実装されています。 今後も人間が行っている作業全般をAIが代替していく方針で計画されているため、人手によるログ確認、SOCではなく、XDR Security を主体としたセキュリティ管理へ移行することが、管理品質や運用効率を含めて良いのではないかと考えています。   まとめ SCSKでは、2022年1月にCatoクラウドに対応したSOCサービスをリリースしています。 SASE「Catoクラウド」のセキュリティ・マネージドサービス機能を強化 SCSK株式会社（本社：東京都江東区、代表取締役 執行役員 社長 最高執行責任者：谷原 徹、以下 SCSK）は、SASEの概念を実装したネットワークセキュリティクラウドサービス「Catoクラウド」のセキュリティにおける検知・対応・復旧を強化... www.scsk.jp すでに複数のお客様でSOCをご利用いただいており、以下の導入事例 マルホ様でもSOCをご利用いただいております。 マルホ株式会社 様｜お客様事例｜SCSK株式会社 データセンター集約型のネットワークをCatoクラウドで全面刷新 通信環境の効率的な運用と共にセキュリティ強化を実現 www.scsk.jp SOCの24時間365日リアルタイム監視ではなく、月に一度、月次のタイミングでの確認を支援する月例報告会サービスもご提供しております。 Cato クラウド向け月次レポートサービスの紹介と技術的な仕組みの解説 SCSKでは Cato クラウドの導入から運用まで一貫した技術サポートやサービスを提供しております。本記事はサービスメニューの1つである月次レポートサービスのご紹介と、その裏側の技術的な仕組みについて解説いたします。 blog.usize-tech.com 2024.01.22 月例報告書を作成し、報告会を行うサービスで、上記の記事は、少し古いバージョンですが、月次報告書（別紙）のサンプルレポートを掲載しています。 セキュリティの観点においては、Catoクラウドのログ（Event）をすべて集計し、傾向分析（前月比較）を実施しています。 Security（Event_Type）集計し、Internet Firewall、Anti Malware、NG Anti Malware、IPS、DNS Protection、Suspicious Activityなどを Event_Sub_Type毎でログ集計し、前月との比較を実施しています。 さらに、Event_Sub_Type の集計もしているため、Internet Firewallにおいては、各ポリシー毎のログ集計、SWGではカテゴリ毎のログ集計を実施しています。DNS Protection、Suspicious Activityなども同じです。 まずは、SOCを利用される前に、月例報告会を試されて自社のログ状況を把握されることから始められてどうしょうか。 現在、当社の月次レポートサービスをお試しいただけるキャンペーンを実施していますので、Catoクラウドをすでにご利用のお客様は、ぜひご検討ください。 ※もちろん、SCSKでなく他のパートナーからCatoクラウドを契約されているお客様もご利用可能です。 https://form.scsk.jp/public/file/document/download/15055 form.scsk.jp SOCを含め、Catoクラウドのセキュリティ運用にお悩み方がいらっしゃれば、遠慮なく お問い合わせ ください。

こんにちは、広野です。 以下の記事で、Storage Browser for Amazon S3 の実装方法を紹介しました。 【re:Invent 2024 発表】Storage Browser for Amazon S3 を React アプリに組み込みました 2024/12/1 に GA されました Storage Browser for Amazon S3 を既存 の S3 と React アプリに組み込みました。(AWS Amplify, Next.js 不使用) blog.usize-tech.com 2024.12.09 また、追加記事でダウンロードを禁止する設定にしました。 Storage Browser for Amazon S3 でダウンロードを無効にする デフォルトの設定ではセキュリティ的に実用的ではなかったので、少々セキュリティ設定を組み込んでみました。 blog.usize-tech.com 2024.12.12 しかしながら、このままではセキュリティがザルなので、実用的ではありません。本記事では、アクセスログを追加してみたのでその方法を紹介します。 追加した設定 Amazon S3 のアクセスログ取得 設計上、Amazon Cognito のユーザーで認証しています。ですので、Amazon Cognito ユーザー名を含めたログを残します。 Storage Browser を使用するためのアーキテクチャは以下の記事と同じです。Amazon Cognito ユーザープールの認証で React アプリにログインし、ログインしたユーザーに Cognito ID プールで一時的な IAM ロールを割り当てます。付与された権限で Amazon S3 バケットを読み書きします。 AWS Amplify Storage を AWS CloudFormation でマニュアルセットアップする サーバーレス WEB アプリ (SPA) から、ファイルをバックエンドにアップロードして処理したいことがあります。AWS Amplify と連携させた Amazon S3 バケット「AWS Amplify Storage」を使用すると、アプリとセキュアに連動したストレージを簡単に作ることができます。 blog.usize-tech.com 2022.05.31 Storage Browser で読み書きする Amazon S3 バケットへのアクセスログを残します。 検索しやすいように、今回は AWS CloudTrail Lake イベントデータストアを使用します。 該当の Amazon S3 バケットのデータイベントのみを保存 するようにしました。 CloudTrail Lake イベントデータストア - AWS CloudTrail このページでは、CloudTrail Lake イベントデータストアタイプについて説明します。 docs.aws.amazon.com 基本的には公式の手順通りなのですが、該当の Amazon S3 バケットのデータイベントのみを保存する設定が必要です。マネジメントコンソールでは、以下のように設定しました。気を付けないといけないのは、Value の欄に S3 バケットの ARN を入れるのですが、バケット名の最後に / (スラッシュ) を入れないようにしましょう。 Amazon Cognito Lake イベントデータストアは Amazon Athena と連携して Athena からクエリできるようにもできるのですが、今回はやめました。他のデータソースと統合したければ、Athena でクエリするようにした方が良いです。 AWS CloudFormation でデプロイしたので、テンプレートも紹介しておきます。366 日で削除する S3 ライフサイクル設定を入れています。 AWSTemplateFormatVersion: 2010-09-09 Description: The CloudFormation template that creates a S3 bucket with CloudTrail logs for Storage Browser for Amazon S3. # ------------------------------------------------------------# # Input Parameters # ------------------------------------------------------------# Parameters: SubName: Type: String Description: Unique system sub name of example. (e.g. dev) Default: dev MaxLength: 10 MinLength: 1 DomainName: Type: String Description: Domain name of the Storage Browser URL. xxxxx.xxx (e.g. sampledomain.name) Default: sampledomain.name MaxLength: 40 MinLength: 5 AllowedPattern: "[^\\s@]+\\.[^\\s@]+" SubDomainName: Type: String Description: Sub domain name for URL. xxxxx.sampledomain.name (e.g. dev) Default: dev MaxLength: 20 MinLength: 1 S3DataEventRetentionDays: Type: Number Description: The retention period (days) for S3 data event logs. Enter an integer between 90 to 540. Default: 366 MaxValue: 540 MinValue: 90 Resources: # ------------------------------------------------------------# # S3 # ------------------------------------------------------------# S3Bucket: Type: AWS::S3::Bucket Properties: BucketName: !Sub example-${SubName}-storagebrowser PublicAccessBlockConfiguration: BlockPublicAcls: true BlockPublicPolicy: true IgnorePublicAcls: true RestrictPublicBuckets: true CorsConfiguration: CorsRules: - AllowedHeaders: - "*" AllowedMethods: - "GET" - "HEAD" - "PUT" - "POST" - "DELETE" AllowedOrigins: - !Sub https://${SubDomainName}.${DomainName} ExposedHeaders: - last-modified - content-type - content-length - etag - x-amz-version-id - x-amz-request-id - x-amz-id-2 - x-amz-cf-id - x-amz-storage-class - date - access-control-expose-headers MaxAge: 3000 Tags: - Key: Cost Value: !Sub example-${SubName} # ------------------------------------------------------------# # CloudTrail Event Data Store for S3 kbdatasource # ------------------------------------------------------------# CloudTrailEventDataStore: Type: AWS::CloudTrail::EventDataStore Properties: Name: !Sub ${S3Bucket}-s3-data-events BillingMode: EXTENDABLE_RETENTION_PRICING FederationEnabled: false IngestionEnabled: true MultiRegionEnabled: false OrganizationEnabled: false RetentionPeriod: !Ref S3DataEventRetentionDays TerminationProtectionEnabled: true AdvancedEventSelectors: - Name: !Sub ${S3Bucket}-s3-data-events FieldSelectors: - Field: eventCategory Equals: - Data - Field: "resources.type" Equals: - AWS::S3::Object - Field: resources.ARN StartsWith: - !Sub "arn:aws:s3:::${S3Bucket}" Tags: - Key: Cost Value: !Sub example-${SubName} DependsOn: - S3Bucket ログの検索 ログは AWS CloudTrail Lake データストアに保存されていますので、SQL で検索することができます。しかし、AWS CloudTrail のデータイベントログを 1 件出力すると、以下のような階層構造を含むデータが記録されます。 これでは、どこに何があるのか見つけられません。 [ { "eventVersion": "1.11", "userIdentity": "{type=AssumedRole, principalid=AROATLXY4HCCXNO6SVHIB:CognitoIdentityCredentials, arn=arn:aws:sts::999999999999:assumed-role/xxxx-CognitoIdPAuthRole-scsk/CognitoIdentityCredentials, accountid=999999999999, accesskeyid=ASIATLXY4HCCQTLMWCZV, username=null, sessioncontext={attributes={creationdate=2024-12-12 05:22:57.000, mfaauthenticated=false}, sessionissuer={type=Role, principalid=AROATLXY4HCCXNO6SVHIB, arn=arn:aws:iam::999999999999:role/xxxx-CognitoIdPAuthRole-scsk, accountid=999999999999, username=xxxx-CognitoIdPAuthRole-scsk}, webidfederationdata={federatedprovider=cognito-identity.amazonaws.com, attributes={cognito-identity.amazonaws.com:amr=[\"authenticated\",\"cognito-idp.ap-northeast-1.amazonaws.com/ap-northeast-1_BukHorAF0\",\"cognito-idp.ap-northeast-1.amazonaws.com/ap-northeast-1_BukHorAF0:CognitoSignIn:c7243a48-1081-70e9-43cf-b90864365a29\"], cognito-identity.amazonaws.com:aud=ap-northeast-1:2f961a08-67b6-4918-9711-09317abeb02b, cognito-identity.amazonaws.com:sub=ap-northeast-1:35df1c38-8506-c926-5a2e-1b0159e0da8d}}, sourceidentity=null, ec2roledelivery=null, ec2issuedinvpc=null, assumedroot=null}, invokedby=null, identityprovider=null, credentialid=null, onbehalfof=null, inscopeof=null}", "eventTime": "2024-12-12 05:23:20.000", "eventSource": "s3.amazonaws.com", "eventName": "PutObject", "awsRegion": "ap-northeast-1", "sourceIPAddress": "xxx.xxx.131.235", "userAgent": "[Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.0.0 Safari/537.36 Edg/131.0.0.0]", "errorCode": "", "errorMessage": "", "requestParameters": "{If-None-Match=*, bucketName=xxxx-scsk-storagebrowser, Host=xxxx-scsk-storagebrowser.s3.ap-northeast-1.amazonaws.com, key=bot2/test6.txt}", "responseElements": "{x-amz-server-side-encryption=AES256}", "additionalEventData": "{SignatureVersion=SigV4, CipherSuite=TLS_AES_128_GCM_SHA256, bytesTransferredIn=5, SSEApplied=Default_SSE_S3, AuthenticationMethod=AuthHeader, x-amz-id-2=H+RhWUuEaBNn5NzXQZzfPmQNhcf9jyTosjNHd+PPrJ9xTTp0CVlR+fvU/t8EJpsKPj/1AxZ+osc=, bytesTransferredOut=0}", "requestID": "NFYGVKXT5894ZXYJ", "eventID": "f9e3aedf-7a2b-4359-9c6d-7291a8a97bd9", "readOnly": "false", "resources": "[{accountid=null, type=AWS::S3::Object, arn=arn:aws:s3:::xxxx-scsk-storagebrowser/bot2/test6.txt, arnprefix=null}, {accountid=999999999999, type=AWS::S3::Bucket, arn=arn:aws:s3:::xxxx-scsk-storagebrowser, arnprefix=null}]", "eventType": "AwsApiCall", "apiVersion": "", "managementEvent": "false", "recipientAccountId": "999999999999", "sharedEventID": "", "annotation": "", "vpcEndpointId": "", "vpcEndpointAccountId": "", "serviceEventDetails": "", "addendum": "", "edgeDeviceDetails": "", "insightDetails": "", "eventCategory": "Data", "tlsDetails": "{tlsversion=TLSv1.3, ciphersuite=TLS_AES_128_GCM_SHA256, clientprovidedhostheader=xxxx-scsk-storagebrowser.s3.ap-northeast-1.amazonaws.com}", "sessionCredentialFromConsole": "" } ] ですので、ログを以下の項目に整形して表示したいと思います。 eventTime 日時 eventName オペレーションの種類 cognitoUser Cognito ユーザー名 bucketName S3 バケット名 key S3 オブジェクトキー名 sourceIpAddress ソース IP アドレス userAgent デバイス情報 errorCode エラーコード errorMessage エラーメッセージ AWS CloudTrail Lake イベントデータストアに対して、以下のクエリを実行します。 FROM で指定するテーブル名は、画面でイベントデータストアを選択すると自動で ID が入ります。 WHERE 以下の条件は、適宜変更してください。 SELECT eventTime, eventName, split_part(json_extract_scalar(userIdentity.sessioncontext.webidfederationdata.attributes['cognito-identity.amazonaws.com:amr'],'$[2]'),':',CAST(3 AS BIGINT)) AS cognitoUser, element_at(requestParameters,'bucketName') AS bucketName, element_at(requestParameters,'key') AS key, sourceIpAddress, userAgent, errorCode, errorMessage FROM 137d78ec-d8ac-4dcf-aebb-xxxxxxxxxxxxx WHERE eventTime >= '2024-12-12 05:00:00' AND userIdentity.type = 'AssumedRole' AND eventName in ('ListObjects','PutObject','DeleteObject') 以下のように、結果が整形されて出力されます。これで見やすくなりました！ 今回の環境では、Amazon Cognito のログインをメールアドレスにしているため、ユーザー名が UUID になっています。 どの Cognito ユーザーがどのオブジェクトに対してどの操作をしたのか、追跡できるようになりました！ まとめ いかがでしたでしょうか？ この設定は最低限必須なものだと思いまして、記事にしました。 検索用 SQL づくりが一番苦労しました。ログのデータ型がよくわからず、型変換も入れないと期待する値を取得できませんでした。もっとスマートな方法はあるかもしれません。 本記事が皆様のお役に立てれば幸いです。

こんにちは、広野です。 以下の記事で、Storage Browser for Amazon S3 の実装方法を紹介しました。 【re:Invent 2024 発表】Storage Browser for Amazon S3 を React アプリに組み込みました 2024/12/1 に GA されました Storage Browser for Amazon S3 を既存 の S3 と React アプリに組み込みました。(AWS Amplify, Next.js 不使用) blog.usize-tech.com 2024.12.09 しかしながら、このままではセキュリティがザルなので、実用的ではありません。本記事では、少々セキュリティ設定を組み込んでみたのでその方法を紹介します。 追加した設定 ダウンロード禁止 ダウンロードフリーのままだと情報漏洩の温床となりそうだったので、ダウンロード不可にします。 Amazon S3 のアクセスログ取得 設計上、Amazon Cognito のユーザーで認証しています。ですので、Amazon Cognito ユーザー名を含めたログを残します。 Amazon Cognito ユーザー名を含む Amazon S3 アクセスログの保管方法については今時点方法がわからなかったので、わかり次第記事にしたいと思います。 ダウンロード禁止 これは簡単でした。以下 2 点を実装しました。 Amazon Cognito ID プールが一時的に割り当てる IAM ロール内に定義していたアクセス権限から、”s3:GetItem” をはく奪しました。 - Action: - "s3:ListBucket" Resource: - !Sub "arn:aws:s3:::xxxx-scsk-kbdatasource" Effect: Allow - Action: - "s3:DeleteObject" # - "s3:GetObject" この行を削除 (YAMLですみません、AWS CloudFormation でデプロイしているので) - "s3:PutObject" Resource: - !Sub "arn:aws:s3:::xxxx-scsk-kbdatasource/*" これだけでもダウンロード禁止は機能しますが、ダウンロードしようとするとエラーメッセージが表示されてしまうので、Storage Browser の画面からもダウンロードボタンを消しました。アプリコード内 (App.jsx) で get の部分を削除します。 変更前 paths: { "bot1/*": { authenticated: ["write", "get", "list", "delete"] }, "bot2/*": { authenticated: ["write", "get", "list", "delete"] } 変更後 paths: { "bot1/*": { authenticated: ["write", "list", "delete"] }, "bot2/*": { authenticated: ["write", "list", "delete"] } そうすると、画面からダウンロードボタンがなくなりました。 まとめ いかがでしたでしょうか？ 小ネタでしたが、ニーズあると思って記事にしました。 本記事が皆様のお役に立てれば幸いです。

本記事は TechHarmony Advent Calendar 2024 12/12付の記事です 。 2024年11月18日のCatoクラウドのアップデート情報 にて、Catoクラウドの管理操作や設定作業に利用できるツールのソースコードを GitHub 上で公開したと唐突にアナウンスされました。 今回のブログ記事では、実際にどのようなものが公開され、どのような時に活用できるものなのか紹介したいと思います。 GitHub 上で公開されているもの 各種ソースコードは、GitHub 上の Cato Networks 社の Organization 配下で公開されています。 Cato Networks Cato Networks has 16 repositories available. Follow their code on GitHub. github.com 2024年12月12日時点では、実際に使えそうなものとして次のものが含まれています。 API をコマンドライン操作で実行できる CLI ツール API を Go 言語のプログラムから操作するための SDK Cato クラウドの各種設定作業を行うための Terraform 用のプロバイダ Cato クラウドと AWS や Azure との間で vSocket 接続や IPsec 接続を行うための Terraform 用のモジュール API を Python から操作するためのサンプルコードや Jupyter Notebook これらは全てオープンソースライセンス (Apache License Version 2.0) で配布されていますので、ツール類を自由に利用できるのはもちろんですし、ソースコードを自由に改造して利用することもできます。ただし、提供されているツール類は Cato クラウドの商用サポートがあるわけではなく、使い物になるレベルのものになっているかどうかは保証されていないため、利用の際にはその点を認識しておく必要があります。 以降では、これら提供されているものがどのようなものか、少し詳しく解説していきます。 CLI ツール CLI ツール概要 CLI ツールのソースコードは GitHub の catonetworks/cato-cli リポジトリで公開されています。 CLI は Python 言語で開発されており、README に記載の通り pip を用いて catocli パッケージをインストールして利用できます。利用するには Python 3.6 以上の実行環境が別途必要となります。 これまで API を実行するには多少なりともプログラムを書かざるを得ませんでしたので、CLI ツールはずっと待ち望んでいたものでした。なので、あとは CLI を上手く使えばいろいろと捗ります！と言いたいところですが、2024年12月12日時点ではドキュメントもヘルプもあまり整備されていないため、簡単に使えるものではないというのが実情です…。しょうがないのでソースコードを読み、おおよその使い方がわかってきましたのでその内容を共有します。 まず、CLI を利用する前提として、Cato クラウドの API について理解している必要があります。それには弊社の過去記事を参考にしつつ公式の API Reference を参照ください。 Cato API の利用方法と制限事項 Cato API の具体的な利用方法や注意事項を Python コードを交えて解説しています。 blog.usize-tech.com 2023.08.08 “catocli -h” コマンドを実行してヘルプを見てみると、次の4つのパラメータがあります。 query mutation entity raw query と mutation は、それぞれ Queries と Mutations の分類の API を実行する際に指定するパラメータであり、API 名と引数を続けて指定してすれば API を実行できます。entity は query の中の entityLookup API を少しだけ実行しやすくしたものですが、使っても使わなくても良い特殊な存在のように思えます。raw は GraphQL のクエリそのものや引数を指定して API を実行するもので、これを通常使う必要はないですが、新しい API が用意されたけど CLI はまだサポートしていない場合などに使うものかもしれません。 entityLookup API の実行例 では、手始めに Query の entityLookup API を実行してみましょう。 まずは “catocli query entityLookup -h” コマンドを実行してヘルプを確認するわけですが、これを見ても引数の指定方法はさっぱりわかりませんね…。 $ catocli query entityLookup -h usage: EXAMPLES: catocli query entityLookup -h catocli query entityLookup catocli query entityLookup "$(cat < entityLookup.json)" catocli query entityLookup '{"entityIDs": ["ID"], "entityInput": {"id": {"id": "ID"}, "name": {"name": "String"}, "type": {"type": "enum(EntityType)"}}, "from": "Int", "helperFields": ["String"], "limit": "Int", "lookupFilterInput": {"filter": {"filter": "enum(LookupFilterType)"}, "value": {"value": "String"}}, "search": "String", "sortInput": {"field": {"field": "String"}, "order": {"order": "enum(DirectionInput)"}}, "type": "enum(EntityType)"}' positional arguments: json Variables in JSON format. optional arguments: -h, --help show this help message and exit -accountID ACCOUNTID Override the CATO_ACCOUNT_ID environment variable with this value. -t [T] Print test request preview without sending api call -v [V] Verbose output -p [P] Pretty print 結論として、CLI にどのような引数を指定すれば利用できるのかを知るには、現状では CLI のソースコードの一部を見て把握せざるを得ませんでした。 Query の entityLookup API の場合、見るべきものは次の2つのファイルです。 https://github.com/catonetworks/cato-cli/blob/main/catocli/parsers/query_entityLookup/README.md https://github.com/catonetworks/cato-cli/blob/main/queryPayloads/query.entityLookup.json 1つ目のファイルは改行がうまく表示されないため見づらいですが、entityLookup API を実行するコマンドには10個の引数が用意されており、その中でも accountID と type の2つが必須の引数であることがわかります。 また、2つ目のファイルを見ると、実際に実行される GraphQL のクエリや引数の型や構造がわかります。このファイルには “enum(EntityType)” や “enum(LookupFilterType)” といった列挙型のような記載もありますが、それらの具体的な値は API Reference  のほうに記載されています。 これら情報を踏まえて、accountID 引数のみコマンドラインで用意されたパラメータで指定し、それ以外の引数を JSON 形式の文字列として指定すれば、CLI で API を実行できました。 例えば、自アカウントに登録済の Site の一覧を取得したい場合、次のように CLI を実行すれば JSON 形式で結果を取得できます。 $ export CATO_TOKEN=APIキー $ catocli query entityLookup -accountID=アカウントID '{"type":"site"}' { "data": { "entityLookup": { "items": [ { "description": "BRANCH ", "entityEntity": { "entityTypeType": "site", "id": "XXXXX", "name": "XXXXX" }, "helperFields": { "connectionType": "Socket X1500", "creationDate": "Aug 24, 2023 8:02:44 AM", "description": "", "isHA": "false", "lastModified": "Oct 25 2024 1:04:32 AM", "operationalStatus": "active", "protoID": "XXXXX", "type": "BRANCH" } }, 省略 ], "total": 9 } } } ここまで実行できれば、後は jq コマンドなどを使ってデータ抽出や加工もできますね。 events API の実行例 もう少し複雑な例として、Query の events API も CLI で実行してみます。今回は「2024年11月の Internet Firewall のルールごとのイベント数を降順で取得する」といったことを試してみます。 まず、events API の引数は次の2つを見るとわかります。 https://github.com/catonetworks/cato-cli/blob/main/catocli/parsers/query_events/README.md https://github.com/catonetworks/cato-cli/blob/main/queryPayloads/query.events.json これらの内容をもとに、次のような引数を与えると実現できます。引数の内容については 過去のブログ記事  もご参照ください。 { "timeFrame": "utc.{2024-11-01/00:00:00--2024-12-01/00:00:00}", "eventsMeasure": [ { "fieldName": "event_count", "aggType": "sum" } ], "eventsDimension": [ { "fieldName": "rule" } ], "eventsFilter": [ { "fieldName": "event_sub_type", "operator": "is", "values": [ "Internet Firewall" ] } ], "eventsSort": [ { "fieldName": "event_count", "order": "desc" } ] } entityLookup API の実行例と同様に上記の引数をコマンドラインで直接指定しても良いですが、長いのでいったんファイルに記載しておき、ファイルから引数を渡して次のように CLI を実行すると少しスマートです。 $ vim events-request.json 引数の JSON を記載する $ catocli query events -accountID=アカウントID "$(cat < events-request.json)" { "data": { "events": { "from": "2024-11-01T00:00:00Z", "id": "XXXX", "records": [ { "flatFields": [ [ "event_count", "17987" ], [ "rule", "Any Allow" ] ], "prevTimeFrame": null, "trends": null }, 省略 ], "to": "2024-12-01T00:00:00Z", "total": 7, "totals": { "event_count": 21090, "rule": null } } } } なかなか良い感じです。 同じようなやり方で他の API も CLI ツールで実行できますが、Cato クラウドの API や GraphQL の構文などについて十分理解していないと使いこなせないため、CLI ツールがあるからといって簡単に API を実行できるわけではないというのが辛いところですね…。 Go Client SDK Cato クラウドの API を Go 言語のプログラムから操作するための SDK は、GitHub の catonetworks/cato-go-sdk リポジトリで公開されています。 Go 言語のプログラムを書く人であれば上記リポジトリの examples ディレクトリにあるサンプルコードを見れば一目瞭然だと思いますが、cato-go-sdk を import し、CatoClient インターフェースのインスタンスを New すれば、あとは Visual Studio Code などで入力補完を利かしながらプログラムを書けます。SDK があるのと無いのとではプログラムの書きやすさが段違いです！ Cato クラウドの API について理解していないと使いこなせないというのは変わりませんが、GraphQL の部分の多くが隠蔽されているので、GraphQL をそこまで理解していなくてもプログラムが書けそうです。 他の言語（特に Python）向けの公式の SDK の提供を期待しています。 Terraform Cato クラウドを扱うための Terraform 用のプロバイダやモジュールのソースコードは、 名前に terraform を含む複数のリポジトリ で公開されています。 2024年12月12日時点では次のものが用意されています。 Cato クラウドの各種設定項目を Terraform のリソースとして扱うためのプロバイダ Cato クラウドと AWS や Azure との間で vSocket で接続するためのモジュール Cato クラウドと AWS や Azure との間で IPsec で接続するためのモジュール これらは Terraform Registry の catonetworks 名前空間 で配布されていますので、GitHub からソースコードを入手する必要はなく、自分の Terraform コード内から参照して利用できます。 Cato クラウド用 Terraform プロバイダ Cato クラウド用の Terraform プロバイダには現時点では次のリソース（合計9種類）が含まれています。 Socket / vSocket サイトや IPsec サイトを操作するリソース サイトのネットワークやホストを操作するリソース Socket / vSocket サイトの WAN インターフェースを操作するリソース Internet Firewall のルールやセクションを操作するリソース WAN Firewall のルールやセクションを操作するリソース プロバイダやリソースの利用方法を記載した ドキュメント も用意されていますので、そちらも合わせてご参照ください。 Terraform で操作可能な範囲はまだ限られていますが、比較的頻繁に設定を追加・変更するものが Terraform で操作できるようになっている印象を受けます。特に、多数のサイトを追加して管理する必要がある場合には Terraform を使ってみるのは良さそうです。 Cato クラウドの API ですと他のリソースも扱えますので、Terraform で扱えるリソースも今後拡充されていくものと思います。 Cato クラウド用の Terraform モジュール 用意されている Terraform モジュールは、単に Cato クラウド側の設定を行うだけでなく、AWS や Azure 側にも必要なリソースを構築してくれるものとなっています。 AWS と Azure のどちらを利用するか、vSocket と IPsec サービスのどちらを利用するか、vSocket を利用する場合に VPC / VNet を作成するか既存のものを利用するか、といった違いにより6種類のモジュールが用意されていますので、どのように構築したいかに応じて使い分けることになります。 特に、vSocket を利用する場合はパブリッククラウド側で作成・設定すべきリソースの量が多く手動で構築するのは大変ですので、用意された Terraform モジュールを利用すると良さそうに思います。逆に IPsec サービスを利用する場合は、Terraform モジュールではなくプロバイダを使ってリソースを作成するというのでも十分かもしれません。 なお、モジュールのドキュメントはほぼ用意されていませんが、 利用例のコード が用意されていますので、そちらを見るとどのようにコードを書けばよいか概ねわかるかと思います。ただ、どのような変数を与えるべきかについては少し悩む部分があり、Cato クラウド側の設定値に関する変数はともかく、パブリッククラウド側の変数を決めるには当然パブリッククラウド側の構築に関する知識も必要ですので、一筋縄ではいかないかもしれません。 まとめ Cato クラウドが GitHub 上でオープンソースライセンスで公開したものについてざっくりと説明しました。簡単に利用できるものではありませんが、ソフトウェア開発者であれば十分乗り越えられるでしょう。 最近は Cato クラウドの API が拡充されつつあり、CLI やプログラムからも操作しやすくなってきたことで、ようやく開発者にとっても Cato クラウドがクラウドサービスになってきたと実感しています。また、オープンソースとして公開されていると安心感がありますし、開発者の性としてそのエコシステムに対して何らかの形で貢献しようという意欲も沸いてきました。

こんにちは。SCSK渡辺(大)です。 人生初のIDEとしてCloud9を使っていたのですが、とある理由からVisual Studio Codeを使いたくなりました。 Visual Studio CodeからAWSリソースにアクセスするには、アクセスキーが必要になります。 そこで今回は、 ベストプラクティスに準拠してアクセスキーを利用する方法を考えてみました。 当記事はアクセスキーの漏洩を防止するという内容ではなく、万が一にもアクセスキーが漏洩した場合に備えた内容です。 アクセスキーが漏洩した場合のリスク 一例ですが以下が挙げられます。 不正利用により予期せぬ多額の請求 顧客情報などの情報漏洩 リソース削除によるサービス停止 IAMでのセキュリティのベストプラクティス ベストプラクティスを確認します。 参考： IAMでのセキュリティのベストプラクティス 付与する権限は最小限にしましょう 一時的な認証情報を使用 しましょう。それが無理なら アクセスキーをローテーション しましょう アクセス先を MFA強制 にし、アクセス元に MFA設定 にしましょう MFAを強制したい Visual Studio CodeからAWSリソースにアクセスするためには、ローカル環境に導入したAWSクレデンシャルファイルにアクセスキーとシークレットキーを明記する必要があります。 ただし、それだけではMFA強制にすることは出来ません。 AWS CLIでMFA強制にするにはひと手間必要です。 AWS CLIに多要素認証(MFA)を強制する - 株式会社セキュアイノベーション セキュアイノベーションが情報セキュリティに関してご案内するブログです。今週はAWS CLI へ多要素認証を設定する必要性についてご案内しています。 www.secure-iv.co.jp   このひと手間が面倒だと感じたのでBashシェルスクリプトにしました。 ■get-session-token.sh #!/bin/bash # credentialsを削除し、credentials.bkをcredentialsとしてコピー unset AWS_ACCESS_KEY_ID AWS_SECRET_ACCESS_KEY AWS_SESSION_TOKEN if [ -f ~/.aws/credentials.bk ]; then rm -f ~/.aws/credentials cp ~/.aws/credentials.bk ~/.aws/credentials echo "AWS credentials have been reset from backup." else echo "Backup file (credentials.bk) not found. Please ensure it exists." exit 1 fi # 現在の AWS 設定を確認 echo "Current AWS configuration:" aws configure list # MFAトークンコードの入力を求める read -p "Enter your MFA token code: " token_code # AWS STS get-session-tokenを実行 session_token=$(aws sts get-session-token --serial-number arn:aws:iam::[アカウントID]:mfa/[MFA名] --token-code $token_code) if [ $? -ne 0 ]; then echo "Failed to get session token. Please check your AWS configuration and MFA token." exit 1 fi # クレデンシャルを環境変数にエクスポート export AWS_ACCESS_KEY_ID=$(echo $session_token | jq -r '.Credentials.AccessKeyId') export AWS_SECRET_ACCESS_KEY=$(echo $session_token | jq -r '.Credentials.SecretAccessKey') export AWS_SESSION_TOKEN=$(echo $session_token | jq -r '.Credentials.SessionToken') # AWSクレデンシャルファイルを更新 aws configure set aws_access_key_id $AWS_ACCESS_KEY_ID aws configure set aws_secret_access_key $AWS_SECRET_ACCESS_KEY aws configure set aws_session_token $AWS_SESSION_TOKEN echo "AWS credentials have been updated." # 更新された AWS 設定を確認 echo "Updated AWS configuration:" aws configure list # 現在のロールを表示 echo "Current role is..." aws sts get-caller-identity --query "[Account, Arn]" if [ $? -ne 0 ]; then echo "Failed to get caller identity. Please check your AWS configuration." exit 1 fi   ついでに、スイッチロールもBashシェルスクリプトにしました。 ■change-role.sh #!/bin/bash # 現在の認証情報を表示 echo "Current identity:" aws sts get-caller-identity # ユーザーからアカウントIDとロール名を入力してもらう read -p "Enter the AWS account ID: " account_id read -p "Enter the role name: " role_name # role assumeを実行 echo "Assuming role..." role_credentials=$(aws sts assume-role --role-arn "arn:aws:iam::${account_id}:role/${role_name}" --role-session-name "${role_name}") # 環境変数を設定 export AWS_ACCESS_KEY_ID=$(echo $role_credentials | jq -r '.Credentials.AccessKeyId') export AWS_SECRET_ACCESS_KEY=$(echo $role_credentials | jq -r '.Credentials.SecretAccessKey') export AWS_SESSION_TOKEN=$(echo $role_credentials | jq -r '.Credentials.SessionToken') # 新しい認証情報を確認 echo "New identity after assuming role:" aws sts get-caller-identity   設計 方針 IAMユーザーにはIAMロールへスイッチ（AssumeRole）できる権限のみを付与する IAMロールの信頼ポリシー上でも、IAMユーザーからのスイッチにはMFA強制にする IAMロールにはAdministratorAccessを付与する 構成図   準備 AWS側の作業 IAMユーザーを作成する 自分のMFA設定、アクセスキー作成、下記IAMロールへのスイッチ、のみ許可する IAMロールを作成する 信頼ポリシーは上記IAMユーザーかつMFA強制でスイッチ許可する AdministratorAccessを付与する IAMユーザーでAWSマネジメントコンソールにログインする  MFA設定する アクセスキーを作成する ローカル環境側の作業 Visual Studio Codeをインストールする AWS CLIを導入する Visual Studio Codeで「aws –version」と打ってバージョンが表示されることを確認する jqを導入ダウンロードする Bashシェルスクリプトで使う 公式サイト からダウンロードした.exeファイルをjq.exeにリネーム後、所定の場所（WindowsならC:\WINDOWS\system32\jq.exe）に移動する Visual Studio Codeで「jq –version」と打ってバージョンが表示されることを確認する AWSクレデンシャルファイルを修正する Visual Studio Codeで「aws config」と打ち、アクセスキー、シークレットキーを入力する（その他は任意） 前述のBashシェルスクリプトを作成する credentialsをコピーしてcredentials.bkを作成する 実行結果 １．BashシェルスクリプトでMFA認証します。 XXXXX@XXXXXX XXXXXX ~/work/awsTest $ ./get-session-token.sh AWS credentials have been reset from backup. Current AWS configuration: Name Value Type Location ---- ----- ---- -------- profile <not set> None None access_key ****************XXXX shared-credentials-file secret_key ****************XXXX shared-credentials-file region ap-northeast-1 config-file ~/.aws/config Enter your MFA token code: 999999 AWS credentials have been updated. Updated AWS configuration: Name Value Type Location ---- ----- ---- -------- profile <not set> None None access_key ****************XXXX env secret_key ****************XXXX env region ap-northeast-1 config-file ~/.aws/config Current role is... [ "[アカウントID]", "arn:aws:iam::[アカウントID]:user/[IAMユーザー名]" ]   ２．MFA認証したものの、IAMユーザーには殆ど権限ないことを確認します。 特に、IAMロールのリストが表示できないことは重要です。 表示できてしまうと、アクセスキーの不正利用者が全てにスイッチロールすることを試すことが出来てしまうためです。 XXXXX@XXXXXX XXXXXX ~/work/awsTest $ aws iam list-roles An error occurred (AccessDenied) when calling the ListRoles operation: User: arn:aws:iam::[アカウントID]:user/[IAMユーザー名] is not authorized to perform: iam:ListRoles on resource: arn:aws:iam::[アカウントID]:role/ because no identity-based policy allows the iam:ListRoles action XXXXX@XXXXXX XXXXXX ~/work/awsTest $ aws s3 ls An error occurred (AccessDenied) when calling the ListBuckets operation: User: arn:aws:iam::[アカウントID]:user/[IAMユーザー名] is not authorized to perform: s3:ListAllMyBuckets because no identity-based policy allows the s3:ListAllMyBuckets action   ３．IAMロールにスイッチロールします。 XXXXX@XXXXXX XXXXXX ~/work/awsTest $ source ./change-role.sh Current identity: { "UserId": "[UserId]", "Account": "[アカウントID]", "Arn": "arn:aws:iam::[アカウントID]:user/[IAMユーザー名]" } Enter the AWS account ID: [アカウントID] Enter the role name: [IAMロール名] Assuming role... New identity after assuming role: { "UserId": "[UserId]:[IAMロール名]", "Account": "[アカウントID]", "Arn": "arn:aws:sts::[アカウントID]:assumed-role/[IAMロール名]/[セッション名]" }   ４．IAMロールにはAdministratorAccessが付与されているので、コマンドが受け付けられました。 XXXXX@XXXXXX XXXXXX ~/work/awsTest $ aws iam list-roles { "Roles": [ { "Path": "/service-role/", ～～（中略）～～ "AssumeRolePolicyDocument": { ^C XXXXX@XXXXXX XXXXXX ~/work/awsTest $ aws s3 ls yyyy-mm-dd hh:mm:ss [S3バケット名]   まとめ 思ったより大変でした。 調査の途中、AWS Toolkitとごっちゃになってしまいました… 余談ですが、いまはAWS AmplifyとCDKをマイペースで勉強中です。 当記事もそうですが、アウトプットすることは自分の勉強になるので、次はAmplifyかCDKについての記事を投稿してみたいと思っています。

本記事は TechHarmony Advent Calendar 2024 12/11付の記事です 。 以前、LinuxOSにて自動接続できる方法はないかといったお問い合わせがありました。 結論、CatoのサービスではLinux OS起動時、自動接続は可能です。 Always-ON policy > SettingsにてLinuxへConnect on bootにチェックを入れることでOS起動時Catoへ接続することが可能です。 ただ、Linux OS の場合、現在のサービスではユーザー毎に設定はできず設定を有効にしてしまうと全ユーザーに設定が反映されてしまいます。 今回の記事ではCMA上の設定ではなくLinuxユニットファイルからユーザー毎に自動接続の設定を行っていきたいと思います。 今回の環境 ホストOS: Windows 11 Linux Client version: 5.3.0 仮想化ソフトウェア: VMware Workstation pro 17 ゲストOS: Debian 12.04 ネットワークアダプター : ブリッジネットワーク ■構成図 Catoクライアントのインストール方法 クライアントダウンロードポータルからLinuxタブを選択し、クライアントをダウンロードします。 利用可能なファイルタイプには.rpm (Red Hat Package Manager)と.deb (Debian)があります。 ダウンロード後、下記のコマンドを実行しクライアントのインストールを行ってください。 rpmファイルの場合: sudo rpm -i cato-client-install.rpm Debianファイルの場合: sudo dpkg -i cato-client-install.deb 以上がCatoクライアントインストール手順となります。 ユニットファイルの作成 ユニットファイルとは、Systemdとサービスマネージャによって使用される設定ファイルの一種です。 Systemdはカーネルが生成する最初のユーザープロセスでありLinuxの起動処理やシステム全体の管理を行います。 プロセス番号はPID=1となり、メモリ上で常に待機している常駐プログラムとなります。 よって、OS起動時、Catoへ接続するユニットファイルを作成することで、自動的にCatoへ接続できるシステムとなります。 設定内容は以下の通りです。 vi /etc/systemd/system/cato.service [Unit] Description=Cato Client After=network-online.target Wants=network-online.target [Service] Type=oneshot RemainAfterExit=yes ExecStart=/usr/bin/cato-sdp start --user=メールアドレス --account=アカウント名 --password=パスワード --reset-cred ExecStop=/usr/bin/cato-sdp stop ExecReload=/bin/sh -c　 '/usr/bin/cato-sdp stop; sleep 1; /usr/bin/cato-sdp start --user=メールアドレス --account=アカウント名　--password=パスワード --reset-cred' Restart=no [Install] WantedBy=multi-user.target このUnitファイルでは、ネットワークに接続後Catoクライアントが起動するよう設定しています。 ExecStartに指定されたコマンドでCatoクライアントを起動し、ユーザー名、アカウント名、パスワードを指定し接続します。 この設定により、システム起動後、自動的にVPN接続が行われます。 *メールアドレス、アカウント名、パスワードを各自変更してください。 自動接続 ユニットファイルの作成が完了したら、起動、自動起動の設定を行って下さい。 #起動 sudo systemctl start cato.service #自動起動の設定 sudo systemctl enable cato.service *初回ログイン時webサイトが開かれ認証が必要となります。 以上で自動接続の設定は完了となります。 再起動を行い無事自動接続ができているか確認しましょう。 まず作成したユニットファイルが実行されているか確認します。 サービスが(enabled)有効化されており、サービスが実行中(active)になっていることが確認できます。 最後にCatoへ自動接続されているか確認します。 ステータスの内容から無事Catoへ接続できていることが確認できました。 まとめ Linux OSにてユニットファイルの作成と起動をさせることで、ユーザー毎にCatoへ自動接続することは可能です。 実環境への導入は、運用上の仕様や要件などを考慮の上、実装ください。

こんにちは、SCSKでAWSの内製化支援『 テクニカルエスコートサービス 』を担当している貝塚です。 ある案件で、PrivateLink経由でRDSエンドポイントに接続したいという要件がありました。 RDSエンドポイントのIPアドレスは、RDSのフェイルオーバーなどいくつかの条件で変化してしまう可能性があるため、IPアドレスではなくDNS名で接続することが推奨されます。（以下記事参照） RDS インスタンスに割り当てられた IP アドレスに関連する問題のトラブルシューティング Amazon Relational Database Service (Amazon RDS) インスタンスに割り当てられた IP アドレスに関する情報を探しています。 repost.aws PrivateLinkはNetwork Load Balancerを使用して実装しますので、接続先(ターゲット)はIPアドレスで指定する必要があります。そのため、フェイルオーバーなどによりRDSのIPアドレスが変わると、PrivateLink経由での接続ができなくなってしまいます。 この問題に対する対応の一例として、これまでは、RDSの発行するフェイルオーバーイベントを拾って、LambdaでNLBのターゲットを書き換えるという対応が取られてきました。 Access Amazon RDS across VPCs using AWS PrivateLink and Network Load Balancer | Amazon Web Services November 2024: This post was reviewed for accuracy. In this post, we provide a solution to access Amazon Relational Data... aws.amazon.com   re:Invent 2024でPrivateLinkの新機能が発表！ AWSが配信している AWS Blackbelt Online Seminar re:Invent 2024 アップデート速報 より引用します。 AWS PrivateLinkを介したVPCリソースへのアクセスが可能に • AWS PrivateLinkを利⽤してVPC内の様々なリソースにアクセス可能に • 従来はNetwork Load BalancerやGateway Load Balancerを使⽤する場合にのみ利⽤できた • 今回のアップデートによりAWS Resource Access Managerを利⽤することで任意のVPC内リソースを共有できるようになった AWSの別の記事 によると、 Now, customers can share any VPC resource using AWS Resource Access Manager (AWS RAM). This resource can be an AWS-native resource such as an RDS database, a domain name, or an IP address in another VPC or on-premises environment. とあります。 つまりは、エンドポイントのDNS名でRDSに接続可能で、NLBの要らないPrivateLinkと考えてよさそうです。 まさに担当案件の悩みを解消する新機能ということで、早速使用してみました。 検証構成 検証構成は以下の通りとしました。 RDSを共有する側のアカウントをアカウントA、RDSを利用する側のアカウントをアカウントBとすると、設定手順は以下の通りとなります。 ① アカウントAでResource Gatewayを作成する ② Resource Gatewayに関連付ける形でResource Configurationを作成。RDSのDNS名やポート番号などを指定する ③ Resource Access ManagerでResource ConfigurationをアカウントBに共有する ④ アカウントBでResource Endpointを作成する ① アカウントAでResource Gatewayを作成する VPCメニューからResource gatewaysを選択し、Create resource gatewayをクリックします。   Resource gateway name, IPアドレスタイプ, 対象のVPCとサブネット, 適用するセキュリティグループを指定してResource Gatewayを作成します。 ここで指定したサブネットからIPアドレスが割り当てられ、共有するリソースへアクセスするときのソースIPになります。少なくともマネジメントコンソールからは、指定できるのはサブネットまででIPアドレスを指定することはできないようです。 ② Resource Gatewayに関連付ける形でResource Configurationを作成。RDSのDNS名やポート番号などを指定する 作成されたResource Gatewayの詳細画面からCreate resource configurationを押してResource Configurationを作成します。   単独のDNS名を指定したい場合はConfiguration typeにResourceを指定すればよいようなのでそのようにします。   TypeはSingleを指定します。(他の選択肢、ChildとARNの使い方については後日記事にする予定です) Resource typeはDNS resourceを選択し、ドメイン名にRDSエンドポイントのFQDNを入力します。   今回、SQL Serverと接続したいので、Port rangesは以下の通り1433のみとしました。 Association settingsはAllowとします。今回はどちらを選んでも関係ないはずです。 Share resource configurationで、Resource Access Managerの設定を指定できますが、今回は、この後Resource Access Managerからリソース共有を設定するので、ここでは空欄にしておきます。 アクセスログの出力先を指定し、Resource Configurationを作成します。 ③ Resource Access ManagerでResource ConfigurationをアカウントBに共有する Resource Access Managerで、自分が共有：リソースの共有から、「リソース共有を作成」をクリックし、リソース共有を作成します。 リソースの種類はVPC Lattice Resource Configurationsです。   共有権限を与えるプリンシパルとしてアカウントBのアカウントIDを指定し、共有を作成します。 ④ アカウントBでResource Endpointを作成する アカウントBでリソース共有を承認後、VPCメニューのエンドポイントを選択し、エンドポイントを作成します。 タイプはリソースを選択します。リソース設定のところに共有されたリソースが表示されるはずですのでそれを選択します。   エンドポイントを作成するVPCとサブネットを選択します。Resource Configurationの作成と同様、(マネージメントコンソールからは)サブネットは選択できてもIPアドレスまでは指定できないようです。 セキュリティグループを選択し、エンドポイントを作成します。   作成されたエンドポイントの「関連付け」タブに、エンドポイントのDNS名が記載されているので確認します。(なぜこんな分かりづらいところに……) 接続確認 アカウントBのEC2から、上で調べたエンドポイントのDNS名にアクセスすると、無事、SQL Serverに接続することができました！ PrivateLinkに期待されている通り、相互に相手のIPを意識することなく接続できています。 なお、CloudWatch Logsを確認すると、以下のようなシンプルなログが出力されていました。 sourceIpPortに、接続に使用したEC2のIP destinationIpPortに、リソースエンドポイントのIP gatewayIpPortに、リソースゲートウェイを作成したサブネットのIP resourceIpPortに、RDSのIP が表示されていることが分かります。 リソースを共有する側に、このようなログという形でアクセス元のIP情報が残るのは、NLBを使用したPrivateLinkとの違いですね。 まとめ Resource Endpointを使用することで、RDSのエンドポイント(DNS名)にPrivateLink経由で接続できることが分かりました。 今回、RDSをMulti-AZ構成にしなかったため、FQDNが複数のIPを返してくるときの動作や、RDSエンドポイントのIPが変わったときの動作を確認することができませんでした。 また、VPC Latticeの新機能との組み合わせにより、柔軟なネットワーク接続が可能になっているようです。 今後、これらのことも記事にしていきたいと考えています。

Catoクラウドに関するお問合せとして、「特定の拠点でどの端末が最も多く通信をしているのか？」や「拠点に負荷をかけている通信は何か？」といった質問をいただくことがあります。 これらの課題を解決できるダッシュボードツールとして、「App Analytics」というものがございます。この記事では、App Analyticsの特徴やその確認方法について紹介します！ 画⾯は2024年12⽉時点のものです。 機能アップデート等で変わる場合がありますので、あらかじめご了承ください。 App Analyticsとは App Analyticsは、アカウント全体、特定のSite、または特定のユーザ単位で、アプリケーションの使用状況とトラフィックを可視化するツールであり、主に以下の特徴を持っています。 特徴その1：可視化と分析 ユーザやアプリケーション、Siteごとのトラフィック量をリアルタイムで表示することができます。 トラフィックの異常や傾向を容易に特定することが可能です。 特徴その2：柔軟なフィルタリング フィルタリング機能を用いて、注目したいデータをピンポイントで絞り込むことができます。 例えば、特定のユーザが利用する「Zoomアプリ」の利用状況といったピンポイントな情報であっても、フィルタリング機能を利用することで容易に確認することが可能です。 特徴その3：アプリケーションのリスク管理 App Analyticsに記録されるアプリケーションには、Cato独自の「リスクスコア」が付与されています。 このスコア（0～10）は、脆弱性のレベルを示しており、潜在的なリスクを迅速に把握することが可能です。 App Analyticsに表示される情報は、通常5分以内に更新されます。 一部のデータは最大30分ほどの遅延が発生する場合があります。 次の項目では、App Analyticsの基本的な見方についてご説明します！ App Analyticsの見方 App Analyticsの画面は、アカウント単位、Site単位、ユーザ単位で開くことができます。 それぞれCMA(Cato Management Application)から以下の流れで開くことができます。 アカウント：Home > App Analytics Site：Network > Sites > Siteを選択 > Application Analytics ユーザ：Access > Users > ユーザを選択 > Application Analytics フィルタリング機能により絞ることもできるのでお好みの方法でお開きください。 App Analyticsの表示説明 上記の手順でApp Analyticsを開くと以下の画面が表示されます。 ※画像はアカウント単位で開いたものです 主な表示内容については以下の表をご覧ください。 番号 名前 内容 ① Time range 表示される情報の期間を設定できます ※期間を最大90日間まで指定可能です ② Events filter bar フィルタリング機能です 絞りたい情報を入力することで表示される情報を絞ることができます ③ Top Users トラフィック使用量が多いユーザが表示されます ④ Top Applications トラフィック使用量の高いアプリケーションが表示されます ⑤ Top Sites トラフィック使用量の高いSiteが表示されます ※Siteにカーソルを合わせると、その名前、場所、および総帯域幅の使用量が表示されます ⑥ Analytics type tabs Analytics data table 表示されているタブ(Site、アプリケーション、ユーザ等)ごとのデータや分析結果が表示されます 「+」ボタンをクリックすることでより詳細な情報を確認することができます ⑥のAnalytics type tabsについて、表示されているタブの役割は以下をご覧ください。 ※アカウント単位、Site単位、ユーザ単位によっては表示されないタブもあります(以下表の表示対象を参照) 名前 内容 表示対象 Site アカウント内のすべてのSiteが表示されます 「+」からSite配下にいるすべてのユーザ情報が確認できます Site配下にいないリモートユーザが「Remote User」として表示されます アカウント Applications 時間範囲内で使用されたすべてのアプリケーションが表示されます 各アプリケーションのリスクスコアをが確認できます(０ ～ 10) ※Custom Applicationリスクスコアは表示されません 全て Categories 時間範囲内で使用されたすべてのカテゴリが表示されます 「+」からカテゴリ内の各アプリケーションが表示されます 全て Users 時間範囲内にCatoに接続しているすべてのユーザが表示されます アカウント、Site Users/Hosts 時間範囲内にアカウントに接続しているすべてのユーザーとホストが表示されます アカウント、Site Sources 時間範囲内にセッションを開始したすべての送信元IPアドレスが表示されます 全て Destinations 時間範囲内にアクセスされたすべての宛先ドメイン/IPアドレスが表示されます 全て Connections 時間範囲内にアカウントに接続しているすべてのユーザーとホストが表示されます 「+」からそのユーザー/ホストが使用する各アプリのトラフィック・フローの宛先と方向が確認できます 全て   App Analyticsの活用例 App Analyticsの表示内容を理解したら、実際にどう役立てることができるのかを以下２パターン別の利用例を用いてご紹介します。 パターン１　拠点に対して 通信量の多いアプリケーションやホストを一目で 特定 はじめに、調べたい拠点(Site)のApp Analyticsを開きましょう。 Network > Sites > Siteを選択 > Application Analytics 表示されたTop Applicationsから使用量の多いアプリケーションを、またTop Users/Hostsから、通信の多い送信元ホストを確認しましょう。 パターン２　 特定の端末が多く通信をしている相手の特定 例えば、ファイルサーバを指定して、どのホストとの通信量が多いかを特定するときなどに利用できる方法です。 はじめに、App Analyticsを開き、調べたいサーバのIPアドレスをフィルターに入力して表示される情報を絞りましょう。 次にSourceタブをクリックし、送信元IPアドレスを全て表示させます。 [Upload]や[Download]などの項目をクリックし、トラフィックの大きい順に並び変えます。 トラフィックの大きい順に並び変えたら、実際に通信量の多いPCを確認しましょう。 まとめ 本投稿では、App Analyticsの見方や活用方法について一例をご紹介しました。 トラブルでお困りの方のお役に立てれば幸いです。 なお、弊社の FAQ サイトでは 、よくあるご質問やCato クラウドのアップデート情報を公開しておりますので、是非ご参照ください！

本記事は、 Japan AWS Ambassador Advent Calendar 2024 の 2024/12/9 付記事です。 こんにちは、広野です。 2024年の re:Invent で、アプリから Amazon S3 バケットのオブジェクトを操作できるようにするための UI モジュールがリリースされました。 Storage Browser for Amazon S3 is now generally available - AWS Discover more about what's new at AWS with Storage Browser for Amazon S3 is now generally available aws.amazon.com 今回は実際に既存アプリに組み込んでみたので、その方法を紹介します。 そもそも何が嬉しいのか 開発したアプリから、S3 のオブジェクトをマネジメントコンソールの UI 風に操作できる。例えば RAG アプリに必要な独自ドキュメントを S3 に格納している場合、アプリの管理画面に S3 操作用 UI を組み込み、メンテすることができるようになる。このニーズはかなりあったはず！これまでは手作りしていた方が多かったのでは？ UI だけでなく、アップロード、削除、変更、フォルダ作成などの機能がモジュールに組み込まれている。アクセス権限制御もそこそこいける。すなわち、開発者がそういったベーシックな機能を開発しなくて済む。超絶楽！ AWS 純正モジュールなので、AWS がサポートしてくれる。安心！ このアップデートは神すぎます。もともと、9月にアルファリリースされていて早期の GA を期待していたのですが、re:Invent に間に合わせてくれて嬉しいです。AWS Amplify がリリースされたのと同じぐらいの衝撃を今受けております。 実際につくってみたもの UI はデフォルトのままにしました。カスタマイズも若干できそうです。 Home デフォルトで表示されます。カスタマイズ可能です。 指定したバケットおよびフォルダの一覧が表示されます。ここに表示されたフォルダ配下のオブジェクトをメンテナンスできます。 権限は Read / Write / Delete が選択できそうです。 Amazon Cognito でアプリにログインしたユーザにのみ、権限を与えています。 フォルダ名を押すと、その詳細が表示されます。ここでは bot1 を選択します。 今時点、オブジェクトがないので No Files と表示されます。 3点リーダーボタンを押すと、操作可能なメニューがハイライトされます。ここでは Upload をします。 右上の Add files ボタンを押すとファイル選択ウィンドウが表示されますが、ダイレクトに枠内に複数のアップロード対象ファイルをドラッグアンドドロップすることも可能です。最後に右下の Upload ボタンを押します。 アップロードが完了すると、Completed のステータスに変わります。今回は省略しますが、転送の進捗がパーセント表示されます。AWS マネジメントコンソールでも、S3 バケットを確認したらきちんとファイルが入っていました。 削除もしてみます。オブジェクトを選択して、Delete を選択します。 削除対象オブジェクトがリストアップされます。 右下の Delete ボタンを押すと、削除されました。省略しますが、マネジメントコンソールの方でも削除されたことを確認できました。 アーキテクチャ 今回、既存のアプリに追加で組み込んでみました。 AWS のアーキテクチャは以下のブログ記事で紹介したものと全く同じですので、こちらをご覧ください。 AWS Amplify Storage を AWS CloudFormation でマニュアルセットアップする サーバーレス WEB アプリ (SPA) から、ファイルをバックエンドにアップロードして処理したいことがあります。AWS Amplify と連携させた Amazon S3 バケット「AWS Amplify Storage」を使用すると、アプリとセキュアに連動したストレージを簡単に作ることができます。 blog.usize-tech.com 2022.05.31 簡単に説明しますと。 Amazon Cognito ユーザープールでアプリの認証をする。 その際に Amazon Cognito ID プールで、認証済みユーザーに任意の Amazon S3 バケットへのアクセス権限を付与する。 アプリから Storage Browser でファイルを Amazon S3 と送受信する。 AWS リソースの設定 上記アーキテクチャが実現できている前提で、以下の作業が必要です。 対象の Amazon S3 バケットに CORS 設定をする。Storage Browser が REST API で S3 にアクセスするため。 Amazon Cognito ID プールで Cognito ログイン済みユーザーに割り当てる IAM ロール (認証されたロール) に、対象の Amazon S3 バケットへのアクセス権限を定義する。 Amazon S3 バケットへの CORS 設定 以下の AWS 公式ドキュメントに書いてある通りです。Allowed Origins に、アクセス元アプリの URL を追加するとよりセキュアです。 Configuring Storage Browser for S3 - Amazon Simple Storage Service To allow Storage Browser for S3 access to S3 buckets, the Storage Browser component makes the REST API calls to Amazon S... docs.aws.amazon.com Amazon Cognito ID プールの認証されたロールの設定 これです。Amazon Cognito ID プールの設定の中に、認証されたロールという設定があります。 ここに、該当の Amazon S3 バケットへの権限を設定します。 AWS が標準として紹介しているのが、Cognito ユーザー単位で権限を制御できるようにしている方法です。 Import an S3 bucket or DynamoDB table - JavaScript - AWS Amplify Gen 1 Documentation Learn how you can import existing S3 bucket or DynamoDB table resources as a storage resource for other Amplify categori... docs.amplify.aws 私はそこまでこだわる理由がなかったので、バケット単位で権限を付与しました。 React アプリのコード React 18.3.1 と Vite を使用している前提です。(Next.js と AWS Amplify は使用していません) おそらく今時点では React 19 はモジュールの Dependency エラーが出るのでお勧めできません。 モジュールは、公式ドキュメント通り以下をインストールしておきます。 npm install --save @aws-amplify/ui-react-storage aws-amplify Installing Storage Browser for S3 - Amazon Simple Storage Service You can install Storage Browser for S3 from the latest version of aws-amplify/ui-react-storage and aws-amplify packages ... docs.aws.amazon.com App.jsx Vite を使用するとソースコードのルートが main.jsx になると思うのですが、私は create-react-app の名残で App.jsx に Amplify.configure を記述していました。AWS ドキュメントには、Amplify.configure はルートに書けとありましたが直すのが面倒なのでそのままにしています。 以下の例のように、Amplify.configure を記述する必要があります。Amplify で環境をデプロイしていないので、設定はマニュアル作成です。※具体的な値は VITE_ から始まる環境変数をビルド時に持ってきます。 import { Authenticator, useAuthenticator } from '@aws-amplify/ui-react'; import { Amplify } from 'aws-amplify'; import Loggedin from './Loggedin.jsx'; import Notloggedin from './Notloggedin.jsx'; //Cognito, S3, AppSync 連携設定 Amplify.configure({ Auth: { Cognito: { userPoolId: import.meta.env.VITE_USERPOOLID, userPoolClientId: import.meta.env.VITE_USERPOOLWEBCLIENTID, identityPoolId: import.meta.env.VITE_IDPOOLID } }, Storage: { S3: { bucket: import.meta.env.VITE_S3BUCKETNAMEAMPLIFYSTG, region: import.meta.env.VITE_REGION, buckets: { amplifystorage: { bucketName: import.meta.env.VITE_S3BUCKETNAMEAMPLIFYSTG, region: import.meta.env.VITE_REGION }, kbdatasource: { bucketName: import.meta.env.VITE_S3BUCKETNAMEKBDATASRC, region: import.meta.env.VITE_REGION, paths: { "bot1/*": { authenticated: ["write", "get", "list", "delete"] }, "bot2/*": { authenticated: ["write", "get", "list", "delete"] } } } } } }, API: { GraphQL: { endpoint: import.meta.env.VITE_APPSYNC, region: import.meta.env.VITE_REGION, defaultAuthMode: 'userPool' } } }); //ログインチェック function Authcheck() { const { authStatus } = useAuthenticator((context) => [context.authStatus]); return (authStatus === "authenticated") ? <Loggedin /> : <Notloggedin />; } export default function App() { return ( <Authenticator.Provider> <Authcheck /> </Authenticator.Provider> ); } 少し解説します。 ベースは、以下の公式ドキュメントの通りなのですが、 それだけでは動きませんでした。 Use Amplify Storage with any S3 bucket - React - AWS Amplify Gen 2 Documentation You can use the Amplify Storage APIs against your own S3 bucket in your account. AWS Amplify Documentation docs.amplify.aws 対象の S3 バケット内のパス (フォルダ) を、指定する必要があります。仕様として、そのフォルダより上位のオブジェクトにはアクセスできません。また、そのフォルダ内のオブジェクトにどの操作を許可するかの定義をします。 以下の paths: の部分です。※これが、ドキュメントには載っていない kbdatasource: { bucketName: import.meta.env.VITE_S3BUCKETNAMEKBDATASRC, region: import.meta.env.VITE_REGION, paths: { "bot1/*": { authenticated: ["write", "get", "list", "delete"] }, "bot2/*": { authenticated: ["write", "get", "list", "delete"] } } } kbdatasource というのは適当に付けた名前なので、ここは任意の名称で問題なさそうです。他の設定と紐づいてはいません。 設定すれば複数 S3 バケットも操作できると思います。少なくとも paths が設定されているバケット、フォルダでないと操作ができなそうです。 Storage Browser の実装 これは公式ドキュメント通りでした。 Storage Browser for Amazon S3 | Amplify UI for React The StorageBrowser component gives your end users a simple, visual interface for working with data stored in S3. ui.docs.amplify.aws デフォルトの UI 設定であれば、以下だけで実装できます。私の場合は Amplify でリソースをデプロイしていないので、Storage Browser を実装したい画面のコードに以下を追加しました。 import "@aws-amplify/ui-react-storage/styles.css"; import { createAmplifyAuthAdapter, createStorageBrowser } from '@aws-amplify/ui-react-storage/browser'; //中略 //Storage Browser const { StorageBrowser } = createStorageBrowser({ config: createAmplifyAuthAdapter() }); //中略 //returnの中で、画面内、表示させたい箇所にこれを差し込む {/* S3 Storage Browser */} <StorageBrowser /> CSSはインポートしておかないと、UI デザインが崩れると思います。 コードはほんの数行なのに、S3 バケット内を操作できる UI が実装できるって、凄すぎませんか！？ まとめ いかがでしたでしょうか。 既存 Amazon S3 バケットに Storage Browser からアクセスする方法は公式ドキュメントには載っていない情報だったのと、GA 直後で情報が少なかったのもあって、調べるのに苦労しました。ちゃんとは言い忘れましたが、AWS Amplify は一切使わず、Amazon CloudFront、Amazon S3 のホスティング環境に AWS CodePipeline 等でビルド、デプロイしています。そんな環境でも Amplify ブランドの UI モジュールは使えますので、ご安心ください。 本記事が皆様のお役に立てれば幸いです。

本記事は TechHarmony Advent Calendar 2024 12/9付の記事です 。 どうも、Catoクラウドを担当している佐々木です。 Catoクラウドを利用しているユーザーから、以下のような問い合わせをいただくことがあります。 Socketから定期的にAmazon.comやGoogle.comにpingしてるけど、これって何？？？   これは 「Synthetic Monitoring」 という品質監視をする機能の動作で、正常なものです！！！ ということで、今回は 「Synthetic Monitoring」  についてご紹介します。   画⾯は2024年12⽉時点のものです。機能アップデート等で変わる場合がありますので、あらかじめご了承ください。   「Synthetic Monitoring」ってなに？ ラストマイルリンク、つまりインターネット回線の品質を監視するCatoの標準機能です。 Socketからインターネット上の特定の宛先（ドメイン、IPアドレス）へ定期的に通信(ICMP)を行うことによって、 インターネット回線上での遅延やパケットロスを監視しています。 「通信が遅いなー」と思った時に、どこが悪いのか切り分けするために活用できる機能ですね。   「Synthetic Monitoring」では、Amazon.comやGoogle.comを含む3つのWEBサイトに対して、 5秒間隔でPINGをするというデフォルト設定がされています。                    そのため、Socketから定期的にAmazon.comやGoogle.comにpingしていたんですねー！   「Synthetic Monitoring」の結果はどこで確認できるの？ 各サイトの「Site Monitoring」にある「Network Analytics」から確認できます。 ラストマイルリンク（インターネット回線）のパケットロスと遅延が確認できます。    例えば、通信が遅いと感じたらこのグラフを確認いただき、いつもよりパケットロスが増えている、遅延（RTT）が高くなっているのであれば、インターネット回線で問題ある可能性が高いので、インターネット回線の提供キャリア（ISP）に確認を依頼するといった対応がとれます。 また、ラストマイルリンクのグラフでは問題ないものの「Network Analytics」内にある別のグラフ「Packet Loss」でパケットロスが増えている、遅延（RTT）が高くなっている場合は、Cato側で問題が発生している可能性があるのでCato側の状態を確認するといった対応がとれます。   ▼イメージ   「Synthetic Monitoring」のチューニング方法 先ほど「Synthetic Monitoring」ではAmazon.comやGoogle.comを含む3つのWEBサイトに対して、 5秒間隔でPINGをするというデフォルト設定がされている、という話をしましたが、もちろんカスタマイズすることも可能です。                    ▼設定箇所 「Network」タブにある「Synthetic Monitoring」から設定できます。 「Internet Applications via local internet breakout」の項目を設定します。  ※チェックボックスを外すと、機能が無効になります。   ▼パラメータ 設定値 設定内容 デフォルト値 Test Interval  Socketからの通信間隔を設定します 5秒 Probe Type 通信の種類が選択できます ICMP/HTTP/HTTPS/DNS/TCP ※ICMP以外は別ライセンスが必要（注意事項参照） ICMP Destinations 通信を行う相手を指定します IPもしくはドメインで最大5つまで設定可能です Facebook.com/Google.com/Amazon.com   注意事項 「Synthetic Monitoring」を利用する際に以下の注意事項があります。 おもにDEM Pro（Digital Experience Monitoring Pro）ライセンスに関連する事項になります。 DEM Proについては、以下の記事をご参照ください。 【Catoクラウド】新オプション! Digital Experience Monitoring はここがすごい! Catoクラウドの新オプション「Digiral Experience Monitoring」の機能をご紹介します。 blog.usize-tech.com 2024.12.06   1.DEM Proライセンスを購入しないと動作しない機能がある DEM Proライセンスを購入しないと「Synthetic Monitoring」の一部機能が動作しません。 しかも、動作はしないのに、設定はできてしまうので注意が必要です。 具体的には以下が該当します。 「Probe Type」でICMP以外利用できません（設定は可能） 「Internet Applications via the Cato Cloud」も利用できません。 ※Catoクラウド経由でインターネットアプリケーションの品質監視をする設定です。 「WAN Applications via the Cato Cloud」も利用できません。 ※Catoクラウド経由でのWAN上のアプリケーションの品質監視をする設定です。 ▼イメージ   DEM Proライセンスを購入すると利用できる「Experience Monitoring」が、もともとフリートライアルで利用できていたことの名残で「動作はしないけど、設定できる」上記の設定箇所が残っているようです。 Catoサポート曰く、まもなく上記設定項目自体を別の場所に移動させるようなので、いずれこの注意点も解消されると思っています。   2.デフォルトの「Amazon.com」を指定すると一部グラフが見にくくなる 日本国内でCatoを利用している場合、Destinationsの「Amazon.com」を変更したほうがいいと思っています。 「Amazon.com」はおそらく 日本国外 のサーバが応答しており、パケットロス、遅延の数値が大きくなりがちなためです。 ▼イメージ   ▼対策 「Amazon.com」を消して、日本国内のサーバが応答するであろうドメインを登録します。 ※Amazon系なら「Amazon.jp」、他にも「Yahoo.co.jp」や通信品質を確認したいWEBサイトを登録してもいいと思います。 3.中国拠点の設定はよりカスタマイズが必要 中国拠点の場合、Socketからデフォルト設定の3サイト（AmazonやGoogleなど）へ通信ができません。 ラストマイル監視が常に100%Lossになってしまうので、中国の拠点だけ「Synthetic Monitoring」の宛先を中国国内からアクセス可能なURLへ変更することをオススメします。 例：「 weibo.com」「baidu.com」「qq.com」など ※サイト単位で 設定する場合は、「該当のサイト」の「Site Configuration」>「Synthetic Monitoring」から設定可能です。   まとめ 今回のポイントは以下です。 ・Socketから定期的にAmazon.comやGoogle.comにPingしてるのは正常な動作 ・Synthetic Monitoringという品質監視をする機能の動作で通信遅延の切り分けに役立ちます ・デフォルトではAmazon.com/Google.com/Facebook.comに5秒間隔でPingを実施 ・自分好みにチューニング可能（一部注意事項あり）   上記以外の情報についても弊社の 「Catoに関するFAQサイト」 に多数情報ございますのでご参考にください。 よくあるご質問 | Cato Cloud ケイトクラウド - SCSK Cato SASE Cloud Platform. powered by SCSK cato-scsk.dga.jp   最後に、SCSKではPoCから導入、運用まで幅広くCatoに関する支援を行っております。 本番構成への移行を見据えたPoC構成や、PoCでつまづきやすい点のサポートなど、豊富な導入実績を基にご支援いたします。 ぜひお声がけください！

本記事は TechHarmony Advent Calendar 2024 12/8付の記事です 。 Catoクラウドの管理者の皆様には、日々様々な通知が届いていませんか？ 今回はCatoクラウドの通知機能についてまとめてみました。 通知というと、セキュリティ関連やネットワーク関連の警告、またはサービス障害関連の通知を思い浮かべる方が多いと思います。 ですが実際には他にも様々な通知が届いているはずです。 今回はCatoではどんな通知機能があるのか整理してみたいと思います。 通知の種類 まず、Catoの通知を大きく分類するとこんな感じです。 No 通知の種類 内容 1 セキュリティに関する通知 各種セキュリティポリシーにマッチした通信の発生をトリガーに通知します 2 Socketの接続に関する通知 Link Health RulesによるSocket 接続状態の異常検知をトリガーに通知します 3 インシデントの通知 XDR機能によるインシデントの検知をトリガーに通知します 4 CMAのシステム通知 Socketのアップグレード結果やライセンスの有効期限などを通知します 5 アップデート情報の通知 週に1度、機能強化や新機能に関する情報が通知されます 6 サービス障害・メンテナンス通知 各PoPのメンテナンスやサービス全体に関する障害が発生した場合に通知されます これらの通知は、デフォルトで通知が有効化されているものとそうでないものがあります。 結論からお伝えすると、CMAのシステム通知(No.4)とアップデート情報の通知(No.5)はデフォルトで有効化されており、その他は管理者の設定次第となっています。 デフォルトで有効化されて いる もの → アップデート情報の通知，CMAのシステム通知 デフォルトで有効化されて いない もの → セキュリティに関する通知，Socketの接続に関する通知，インシデントの通知，サービス障害・メンテナンス通知 こう見ると、ほとんどが管理者の設定次第ということがわかります。 さらに、有効/無効化および通知先と通知タイミングの設定は、CMAからできるものとできないものがあります。 少しややこしいので、今回はこのあたりを整理していきます。 CMAで設定するもの それでは、まずCMAから設定できるものです。 No.1 セキュリティ機能による通知 セキュリティ機能による通知は管理者であればご存知と思いますが、ポリシーにマッチした通信の発生をトリガーに通知するものです。 例えばInternet Firewallであれば下図のような「Security Alert」が通知されます。 各ポリシーを定義する際に通知の設定を行いますが、この時すべてのポリシーに対して通知設定をする必要はなく、重要なポリシーに対してのみ通知の設定を行うとよいかと思います。 また、Catoがデフォルトでポリシーを定義している場合があります。 例えばIPS・DNS Protection・Anti-Malwareです。Internet Firewallのカテゴリフィルタなどのポリシーもそうですね。 このようなデフォルトで定義されているポリシーは通知が無効化されていることが多いです。 これらのデフォルトポリシーは、通知が大量に飛んでしまう可能性を考慮し基本的にはそのまま(無効の状態)で問題ございませんが、各企業のセキュリティポリシーに沿って変更を検討いただくのもよいかと思います。 No.2 Socketの接続に関する通知 Socketの接続に関する通知は、Link Health Rulesという機能をを使います。 Link Health RulesにてSocketの接続状態における異常を検知するようルールを定義し、異常の検知をトリガーに通知します。 例えば、SocketのDisconnectを検知した際は下図のような「Health Alert」が通知されます。 また、Link Health RuleにはConnectivity Health RulesとQuality Health Rulesの2つがあり、CatoのBest Practiceによるとこれらは 設定しておくことが推奨 となっております。 詳しい設定方法は本記事では割愛しますが、それぞれで検知できる内容をまとめるとこんな感じです。 Connectivity Health Rules 以下のような接続の正常性に関するイベントを選択し、そのイベントの発生をトリガーに通知します。                                                  No イベントの種類 説明 1 Failover プライマリリンクとセカンダリリンク間、またはその逆のフェイルオーバー 2 Primary Disconnect アクティブ状態のリンクの切断 3 Secondary Disconnect パッシブ状態またはラスト リゾート ステートのリンクの切断 4 Socket Failover HA 構成のソケット間のフェイルオーバー 5 Internet as a Transport インターネット(Cato Cloudではない)を介してデータを転送しているリンクの切断 Quality Health Rules 以下のような接続の品質閾値を設定し、評価期間にその設定した閾値を満たない場合に通知します。 この時、品質閾値は複数を組み合わせて設定することができます。                                                  No 品質閾値の種類 説明 1 Packet Loss 送信パケットの割合 2 Distance (msec) 送信元と PoP 間でパケットが移動するのにかかる時間 (ミリ秒) 3 Jitter (msec) パケット間の遅延 (ミリ秒単位) 4 Congestion 輻輳（評価期間に破棄されたパケットが1%を超えた状態） No.3 インシデントの通知 CatoではXDRという機能により、セキュリティを脅かすインシデントを自動的に検知する機能が提供されています。 検知したインシデントのことを「ストーリー」と呼んでいますが、Detection ＆ Responseという機能を使えばそのストーリー生成をトリガーに通知させることができます。 例えば、危険なマルウェアの侵入口なる可能性を秘めたダウンローダーを検知するストーリーが生成された際に「Detection ＆ Response Alert」を通知します。 また、各ストーリーには「Criticality」という重要度を表す値が1 (低) ～ 10 (高) で付与されます。 Criticalityが7以上のストーリーは注意が必要だと言われていますので、Criticalityが7以上のストーリー生成をトリガーに通知を行うことを推奨しています。 こちらも設定方法の詳しい説明は割愛しますが、このようにCriteriaで条件を定義することができます。 No.4 CMAのシステム通知 CMAのシステム通知とは、Socketのアップグレード結果の通知やライセンスの有効期限の通知など様々です。 2024年12月時点では、CMAのSystem Notificationsのページで設定ができるようになっており、デフォルトで以下のイベントをすべての管理者へ通知する設定となっています。 No イベントの種類 内容 1 Data Export CSVファイルなどのデータエクスポート 2 Expired Signing Certificate デバイス認証に使用されるルートCA署名証明書の有効期限切れ 3 SCIM Provisioning SCIMプロビジョニングの成功または失敗 4 Admin Locked/Unlocked CMAの管理者アカウントロックとロック解除 5 User Locked/Unlocked Catoクライアントのロックとロック解除 6 License Updated ライセンスの有効期限切れ・更新・変更 7 Activate New Socket Socketのアクティベート（Siteとの紐づけ）準備完了 8 General Notification CMAアカウントに影響を与える状況に対する特別なお知らせ ※ほとんど送信されません。 9 Socket Upgrade Socketバージョンアップの連絡 10 DC Connectivity Failure User Awarenessのディレクトリ サービス同期に使用されるWMI コントローラの失敗 11 Directory Services Sync LDAPを使用したディレクトリ サービス同期の失敗 例えば、Socketのアクティベート準備が完了した際は、下図のように「Activate New Socket」が通知されます。 次に、設定方法についてです。 設定方法 設定方法はNo.1～4すべて同様です。 「Send Notification」にチェックを入れることで通知機能の有効化を行い、通知先と通知タイミングを定義していきます。 以下は管理者全員に即時でメール通知する方法で、一番スタンダードな設定方法です。 Send notification to：Mailing List（All Admins） Frequency：immediate 事前に定義しておけばCMAの管理者以外にメール通知させることも可能です。 また、メールによる通知だけでなくWebhookを使ってSlack、ServiceNow、Jira、その他Webhook 経由でのアラート受信に対応しているサービスに対して通知を行うことも可能です。 Webhook機能を利用してSlackに通知する方法はこちらの記事をご参照ください。 Catoからの通知をWebhook機能を利用してSlackで受信してみた Catoが提供しているWebhook機能を実際に試してみました。 blog.usize-tech.com 2024.02.19 通知メールのカスタマイズ 少し話が脱線しますが、通知メールのカスタマイズ機能があることをご存知でしょうか？ デフォルトでは下図のようにCatoのテンプレートになっていますが、Email Templateページにて各企業ブランドに合わせてカスタマイズすることができます。 特に③の「Contact us message」の部分関しては、具体的な連絡先に変更すると便利だと思います。 E-mail Logo Brand Color Contact us message CMAで設定できないもの では、続いてCMAから設定ができないNo.5、No.6についてです。 No.5 アップデート情報の通知 Catoでは毎週のように機能強化や機能追加が行われており、日本の場合は毎週日曜日の夜中～月曜日の早朝にかけて下図のような「Product Update」が管理者に通知されます。 この通知は、管理者として登録がされた時点でデフォルトで有効になり、Catoから自動でメール配信される設定になっています。 そのため、管理者にてCMAから無効化や通知先・通知タイミングの変更を行うことができません。 もし配信をとめてほしいといった場合は、メール本文の一番下にある「unsubscribe from this list」をクリックし、次のページで「Unsubscribe」をクリックします。こうすることで購読停止が可能です。 ですがアップデート情報の中には、重要な情報も含まれますので、購読停止はせずに内容をご確認いただくことをお勧めします。 No.6 サービス障害・メンテナンス通知 最後に、サービス障害・メンテナンス情報の通知についてです。 サービス障害・メンテナンスはサービス停止を伴う場合があり非常に重要な情報なのですが、なんと 管理者ご自身で 通知の設定をしないと通知がされません！ ですので、必ず 設定をしておくことを推奨 します。 通知設定を行うと、例えば緊急メンテナンスが行われる際に下図のような「Emergency Maintenance Notification」が通知されます。 また、PoP障害の場合は「PoP Infrastructure – Services degradation due to（原因）」が通知されます。 詳細はこちらの記事でご説明しておりますのでご参照ください。 Catoクラウドのステータスページについて Catoクラウドでは、現在のサービス状態や定期メンテナンスなどの情報を確認できるステータスサイトのページがあります。 今回はステータスページについて、見方や使用方法を確認していきたいと思います。 blog.usize-tech.com 2024.02.06 まとめ 最後に、本記事のまとめです。 この記事が、今一度通知設定を見直すきかっけになれば幸いです！ 通知機能はデフォルトで有効化されているものとそうでないものがある 通知機能はCMAで設定できるものとできないものがある サービス障害・メンテナンス通知はデフォルトで無効になっているため設定するを推奨します Socketの接続に関する通知もCatoのBest Practiceに準じて設定することを推奨します

本記事は TechHarmony Advent Calendar 2024 12/7付の記事です 。 こんにちは、Catoクラウド担当SEの中川です。 本記事では、年末ということで、2024年のCatoに関する、価格改定などお客様のお財布事情に影響の高かったお知らせや、ユーザーの目を引いたアップデート情報などご紹介します！ 価格改定・サービス体系の変更 早速ながら価格の話になります・・！ 2023年11月3日、Cato Networks社から Pricing Update として全世界のパートナーに対して一斉に通知が行われました。 2024年2月以降の価格体系および価格の見直しが行われるという内容が発表されました。 年明け早々の話題でしたので詳細な解説は不要かと思いますが、おさらいしたい方は以下の記事をご覧ください。 Catoクラウドの価格改定（Pricing Update）について 2023年11月にアナウンスされたCatoクラウドの価格改定（Pricing Update）について現行サービス体系との差異を中心に解説します。※実際の価格については記載していません。 blog.usize-tech.com 2023.12.25 概要をお伝えしますと、価格は日本においては円安の影響が大きく、 値上げ となりました。 価格体系の変更については、リージョンやSiteライセンスのPoP接続帯域の統廃合、セキュリティオプションが統廃合されました。 また、新サービスとして、XDR Security Pro、Endpoint Security（EPP）、Socket X1600 LTEモデルについての発表が行われました。 2024年最新版のサービス体系の詳細は、以下の記事をご覧ください。 Catoクラウドのサービス体系について（2024年最新版） 2024年2月以降のCatoクラウドの新しいサービス体系（基本料金、オプション料金、マネージドサービス）について解説を行っています。 blog.usize-tech.com 2024.01.29 特に価格改定の影響は、日本ユーザへ大きな影響を与えました。 さらに直近、日本とアメリカでは政治の変わり目が訪れました。政治経済が不安定な中、為替相場の変動も大きい状況です。 Catoのみならず、特に海外製品のクラウドサービス利用にあたっては、こういった価格改定が起きうることを、常に念頭に置いておくことが重要かもしれません。 新サービスのリリース ここでは、2024年Cato社がリリースした新サービスをご説明していきます！ 上記サービス体系の変更でも少し触れましたが、2月早々にEPPとXDR Security Proがリリースされました。 さらに、トライアルとして無償提供されていたExperience Monitoringが、11月にDEM (Digital Experience Monitoring) という名前で有償版としてリリースされました。 EPP 2024年2月5日に、新サービスとしてEPPとXDR Security Proがリリースされました。 詳細なご説明は以下の記事をご覧ください。 CatoクラウドのEPPとXDRについて Catoクラウドで新たにリリースされたEndpoint Protection（EPP）とExtended Detection and Response（XDR）についての解説をしています。 blog.usize-tech.com 2024.02.14 EPPとは、「Endpoint Protection Platform」の略称です。PCなどのエンドポイントデバイスを、サイバー脅威から保護するセキュリティ製品のことを言います。 EPPは、端末にEPPソフトウェアをインストールして利用します。 Catoクラウド上を流れるネットワークを超えて、エンドポイントまでをCMA上で管理可能となる製品となっています。 XDR Security Pro 続いて、XDRです。 まず、XDRは、「Extended Detection and Response」の略称です。 簡単に申し上げると、エンドポイントやネットワーク、セキュリティ、クラウドといった各種のログを収集・分析し、攻撃を可視化、インシデント管理を一元化できるセキュリティソリューションのことです。 CatoのXDRは、世界初のSASEベースのXDRソリューションで、Catoクラウドで検知したイベントをもとに分析した結果がCatoの管理コンソール上で確認可能です。 また、その分析結果をもとに、Cato管理コンソール上でスムーズに必要な対処まで行うことができることが魅力となっています。 DEM Pro (Digital Experience Monitoring Pro) Experience Monitoringとは、その名の通り、(ユーザの)体験を監視することができる、2024年11月3日にリリースされたばかりの新機能です。 具体的には、アプリケーションのパフォーマンスのほか、端末のCPU/メモリ、Wifi、回線/プロバイダの状況まで可視化でき、通信経路上の問題の早期発見と迅速な解決が可能となるオプションサービスです。 通信遅延が発生しても一体どこに原因があるかわからない、切り分けが困難なときに、この機能を利用すればCMAで即時に判断できるため、ネットワークの運用担当にとって、大変有用な機能なのではと思います。 要注目なアップデート情報 Catoクラウドでは、上記のような大々的な新サービスリリースの他、毎週のように機能アップデートが行われています。 ここでは、今年の1月から遡り、11月までの少しばかり目を引いたアップデートをいくつかご紹介していきます。 なお、弊社の FAQサイト では、毎週情報更新し掲載しておりますのでぜひご購読ください！ 1月 アラート通知のWebhooksサポート 1月29日のアップデート です。 Webhookを使用して、サードパーティのプラットフォームにアラートを送信し、アラートベースの自動化フローを作成できるようになりました。 カスタムヘッダーのサポートを含む高度なカスタマイズが提供されています。 メッセージ本文をカスタマイズしたり、事前定義済みのテンプレートの使用もできます。 1月 CASBでアプリカテゴリにてアクティビティの制御が可能に こちらも 1月29日のアップデート です。 CASBの機能が強化され、特定のアプリだけでなく、アプリカテゴリに対するアクティビティを制御できるようになりました。 例えば、次のようなことが可能になりました。 ファイル共有（File Sharing）またはオンラインストレージ（Online Storage）カテゴリのアップロードをブロックするルールを設定し、新しいアプリがカテゴリに追加されると、ルールが自動的に更新されます。 一緒に管理したいアプリを含むカスタムカテゴリを定義し、そのカテゴリのダウンロードをブロックする単一のルールを作成する。サポートされるアクティビティには、アップロードとダウンロードが含まれます。 2月 イベントにセキュリティに関するフィールドが追加 2月には先述の通り、XDRとEPPがリリースされましたが、もちろんその他にもアップデートは多数あり、 2月19日のアップデート から1つご紹介します。 このアップデートではイベントログとして出力されるログ情報に、セキュリティ関連の情報が追加されました。 例えば、インターネットファイアウォールイベントを使用して、TLSインスペクションされたのかバイパスされたのか、またどのネットワークルールがマッチしたのか、さらにQoSプライオリティ値とPoPのパブリック・ソースIPの情報が確認できるようになりました。 3月 RBIの機能強化 3月18日のアップデート により、リモートブラウザ隔離（RBI）で行うようにする制御が細かく指定できるようになりました。 アップロード、ダウンロード、コピー/ペースト、印刷などの操作をブロックまたは許可できるようになりました。 加えて、Read Only設定も追加され、ユーザがサイト上で認証情報やその他の機密データを入力できないような制御も可能となりました。 4月 UserAwareness機能にて、Azure ADでSCIMプロビジョニングされたユーザーを識別可能に 4月15日のアップデート で公表されました。 Cato Identity Agentは、Microsoft Azure ADハイブリッドジョインを使用するときに、サイト配下にいるSCIMプロビジョニングされたユーザーを識別できるようになりました。 また、これまではAzure ADでSCIMプロビジョニングしているユーザーには、SDPライセンスが必要でしたが、本アップデートにて必要なくなりました。 5月 CASB・DLPでブロック通知が表示されるように 5月6日のアップデート です。 ユーザーエクスペリエンスを向上させるために、CASB・DLPによってブロックされたときの通知を有効にできるようになりました。 これまでCASB・DLPのルールでブロックされた際には、Catoによるブロックとは分かりづらく、何らかのエラーで操作できないことしか分からない状況でした。 本アップデートで、操作がブロックされた原因がCatoによる制御であることが、ユーザにとって分かりやすいよう改善されました。 6月 SLA計測のメカニズムを改善 こちらは 6月3日のアップデート で公表されたものです。 SiteのSLAを計測するメカニズムの粒度が改善されました。特定のパーセンテージの時間ウィンドウを定義し、そのウィンドウ内でSLAが守られているか判断します。 例えば、パケット損失が120秒の時間ウィンドウの50%に設定されている場合、そのウィンドウ内で60秒間パケット損失が発生すると、そのSiteは許容できないSLAの値として判定されるよう設定可能になりました。 6月 複数の管理者でインターネットファイアウォールの同時編集が可能に 6月17日のアップデート で公開された機能です。 タイトルの通りではありますが、インターネットファイアウォールポリシーを複数の管理者が並行して変更できるようになりました。 また同時に、多数のルールがある場合にも応答性が高くなり、インターネットファイアウォールポリシーを管理するためのAPIがサポートされるようになりました。 加えてこの3か月後の 9月16日のアップデート にて、WANファイアウォールでも同様の機能が追加されました。 6月 リモートユーザーセッションの取り消し機能追加 これもまた6月になります。 6月24日のアップデート になります。 ネットワークへのアクセス制御を強化するために、すべてのデバイスでセッションを取り消すことができるようになりました。 取り消したリモートユーザには再認証が強制されます。ユーザーは新しいセッションを確立するために再認証するまでネットワークにアクセスできません。 セッションの取り消しは、盗難デバイス、アカウントの侵害、すでに退職している従業員などによる不正アクセスを防ぐのに役立ちます。すべての認証方法、IdP、およびすべてのクライアントバージョンでサポートされています。 7月 モバイルユーザーの初回接続手順の簡素化 7月22日にリリースされたアップデート です。 ユーザーがCatoクライアントでサインインする際に、Catoクライアントを起動しメールアドレスを入力したタイミングで、Activationメールが送信されるようになりました。(LDAP / 手動登録の場合のみ) それまでは、Cato管理者がユーザ作成したタイミングでActivationメールが自動送信されていました。本アップデートにより、ユーザは自分のタイミングでパスワード設定できるようになりました。 8月 デバイスポスチャにて、実行中プロセス/レジストリキー/プロパティリストが選択可能に 8月5日のアップデート です。 セキュリティ強化のため、実行中のプロセス、レジストリキー（Windowsデバイス上）、およびプロパティリスト（macOSデバイス上）のチェックをデバイスポスチャの条件に指定できるようになりました。 9月 デフォルトのTLSインスペクションバイパスルールの可視化 こちらは 9月2日のアップデート です。 TLSインスペクションを適用すると問題を引き起こす可能性のある特定のアプリ、OS、クライアントをCato社はデフォルトでバイパスしています。 これらのデフォルトのTLSインスペクションルールがCMAで閲覧可能になりました。CMA ＞ Security ＞ TLS Inspection内のDefault Bypass Ruleから確認できます。 10月 Azure vSocketが2 NICをサポート 10月7日に公開されたアップデート です。 最新のvSocketファームウェアにて、2つのNICを持つAzure VMをサポートするようになりました。 これにより、小規模なVMインスタンスタイプを使用してAzureのコストを削減できます。 既存の3 NIC vSocketは、新しい2 NIC VMインスタンスに移行可能です。なお、3つのNICも選択は可能です。 早速SCSKでは移行手順を確認し、以下の技術ブログにて詳細をご説明させていただいております。Azure vSocketご利用中の方はぜひご覧ください。 ・ 【Catoクラウド】AzureのvSocketが2ポート対応した件 11月 CMAのUIが大幅変更 こちらは直近 11月18日に公表されたアップデート になります。 CMAのUIが大幅に変更されるという内容で、主に、旧レイアウトでMonitrotingのメニューにあるダッシュボードが、Access / Network等の機能別メニューの配下へ移動されます。 また、ページのお気に入り機能の追加もされるようです。ブラウザのブックマーク機能のようなもので、お気に入りにしておくと即時に登録したページに移れるという機能です。 なお、本アップデートで変更されるのはレイアウトのみで、ご利用いただける機能には変更はないことご安心ください。 2024年12月7日現在、CMA画面右上にトグルスイッチが表示されており、旧レイアウトと新レイアウトの切替えが可能となっております。 将来的にはすべてのアカウントで新メニュー画面が適用される予定となっていますので、早いうちに使い慣れておくことをオススメします！ 業界ニュース 最後にCato、SASEにまつわる業界ニュースを2つ取り上げます！ Cato Networks社、シングルベンダーSASEのリーダーに Cato Networks社が、2024年7月3日に発行された ガートナー（Gartner™）のマジック・クアドラント（Magic Quadrant™）のシングルベンダー SASE 部門においてリーダーに認定されました。 2023年はチャレンジャー認定でしたが、2024年はリーダーに認定されました。 シンプルで統合された管理画面 CMAがユーザから高い支持を得ており、その結果として、ユーザエクスペリエンス（UX）についても、他ベンダーと比較して高い評価を得ています。 詳細は以下のブログをぜひご覧ください。 Cato Networks社が 2024年 ガートナーのマジック・クアドラントのシングルベンダー SASE でリーダーに認定 Cato Network社 Catoクラウドが 2024年最新版 ガートナー マジック・クアドラントのシングルベンダー SASE でリーダーに認定されました blog.usize-tech.com 2024.07.22 Cato Networksの「Partner Summit 2024」にて2年連続でパートナーアワード受賞 宣伝にはなりますが、ありがたいことにSCSKは、2回目の日本開催となる「Partner Summit 2024」 において「Best Partner Marketing Campaign 2023」を受賞しました。 SCSKは、Catoクラウドのビジネス拡大に向け、認知向上、新規案件の創出を目的としたマーケティング面で、顕著な成果を上げたことを評価いただきました。 2年連続でパートナーアワードを受賞できたことを大変光栄に思います。 これからも、このSCSK技術ブログ「TechHarmony」への記事投稿も継続し、さらにCatoクラウドのデジタルコンテンツの拡充を図って行きたいと考え直近ではYoutubeへのトラブルシュートのための動画アップロードを始めています。ぜひこちらもご参照ください！ ↓Youtube動画リンク集↓ 設定方法やトラブルシュートの動画集 | よくあるご質問 | Cato Cloud ケイトクラウド - SCSK 設定方法やトラブルシュートに役立つ動画集です。【Catoクラウド】通信ログ(Events)の確認方法【Catoクラウド】拠点全体でインターネット... cato-scsk.dga.jp まとめ 今年のアップデート総まとめ、いかがでしたでしょうか。 2024年は、年明け早々にサービス体系の変更・価格改定、新サービスのリリースから始まった年でした。 1年分のアップデート情報を振り返ってみて、セキュリティ強化と運用の利便性向上が特に目立った1年だったと感じます。 これはCatoが現代のセキュリティ需要に応えると同時に、ユーザ企業自身でも簡単に運用ができる製品を目指しているのではないかと思っています。 来年のアップデート情報にも期待が高まります！

本記事は TechHarmony Advent Calendar 2024 12/6付の記事です 。 本記事では、2024年11月3日にリリースされた、Catoクラウドの新しいオプションである「Digital Experience Monitoring」をご紹介します。 Experience Monitoringとは、ユーザがWebサイトやSaaSアプリケーションを利用する際に、通信が遅くないか、どのくらい快適に利用できているかを可視化する機能です。 もともとCatoクラウドではExperience Monitoringの一部機能をトライアルとして提供していましたが、2024年11月3日から機能拡充し、有償オプションにリニューアルしています。このオプションサービス名が 「 Digital Experience Monitoring 」(以下 DEM ) です。 なお、リニューアル前のExperience Monitoringについては、以下の記事でご紹介しています。あわせてご参照ください。 ユーザー通信可視化の新機能！Experience Monitoringについて ユーザー通信可視化の新機能！「Experience Monitoring」について紹介します。 blog.usize-tech.com 2024.02.08 DEMで何ができるの? 以前のExperience Monitoringの機能はすべて利用できる他、さらに以下3機能が追加されています。 Device Monitoring ユーザ環境について、かなり詳細な情報が取れるようになりました。 Synthetic Probe Monitoring 通信品質を判断するための通信対象を、柔軟にカスタマイズ指定できるようになりました。 XDRでのExperience Anomaly検知 SiteのExperienceの急激な変化を、XDR Storyとして検知・通知できるようになりました。 これにより、 「ユーザが快適に業務アプリを使えているかのモニタリング」がより細かくできる ようになり、また 問題発生時の原因箇所の特定がより簡単に なりました。 本記事では、これらの新機能を中心に、できることや活用方法をご紹介していきます。従来の機能については、前述のExperience Monitoringの記事をご参照ください。 新機能1) Device Monitoringとは? Device Monitoringは、 Catoクライアント (※) をインストールしているモバイルユーザの環境を、詳しく確認できる機能 です。画面を見るとその機能が一目瞭然です。 ※2024年11月現在、WindowsとMacOSクライアントのみの機能です。 特定の1ユーザのExperience Monitoring画面を例にご紹介します。 ユーザごとの画面は上記のようになっています。 ① ユーザ名、接続PoP、利用デバイス名、OS、クライアントのバージョン、接続ISPなどの基本情報 ② 指定期間内のユーザのExperienceの状況 ③ 端末からアプリケーションまでの間で、どの箇所に問題がありそうかの分析 ④ ③の各項目の詳細情報 上記スクリーンショットの例を見ると、端末、Wi-Fi、LANの状況は 緑表示 で良好そうで、その先のLast Mile(回線・プロバイダ)やApplication側の通信は 黄色表示 の普通、全体として Fair (普通)という状況です。 ④の各項目では、以下の詳細情報が確認可能です。アイコンと詳細情報は、以下の図のように対応しています。 項目名 確認できる内容 アイコンがPoor(赤色)のときに疑われる事象 Device Hardware Catoクライアントが収集した、その端末のCPU使用率、Memory使用率 端末自体の負荷が高く、動作が遅くなっている可能性があります。端末の状況を確認します。 Wi-Fi 端末が接続している無線アクセスポイントの電波強度 利用環境のWi-Fiの電波が弱い可能性があります。 LAN Gateway 端末が接続しているLAN内のゲートウェイへのPacket Loss、Distance LAN内で、通信混雑・不安定などが発生している可能性があります。 Last Mile 端末からCato PoPを通らずにInternetへ出る場合のPacket Loss、Distance、またCatoクライアントのTunnel接続時間 インターネット接続環境の通信品質が良くない可能性があります。 Application Performance Cato PoPを経由してアプリケーションへ接続する際の応答時間 また、設定した 「Synthetic Probe Monitoring(※)」の観測状況 ※次項にてご紹介します ‐ Applications アプリケーションごとの応答時間や接続状況(Good/Fair/Poor) 特定のアプリケーションだけがPoorの場合、そのアプリケーションの反応が良くなかったり、ご利用地域からのサーバまでの距離が遠い可能性などがあります。 各項目を確認することで、例えばユーザから「特定アプリへの通信が遅い」と申告があった際に、何が原因になっているのかのアタリを簡単につけることができます。これは便利ですね! 新機能2) Synthetic Probe Monitoringとは? Application Performanceで通信品質を測定する際の、通信先となる対象を、柔軟に設定できる機能です。 DEMオプションを契約している場合のみ、Cato管理画面に「 Experience Monitoring Probes 」という設定項目が表示されます。 デフォルトの状態では、測定対象(Probe)として”catonetworks.comへのICMP通信”が定義されています。これは、全Site・全Userについて「 catonetworks.comへのICMP応答によって、Application Performanceを測定することとする 」という設定です。 ですが、ユーザにとっては、catonetworks.comへのICMPが早くても遅くても、業務にはおそらく影響しないので、ユーザの通信体感を測る目的には合っていなそうです。 そこで、ここのProbeを業務でよく使う通信先・通信内容に設定します。例えば「outlook.office.comへのHTTPS接続」(※)などです。ProbeはInternetとWANの両方が設定できますので、 業務でよく使うSaaSと、オンプレシステムの2つを登録 しておくと、InternetとWAN両方の通信状況が可視化できて良いかと思います。 ※ProbeはICMPの他、HTTP、HTTPS、DNS、TCPが指定できます。 また、設定したProbeは、指定したSiteやユーザ、またグループにのみ適用することも可能です。設定例として、国・エリアによって使うアプリが違う場合には、それぞれ異なるProbeを指定するといったことができます。 ユーザの利用体感に近いデータを測定できるよう、そのユーザが業務でよく使うアプリケーションをProbeとして設定するのがポイントです。 Device MonitoringとSynthetic Probe Monitoringで何ができるの? Probeを設定すると、前述の「 Application Performance 」にて、指定したProbeへの通信状況のグラフが表示されます。 以下の例は、Internet向けに「teams.microsoft.com」を指定し、WAN向けには何も指定していない状態です。 見ると、TeamsへのPacket lossが100%になっているような時間帯があり、一時的にTeams通信に問題が出ていたことが予想されます。 その時間帯の他の監視項目(Device Hardware、Wi-Fi、LAN Gateway、Last Mile)を見てみて、特に問題が無いようであれば、Teams側で何らかの問題が発生していたかもしれません。 用途としては、例えばユーザから「最近社内システムへの通信が遅い」という申告があった際に、Synthetic Probe Monitoringのグラフを見て、以前と現在とで変化があるか、他のユーザはどうなのかといった情報を確認し、問題の切り分け材料にできるかと思います。 新機能3) XDRでのExperience Anomaly検知 ここまでご紹介したExperience分析は、モバイルユーザだけでなく、Site内にいるユーザや、Site(拠点)自体に対しても可能です。 このうち、SiteのExperienceについては、普段と異なる、急激なレスポンス悪化等があったときに、Cato XDRのStoryとして検出し、管理者へ通知することが可能になりました。拠点の通信状況の監視手段としてぜひ活用いただきたいです。 (余談)Good/Fair/Poorをどう判定しているの? ところで、Experience Monitoringの Good / Fair / Poor  はどういった基準で判断されているのでしょうか。 Catoによると、すべてのCatoユーザが生成した実際のトラフィックから、AIでベースライン(期待される基準)を規定し、そのベースラインよりも良いか、同じくらいか、悪いかで判断しているそうです。ベースラインは動的に変化するため、同じようなExperienceでも、日によって判定が違うということはあるようです。 決まったしきい値があるというわけではないので、問題切り分け時の参考情報のひとつとして見ておくのがよいかなと思います。 まとめ 以上、「Digital Experience Monitoring」の新機能についてご紹介しました。 Experience Monitoringは、個々のユーザが快適に業務を行えているかを可視化できます。 検証している我々も「Catoクライアントを入れているだけで、ここまでユーザの状況がわかっちゃうのか!」と驚きました。ネットワーク管理者の強い味方になる機能ですので、ぜひ導入をご検討ください。 機能の詳細は、以下のCato Knowledge Baseも合わせてご参照いただけますと幸いです。 Experience Monitoring | Cato Knowledge Base

この度、4年ぶり位にCato Management Application（CMA）がリニューアルされます！ リニューアルと言うと大袈裟かもしれませんが、メニュー構成の変更により特定のサービスやコンテンツの配置が変わってより使いやすくなるというものです。 実際に見てみた感想としては、各サービスやコンテンツが然るべきところに収まったという印象です。 CMAのAdminアカウントをお持ちの方には、アップデートの通知が届いていることと思いますし、またCMAにログインした際、ページ上部に「Try New Navigation」というトグルスイッチが表示されているのでもうお気付きかもしれませんね。 この記事では、今回の変更についてご紹介しますので是非ご覧ください！ CMAの特徴 今更ですが、CatoクラウドのCMAの特徴について少しだけ述べたいと思います。 CMAの一番の売りは、全てのネットワーク設定やセキュリティ設定はもちろん、Catoを通過した全てのログが1つのコンソール画面で見る事ができる点と、ネットワークエンジニアならある程度直感で操作できるような使い勝手の良さです。 文章で書いても伝わりにくいと思うのですが、個人的に良いと思うところは以下の通りです。 メニュー構成がシンプル 通信ログが1つのEventで完結しているので状況把握や切り分けが早い 各機能の設定方法の親和性が高いので抵抗感がない 契約内容が確認できる 以前はいくつかの機能の中には独特の設定方法があったのですが、徐々に「オブジェクトを組み合わせてルールを作り、そのActionを決める」設定方法に統一されてきた感じがあります。なので初めて使うセキュリティ機能やSD-WANの設定も直感でできてしまいます。 実際のお客様でも、操作概要を説明した後は我々のサポートがなくても一通りの設定ができてしまうケースも多くあります。 また、契約しているサービスの内容やSocketのシリアルNoなども一覧で見ることができ構成管理的なところもフォローしているので、管理資料の数が圧倒的に少なくなりました。以前はVisioでネットワーク構成図を作り、ExcelでFirewallの設定やルーティング情報、機器管理表を作成してコツコツ更新していましたが、そんな手間は一切なくなりました！ リニューアルの理由 話はそれましたが、今回のリニューアルは以下の課題をクリアする目的があったようです。 新しく追加されるダッシュボード系のサービスがすべて「Monitoring」に追加されて数が増えてきた 設定とモニタが別のタブにあったため、タブ間の行き来が多く発生していた 新サービスが追加される際、明確な配置基準がないため、見たいメニューやコンテンツを探すのに時間がかかっていた Catoでは新しいサービスが次から次へとリリースされるので、これまでのメニュー構成とのGAPが大きくなってきたのだと思われます。また新たなメニュー構成は、Catoの今後のサービス拡充の方向性に沿ったものであると想像できます。 旧ナビゲーションはいつまで使えるのか？ 今回のリニューアルは2024年9月のUpdate情報に掲載されました。我々としては、メニュー構成の変更により公開している操作手順やセミナー資料の更新が発生するのでリニューアルの時期を気にかけていたのですが、11月になってようやくリリース、その後徐々にお客様のアカウントにも切り替えのトルグスイッチが表示されてきたという経緯です。 また旧ナビゲーションの終了は、この先2ヶ月位という話です。なので早ければ2025年明けには「2025年2月×日で旧ナビゲーションは終了」という通知がくるかもしれません。最初は戸惑うかもしれませんが、早めに切り替えて慣れておいた方がよいでしょう。 変更点について それではリニューアルによってどう変わるのかをご紹介します。 まずメインメニューとも言える上部のタブ名が変わります。 ▼図1.従来のタブ   ▼図2.新しいタブ   並べてみると以下の通りです。6つのうち3つが変更になります。 Monitoring　⇒　 Home Network　⇒　Network Access　⇒　Access Security　⇒　Security Assets　⇒　 Resources Administration　⇒　 Account   各タブにあるメニュー数のBefore/Afterを見ると「Monitoringタブ」が大幅に減少して、その他のタブに移動しているのが分かります。 １．Monitoring/Homeタブ ２．Networkタブ ３．Accessタブ ４．Securityタブ ５．Assets/Resourcesタブ ６．Administration/Accountタブ 各サービスがどのタブに移動したのかは、 こちら のCatoのナレッジに記載があります。 この移動一覧を見ると、「Monitoringタブ」にあったネットワーク関連のダッシュボードは「Networkタブ」に、またセキュリティ関連のダッシュボードは「Securityタブ」に移動されています。 その他では、例えば特定のIPアドレスレンジを登録しておく IP Range は「Networkタブ」から「Resourcesタブ」に移動しています。 確かに「Resourcesタブ」にあって然るべきという納得感があります。 気になった点は、モバイルユーザーの接続制限を行う Device Posture が「Accessタブ」から「Resourcesタブ」に移動し、接続制限のルールを設定する「Client Connectivity Policy」はそのまま「Accessタブ」に残っているので、 Device Postureの一連の設定の際にはタブ間の移動が発生 してしまうこと位でしょうか。 目的のサービスがどこにあるのか迷った時には トグルスイッチをNew Navigationに切り替えて使っていると、目的のサービスが探せない事が何回もありました。 そんな時は、タブ列の左にある四角ボタンの「Account Menu」が役立ちました。これまで私はあまり使わなかったのですが、検索バーもあるので、サービス名が分かっていれば検索することで一発で辿り着きます！ さいごに CMAのような管理画面の使い勝手は、日々の運用では重要な要素だと考えます。 中にはいつまでたっても覚えにくいユーザー・インターフェースもありますが、当社のセミナーにご参加いただいたお客様からは「Catoはコンソールが分かり易い」という言葉をちょくちょくいただきます。またPoCでCMAの操作説明をさせていただく時にも「Firewallでルール作るみたいに・・・」とお伝えすれば「なるほど！」と理解してくれるケースが多くあります。 SCSKでは、デモセミナーやリモートハンズオンセミナーを開催していますので是非CMAの操作感を体験下さい！ 最後に！2024年12月現在CMAは日本語を含む10言語に対応しています。

どうも。みなさん re:Invent 2024 楽しんでますか? 寺内は東京にいます。 とはいえ、AWSからの大量のNews情報はキャッチできますので、見ていると興味深いキーワードが。 the next generation of Amazon SageMaker “ネクストジェネレーション” と聞くと、なんかワクワクしますよね。 ということで、詳しく見てみます。AWS発表のブログ記事は以下です。 Introducing the next generation of Amazon SageMaker - AWS Discover more about what's new at AWS with Introducing the next generation of Amazon SageMaker aws.amazon.com Amazon SageMakerは、データアナリストや機械学習モデル開発者のための統合開発環境(IDE)です。 機械学習モデルの開発は、大きく以下のステップを踏みます。 データ収集 → データの前処理 → 特徴量エンジニアリング → 学習(Training) → モデルテスト → モデルの評価 この一連の流れを、1つのコンソールの中ですべてを実施できることを目指しているのがAmazon SageMaker だといえます。 SageMakerリリース後、AWSではBedrockが出たり、Redshift Serverlessが出たりとAWSサービス周辺も急激に変化しています。そうした変化に合わせて、よりよい開発体験を提供するために、SageMakerの再構築を行うことにしたのだと推測できます。 この記事では、Amazon SageMaker Unified Studio を準備し、Jupyter Notebook で HELLO WORLD するところまでを記載します。 東京リージョンでも使えるとのこで、早速やってみましょう。 AWSマネジメントコンソールのサービス検索で “sagemaker” と入れると、あれ? 従来のSageMakerは、Amazon SageMaker AI と名称が変わり、次世代SageMakerは、Amazon SageMaker platform という名称のようです。 早速、Amazon SageMaker platform を選んでみましょう。 こちらの画面には、しっかり Amazon SageMaker Unified Studio と書いてありますね。 従来のSageMakerと同じく、まずはDomainを作るようです。作ってみましょう。 クイックセットアップでやってみます。 しかし、下の黄色いところに、適切なVPCを作ったほうがいいようなことが書いてありますので、既存のVPCではなく、Amazon SageMaker Unified Studio専用のVPCを作ることにします。 名前くらいしか入れることはないですね。作成を押すと、sagemaker_unified_studio_network_setup.yml というCloudFormationテンプレートが動きいろいろ作ります。ここでできたVPCを観察してみると、以下のような構造のようです。 一つのパブリックサブネットと、三つのプライベートサブネットがあります。 驚くのは、勝手に作られたエンドポイントの数です。 なんと28個! 利用料いくらかかるのでしょう。Redshift ServerlessやEMRなど、いらないのは、速攻で消したいところです。 再度、SageMakerのクイックセットアップに戻ると、作られたVPCの情報がすでに入力されています。その他、S3やBedrockなどの情報を確認し、ドメインの作成ボタンを押します。 終わると、以下のドメインへのログイン画面が出ます。 SSOは、この環境では使っていないので、AWS IAMでのサインインを選びます。 めでたく、Amazon SageMaker Unified Studioのホーム画面が出ました。 次に、プロジェクトを作成します。右側真ん中あたりにある緑色の「プロジェクトを作成」を押します。 プロジェクトの名前を入れて、プロジェクトの種類を選択します。ここでは、「データ分析とAI-MLモデルの開発」を選択します。 以下のように、CodeCommitやログの保存期間、SageMakerインスタンスが使うEBSボリュームサイズ、LakehouseやRedshift Serverlessの名称などを設定します。 こうして「プロジェクトを作成」ボタンを押すことで、作成処理が始まります。 これは10分ほどかかります。 無事終わると、以下のようにAmazon SageMaker Unified Studioのホーム画面の画面中央上部でプロジェクトが選択できるようになります。 これらのプロジェクトの作成で、少なくともS3とCodeCommitリポジトリが作成されます。確認してみましょう。 S3のバケットはこちら。 CodeCommitはこちら。 リポジトリの中身を見てみるといくつかファイルができています。 さて、SageMakerのホーム画面でプロジェクトを選択すると、以下のように作業の中心となるワークスペースが開きます。 中心にはCodeCommitの中身であるファイルが作られています。 ここにファイルを新規作成し、git commit して、push すれば、そのままCodeCommitリポジトリに入るのですから楽ちんです。 さて、左上に「Discover」「Build」「Governance」というメニューがあります。これらの中身は、それぞれ以下のようになっています。 Discoverの中身。 Buildの中身。 Governanceの中身。 データ解析系のメニュー、機械学習モデル開発のためのメニュー、ガバナンスのためのメニューと別れており、関連するサービスと密に連携が取れていることがわかります。 ここでは「Build」メニューから、JupyterLabを起動すると以下の画面になります。Python 3 のNotebookを作ってみます。 すると、わりとカッコいいNotebook画面がでました。ちょっとCloud 9っぽいというか、VS Codeっぽいというか。 ということで、Hello World、やっておきました。 左のツールバーで、Gitを選んで、CommitとPushをすれば、CodeCommitにしっかりと記録されます。ちょー簡単!   さて、生まれ変わったSageMaker Unified Studio 。全体的にAWSサービスのストレージおよびデータベースとの一体感が出て、使いやすくなっていそうです。 IICユーザでもIAMユーザでも使えるのがいいですね。 まずはやってみた、というレベルですが、データ分析の開発ワークスペースとして活用できればと思います。 ではまた。

みなさんこんにちは。 クラウド環境の利用が拡大する中で、最も重要な課題の一つがデータセキュリティです。クラウドには膨大なデータが保存されていますが、その中には機密情報や規制対象データが含まれていることも少なくありません。こうしたデータを適切に保護するために注目されているのが、DSPM（Data Security Posture Management）です。 本記事では、DSPMをこれから導入しようと考えている方に向けて、その基本的な考え方や導入メリットを解説します。   DSPMとは？ DSPM（Data Security Posture Management）は、クラウド環境に保存されたデータを中心に 可視化し、分類し、保護する ためのソリューションです。 従来のセキュリティ対策はインフラやネットワークが中心でしたが、DSPMはデータそのものに焦点を当てています。 クラウド環境でのデータ管理には以下のような課題があります。 機密情報や個人情報がどこに保存されているかわからない 不適切なアクセス設定によりデータが漏洩するリスク 法規制（例：GDPR、CCPA）への準拠状況が不明確 DSPMは、これらの課題を解決し、クラウド環境全体のデータセキュリティ態勢を最適化します。   DSPMの基本的な機能 DSPMが提供する主な機能を以下にまとめます。 データの可視化と分類 DSPMは、クラウド環境に保存されているデータを自動でスキャンし、どのデータがどこに保存されているかを可視化します。また、データをカテゴリ別に分類し、たとえば「機密データ」「公開データ」「個人情報」などを識別してラベリングします。 リスク評価 保存されたデータに関連するセキュリティリスクを特定します。たとえば、暗号化されていない機密データや、広範囲に公開されたデータを検出します。 コンプライアンス対応 GDPRやCCPAといった規制への準拠状況を自動的に評価し、必要な改善点を特定します。 不適切なアクセス設定の検出 データに対して不適切なアクセス権限や公開設定がされている場合、警告を発します。たとえば、「パブリックに公開されたS3バケット」を特定します。 修復の自動化 検出された問題について、適切な修正手順を提案し、自動で修復することが可能です。たとえば、公開設定をプライベートに変更するなどのアクションを実行します。 DLP機能の統合 一部のDSPMはDLP機能を持っており、データの流出につながる怪しい挙動を検出、防御します。   DSPM導入のメリット データ漏洩リスクの大幅な軽減 データがどこに保存され、誰がアクセスできるのかを把握することで、誤った設定や不適切なアクセスによる漏洩リスクを低減します。 運用効率の向上 従来は手作業で行っていたデータ分類やセキュリティ評価を自動化することで、運用担当者の負担を大幅に軽減できます。 コンプライアンス対応の強化 厳しい規制に準拠するためには、データ管理が欠かせません。DSPMは規制の要件を自動でチェックし、適切な対応をサポートします。 データセキュリティの統一的な管理 サードパーティ製のDSPMソリューションを利用することで、AWS、Azure、GCPなど複数のクラウドを利用している場合でも、統一的にデータを管理できます。   DSPM導入時に注意すべきポイント クラウド全体のデータ構造を把握する DSPMを効果的に活用するには、導入前に自社のクラウド環境でどのようなデータがどこに保存されているのか、大まかに把握しておくことが重要です。これはDSPMも完璧ではなく、検出されたデータの妥当性を確認する必要があるためです。 データ分類ポリシーの策定 DSPMはデータを自動で分類しますが、その分類基準は組織ごとに異なってきます。自社のセキュリティポリシーやビジネス要件に合わせた分類ルールを明確にしましょう。 運用体制の整備 監視対象が機密情報になるので、通常のインシデント対応ではなく、緊急度を高めたエスカレーションフロー等、特別な運用ルールを準備しておくことも検討すべきです。   DSPM導入のプロセス 現状分析 まず、現在のデータ管理状況を把握します。クラウド上のデータ量やリスクの高い領域を明確化しましょう。 要件定義 DSPMに求める要件を具体的に定義します。たとえば、「特定の規制への準拠」や「暗号化されていないデータの自動検出」、「DLP機能有無」などです。また、アラート通知頻度や通知方法など、運用要件の具体化が重要です。 ツール選定 DSPMツールは各社から提供されていますが、機能や対応クラウドが異なります。まず、自社のクラウド環境（AWS、Azure、GCPなど）に対応しているかを確認しましょう。また、必要な機能（DLP機能の有無、リアルタイム監視、コンプライアンス対応など）が備わっているかを比較検討します。 導入と設定 選定したDSPMツールを導入し、自社のデータ分類ルールやセキュリティポリシーに基づいて設定を行います。この際、クラウド環境内の各リソース（ストレージ、データベース、コンテナなど）を対象に、どのようなデータが保存されているかを整理し、適切な保護レベルを設定します。 運用開始と最適化 実際の運用を開始し、DSPMの有効性を検証します。検出されたアラートの精度や対応の迅速さを評価し、必要に応じて監視ポリシーのチューニングや体制、運用ルールの見直しを行います。   まとめ DSPMは、クラウド環境に保存されたデータを適切に管理し、セキュリティを強化するための重要なソリューションです。特に、どのデータがどこに保存され、どのように保護されているのかを可視化する機能は、データセキュリティ対策の基本といえるでしょう。 一部のDSPMはDLP機能も統合しており、データ漏洩防止の面でも大きな効果を発揮します。これから導入を検討している方は、自社の課題を明確化し、適切なツールを選定することで、効果的なデータセキュリティ対策を実現してください。

クラウドの普及が進む中、セキュリティ対策の重要性が高まっています。その中でも特に課題として挙げられるのが、クラウド環境における権限管理の複雑化です。多くの企業で、権限の設定ミスや適切でないアクセス許可が原因でセキュリティリスクが高まっています。 そこで注目されているのがCIEM（Cloud Infrastructure Entitlement Management）です。本記事では、CIEMの基本的な役割や導入のメリット、実際に導入する際のポイントを解説します。   CIEMとは？ CIEM（Cloud Infrastructure Entitlement Management）は、クラウド環境におけるアクセス権限や認証情報を管理するためのソリューションです。従来のアクセス管理は、主にオンプレミスの環境を対象に設計されていました。しかし、クラウド特有のスケーラビリティや多様性に対応するには、新しいアプローチが必要です。CIEMは、次のような課題に対応するために設計されています。 誰がどのリソースにアクセスできるのかが不明確 不必要に広範な権限が与えられたユーザーやロールの存在 アクセス権限の設定変更や更新が正しく行われていない こういった課題の解消は、昨今よく聞くようになったゼロトラストへの対策としても有効なため、CIEMは今後、更に重要度が増すソリューションとなることが想定されます。   CIEMの基本的な機能 CIEMが提供する主な機能を以下にまとめます。 アクセス権限の可視化 クラウド環境内の全ユーザー、ロール、サービスアカウントに対して、どのリソースにどのような権限が与えられているのかを可視化します。 過剰権限の検出 必要以上に広範な権限が与えられているユーザーやロールを特定し、リスクを低減します。たとえば、「Administrator」のような特権が不要に設定されている場合、警告を出します。 ポリシー違反の検出 組織のセキュリティポリシーやクラウドベンダーの推奨設定に違反するアクセス設定を検出します。 最小権限の推奨 リソースに必要な最低限の権限を自動的に提案します。 自動修復機能 検出した問題を手動または自動で修復できます。たとえば、不要なアクセス権を削除するなどの操作を効率的に実行できます。   CIEM導入のメリット CIEMを導入することのメリットを以下にまとめます。 セキュリティリスクの大幅な低減 クラウド環境における不適切なアクセス権限は、情報漏洩や不正アクセスの原因となります。CIEMを導入することで、権限設定ミスを自動的に検出し、リスクを軽減できます。 コンプライアンス対応の効率化 多くの業界規制（例：GDPRやISO 27001）では、アクセス権限の適切な管理が求められています。CIEMは、これらの規制に対応するための自動化ツールとして活用できます。 運用負担の軽減 手動でのアクセス権限の管理は時間と労力がかかります。CIEMは、アクセス権限の可視化や設定変更を効率的に行うため、運用負担を大幅に軽減します。 マルチクラウド環境の一元管理 AWS、Azure、GCPなど複数のクラウドを利用している場合でも、サードパーティ製のCIEMソリューションを使えば一元的にアクセス権限を管理することが可能です。   CIEM導入時に注意すべきポイント 自社のセキュリティポリシーに基づいた設計 CIEMを導入する前に、自社のセキュリティポリシーを明確に定義しておくことが重要です。たとえば、「どのようなユーザーにどのような権限を与えるべきか」という基準を具体化しておくことで、CIEMを効果的に活用できます。 運用ルールの明確化 CIEMは多くのプロセスを自動化できますが、全てを自動化すると逆に問題が発生する場合があります。たとえば、重要な権限を誤って削除してしまうと、業務に支障をきたす可能性があります。人の監視や承認プロセスを組み合わせて適切に運用できる事前のルール作りが重要です。 運用体制の整備 CIEMを導入するだけでなく、定期的な監視や更新を行う体制を整える必要があります。担当者の権限管理に関する基礎的な知識のインプットや、一度作った運用ルールの見直しを運用しながら行うことが重要です。   CIEM導入の具体的なプロセス 現状分析 まず、現在のクラウド環境のアクセス権限設定を把握します。どのような権限が誰に与えられているのかを明確化しましょう。 ツール選定 CIEMツールは、機能や対応するクラウドプラットフォームによって異なります。自社のニーズに合ったツールを選ぶことが成功の鍵です。 導入と設定のチューニング CIEMツールを導入し、セキュリティポリシーに基づいた設定を行います。特にCIEMはアラート量が多くなりがちなソリューションのため、設定が適切でない場合、過検知や誤検知が多発し、未解決アラートが山積するという状態になります。運用しながら適切に監視設定のチューニングを行うことが大切です。   まとめ CIEMは、クラウド環境の権限管理を効率化し、セキュリティを強化するために必須となるソリューションです。特に、複雑化するクラウド環境において、誰がどのリソースにアクセスできるのかを明確にしておくことは、セキュリティ対策を行う上でのベースになります。 CIEMの導入を検討している方は、自社の課題やセキュリティポリシーを整理し、最適なツールを選ぶことから始めてみてください。

クラウド環境が普及する中で、アプリケーションやコンテナ、仮想マシンなどのワークロードをどのように保護するかが重要な課題となっています。こうした課題を解決するために注目されているのが、CWPP（Cloud Workload Protection Platform）です。 CWPPは、クラウド上の動的なワークロードを保護するためのセキュリティプラットフォームであり、特にクラウドネイティブな環境で効果を発揮します。本記事では、CWPPの基本的な概要、導入メリット、活用方法について解説します。   CWPPとは？ CWPP（Cloud Workload Protection Platform）は、クラウド環境内のワークロード（仮想マシン、コンテナ、サーバレス機能など）を保護するためのセキュリティソリューションです。従来型のセキュリティ対策がオンプレミス環境を対象としていたのに対し、CWPPは次のようなクラウド特有の課題を解決します。 ワークロードが動的にスケールし、従来型のセキュリティソリューションでは対応できない コンテナやサーバレスなど、新しい技術への対応が求められる マルチクラウド環境で一元的に保護を行う必要がある CWPPは、これらのニーズに応え、クラウド上のワークロードを包括的に保護します。   CWPPの基本的な機能 CWPPが提供する主な機能を以下にまとめます。 脆弱性スキャン アプリケーションやコンテナイメージをスキャンし、既知の脆弱性を特定します。これにより、本番環境に脆弱性のあるイメージを展開するリスクを未然に防ぎます。 ランタイム保護 ワークロードの実行時に異常な動作や不審なアクティビティを検出し、リアルタイムで保護します。たとえば、許可されていないプロセスの実行や不審なネットワーク通信をブロックします。 ファイルとデータ保護 ワークロード内部のデータやファイルの改ざんを検出し、必要に応じてアラートを発します。 ネットワークセキュリティ ワークロード間の通信を監視し、異常なトラフィックを検出します。また、ファイアウォールルールを適切に設定するための推奨事項も提供します。 コンプライアンス対応 PCI DSSやHIPAAなど、業界規制やセキュリティフレームワークに準拠しているかを評価し、不足している項目を特定します。 自動化とインテグレーション CI/CDパイプラインに統合することで、セキュリティチェックを開発プロセスに組み込むことが可能です。これにより、コードの変更が行われるたびに自動でセキュリティ検査が実施されるため、開発者は早い段階で潜在的な脆弱性を発見し、修正できます。さらに、CI/CDパイプライン内でテストやセキュリティスキャンを行うことで、セキュリティ基準を満たしていないコードを本番環境にデプロイすることを防ぐことができます。   CWPP導入のメリット リアルタイムでのセキュリティ強化 CWPPはワークロードのランタイム中に発生する脅威をリアルタイムで検出し、迅速に対応することで、攻撃を未然に防ぎます。 脆弱性管理の効率化 開発から本番環境までのプロセスで脆弱性を早期に特定できるため、セキュリティ対応の効率が向上します。特に、CI/CDパイプラインに統合することで、開発の初期段階から脆弱性をチェックし、修正することで、後工程での手戻りを減らし、開発全体の効率化にもつながります。 クラウドネイティブ技術への対応 コンテナやサーバレスといったクラウドネイティブ技術を安全に活用するためのセキュリティ基盤を提供します。これにより、新しい技術を取り入れた場合でも、セキュリティリスクを最小限に抑えつつ、クラウドの柔軟性を活かすことができます。 運用負担の軽減 脆弱性スキャンやコンプライアンスチェックの自動化により、運用担当者の作業負荷が大幅に軽減されます。 マルチクラウド環境の一元管理 サードパーティ製のCWPPソリューションを利用すれば、AWS、Azure、GCPなど、複数のクラウドを利用している場合でも、一元的にワークロードを管理し、保護することが可能です。また、複数のクラウドを利用する企業にとって、統一されたセキュリティポリシーの適用が容易になり、全体的なセキュリティの統制が強化されます。   CWPP導入のプロセス 現状分析 まず、現在のワークロード環境を把握し、どのようなリスクや課題があるかを明確にします。クラウド環境におけるワークロードの種類（仮想マシン、コンテナ、サーバレスなど）を洗い出し、それぞれのワークロードがどのようなセキュリティリスクに直面しているかを分析します。また、既存のセキュリティ対策の効果を評価し、CWPP導入によってどの部分を強化するべきかを明確にすることが重要です。 ツール選定 自社環境に最適なCWPPツールを選定します。AWSやAzureなど特定のクラウドに最適化されたツールもあれば、マルチクラウド対応の汎用ツールもあります。ツール選定時には、クラウド環境との互換性、主要な機能（脆弱性管理、ランタイム保護、コンプライアンス対応など）、および自動化のレベルを比較検討します。また、ツールが自社のセキュリティポリシーに適合するか、操作性が良いか、導入後のサポート体制が充実しているかなども重要な判断基準です。 導入と設定 選定したツールを導入し、自社のワークロードに合わせた設定を行います。各ワークロードの種類（仮想マシン、コンテナ、サーバレスなど）に応じて、適切な保護ポリシーを設定します。例えば、コンテナに対しては脆弱性スキャンの頻度やランタイム保護の詳細設定を行い、仮想マシンにはネットワークモニタリングの設定を強化します。初期設定後には、試験運用を行い、設定が適切に機能しているかを確認します。 運用と最適化 導入直後は、脆弱性スキャンやランタイム保護の結果を細かく監視し、ツールの精度やアラートの有効性を評価します。運用中に発見された問題や課題に基づいて、設定を調整し、最適化を行うサイクルを繰り返します。定期的なレポート作成やレビューを通じて、セキュリティ態勢が維持・向上されているかを確認し、必要に応じて運用ルールや体制の見直しを行います。   まとめ CWPPは、クラウド環境におけるワークロードを包括的に保護するための強力なツールです。特に、クラウドネイティブ技術を活用する企業にとっては、セキュリティ強化と効率化の両方を実現できるソリューションと言えますので、積極的なCWPPの活用をおすすめします。

みなさんこんにちは。 近年、クラウドサービスを利用する企業が急増しています。その一方で、クラウド環境におけるセキュリティ対策が課題となるケースも増えています。そこで注目されているのがCSPM（Cloud Security Posture Management）というソリューションです。本記事では、CSPMをこれから導入しようと検討中の方に向けて、その概要とメリット、導入のポイントを詳しく解説します。   CSPMとは？ CSPMは、「クラウドセキュリティの態勢管理」を意味するツールで、クラウド環境における設定やポリシーを監視・評価し、潜在的なセキュリティリスクを特定するためのソリューションです。 クラウドの利用が広がる中で、適切なセキュリティ設定を維持することは非常に重要です。たとえば、誤ったアクセス権限の設定や不要なポートの開放といった設定ミスが、データ漏洩や不正アクセスの原因となることがあります。CSPMはこうしたリスクを自動的に検知し、修正するための支援を行います。   CSPMの基本的な機能 CSPMが提供する基本的な機能には、次のようなものがあります。 リソースの可視化 クラウド環境内のリソース（仮想マシン、データベース、ストレージなど）を一元的に可視化します。これにより、どのような設定や構成がされているのかを確認できます。 セキュリティ設定の評価 クラウドベンダーや業界標準（例：CISベンチマーク）に基づいて設定をチェックし、問題があれば警告を出します。 コンプライアンス対応 GDPRやHIPAAなどの規制に準拠しているかを自動的に評価し、不足している箇所を特定します。 リスクの優先順位付け リスクの重大性を評価し、優先的に対応すべき項目を特定します。これにより、限られたリソースで効率的にセキュリティ対策が可能です。 修復の自動化 発見した問題に対して、自動または手動で修正手順を実行できます。たとえば、不必要に開放されたポートは自動的に閉じるといった操作です。   CSPMの導入メリット CSPMを導入することで得られる主なメリットをいくつか挙げてみましょう。 セキュリティリスクの低減 クラウド環境では、設定ミスや人為的なエラーが主なセキュリティリスクとなります。CSPMは、設定ミスを迅速に特定・修正できるため、リスクを大幅に低減します。 可視性の向上 クラウド環境は複雑で、リソースがどこにあり、どのような状態なのかを把握するのは困難です。CSPMはこれらを統一的に管理するため、現状を正確に把握できます。 コンプライアンスの効率的な対応 手動でコンプライアンス対応を行うのは時間がかかり、ミスが発生しやすいものです。CSPMの自動チェック機能を利用すれば、効率的かつ確実にコンプライアンス要件を満たすことが可能です。   導入時に注意すべきポイント CSPMを導入する際には、以下の点を考慮することが重要です。 自社環境に合ったCSPMツールの選定 CSPMツールは多種多様です。自社のクラウド利用状況やセキュリティポリシーに合ったツールを選ぶことが大切です。たとえば、AWSのみを使用している場合と、AWS・Azure・GCPのマルチクラウド環境を使用している場合では、適切なツールが異なります。 運用体制の構築 CSPMツールは導入しただけでは十分に機能しません。定期的なモニタリングや、検出された問題への迅速な対応を行う体制を整える必要があります。 ユーザーへの教育 CSPMは技術的なツールですが、最終的には運用する人が重要です。設定の正しい理解やツールの操作方法について、担当者を教育することが必要です。   具体的な導入プロセス 最後に、CSPM導入の一般的なプロセスを簡単に紹介します。 現状分析 現在のクラウド環境の状況を把握し、どのようなリスクや課題があるのかを明確化します。 要件定義 CSPMツールに求める要件を明確にします（例：対応するクラウドプラットフォーム、コンプライアンス、運用要件など）。 ツール選定と導入 市場のツールを比較し、自社に最適なものを導入します。ツールの選定においては、事前に整理した要件を機能と運用の両面で満たすことができるかを、PoC等を通じて確認することが重要です。 運用開始と最適化 導入後は、実際の運用を通じてツールの有効性を検証し、必要に応じて運用フローを改善します。   まとめ CSPMは、クラウド環境のセキュリティを強化するための強力なソリューションです。設定ミスや人為的なエラーを防ぎ、クラウド利用を安心して進めるためには欠かせないものになっています。導入にあたっては、自社の課題や目指すべきゴールを明確にし、最適なツール選定と、ツール導入後の運用の準備が成功のカギです。 クラウドのセキュリティ対策を一歩進めたい方は、ぜひCSPMの導入を検討してみてください。

本記事は 新人ブログマラソン2024 の記事です 。 皆さんこんにちは！入社して間もない新米エンジニアの佐々木です。 最近、実務でAWSやSnowflakeを用いたデータ活用基盤の構築に携わっており、日々新しい技術に触れる毎日です。中でも特に興味を持ったのが、 SnowflakeのCortexAI という機能です。 どうやらCortexAIという機能を利用すると「データ分析の自動化」や「機械学習モデルの簡単な構築」を実現できるそうです。 一方で、やはり正直最初は半信半疑でした。一体どれほど簡単に使えるのか、実際に試してみなければ！ しかし、いざ試そうとしたところ「何から手をつければいいのか？」と戸惑うことばかり、、、 そこで、Snowflakeが提供する公式チュートリアルに助けを求めることにしました。 本記事では、私がCortexAIの公式チュートリアルを実践する中で気づいたこと、そしてそこから得られた学びについてお話していきます。これからSnowflakeやCortexAIを触れようと考えている方の参考になれば幸いです！ Snowflakeとは Snowflakeは、 Snowflake社が提供するクラウドデータプラットフォーム です。 データウェアハウス、セキュリティ、ガバナンス、可用性、データレジリエンスなど、データ分析に必要な機能をすべて網羅した フルマネージドサービス なんです。 そんなSnowflakeが最近着目しているキーワードとして 「AIデータクラウド」 があります。 AIデータクラウドとは、データウェアハウスとAI/ML機能を統合したクラウドベースのプラットフォームのことを指します。 Snowflake社はこのAIデータクラウドを通して、 データサイエンスと機械学習を民主化し、あらゆる規模の組織がデータドリブンな意思決定を容易に行えるようにする ことを目指しています。 Snowflakeクラウドデータプラットフォーム | Snowflake AIデータクラウド CortexAIとは Cortex AIは、 Snowflakeが提供する機械学習プラットフォーム です。 Snowflakeのデータウェアハウス上で直接機械学習モデルの構築、トレーニング、デプロイをできるという特徴があります。また、難しいプログラミングや専門知識がなくても、ある程度の分析や予測が比較的簡単にできるという特徴もあります。 Snowflake Cortex for Generative AI 公式チュートリアルの概要 本記事で取り扱う公式チュートリアルは以下の通りです！ Build A Document Search Assistant using Vector Embeddings in Cortex AI このチュートリアルでは、 Snowflake Cortex AIのベクトル埋め込み機能を利用して、ドキュメント検索アシスタントを構築 します。因みに文書検索アシスタントとは、大量のドキュメントデータの中からユーザーが求める情報を見つけ出すのを支援するツールのことを指します。 チュートリアル全体の手順は以下の大きく3つの流れです。 データ準備と前処理: 検索対象となるドキュメントデータの準備、データベース、スキーマ、ウェアハウスの作成、ドキュメント分割関数の作成を行います。 ベクターストアの構築: CortexAIを用いて各ドキュメントを数値ベクトルとして表現し、ベクターストアの作成を行います。 チャットUIおよびロジック構築:  前工程で作成したベクターストアを利用して、誰でも簡単に文書検索ができるように、SnowflakeのStreamlitを使用して簡単なフロントエンドの作成を行います。 実際に挑戦してみた！！ データ準備と前処理 データ準備 まず初めに、今回検索対象となるドキュメントデータを準備します。 今回はチュートリアルで配布されている以下の4つの英文ファイルを使用しました。これらのドキュメントは様々な自転車に関する情報が記述されているPDFファイルです。 Mondracer Infant Bike Premium Bycycle User Guide Ski Boots TDBootz Special The Ultimate Downhill Bike データベース、スキーマ、ウェアハウスの作成 次に今回使用するデータベース、スキーマ、ウェアハウスを作成していきます。 そのために、Snowflakeのワークシートを新規で作成し、以下のコードを実行します。 CREATE DATABASE CC_QUICKSTART_CORTEX_DOCS; --create databse CREATE SCHEMA DATA; --create schema USE CC_QUICKSTART_CORTEX_DOCS.DATA; CREATE OR REPLACE WAREHOUSE XS_WH WAREHOUSE_SIZE = XSMALL; --create warehouse USE WAREHOUSE XS_WH; これにより、データベース、スキーマ、ウェアハウスの大枠の準備ができました！ ドキュメント分割関数の作成 次にドキュメントデータを読み取り、それらをチャンクに分割するためのユーザー定義関数（pdf_text_chunker）を作成します。 ここでユーザー定義関数とは、SQLクエリ内で呼び出せる、ユーザーが作成した再利用可能なコードブロックのことを指します。 またチャンク分割とは、Snowflakeがデータを効率的に管理・処理するために、自動的にデータを小さなブロックに分割する仕組みのことを指します。これによって、大量のドキュメントデータでも高速にアクセス・検索することが可能になるというメリットがあります！ 関数を作成するために、Snowflakeのワークシートで以下のコードを実行します。 create or replace function pdf_text_chunker ( file_url string ) returns table ( chunk varchar ) language python runtime_version = '3.9' handler = 'pdf_text_chunker' packages = ( 'snowflake-snowpark-python' , 'PyPDF2' , 'langchain' ) as $$ from snowflake . snowpark . types import StringType , StructField , StructType from langchain . text_splitter import RecursiveCharacterTextSplitter from snowflake . snowpark . files import SnowflakeFile import PyPDF2 , io import logging import pandas as pd class pdf_text_chunker : def read_pdf ( self , file_url : str ) -> str : logger = logging . getLogger ( "udf_logger" ) logger . info ( f "Opening file {file_url}" ) with SnowflakeFile . open ( file_url , 'rb' ) as f : buffer = io . BytesIO ( f . readall ()) reader = PyPDF2 . PdfReader ( buffer ) text = "" for page in reader . pages : try : text += page . extract_text (). replace ( '\n' , ' ' ). replace ( '\0' , ' ' ) except : text = "Unable to Extract" logger . warn ( f "Unable to extract from file {file_url}, page {page}" ) return text def process ( self , file_url : str ): text = self . read_pdf ( file_url ) text_splitter = RecursiveCharacterTextSplitter ( chunk_size = 4000 , #Adjust this as you see fit chunk_overlap = 400 , #This let's text have some form of overlap. Useful for keeping chunks contextual length_function = len ) chunks = text_splitter . split_text ( text ) df = pd . DataFrame ( chunks , columns =[ 'chunks' ]) yield from df . itertuples ( index = False , name = None ) $$ ; 上記のコードについて補足説明をします。 6行目： packages = ( 'snowflake-snowpark-python' , 'PyPDF2' , 'langchain' ) 必要なPythonパッケージを指定しています。snowflake-snowpark-pythonはPythonコードの埋め込み、PyPDF2でPDFファイルの読み込み、langchainでテキストの分割処理に利用します。 18行目～35行目： def read_pdf ( self , file_url : str ) -> str : PDFファイルの読み込みをするための関数です。ページごとにテキストを抽出し、改行文字やNULL文字をスペースに置換して連結した文字列を返します。 37行目～50行目： def process ( self , file_url : str ): テキストを指定されたサイズに分割するための関数です。今回のコードではチャンクサイズを4000文字、チャンク間のオーバーラップを400文字に設定しています。 これにより、ドキュメントを分割するための関数ができました！ ドキュメントアップロード用ステージの作成 次にドキュメントをアップロードするステージを作成します。 そのために、ワークシートで以下のコードを実行します。 create or replace stage docs ENCRYPTION = ( TYPE = 'SNOWFLAKE_SSE' ) DIRECTORY = ( ENABLE = true ); その後、作成したDOCSステージに準備した4つのドキュメントデータを以下のようにアップロードします。 以上でデータ準備および前処理は完了です！！ ベクターストアの構築 次にベクターストアを構築していきます。 ベクターストアとは、 文書のベクトル表現（数値ベクトル）を保存するデータベース のことを指します。 これにより、従来のテキスト検索では難しい「意味的な検索」についても、文書間の意味の類似度を計算することで実現することができるようです！ テーブルの作成 まず初めに、各ドキュメントのチャンクとベクトルを保存するためのテーブル（DOCS_CHUNKS_TABLE）を作成するために、以下のコードを実行します。 create or replace TABLE DOCS_CHUNKS_TABLE ( RELATIVE_PATH VARCHAR ( 16777216 ), -- Relative path to the PDF file SIZE NUMBER ( 38 , 0 ), -- Size of the PDF FILE_URL VARCHAR ( 16777216 ), -- URL for the PDF SCOPED_FILE_URL VARCHAR ( 16777216 ), -- Scoped url ( you can choose which one to keep depending on your use case ) CHUNK VARCHAR ( 16777216 ), -- Piece of text CHUNK_VEC VECTOR ( FLOAT , 768 ) ); -- Embedding using the VECTOR data type 上記で作成したテーブルのCHUNKカラムにドキュメントのチャンクが、CHUNK_VECカラムにチャンクから計算されたベクトル値が格納されます。 テーブルへのデータ挿入 次に、作成したドキュメント分割関数（pdf_text_chunker）を利用して、ドキュメントを処理し、チャンクを抽出します。そして抽出したチャンクからベクトル値を計算し、テーブル（DOCS_CHUNKS_TABLE）にそれらの情報を挿入します。 insert into docs_chunks_table ( relative_path , size , file_url , scoped_file_url , chunk , chunk_vec ) select relative_path , size , file_url , build_scoped_file_url ( @docs , relative_path ) as scoped_file_url , func . chunk as chunk , SNOWFLAKE . CORTEX . EMBED_TEXT_768 ( 'e5-base-v2' , chunk ) as chunk_vec from directory ( @docs ), TABLE ( pdf_text_chunker ( build_scoped_file_url ( @docs , relative_path ))) as func ; 上記のコードについて補足説明をします。 8行目： SNOWFLAKE . CORTEX . EMBED_TEXT_768 ( 'e5-base-v2' , chunk ) as chunk_vec SnowflakeのCortex機能を使用して、チャンクのベクトル値を生成します。様々あるモデルの内、今回はe5-base-v2というモデルを使用してベクトル値を生成しています。 11行目： TABLE ( pdf_text_chunker ( build_scoped_file_url ( @docs , relative_path ))) as func ; build_scoped_file_url ( @docs , relative_path ) では、各ドキュメントの相対パス（relative_path）とステージパス（@docs）を組み合わせてSnowflake内で一意に参照できるURLを生成しています。 その後、生成したURLをもとに作成した関数（pdf_text_chunker）でドキュメントをチャンクに分割し、戻り値をfuncというエイリアスで参照できるようにしている形です。 これで、チャンクとベクトル値を含むベクターストアを作成することができました！ チャットUIおよびロジックの構築 最後に、作成したベクターストアを利用して、誰でも簡単に文書検索ができるように、SnowflakeのStreamlitを使用して単純なフロントエンドを作成していきます。 具体的には、SnowflakeのCortexとStreamlitを使って、ユーザーがアップロードしたドキュメントをコンテキストとして利用（RAG）し、大規模言語モデル（LLM）で質問に答えるアプリケーションを作成します。 Streamlitとは、 カスタムWebアプリを簡単に素早く構築することができるオープンソースのPythonライブラリ です。 さらにStreamlitを使用することで、アプリ実行を同じアカウント内の他のユーザーと共有することができ、データの安全性と保護が維持されるというメリットがあります。 Streamlit構築 早速、Streamlitで以下のようにコードを変更します。 import streamlit as st # Import python packages from snowflake . snowpark . context import get_active_session session = get_active_session () # Get the current credentials import pandas as pd pd . set_option ( "max_colwidth" , None ) num_chunks = 3 # Num-chunks provided as context. Play with this to check how it affects your accuracy def create_prompt ( myquestion , rag ): if rag == 1 : cmd = """ with results as (SELECT RELATIVE_PATH, VECTOR_COSINE_SIMILARITY(docs_chunks_table.chunk_vec, SNOWFLAKE.CORTEX.EMBED_TEXT_768('e5-base-v2', ?)) as similarity, chunk from docs_chunks_table order by similarity desc limit ?) select chunk, relative_path from results """ df_context = session . sql ( cmd , params =[ myquestion , num_chunks ]). to_pandas () context_lenght = len ( df_context ) - 1 prompt_context = "" for i in range ( 0 , context_lenght ): prompt_context += df_context . _get_value ( i , 'CHUNK' ) prompt_context = prompt_context . replace ( "'" , "" ) relative_path = df_context . _get_value ( 0 , 'RELATIVE_PATH' ) prompt = f """ 'You are an expert assistance extracting information from context provided. Answer the question based on the context. Be concise and do not hallucinate. If you don´t have the information just say so. Context: {prompt_context} Question: {myquestion} Answer: ' """ cmd2 = f "select GET_PRESIGNED_URL(@docs, '{relative_path}', 360) as URL_LINK from directory(@docs)" df_url_link = session . sql ( cmd2 ). to_pandas () url_link = df_url_link . _get_value ( 0 , 'URL_LINK' ) else : prompt = f """ 'Question: {myquestion} Answer: ' """ url_link = "None" relative_path = "None" return prompt , url_link , relative_path def complete ( myquestion , model_name , rag = 1 ): prompt , url_link , relative_path = create_prompt ( myquestion , rag ) cmd = f """ select SNOWFLAKE.CORTEX.COMPLETE(?,?) as response """ df_response = session . sql ( cmd , params =[ model_name , prompt ]). collect () return df_response , url_link , relative_path def display_response ( question , model , rag = 0 ): response , url_link , relative_path = complete ( question , model , rag ) res_text = response [ 0 ]. RESPONSE st . markdown ( res_text ) if rag == 1 : display_url = f "Link to [{relative_path}]({url_link}) that may be useful" st . markdown ( display_url ) #Main code st . title ( "Asking Questions to Your Own Documents with Snowflake Cortex:" ) st . write ( """You can ask questions and decide if you want to use your documents for context or allow the model to create their own response.""" ) st . write ( "This is the list of documents you already have:" ) docs_available = session . sql ( "ls @docs" ). collect () list_docs = [] for doc in docs_available : list_docs . append ( doc [ "name" ]) st . dataframe ( list_docs ) #Here you can choose what LLM to use. Please note that they will have different cost & performance model = st . sidebar . selectbox ( 'Select your model:' ,( 'mixtral-8x7b' , 'snowflake-arctic' , 'mistral-large' , 'llama3-8b' , 'llama3-70b' , 'reka-flash' , 'mistral-7b' , 'llama2-70b-chat' , 'gemma-7b' )) question = st . text_input ( "Enter question" , placeholder = "Is there any special lubricant to be used with the premium bike?" , label_visibility = "collapsed" ) rag = st . sidebar . checkbox ( 'Use your own documents as context?' ) print ( rag ) if rag : use_rag = 1 else : use_rag = 0 if question : display_response ( question , model , use_rag ) 上記のコードについて補足説明をします。 10行目～59行目： def create_prompt ( myquestion , rag ): LLMへのプロンプトを作成する関数を定義しています。 特にここではRAGの有無を検証するために、変数ragの値を切り替えることでRAGを利用するかしないかを簡単に選択できるようにしています。rag=1の場合は、ユーザーが自身のドキュメントをコンテキストとして使用し、質問に対して類似度の高いチャンクを検索し、それらを追加した形でプロンプトを作成しています。一方でrag=0の場合は、ドキュメントをコンテキストとして使用せず、質問に回答するシンプルなプロンプトを作成しています。 61行目～69行目： def complete ( myquestion , model_name , rag = 1 ): LLMを使用して質問に回答する関数を定義しています。 SnowflakeのSNOWFLAKE.CORTEX.COMPLETE関数を使用して、指定されたLLMモデルとプロンプトを使用して、テキストの生成を行います。 71行目～77行目： def display_response ( question , model , rag = 0 ): LLMからの応答とドキュメントへのリンク（ rag == 1 の場合）をStreamlitで表示する関数を定義しています。 81行目～114行目： メインのコードです。ここでは以下の処理を行っています。 Streamlitアプリケーションのタイトルと説明を表示 ユーザーがアップロードしたドキュメントの一覧を表示 LLMモデルを選択できるセレクトボックスをサイドバーに表示 質問を入力できるテキストボックスを表示 ドキュメントをコンテキストとして使用するかを選択できるチェックボックスをサイドバーに表示 質問が入力された場合、 display_response 関数を呼び出して回答を表示 上記のコードを実行することで無事アプリが表示されました！ 検証 ここでRAGを利用した場合と、利用しない場合とで回答にどのような違いがあるのかを確認してみます。 そこで「What is the temperature to store the ski boots?（スキーブーツを保管する温度はどれくらいですか？）」という質問をしてみたいと思います。 まずはRAGを利用した場合の回答です。 上記の回答を日本語訳すると、 TDBootzスキーブーツを保管する理想的な温度は摂氏15度です。 参考になる可能性のある資料へのリンク：Ski_Boots_TDBootz_Special.pdf 上記から分かるように、RAGを利用すると精度および具体性の高い回答をしていることが分かります。これは、LLMのテキスト生成に信頼性の高い外部情報（今回はドキュメントデータ）を組み合わせているからだと言えます。   次にRAGを利用しなかった場合の回答です。 上記の回答を日本語訳すると、 スキーブーツは、摂氏7～24度（華氏45～75度）の涼しく乾燥した場所に保管する必要があります。極端に高温または低温の環境での保管は避けてください。これにより、素材が損傷し、ゲレンデでの性能に影響を与える可能性があります。また、カビや mildew（かびの一種）の発生を防ぐために、保管前にスキーブーツを完全に清掃して乾燥させることも良いでしょう。 上記から分かるように、RAGを利用しないと具体性に欠ける一般的な回答しかできていないことが分かります。これは、LLMが内部知識のみを利用し、事前に学習済みのデータに基づいて回答を生成するからだと言えます。 まとめ 本記事では、Snowflakeの公式チュートリアルを実践することで、CortexAIの使い方や利便性について確認することができました。 特にチュートリアルを通して感じたCortexAIの魅力的ポイントを3つ挙げてみました！ シームレスなSnowflake連携 : Snowflakeデータウェアハウスに直接統合されており、データの移動や変換が不要となる。これにより、Snowflake内のデータに対して直接機械学習モデルを構築・実行でき、データサイエンスワークフローがシームレスになり、開発効率が劇的に向上する 高度な埋め込みベクトル機能 : テキストデータの埋め込みベクトル生成をスムーズに行えるため、セマンティック検索や類似テキスト検索といった高度な機能を容易に実装できる 様々なLLMモデルへの対応 : 複数のLLMモデルに対応しているため、プロジェクトのニーズやコストに合わせて最適なモデルを選択できる このような魅力的ポイントを持つCortexAIは、様々なビジネス課題への応用が期待でき、今後ますます注目を集める技術だと思います。 ぜひ、皆さんもCortexAIを試してみて、その可能性を体感してみてください！