はじめに こんにちは。SCSKのふくちーぬです。 今回は、Cloud9を削除してしまった際の適切な復元方法についてお話します。 この話をしようと思ったきっかけとして、利用しているCloud9の実体であるEC2が削除されてしまい、「一体どうすればいいんだ！」と思った経験が背景となります。 というのも、弊社検証環境ではEC2(=Cloud9)が一定期間起動していないものについてはAMI化し、EC2を削除する仕組みが稼働しております。この仕組みのおかげで、コスト削減が実現できております。実際には他の仕組みも動いているのですが、その話はまた今度することにします。 それでは、EC2を削除してしまった際の対処方法を紹介します。 Cloud9環境準備編 今回の状況を再現するために、Cloud9環境を準備します。 Cloud9を構築する Cloud9の構築手順について分かる方は、飛ばしていただいて結構です。 ご自身のアカウントにて、VPC及びサブネット、IGW、ルートテーブル等が構築済みであることが前提となります。 以下の手順を参考に、Cloud9を構築します。 ステップ 1: 環境を作成する - AWS Cloud9 (「 」の最初のステップ) docs.aws.amazon.com コンソール画面から、”Cloud9″を入力し選択します。 “環境を作成”を押下します。 名前は、任意のもので大丈夫です。ここでは、”cloud9-20231121″と入力しています。 インスタンスタイプも何でも良いですが、一番料金が安い最小サイズの”t2.micro”を選択しています。 接続方法として、お手軽に試すことができる”AWS Systems Manager (SSM)”を選択しています。 VPC設定では、任意のVPC,サブネットを指定してください。 ここでは、以下のように設定しています。 VPC：vpc-092d2b38fb260b53b サブネット：subnet-02cb24e380508f54e   設定内容が正しいことを確認後、”作成”を押下してください。 以下のような画面になっていれば、問題なくCloud9の構築ができています。 続いて上記画面にて、”Cloud9で開く”を押下してください。 数分待つとCloud9の環境が立ち上がりました！ Cloud9でファイルの作成をする ここからが本題です。 EC2を削除する前に、Cloud9上で特定のファイルを作成しておき”世界で一つだけのCloud9″にしましょう。 この意図として、復元後に該当ファイルの存在を確かめる作業を実施します。 “New File”を押下してください。 本文には以下のように入力して、ファイル名は”test.txt”とします。 これにてCloud9の準備完了です。 スナップショット取得編 EC2のAMIを取得する Cloud9の実体であるEC2にアクセスします。”EC2インスタンスの管理”を押下してください。 静止点を設けるために、EC2の停止をしておきます。”インスタンスを停止”を押下してください。 AMIを作成するために、”イメージを作成”を押下してください。 イメージ名は、任意のもので大丈夫です。ここでは、”ami-cloud9-20231121″と入力しています。 “イメージを作成”を押下します。 数分後に、AMIが作成されていることを確認しましょう。 EC2削除編 EC2を削除する では実際にEC2(=Cloud9)が一定期間起動していないものを削除する仕組みが動いていたと仮定して、EC2を削除してみましょう。 “インスタンスを終了”を押下してください。 “終了”を押下してください。 先ほどまで、ステークスが”準備完了”であったCloud9ですが、”エラー”になっていることが分かります。 “Cloud9で開く”を押下して、利用できないことを確認してください。 “Return to dashboard”を押下して、コンソールに帰ってきてください。 Cloud9の実体であるEC2が削除されてしまったため、Cloud9が利用できなくなっていますね。 復元編 Cloud9の実体となるEC2を削除してしまった場合は、新規にCloud9を作成し、ボリュームの入れ替えをすることが必須となります。　　（※該当のCloud9環境は、何も利用できず抜け殻のような状態となります。） 復元の手順は、以下の通りです。 新しいCloud9を作成する ボリュームの入れ替えをする 復元の確認する 新しいCloud9を作成する 同様の手順で新しく別のCloud9を作成してください。 ここでは、名前を”cloud9-ver2-20231121″としています。 実際にCloud9を起動してみると、もちろん”test.txt”ファイルの存在しない初期状態のCloud9となります。 ボリュームの入れ替えをする 以下を参考に、新しいCloud9のルートボリュームに対して入れ替えを行っていきます。 Cloud9を停止することなく入れ替えを実施することが可能です。 以前のスナップショットを使用したボリュームの置き換え - Amazon Elastic Compute Cloud Amazon EBS ボリュームを Amazon S3 に保存した以前のスナップショットのデータに置き換えます。 docs.aws.amazon.com   “cloud9-ver2-20231121″のEC2を選択して、”ルートボリュームを置き換える”を押下してください。 各自取得したAMIのイメージIDを選択してください。元のボリュームは必要ないので、チェックも入れておきます。 “置き換えタスクを作成”を押下します。 ルートボリュームの入れ替えに成功し、復元したいボリュームがアタッチされました。 復元後の確認 実際にCloud9を起動して、中身を確認していきましょう。 “test.txt”ファイルが存在することを確認できました。 後片付け Cloud9の削除 古いCloud9は利用できないため、削除しておきましょう。 AMIとスナップショットの削除 AMIとスナップショットも料金がかかるので、削除しておきましょう。 まとめ いかがだったでしょうか。これでEC2が削除されても、AMI・スナップショットを取得しておけば安心してCloud9を復元できます。 本記事が皆様のお役にたてば幸いです。 ではサウナラ～🔥

こんにちは。SCSKの島村です。 Google Cloud のカンファレンスイベント Google Cloud Next Tokyo’23 が国内4年ぶりに 東京ビックサイト にて開催されました。 11月15日（水）－16日（木） の二日間にわたり基調講演や、先進事例セッション、テーマ別のブレイクアウトセッションなど、 充実のプログラムがご用意されておりました。また、 この度当社は、Platinumスポンサーとしても出展させていただきました。 2日間の開催期間中、多くのお客様にご来場いただきました。ありがとうございました。 本記事では、2日間に及んだGoogle Cloud Next Tokyo’23について当社の出展内容を少しだけご紹介させていただければと思います。 弊社では、Google CloudのAI/MLの技術を生かしたソリューションを提供しております。今回の展示会では、その技術を実際に現地でご体験いただけるような2つのデモを実施いたしました。 実施したデモについて、本ブログでも内容を共有させていただきます！！！！ スポンサーブース＠Expoについて Google Cloud パートナーによるスポンサー展示ブースでは、各社がGoogle Cloud（GCP）やGoogle Workspace のデモや導入事例について取り組みをご紹介するだけでなく、導入支援に関するご相談やクラウド全般に関するご質問をオンサイトで行える、そんなスペースです。 SCSKブースでは、弊社のGoogle Cloud に関するこれまでの取り組みをデモを交えながらご紹介させていただきました。 弊社オリジナルキャラクターの「かつのすけ」君です。　Googleカラーの腹巻がとてもお似合いですね。   SCSKブースデモ① コンタクトセンター向け生成AIチャットボットのご紹介 コンタクトセンタ-向けの生成AIチャットボットデモについてご紹介します。 今回は、弊社プレスリリースでも紹介させていただいている「生成AIチャットボット」をブースにてご来場いただいたお客様にお試しいただきました。 プレスリリースの詳細はこちら☟☟☟ 是非こちらもご一読下さい。 すぐに試せる！効果が分かる！「その問い合わせ、もうシナリオを作らなくても生成AIがお答えします」チャットボット・ボイスボットへのビルトイン・生成AIサービスを提供開始 (scsk.jp) Vertex AI Search とは？ Vertex AI Search は、生成AIを活用した検索エンジンを構築するためのサービスです。生成AIによる結果のサマライズやパーソナライズなどの検索結果の強化に加えデータをアップロードするだけで簡単に構築と管理が可能となります。 Vertex AI Search and Conversation の一般提供を開始 | Google Cloud 公式ブログ cloud.google.com より詳しい内容については過去の記事をご確認いただけますと幸いです。 Vertex AI Search and Conversationが一般提供されたので触ってみました【Search編】 SCSK青木です。今回はGoogle CLoud Next'23で一般提供されたVertex AI Search and ConversationのSearchを触ってみました。 blog.usize-tech.com 2023.09.05 Vertex AI Search and Conversationが一般提供されたので触ってみました【Conversation編】 SCSK青木です。Google Cloud Next’23にて一般提供されたVertex AI Search and Conversationを触ってみました。今回はConversationに関して記載しています。 blog.usize-tech.com 2023.09.05 デモ詳細 架空企業のコンタクトセンターを想定した、Vertial Agentによるお客様とのやり取りをデモにてご紹介させていただきました。 Google CloudのPaLM2やOpen AIのGPT-3.5/4などの基盤モデル（FM）では回答が難しかった（ ハルシネーションを起こしていた ）質問に対しても、  企業独自のデータへグラウンディング （接地）し、より 回答率/回答精度の高い ナレッジベースの 生成AIチャットボット をGoogle Cloudのサービスを利用して構築いたしました。 すぐに試せる！効果が分かる！「その問い合わせ、もうシナリオを作らなくても生成AIがお答えします」チャットボット・ボイスボットへのビルトイン・生成AIサービスを提供開始 (scsk.jp) サービスの特徴 チャットボットやボイスボットにおいて、 ① 利用開始時に必要不可欠でありながら煩雑で作業負荷の高い「回答シナリオの作成・メンテナンス」が不要で、 ②  自社で有するナレッジベースやドキュメントを読み込ませることで生成 AIが回答を生成します。  　 また、「この質問には必ず同じ回答を返す」という個別のルール設定も可能です。 実際のデモ画面①☟☟☟☟ お客様とのやり取りを記録し、生成系でサマライズ！！！！（画面右側） 要件や解決の有無だけでなく、お客様の感情も分析しオペレータへのアドバイスがあることでデータを収集するだけでなく、効率的な活用まで！！！   実際のデモ画面②☟☟☟☟ お客様とのやり取りをダッシュボードで可視化！！！！ 問い合わせの件数や、実際の問い合わせに対して生成AIの回答精度など等、様々な情報をダッシュボードにて簡単に確認可能。   SCSKブースデモ② 製造業向け外観検査ソリューションのご紹介 製造業向け外観検査ソリューションデモについてご紹介します。 今回は、Google Cloud の外観検査ソリューションである「Visual inspection AI」の本番導入時をイメージできるような、ミニチュアサイズのデモをご用意いたしました。 実際にカメラとPCを接続し、その場で対象物を撮像し本番ラインを想定した外観検査のデモを実施いたしました。 Visual inspection AI とは？ 製造業の外観検査に特化したGoogle CloudのAIサービスであり、  ● 特徴として「プログラム開発を必要とせず、GUI操作のみですぐに利用可能」 なサービスとなっております。 さらに「目的に応じて3つのモデルを選択」することが可能です。 より詳しい内容については過去の記事をご確認いただけますと幸いです。 【GCP】Visual Inspection AIの新モデル Anomaly Detection を触ってみた！！ Google Cloudの外観検査特化サービス「Visual Inspection AI」について、新モデルが追加されたことをご存じでしょうか？ 今回は、Visual Inspection AIの新モデルであるAnomaly Detectionを実際に使用してみましたのでご紹介させていただきます。 blog.usize-tech.com 2023.04.28 デモ詳細 今回は「スマートフォンの表面の細かな傷を検証する」モデルをご用意させていただきました。  ① 産業用カメラ（写真左）でその場で傷のついたスマートフォンを撮影  ② Visual inspection AIで作成したモデルを利用して推論を実施  ③ その場で推論結果を表示する 実際の向上のラインを想定したEdgeソリューションとしてのデモを見ていただきました。 当日デモの準備時間の写真を少しだけ☟☟ 今回作成した外観検査モデルですが、モデルの学習に利用したデータは、数十枚の正常データ（傷のないアイフォーンの画像）と異常（表面に傷のついた画像）データのみです。 少ない枚数ですが、そこそこの精度を出すことができております。業界固有のドメインに特化したVisual inspection AIならではの強みを体感いただけたのではないでしょうか。   最後に 今回は Google Cloud Next Toyko’23における当社の取り組み についてご紹介させていただきました。 多くのお客様にご来場いただき、弊社の取り組みについてお話をさせていただけたこ大変感謝いたします。皆様のご来場とご意見を励みに、今後もより一層の技術力向上に努めてまいります。 また、今回ご紹介した「生成AIチャットボット」「製造業向け外観検査ソリューション」についてもっと知りたい方は、個別のご相談も承っております。 ありがたいことに、当日多くの方に足を運んでいいだきその場でお話できなかったことやご相談などお気軽にお声掛けください。 お問い合わせは以下のフォームからお願い致します。 お問い合わせ製品・サービス名に「Google Cloud」を選択してください。 お問い合わせ｜クラウド移行だけでは描けない、理想のDXを実現する www.scsk.jp 今後とも、AIMLに関する情報やGoogle CloudのAIMLサービスのアップデート情報を掲載していきたいと思います。 最後まで読んでいただき、ありがとうございました！！！

前回は、サーバレスコンピューティングとは何か、そしてセキュリティの課題と対策の重要性について簡単に解説しました。   サーバレスセキュリティについて考える ① サーバーレスアーキテクチャの理解とそのセキュリティ課題の詳細な洞察を提供します。サーバーレス環境でのセキュリティ対策の重要性とその理由も解説します。技術者、デベロッパー、ITマネージャー必見の内容です。 blog.usize-tech.com 2023.07.21   今回は具体的に、どのようなセキュリティ対策が必要かについて、基本的な考え方を紹介します。   本題に入る前にお知らせです！ ＝＝＝＝＝＝＝ 【CSPMマネージドサービス SmartOneCloudSecurity】 SmartOneCloudSecurityは、PrismaCloudを用いたCSPMマネージドサービスです。PrismaCloudの導入から設定変更まで、弊社技術担当者がお客様のCSPM対策をサポートします。CSPMの導入を検討中の方はもちろん、PrismaCloudを利用中だけど機能や運用面でもっと上手に活用したい、というような課題をお持ちな方は、お気軽に下記URLからお問い合わせください。PrismaCloudのPoCの相談も受けています。 New!!   2023/4より、CWPPの導入サポートも始めました！   Smart One Cloud Security® パブリッククラウドのセキュリティ設定を診断/監視するマネージドCSPMサービスです。Palo Alto Networks社Prisma Cloud（CSPM機能）を使い易く、簡単に導入いただけます。 www.scsk.jp   １．何に対して対策をしないといけないか セキュリティ対策を考える前に、どの領域が対象なのかを明確にする必要があります。 Lambdaの責任共有モデル AWSが提供するLambdaの責任共有モデルを例にとって、サーバレス環境におけるユーザーのセキュリティ責任を探ります。このモデルによると、関数のコード、使用するライブラリ、関数の設定、Identity and Access Management（IAM）のセキュリティ対策がユーザーに求められます。また、AWSのドキュメントには記載されていませんが、データ保護と監視も重要です。つまり、データの暗号化やアプリケーションの性能監視といった対策も必要です。加えて、セキュリティという観点からは、実際にアプリケーションが稼働するワークロードの防御も考慮に入れなければなりません。 ※出典： 責任共有モデル ２．何を対策しないといけないか 次に、何を対策しないといけないかを考えます。サーバレスセキュリティ対策においては、AWSを例に取り、具体的な対策を整理するために次の２つのフレームワークが参考になります。 AWS Well-Architected Framework Serverless Applications Lens CIS Benchmark AWS Well-Architected Framework Serverless Applications Lens AWS Well-Architected Framework Serverless Applications Lens は、セキュリティ、信頼性、パフォーマンス効率、コスト最適化の４つの主要な柱に基づいて、サーバレス特有のベストプラクティスを提供するガイドラインです。セキュリティの柱においては、以下のような対策を行うことが推奨されています。 アイデンティティとアクセス管理 最小特権の原則は、サーバレスセキュリティの土台になります。IAMを用いて関数、データベース、その他リソースへのアクセスを細かく制御します。 インフラストラクチャの保護  サーバレスアーキテクチャでは、アプリケーションが複数のサービスにまたがって稼働します。そのため、ネットワークのセグメンテーションが重要であり、LambdaのセキュリティグループやVPCの適切な設定によりアクセスを制限します。 データの保護 サーバレスアプリケーションはデータが頻繁に移動するため、データは保管状態または転送中であっても暗号化が必須です。KMSを利用してキー管理を行うことで、データを安全に保持します。 検出制御 セキュリティ侵害を迅速に特定するためには、異常なアクティビティを検出する仕組みが必要です。CloudWatch、CloudTrail、またはサードパーティ製のツールを使用して監視を行います。 ※現状、異常なアクティビティを防御しようとすると、サードパーティ製の製品を導入が必要 インシデントレスポンス  セキュリティインシデントが発生した場合の迅速な対応は不可欠です。事前にインシデント対応計画を策定し、自動化された応答メカニズムを導入しておくべきです。 ※参考： Security pillar さらに、AWS Well-Architected Framework Serverless Applications Lensでは、サーバレスを構成する以下の８つのレイヤーについて記載があります。 コンピュートレイヤー データレイヤー メッセージング・ストリーミングレイヤー ユーザー管理とアイデンティティレイヤー エッジレイヤー システムの監視とデプロイレイヤー デプロイアプローチ Lambdaのバージョン管理 これらのレイヤーは、上記の柱と連動しており、AWSサービスを用いて適切なセキュリティ対策を実施できるように設計されています。 アイデンティティとアクセス管理 ⇔ ユーザー管理とアイデンティティレイヤー インフラストラクチャの保護 ⇔ コンピュートレイヤー、データレイヤー、メッセージング・ストリーミングレイヤー、エッジレイヤー データの保護 ⇔ データレイヤー 検出制御 ⇔ システムの監視とデプロイレイヤー 各レイヤーに代表的なサーバレスサービスをマッピングしてみると以下のようになります。考え方のベースとなる柱に対して適切にサービスが散りばめられていて、こう見るとよくできているサービス構成に思えます。   CIS Benchmark CognitoやIAMを用いた認証・認可の強化や、各サービスに対する最小限の権限付与、LambdaやRDSへのセキュリティ対策、CloudWatchやX-Rayによる監視・分析など、基本的なアプローチが明確になりました。次は、CISベンチマークを参考に、これらのサービスに具体的にどのような設定を適用すべきかを検討します。 CISベンチマークは、Center for Internet Security（CIS）によって策定された業界標準のベストプラクティス集です。他のコンプライアンスガイドラインと比較して、より実務に即した技術的設定に重点を置いており、具体的な手順が明確に示されています。 今回も例としてAWSに焦点を当てます。AWSに関するCISベンチマークのドキュメントには以下の4種類があり、各々からサーバーレスサービスに関する重要な記述を抜粋してみます。 CIS Amazon Web Services Foundations Benchmark v2.0.0 CIS AWS End User Compute Services Benchmark v1.1.0 CIS AWS Compute Services Benchmark v1.0.0 CIS Amazon Web Services Three-tier Web Architecture Benchmark v1.0.0 CIS Amazon Web Services Foundations Benchmark v2.0.0 CIS No 推奨事項 2.1.1 S3 バケットポリシーが HTTP リクエストを拒否するように設定されていることを確認する 2.1.2 S3 バケットで MFA Delete が有効になっていることを確認する 2.1.3 Amazon S3内のすべてのデータが検出され、分類され、必要に応じて保護されていることを確認する。  ※Amazon S3バケットには機密データが含まれている可能性があり、セキュリティ目的のために発見、監視、分類、保護されるべきである。Macieと他のサードパーティツールは、Amazon S3バケットのインベントリを自動的に提供することができる。 2.1.4 S3 バケットが「パブリックアクセスをブロック（バケット設定）」で構成されていることを確認する 2.3.1 RDSインスタンスで静止時の暗号化が有効になっていることを確認する 2.3.2 RDSインスタンスの自動マイナーバージョンアップグレード機能が有効であることを確認する 2.3.2 RDSインスタンスにパブリックアクセスが与えられないようにする 3.6 CloudTrail S3バケットでS3バケットアクセスロギングが有効になっていることを確認する 3.10 書き込みイベントのオブジェクトレベルロギングがS3バケットで有効になっていることを確認する 3.11 S3 バケットで読み取りイベントのオブジェクトレベルロギングが有効になっていることを確認する 4.1 未承認の API 呼び出しを確実に監視する 4.8 S3 バケットポリシーの変更を確実に監視する ※CIS Amazon Web Services Foundations Benchmark v2.0.0 から引用、翻訳   CIS AWS Compute Services Benchmark v1.0.0 CIS No 推奨事項 4.1 AWS ConfigがLambdaで有効になっていることを確認する 4.2 Cloudwatch Lambda insightsが有効になっていることを確認する 4.3 AWS Secrets Managerが設定され、データベース用のLambdaで使用されていることを確認する 4.4 ラムダ関数へのアクセスに最小特権が使用されることを保証する。 4.5 すべてのラムダ関数が独自の IAM ロールを持つようにする 4.6 ラムダ関数が誰にでも公開されないようにする。 4.7 ラムダ関数がアクティブな実行ロールを参照していることを確認する。 4.8 Lambda関数でCode Signingが有効になっていることを確認する。 4.9 AWSアカウント内に管理者権限を持つLambda関数がないことを確認する 4.10 ラムダ関数が、権限ポリシーによって未知のクロスアカウントアクセスを許可しないようにする。 4.11 ラムダ関数に使用する実行環境のバージョンにサポート終了日がないことを確認する。 4.12 Lambda環境変数で転送中の暗号化が有効になっていることを確認する ※CIS AWS Compute Services Benchmark v1.0.0 から引用、翻訳   CIS Amazon Web Services Three-tier Web Architecture Benchmark v1.0.0 CIS No 推奨事項 1.4 RDS 上で実行されるデータベースで、静止時の暗号化が有効になっていることを確認する 1.16 全てのS3バケットで、バケットに格納されている全てのオブジェクトに対してサーバーサイドおよびトランジット暗号化を必須とするポリシーがあるか確認する 3.5 リレーショナルデータベースサービスがマルチAZで有効になっていることを確認する 3.6 リレーショナルデータベースサービスのインスタンスにおいて、自動マイナーバージョンアップグレードが有効であることを確認する 3.8 リレーショナル データベース サービスのバックアップ保持ポリシーが設定されていることを確認する 3.11 S3 バケットのバージョン管理が有効になっていることを確認する 3.12 CloudFront Viewer プロトコルポリシーを使用した HTTP から HTTPS へのリダイレクトが設定されていることを確認する 3.13 すべての CloudFront ディストリビューションで CloudFront と Web 層 ELB オリジンの間で HTTPS が必要であることを確認する 4.1 Cloudtwatch アラームおよび Auto-Scaling グループ (スコア付き) から通知を送信するための SNS トピックが作成されていることを確認する 4.2 RDS イベントから通知を送信するための SNS トピックが作成されていることを確認する 4.3 RDS イベント サブスクリプションがインスタンス レベルのイベントに対して有効になっていることを確認する 4.4 RDS イベント サブスクリプションが DB セキュリティ グループに対して有効になっていることを確認する 5.3 AWS Cloudfront Logging が有効になっていることを確認する 5.5 Cloudwatch ログ グループがアプリ層用に作成されていることを確認する 5.7 アプリ層の Cloudwatch ログ グループに保持期間があることを確認します 6.4 Cloudfront ディストリビューション内で地域制限が有効になっていることを確認する 6.30 RDS データベースがパブリックにアクセスできないことを確認する 6.34 RDS データベースがデータ層セキュリティ グループを使用するように構成されていることを確認する ※CIS Amazon Web Services Three-tier Web Architecture Benchmark v1.0.0 から引用、翻訳 CISベンチマークでは、各サービスの具体的な設定方法が明確に示されており、さらにAWS Secrets ManagerやMacieなどの追加サービスを利用したセキュリティ対策も詳細に記述されています。セキュリティ設定に関して不明な点がある場合は、まずはこれらのガイドラインに従って設定を行うことをお勧めします。 ３．対策の全体像 これまでの内容を基に、サーバレスセキュリティにおける対策を、サーバレスシステム構築の構成例に適用する形で整理してみます。 CISベンチマークでは、各サービスの詳細な設定推奨事項が記載されています。ここでそれらを全て取り上げるには量が多すぎますが、基本的には全てのサービスにおいて、各サービス固有のセキュリティベストプラクティスに従った適切な設定が必要です。なお、これらの設定が正しく行われていることを、CSPMソリューションで監視し、設定の不備をリアルタイムに検出することが重要です。 アイデンティティとアクセス管理では、Cognitoを使用して認証・認可を実施し、認証を通過した通信のみを許可します。また、IAMを用いて各サービスに必要最小限の権限を付与し、もし悪意あるユーザーが侵入しても、被害を最小限に抑える体制を整えます。 インフラストラクチャー保護のためには、エッジサービスであるCloudFrontやAPI GatewayにWAFを導入して防御対策を施します。データベースへの認証情報はSecrets Managerで管理し、Lambda関数にはSignerでの署名を用いて、データベースアクセスやLambdaの利用を承認されたユーザーに限定します。さらに、ワークロードとランタイムの保護には、CWPPソリューションを活用して実行環境の脆弱性管理と防御対策を実施します。 データ保護に関しては、保管場所だけでなく伝送中のデータも暗号化します。また、Macieを用いてS3に保存された機密データを特定し、そのアクセスを監視します。 検出制御の観点では、CloudWatchやX-Rayを使用して適切な監視と分析を行える状態にし、異常な状態を定義できればSNSでアラート通知させます。また、前提とした各サービス毎のセキュリティのベスプラに基づく適切な設定が行われていることを監視するために、Security Hubやサードパーティ製CSPMソリューションで脆弱な設定がないことを継続的に監視することも重要です。 ここまでで、サーバレスセキュリティの基本的な対策について考えてみました。サーバレスセキュリティの対策としては、ランタイムやライブラリの脆弱性の管理なども考える必要があるので、次回は更に一歩踏み込んで、脆弱性管理や実際にCWPP製品を使ってみて、どういった対策を行うことができるかを確認していきたいと思います。   CWPPとは何か? クラウドワークロード保護の必要性を解説 クラウド上のデータとアプリケーションの安全性を確保するソリューションとして、日本でも徐々にCWPPの認知度が高まってきています。 CWPPの概要と必要性について解説します。 blog.usize-tech.com 2023.05.23

こんにちは、SCSK株式会社の池田です。 前回は、HAクラスタウェアの「 LifeKeeper（ライフキーパー） 」という製品の概要をご説明しましたが、２回目の今回は少しだけ掘り下げて、LifeKeeperで可用性を高められるミドルウェアにどのようなものがあるかをご紹介します。 HAクラスタウェア「LifeKeeper」で可用性を高めよう！ BCPが求められるシステムの決定版！AWSを代表とするパブリッククラウド上の任意のミドルウェアの可用性を向上できるHAクラスタウェアの「LifeKeeper（ライフキーパー）」について概要をご説明します！ blog.usize-tech.com 2023.11.20   LifeKeeperには、数多くのミドルウェアに対応したオプション製品がある！ LifeKeeperには、サイオステクノロジーやミドルウェアメーカーが事前に動作確認済みのオプション製品（有償）があります。 それを「 Application Recovery Kit 」略して「 ARK(アーク) 」と呼びます。 ARKを使うことで、他のHAクラスタ製品でありがちな、ミドルウェアをHAクラスタ制御する為のスクリプトの作成がいらなくなるんです。 もちろんARKは、サイオステクノロジーがしっかり動作検証してくれてるから、スクリプトの設計や作成、テストが必要ないので、作業工数の短縮にも繋がるんだよ。 ARKを使えば面倒くさいスクリプトを書かなくて良いのはとても便利ね どんなミドルウェアに対応したARKがあるのか？ それ！とても気になるところだよね。 ではどんなミドルウェアに対応したARKがあるのか見てみましょう！ カテゴリ 対応ソフトウェア 対応OS Linux Windows データベース OracleDB 〇 〇 PostgreSQL 〇   SQL Server   〇 DB2 〇   MySQL 〇   データ連携/転送/Mail基盤 HULFT 〇 ※ライセンスは無償提供 保守のみ有鬚 〇 ※ライセンスは無償提供 保守のみ有鬚 IIS   〇 ※本体に無償で同梱 NFS Server 〇   ジョブ JP1/AJS – Manager 〇 〇 JP1/AJS – Agent 〇 〇 その他 WebSphere MQ/IBM MQ 〇   Logical Volume Manager (LVM) 〇   Device Mapper Multipath 〇         よく使われるミドルウェアに対応しているのね 有償のARKがないミドルウェアでも大丈夫！ う～ん　このリストにないミドルウェアはどうすれば良いんだろう？ そうだね。このリストに書いていないミドルウェアをLifeKeeperで保護したいって時もあるよね。 そんな時は大きく二つの方法があるよ！ （１）Quick Service Protection（QSP）を使って簡易的に保護する （２）Generic Application Recovery Kit（Generic ARK）を使ってスクリプトを作りこんで保護する （１）のQSP（キューエスピー）を使った方法については、スクリプトを作成することなくGUIによる設定をするだけで、簡単にサービスの起動/停止/監視を行うことが可能だよ （２）の Generic ARK（ジェネリックアーク）を使って保護する方法は、サイオステクノロジー謹製のサンプルスクリプトをベースに、手の込んだチェック機構などを実装することもできるんだ QSPやGenericARKで保護した実績のあるアプリケーションはこんなにあるんだよ（一例） カテゴリ 対応ソフトウェア 対応OS Linux Windows データベース MariaDB 〇   FUJITSU Software Enterprise Postgres 〇 〇 PowerGres HA 〇   EDB Postgres 〇 〇 データ連携/転送/Mail基盤 DataSpider 〇 〇 ACMS E2X 〇   AsteriaWarp 〇 〇 samba 〇   監視 Zabbix 〇   A-AUTO 〇 〇 その他 Apache 〇 〇 Tomcat 〇   SVF 〇 〇     こんなに実績があるなら 有償のARKがなくても安心ね   そうは言っても、なんかARKって難しそう。。。 有償のARKとか、GenericARKとか出てきたけどちょっと難しそう 聞きなれない言葉だから難しく感じちゃうよね。 じゃあARKについて簡単に触れておくね。 ARK(含むGenericARK)には、以下の４つの機能があるんだ 起動スクリプト(restore) アプリケーションを起動する 停止スクリプト(remove) アプリケーションを停止する 監視スクリプト(quickCheck)*1 アプリケーションが正常かどうか監視を行う（オプション） 回復スクリプト(recover)*1 監視処理で異常を検出した場合、実行してアプリケーションのリカバリーを行う（オプション） *1 スクリプトは任意での組み込み。restore, remove スクリプトだけでリソース作成は可能 この表を見て、勘の良い人はピンときたかもしれないけど、ミドルウェアの起動、停止、回復（再起動）の処理は、完全にLifeKeeperで制御するんだ。だから例えばWindowsのサービス画面では、該当のミドルウェアは「手動」起動にしておく必要があるよ。 OSでは「手動」起動にしておくのは覚えておきたいポイントね 監視処理で、リターンコードが0なら正常、それ以外なら異常と判断して、次の処理を決めるというのが、ARKの役割なんだ。 へ～　ARKの処理って意外とシンプルなんだ。安心したよ まとめ ここまで、LifeKeeperのオプション製品であるARKの概要についてご説明しました。 ・有償ARKがあれば簡単にLifeKeeperで保護できる ・有償ARKがないミドルウェアでも、QSPやGenericARKを使えば保護できる ・ARKの機能はたった４つ（起動、停止、監視、回復） 次回は、AWSなどのパブリッククラウド環境でLifeKeeperが有効な理由をお伝えしますね。お楽しみに。

こんにちは、SCSK株式会社の池田です。 みなさん、HAクラスタウェアの「 LifeKeeper（ライフキーパー） 」という製品をご存じですか？ 「LifeKeeper」は、OS自体や、Red hat Enterprise Linux や Windows Server上の任意のアプリケーションの可用性を高める、今流行りの BCP対策 （※）ぴったりの製品なんです！ （※）BCP：Business Continuity Planningの略で事業継続計画のこと 今日は、この「LifeKeeper」についてご紹介しますね LifeKeeperってナニモノ？？ LifeKeeperとは、サイオステクノロジー社が販売する 日本国産 (※)のHAクラスタウェアです。 （※）Linux版の開発主体が日本国内に、Windows版の開発主体は米国にあります。 「サイオステクノロジー」という会社名を始めて聞くかたもいらっしゃるかと思いますが、四半世紀以上前の1997年に創業、黎明期のLinuxを推進するビジネスからスタートして以来、今回ご紹介するLifeKeeperの開発やOSSに強みを持つ、東京に本社を置く企業なんです。 弊社とは、2004年12月にパートナー契約を結んで以来20年近くに渡って、LifeKeeperに関する技術情報の共有を密に図りつつ、時には共同開発検証するなどして歩んできました。 さてもう一つ聞きなれない「HAクラスタウェア」というキーワードが出てきました。 解りやすく説明しますと、 まず２台のサーバを用意して、片方を稼働系(Active)、もう片方を待機系(Standby)として構成しておきます。 普段ユーザは稼働系を使ってるんですが、稼働系サーバのミドルウェアで障害が発生した時に、待機系でミドルウェアを起動して、接続先のIPアドレスも待機系に移すことでシステムの継続性を担保するミドルウェアのことなんです。 イメージにするとこんな感じです。 一番左の絵が正常時の状態で、クライアントは稼働系サーバに接続していますね。次に真ん中の絵で稼働系サーバに障害が発生しています。それを検知した待機系サーバでミドルウェアを起動させるんです。クライアントは同じIPアドレス(VirtualIP(バーチャルアイピーって言います))に接続しているから、一度は接続が切れますが、待機系サーバに切り替わったことには気が付かないんです。 この切り替わりの処理のことを「 フェイルオーバー 」と言うんです。 サーバが１台だけですと、障害が起きた時にシステムが使えなくて、お客さんも困るし、運用保守する人も急いで復旧させないといけないから焦ってしまいますよね。 LifeKeeperがあれば、そんな不安も一気に解消ね！ どうしてLifeKeeperがお薦めなの？ 数あるHAクラスタの中でも、LifeKeeperの強みってなんだろう HAクラスタ製品はいろいろとあるけれど、LifeKeeperが優れているポイントがいくつかあるよ （１）コア課金と違って、サーバ単位の課金だから、スケールアップもしやすいよ （２）様々なアプリケーションに対応したオプション製品があるから構築が早くて安価だよ （３）GUIが判りやすいから、運用しやすいよ （４）サポートが全て日本語で受けられるよ （５）Linux版は開発元が日本にあるから、要望が受け入れられやすいよ 開発元が日本っていうのが安心ね どんな時にフェイルオーバーが起きるの？？ LifeKeeperがあれば、お客さんもシステム運用する人も皆が安心できることが解りましたね。 さて次は、どんなことをきっかけにフェイルオーバが起きるのかを解説します。 フェイルオーバーのきっかけとなるチェックは大きく２つあります。 （１）対向サーバの死活状態チェック （２）自サーバ上のミドルウェアの死活状態チェック （１）の対向サーバの死活状態チェックのイメージ コミュニケーションパスと呼ばれる回線を使って、相互に状態をチェックしていて、サーバが応答しない時や、なんらかの原因でコミュニケーションパスが切れた場合に障害と判断して、フェイルオーバが発動するんです。 お互いにサーバの状態を確認しているんだね   （２）の 自サーバ上のミドルウェアの死活状態チェックのイメージ 自サーバ上のミドルウェアの死活状態をチェックして、正常ステータス以外の場合に障害と判断します。まず自サーバ上で対象ミドルウェアを再起動して、それでも復旧しない場合はフェイルオーバが発動します。 自サーバ上のミドルウェアの状態を確認しているのね どんな環境で使えるの？ LifeKeeperは、オンプレミス環境や仮想環境はもちろん、Amazon Web Services(AWS)を始めとするパブリッククラウドでも可用性を向上するのに有効なんです。 まとめ ここまで、LifeKeeperの概要についてご説明しました。 ・2台のサーバで構成し、障害時はフェイルオーバすることでシステムを継続利用できる ・チェック方法は、相互にサーバの死活チェックと、自サーバのミドルウェアの死活チェック ・オンプレ、仮想環境はもちろん、最近はパブリッククラウドでも採用 次回は、どんなミドルウェアの可用性を高めることができるかをお伝えしますので、お楽しみに。

今回は、Catoクラウドの肝となるPoP(Point of Presence)についてご紹介します！ PoP(Point of Presence)とは PoPとは、インターネットを介してCatoクラウドのサービスを利用するためのアクセスポイントです。 世界中に自前のPoPを配備することで、グローバルでサービスを展開しています。 2023年6月時点のPoP数は80拠点以上、2024年にはPoP数を120拠点にする計画となっており、 既に日本には、東京(2箇所)と大阪(2箇所)の合計４箇所配備されています。さらに、2023年中には北海道(札幌)がリリース予定です。 日本のPoP ※2023年11月時点 ・東京 第一PoP（Tokyo） ・東京 第二PoP（Tokyo_DC2） ・大阪 第一PoP（Osaka） ・大阪 第二PoP（Osaka_DC2） PoP上でネットワーク機能とセキュリティ機能を実装しているため、ユーザは最寄りのPoPに接続することで、いつでもどこでもセキュアなネットワークを高速に利用できます。 PoPについてはこちらの記事でも紹介されておりますのでご参照ください。 世界初のSASEプラットフォーム Catoクラウドとは？ Cato Networks社 の Catoクラウド（ケイトクラウド）についてご紹介します。 Catoクラウドは世界初のSASEのサービスであり、強固なセキュリティとシンプルな運用管理を実現します。 blog.usize-tech.com 2023.08.15 PoPのアドレス ユーザはPoPに接続し、Catoクラウド経由でインターネット接続した際、インターネットへの出口はCatoクラウドのPoPになります。 出口のアドレス（以下「Egress IP」とする）については、PoPにてCatoのグローバルIPアドレスがランダムに割り当てられます。 Catoが日本のPoPで取得しているグローバルIPアドレスはこちらをご確認ください。 ※JPNIC（Japan Network Information Centre）ではなく、上位のAPNIC（Asia Pacific Network Information Centre）から取得しているアドレスです。 Production PoP Guide – Cato Learning Center (catonetworks.com) ここで少し余談です。 Egress IPのご説明をすると、「ランダム割り当てなので、Egress IPは毎回変更されてしまうのか？」とご質問をいただくことが多いですが、Egress IPは固定することが可能です。 このEgress IPの固定設定は、Microsoft 365やBoxなどのクラウドサービス、またはその他SaaSサービス、特定Webサイトで、ある特定のアドレスからのアクセスを制御している場合などに役立ちます。 Egress IPに関する詳細は別記事にて詳しくご説明しております。 CatoクラウドにおけるEgress IP（送信元IP、出口IP）について CatoクラウドにおけるEgress IPについて解説します。 blog.usize-tech.com 2023.08.22 メンテナンス・障害情報 CatoクラウドではPoPの設備維持のために定期的にメンテナンスが行われます。 メンテナンスによる通信断は一般的に 約30秒 です 。 ※メンテナンスの内容によっては数分に及ぶ可能性もございます。 そのため、定期メンテナンスは業務影響の少ない時間帯での実施が予定されており、日本の場合は午前1時から午前3時に実施されるようスケジュールされています。 ※緊急メンテナンスなど例外もございます。 以下サイトからCato PoPのメンテナンスや障害に関する情報が確認できます。 https://status.catonetworks.com/ SUBSCRIBEより、通知の設定も可能です。 現在、電話やメールに加えてSlackやTeamsでも通知が可能となっているようです。 最適経路の選択 経路選択の仕組み 世界中にPoPが配備されているとお伝えしましたが、通常Catoクラウドへ接続を開始すると、自動的にユーザのロケーションに最も近い最寄りのPoPに接続されます。 実際に、iOSの端末にCatoクライアントをインストールし、東京都内からCatoクラウドへ接続を行ってみました。 接続PoPをCMAにて確認してみると、東京 第二PoP（Tokyo_DC2）に接続されていることがわかります。 日本からの接続の際、通常はこのように日本のPoPに接続されます。 これは、SocketやCatoクライアントが、Steeringサーバから提示された複数の経路候補の中から最も近い経路を選択する仕組みとなっているためです。 Steeringサーバは、SocketやCatoクライアントから最適経路の問い合わせを受けると、ユーザのロケーションやPoPの稼働状況から複数の経路候補をSocketおよびクライアントへ提示する仕組みとなっています。 まとめると以下のような流れです。 経路選択の仕組み １．SocketやCatoクライアントが、Steeringサーバに対してDNS Queryで最適経路の問い合わせを実施 ２．Steeringサーバが、SocketやCatoクライアントに対して接続候補となるPoPリストを提示 ３．SocketやCatoクライアントは、提示された各PoPへ対し、53/udp, 443/udpパケットを送信し最寄りのPoPを確認 ４．SocketやCatoクライアントは、最寄りのPoPへ接続を開始 経路選択時のトラブル例と回避策 ここからは、経路選択時に発生し得るトラブル例と回避策について解説していきます。 トラブル例 経路選択時には、以下2つの事象が発生することがあります。 遠方のPoPに接続する 通常Catoクラウドへ接続を開始すると、自動的にユーザのロケーションに最も近いPoPに接続されますが、稀に遠方のPoPに接続され、ネットワーク接続遅延を引き起こすことがあります。   実際に、東京都内からドバイのPoPに接続するよう設定をしてCatoクラウドへ接続を行ってみると、5秒程度接続に時間がかかりました。東京 第二PoP（Tokyo_DC2）に接続した場合1、2秒程度でCatoクラウドに接続ができるため、遠方のPoPに接続すると若干ではありますが遅延が発生するようです。  海外のPoPに頻繁に接続される場合は、ご利用中のISPのIPアドレスが海外（日本以外）になっている可能性がありますので、IPロケーションサイト等で国（Country）をご確認ください。 IP Address Lookup | Geolocation Lookup a geolocation of an IP address including latitude, longitude, city, region and country. Compare the data from multiple IP location providers. www.iplocation.net                  PoPの切り替わりが頻繁に発生する ユーザのロケーションに最も近いPoPに接続ができても、接続PoPが頻繁に切り替わることによりネットワークが不安定になることがあります。 PoPの切り替わり時には、瞬断～数秒程度の通信断が発生する可能性があるため、PoPの切り替わりが頻繁に発生すると通信が不安定になります。 速度低下・パケット損失・遅延・PoPメンテナンス等によりSocketと最寄りのPoP間の接続性が不安定になると、上記のようなトラブルが発生する可能性があります。 このようなトラブルが発生した際は、接続PoPを任意のPoPに変更および固定すること改善される場合がありますので、設定方法をご紹介いたします！ 回避策 接続PoPの変更・固定は、Site(拠点)単位・モバイルユーザ単位で設定することができますので、それぞれ設定方法をご紹介します。 Site(拠点)を指定のPoPに接続する 設定箇所：Network＞Sites（指定のサイトを選択）＞Site Configuration＞General ＞Preferred PoP Locations    優先的に接続させたいPoPを”Primary”と”Secondary”の2つまで指定することができます。   「Only connect to the Preferred PoP Locations」にチェックを入れると、”Primary”と”Secondary”に指定した優先接続PoPにのみ接続するよう制限することが可能ですが、指定したPoP以外には接続されなくなります。 例えば、図のようにPrimary locationを東京 第二PoP（Tokyo_DC2）に、Secondary locationを大阪 第二PoP（Osaka_DC2）に設定すると、東京 第二PoP（Tokyo_DC2）と大阪 第二PoP（Osaka_DC2）のPoPへの接続性に問題が発生した場合でも、東京 第二PoP（Tokyo_DC2）と大阪 第二PoP（Osaka_DC2）にしか接続ができないということになります。 通常時、何か特別な理由がなければ「Only connect to the Preferred PoP Locations」のチェックは外しておいた方が良いと言えます。 モバイルユーザを指定のPoPに接続する Catoクライアントを起動後、メニューからSettingsを選択し、「MANUAL POP」をONにします。 「PoP SERVER IP」に接続させたいPoPのアドレスを手動で入力します。 私はドバイのPoP(140.82.197.1 )を指定してみました。    設定ができたらホーム画面に戻ってCatoクラウドに接続させ、メニューのStatsにて接続PoPを確認します。 設定した通り、ドバイのPoPに接続できることが確認できました。 Appendix Socketが優先接続PoP以外のPoPに接続した場合、 Socket は優先接続PoPに再接続します。 デフォルトでは60分間待機してから、自動的に優先接続PoPに再接続しますが、再接続するまでの待機時間はカスタマイズが可能です。      再接続までの待機時間は、アカウント単位・Site(拠点)単位で設定することができますので、それぞれ設定方法をご紹介します。 アカウント全体に反映する 設定箇所：Network＞Connection SLA  前述の通り、デフォルトでは60分間となっていますが、変更したい場合は自由に待機時間を変更します。 また、図のように「Disable」を選択すれば自動的に再接続させる機能を無効にすることもできます。 特定Site(拠点)に反映する 設定箇所：Network＞Sites（指定のサイトを選択）＞Site Configuration Connection SLA  図のように「Override Account Settings」にチェックを入れ、アカウント全体の設定方法と同様に設定を行います。 「Override Account Settings」にチェックを入れると、アカウントの設定を上書きすることができます。 つまり、アカウントの設定より特定サイト(拠点)の設定が優先されます。 まとめ 今回は、PoP(Point of Presence)についてご紹介しました。 この技術ブログ（TechHarmony）の他にもFAQサイトでよくあるご質問やCato クラウドのアップデート情報を公開しておりますので、是非ご参照ください！ よくあるご質問 | Cato Cloud ケイトクラウド - SCSK Cato SASE Cloud Platform. powered by SCSK cato-scsk.dga.jp

この記事を書いている担当は、いわゆるレガシーなインフラエンジニアです。 ネットワーク機器や物理サーバ、また回線やデータセンタといった物理寄りの構築・運用を担当してきましたが、ここ数年はAWSやAzureそしてSASEと、クラウドインフラに仕事が移ってきています。 そんな担当から見てCatoクラウドはどうなのか、率直に思うところを書いてみたいと思います。 Catoクラウドの良いところ 一元化された管理画面はとても便利 Catoクラウドは、ネットワーク・セキュリティのオールインワンサービスです。1つの管理画面ですべての機能が操作・確認できます。 従来は、例えば拠点を1つ新設するとなると、その拠点に置くルータを設定し、対向となるデータセンタ側のネットワーク機器に設定追加し、さらにファイアウォール等のポリシーを追加し…、と複数の機器での設定が必要となり、かつ機器ごとの知識を持っている必要がありました。 Catoでは、拠点はほぼゼロタッチで接続でき、ルーティングもセキュリティポリシーも、すべて管理画面からGUIで設定できます。この手軽さはすごいです。実際に、多拠点ネットワークの構築において拠点展開の工数を大幅に減らすことができました。 なお、他の製品では、機能ごとに管理画面が分かれていてリンクが貼られているだけだったり、UIが統一されておらず操作方法がばらばらといったものもありますが、この点Catoは全機能がよく統合されていると思います。 すべてのログが1つの画面で検索できる また、Catoではすべてのログが1つのログ管理画面に集約されています。これは運用者にとって革新的です。 これまでは、例えば特定のユーザで特定の通信ができないという問題が発生した場合、ファイアウォールに入ってブロックされていないかログを見て、次にIPSやProxyのログを見て…というように、いくつもの機器を確認する必要がありました。ログを一元管理するようなソリューションもありますが、異なるベンダの異なる機器のログを集約すると、ログのフィールドが最大公約数的に丸められており、結局実機を見る必要がある…といったことも多かったです。 この点、Catoクラウドは、セキュリティログも接続記録も、すべてが「Events」に一元的に集約されており、ユーザ名と日時で絞り込みをかけるだけで、そのユーザにその時何があったのかを知ることができます。 筆者も当初は、一元化することでログのフィールドが複雑化して、内容を読み解くのが大変では…?と思ったのですが、そうでもありませんでした。ログ毎に必要なフィールドのみが表示されるので、複雑ではないです。 ログ(Events)については、以下の記事もご参照ください。 Catoクラウド Eventsの確認方法 CatoクラウドのEvents画面の見方、ログの絞り込み方について解説します。 blog.usize-tech.com 2023.08.22 ルーティングの設計が不要 Catoクラウドでは、基本は拠点がCatoクラウドへ接続するのみのシンプルな構成となり、すべての経路制御はCatoクラウド側で行うため、ユーザがルーティングを意識する必要がなくなります。 複雑な構成にしない限り、経路制御の知識が全く無くてもネットワークが組めるということです。 冗長構成を組むのが簡単 拠点の回線を二重化したり、機器を2台置いてActive/Standby構成にすることはよくありますが、Catoではこれがとても簡単に設定できます。 従来は、各回線や機器の優先度を設計し、Config作成・設定し、実際に意図どおりに切り替わるかを複数パターンでテストし…といったプロセスを踏んでいましたが、Catoではそれらが自動設定されるため、バックアップ側の回線やSocketを接続し、管理画面から数クリックするだけで冗長化構成が完了します。 細かな融通が利かせられない面はありますが、回線・機器の故障時にもユーザが気づかないレベルで切り替わるため、通常の利用には十分です。 Catoクラウドでも楽にはならない点 仮に社内ネットワークをCatoクラウドにした場合にも、変わらず手がかかる点もあります。 セキュリティ設計・運用は従来どおりやる必要がある Catoクラウドの各種セキュリティ機能では、デフォルトで推奨設定が入っていますので、そのままでも不審な通信はBlockし、安全に利用可能です。 しかしながら、実際の運用においては、自社のセキュリティポリシーによって設定をデフォルトから変える必要があったり、日常的にユーザや部署ごとの個別のルールに対応したりといった、セキュリティ運用業務が発生するかと思います。それはインフラがCatoクラウドになっても同様にやっていく必要があります。 また、Catoクラウドにてセキュリティインシデントを検知した際、その後の対応をどうするかといった部分も、セキュリティ運用として決めておく必要があります。 このあたりは、Catoでも既存インフラでも同じように準備が必要です。 やはり足回り回線は最重要 Catoクラウドは優れたサービスですが、接続にはインターネット回線が必須です。 回線が不安定だったり、十分な速度が出なかったりすると、Catoクラウドへの接続に問題が生じ、業務通信が不安定になったり、利用できなくなってしまいます。 回線の選定や管理運用は、昔も今も変わらず重要です。 Catoクラウドのちょっと困る点 従来インフラと比べて、Catoが少し厄介だなと感じる点もあります。 ブラックボックスな面がある Catoクラウドはサービスである以上、利用者が触ることのできる範囲に限界があります。 例えばなにか通信が想定どおり通らないことがあったとして、従来のルータやファイアウォール等の物理機器が存在する場合には、その機器でDebugやパケットキャプチャを取って調べるといったことをやってきましたが、Catoではこれがほぼできません。 ユーザが確認できるのはWebUIの情報に限られており、詳細はCato社へ問い合わせるしかありません。 各機能の仕様は公開されていますが、細かな動作については回答を得られない場合もあり、正直もどかしく感じることもあります。 SocketにCLIでログインできない Socketへのログイン手段はGUIのみとなってしまっており、CLIが利用できません。コンソールポートは動作しているのですが、利用者にはログインが許可されていません。 GUIの情報には限りがあるため、何かあったときに自分で切り分けができないという点で、なかなかもどかしいです。個人的には、自分の手元のネットワーク機器はCLIでログインして状態確認をしたいです。 ベンダ依存となる これは一口に良し悪しをいうことができない内容ではありますが、ベンダーロックイン状態となることについて、留意しておく必要があります。 Catoに限らず、SASEはネットワーク・セキュリティをまるごとサービス提供元に依存する形となるため、信頼できるサービス提供元を選ぶことが重要です。 サービス提供元の規模・体制などをしっかりと確認し、納得した上で利用したいものです。 使いこなそうとするとキャッチアップが必要 Catoクラウドは、毎週アップデートや追加機能がリリースされています。 有償・無償問わず次々と新しい機能が出るため、その恩恵を受けようと思うとリリース情報にキャッチアップする必要があり、これがなかなか大変です。 なお、当社ではCato社のアップデート情報を、日本語で補足も加えて配信しておりますので、ぜひご参照ください。 リリースノート | よくあるご質問 | Cato Cloud ケイトクラウド - SCSK リリースノートについて cato-scsk.dga.jp よくあるご質問 -リリースノート 最後に 世の中の様々なサービスが”所有”から”利用”に向かっている現在(※)、ネットワークとセキュリティの”利用”と言えるSASEは、急速に一般化していくと考えています。 ※例えばDVDやCDがメディア購入→レンタル→サブスクと移り変わったように ここ10年でパブリッククラウドが一般化し、サーバを誰でもWebUIから数分で建てられるのが当たり前になったように、ネットワークとセキュリティもまた、そうなっていくことでしょう。 今後はSASEも、APIの開放やIaC(Infrastructure as Code)対応が進み、もしかするとマルチクラウドのように、マルチSASEが一般化するかもしれません。 我々SCSK Catoクラウドチームも、進化し続けるSASEや関連テクノロジーの一歩先を行き、手軽になっていく高度な機能をどのように統合・活用し、ビジネスに役立てていくかといった視点でご提案ができるよう、日々精進してまいります。

こんにちは、SCSKの木澤です。 先日、VPCにおける大きなアップデートが発表されました。 Multi-VPC ENI Attachments aws.amazon.com EC2から複数のVPCに対してENIを接続できるようになったよ、という話です。 オンプレミスのネットワーク設計経験者であれば、この話を聞いて「管理用VPCが作れるようになったな」と感じることでしょう。 実際私自身もAWS初心者の頃は管理用のネットワークが構成できないことが気になっていました。 ですが、VPCにおいては安易に管理用VPCを設置すべきではないと考えています。 その理由を下にまとめたいと思います。 オンプレミスネットワーク設計のセオリー オンプレミスにおけるネットワーク設計経験が無い方もいらっしゃると思いますので、丁寧に解説したいと思います。 今回は下図のような一般的なWeb3層のシステムのネットワークを設計することにします。 サービスネットワークの設計 Webサーバはインターネットから直接HTTP(S)のアクセスが届き、より外部からの攻撃を受けやすい状況にあります。 アプリケーション層やデータベースはより安全に守りたい、そのためWebサーバはDMZとして別セグメントに置くことが望ましいとされています。 HTTPS TLS復号処理のオフロードや冗長化を考慮するとこのようなネットワーク（論理）構成を採ることが一般的となります。 ロードバランサを1アーム（ELB同様、Webサーバと並列に設置）にするか否か、DBのセグメントを更に分けるのかどうかなど、更に選択の余地があります。 DBサーバクラスタ間の接続に別セグメントが推奨される場合もあります。 管理用ネットワークの追加 さて、単純にサービスを提供するのであればここまでで良いのですが、実際には運用を考慮する必要があります。 運用を考慮すると、下のような構成にすることが一般的です。 サーバの裏側に管理用ネットワークが追加されました。 以下の観点（背景）のため追加されることが多いかと思います。 監視 対象サーバ等と安定した通信を行う必要があります。 また監視はデータセンター提供ベンダー側が管轄することも多いため、責任分界のため表のサービスネットワークとは分離したいというニーズが出てくることもあります。 バックアップ データのバックアップ・サーバ全体のシステムバックアップ、両方のニーズがあります。 バックアップのトラフィックは重いため、バックアップ中のサービス影響を避けるためネットワークを分離することが望ましいです。 メンテナンス サーバへのメンテナンス等のためのログインも考慮する必要がありますが、障害時にも安定してログインできる必要があります。 またセキュリティの考慮のためインターネットから分離し、閉域網経由でアクセスできることが望ましいため、ネットワークを分離します。 （さらに踏み台サーバを設置し、経由しないとメンテナンスできないようにすることが通常と思いますが） これらの理由のため、管理用ネットワークを設置することが望ましいというわけです。 マルチVPC ネットワークアタッチメントについて さて、今回のアップデートについて触れたいと思います。 EC2インスタンスに紐付くプライマリVPCとは別のVPCにも足を伸ばし、接続できるようになったというアップデートになります。 今回は下図のように、単純に２つのVPCに接続した構成を作ってみます。 構成を簡略化するためにパブリックサブネットにEC2インスタンスを設置しています。 手順 まず、追加ENIを作成します。 EC2インスタンスと同一のAZである必要があります。 追加されたENIのIDを把握しておきます。 続けてEC2インスタンスに追加ENIをアタッチしますが、マネジメントコンソールでは別VPCのENIをアタッチできません。 （2023年11月7日現在。いずれ解決されるものと思いますが） そこで、CloudShellを用いてAWS CLIでアタッチを実施します。 クラスメソッド大瀧さんの記事を参考にしました。ありがとうございます。 複数のVPCにEC2インスタンスを接続する | DevelopersIO ども、大瀧です。本日、Amazon EC2にアップデートがあり、複数のVPCにEC2インスタンスを接続できるようになりました。 試してみた様子をご紹介します。 AWS管理コンソールではENIが表示されない 手順としては、 … dev.classmethod.jp 複数VPCに接続されたEC2インスタンスの動作 今回はテストということで以下のVPCに接続されたEC2を起動しました デフォルトVPC（172.31.0.0/16、接続サブネット 　172.31.0.0/20） 追加VPC（10.101.0.0/16、接続サブネット　10.101.2.0/24）※IPv6有効 EC2から見たネットワーク状態は以下の通りで、確かに両VPCに接続されたNICが有効になっています。 ルーティングテーブルはこのような表示になっています。 両VPCのルーティングテーブルが反映され、デフォルトルートが２つ見えてしまっています。 このルーティングテーブルのままでは追加VPC側CIDR宛のルーティングテーブルが定義されておらず適切に通信ができません。 追加VPC側でルーティングができるよう、スタティックルートの設定を追加します。 これで追加VPC側でも他AZのサブネットと通信可能になります。 $ sudo route add -net 10.101.0.0 netmask 255.255.0.0 gw 10.101.2.1 (宛先CIDR) (サブネットマスク) (宛先ゲートウェイ) 同様に、下図のように追加VPC側でVPC Peeringを行った場合でも、OS上のルーティングテーブルを正しく設定すれば構成可能であることを確認しました。 本アップデートに関するAWS発表内容の通り、OS上の設定で複雑な構成を組むことができ柔軟なネットワーク構成を組めそうです。 Tips：本機能でVPC間のEC2インスタンス移行は可能なのか？ さて、本アップデートの情報に触れた際、私はこのように感じました。 追加ENIを付けてから、デフォルトのENIを削除すれば VPC間の移行が可能では？ VPC間でEC2インスタンスを移行する際は一旦AMI作成した後にインスタンス再作成する必要があります。 これが面倒だなと感じていたので、付け替えが可能になれば楽になるな、という横着ですw ですが、あいにくこれは不可でした。デフォルトで付与されているENIはデタッチできません。   EC2における管理用VPC設置の是非 さて新機能に触れたところで、話を戻して管理用VPCを設置することについての是非について考えたいと思います。 EC2運用管理手法の振り返り 上記にてオンプレミスネットワークにおいては管理用ネットワークを設置する理由として、主に３つの理由（監視・バックアップ・メンテナンス）があると書きました。 これらについて、EC2においては設置が必要かどうか考えてみます。 監視 EC2においてはCloudWatchによるメトリクス監視・エージェント監視が標準です。 別途サードパーティーの監視サービスを利用し、エージェント経由で監視することもあるでしょう。 これらはインターネットゲートウェイ、あるいはVPCエンドポイント経由でパブリックネットワークにあるマネージャと通信するため、管理用VPCは不要となります。 但し下図のように統合監視用のAWSアカウントを設けて管理用（監視用）VPC経由で監視したいというニーズがあるかもしれません。 この構成は検証の結果から理論上は可能であることを確認しました。 今まで本ニーズに関しては、VPCを分けずに普通にPeeringしていたかと思います。 そのため特にVPCを分ける必要性は感じませんが、監視アカウントが別オーナーである場合など選択の可能性があるのは否定しません。 後述するリスクを踏まえて判断すれば良いものと思います。 バックアップ EC2のバックアップについては通常、EBSのスナップショットで取得するかと思います。 このトラフィックはサービスネットワークを通りませんので、トラフィック影響を排除するためにネットワークを分離する必要はありません。 データバックアップを行う場合はサービスネットワークを共用しますが、余程のことがない限り帯域を圧迫することは無いはずです。 メンテナンス サーバへのログインを行う際、Linuxインスタンスへの接続はEC2 Instance Connectあるいはセッションマネージャを利用して接続することが推奨です。（Windowsインスタンスであれば AWS Systems Manager – Fleet Manager ） 何れにせよ、サービスネットワークを経由せずセキュアに接続できることが特徴です。 VPCを分割する必要はありません。 AWSインフラについて 仮想化技術 なぜこれらの運用管理機能がマネージドで提供できるのか、念のためおさらいします。 クラウドサービスにおいては、そもそも仮想化技術がベースになっていることが歴史的背景としてあります。 クラウドでは各ユーザーの設定は論理的なものとして自由に作成・削除ができますが、それを実現するために物理ハードウェア間ではユーザから見えないところで網の目のようにネットワークが張り巡らされています。 バックアップや監視についても同様で、ユーザーから見えない範囲のネットワークで実現しています。 この背景からも、ユーザ側で別途管理用ネットワークを設ける必要が無いということになるわけです。 出展： AWS Blackbelt Online Seminar(EC2) マイクロセグメンテーション AWSに関わらずパブリッククラウドにおいてはネットワーク仮想化(SDN)の機構が採用されています。 最大の特徴として、マイクロセグメンテーションにおける論理分割が可能なことが挙げられます。 AWSにおいては、セキュリティグループを用いて論理分割が可能です。冒頭でオンプレミスネットワークにおいては境界型防御や責任分界の観点でネットワークを分離すると説明しましたが、パブリッククラウドにおいては、そもそもその必要は無い。AWSにおいてはVPC内でセキュリティグループ等で論理分割することがベストプラクティスとなります。 最大の違いはこのネットワーク設計のアプローチにあると言えます。 ゼロトラストの原則を理解する - AWS の規範的ガイダンス セキュリティモデルの基盤となるゼロトラストの中核となる一連の基本原則について学んでください。 docs.aws.amazon.com 管理用VPC設置のリスク 上述の検証結果から理論的には管理用ネットワークを設置することが確認できましたので、設置することに関して制約はありません。 但し、以下のリスクを踏まえて判断をすべきと考えます。 セキュリティのリスク やはり管理用VPCを経由して各インスタンス間が接続されていることによるセキュリティリスクを考慮すべきと思います。 セキュリティグループを用いて制御は可能ですが、接続しないことに越したことはありません。 構成が複雑化することによるトラブル これはオンプレミスの場合にも同様ですが、複数ネットワークを整備することによりルーティングが複雑化することで想定外の動作をしトラブルの要因になることがあります。 できるだけベストプラクティスに則ってネットワーク構成して行きましょう！   まとめ 新機能であるMulti VPC ENI Attachmentの機能についてご紹介させていただきました。 長くなりましたが、私としての結論は 「管理VPCの設置は理論上はできるが避けるべき」 です。 オンプレミスとクラウド流のネットワーク設計方針の本質的な違いを振り返る良いきっかけとなりました。 ありがとうございました。

こんにちは。SCSKの山田です。 Dropboxから新しいドキュメント管理・共有・追跡プラットフォームであるDocSendの提供が始まりました。 今回はこのDocSendについてご紹介いたします。 DocSendとは DocSendの特徴 DocSend は、 1 つのリンクで以下のすべて実現します。 安全なデータ提供 ドキュメントや動画など共有したいデータを安全に外部に共有します。 メールの添付ファイルも必要なくなります。 閲覧状況の分析 共有データが閲覧されたか、どの部分に興味を持たれているか可視化されます。 複数データの一元化 複数ドキュメントを一箇所にまとめて共有できます。 共有された側はまるで書庫から資料を取り出すように必要なデータにアクセス出来ます。 また以下についても活用できます。 バージョン管理の問題を解消 ドキュメントを分析する機能 安全に共有する機能 電子署名で契約締結までの時間を短縮 Docsendの使用方法 具体的な使い方の流れとしては、以下の通りです。 ドキュメントを DocSend にアップロードする Dropbox や他のアプリケーションから DocSend にファイルを簡単にアップロードできます。 ドキュメントの制限を設定および更新する 透かし機能やパスワードを設定しドキュメントのセキュリティを強化することができます。 コンテンツを安全に共有し、アクションを促す メールに添付する手間を省きすべてのドキュメントへのアクセスを、カスタマイズした 1 つのリンクで共有できます。 ドキュメントを追跡し、フォローアップする ドキュメントを詳細に分析します。 取引をより早く成立させる Dropbox Signとは別に電子署名機能が組み込まれています。 Dropboxでは、ファイル共有/リンク共有/Transferなどの共有方法がありますが、DocSendは基本リンクでの共有になります。 一般的には資料を共有してもその後相手がどう扱ったかまでは追うことができませんがDocSendでは追跡が可能です。 DocSendの分析機能 DocSendで一番注目すべきは分析機能かと思います。 通常、メールでの資料送付ではニーズや相手の興味の有無を知ることは難しいですが、分析機能から送付した資料がどのように読み込まれているかを詳しく知ることができます。 具体的に滞在時間/地域情報/訪問数/再生時間などの情報が詳細にとれます。共有したドキュメント・動画の開封率、相手がどのページをどのくらいの時間見たか、飛ばしたかを知ることができるほか、誰かが資料を確認していることをリアルタイムで知らせてくれるメール通知もあります。 組織内で利用する際は、部下や生徒に確認しておくよう依頼した資料に、きちんと目を通しているかのチェックができます。見たか見てないかだけでなく、100％確認したかまで確認できるため、課題レポートや課題図書を見ているかによって正しい評価ができます。 また、地域情報や訪問時間は、大規模災害が起きた際、企業や学校が出した案内を従業員・学生が見れているか、つまり安否確認として役立つことも期待できます。 企業同士で利用する際は、キャンペーンのプレゼン資料や営業提案書を無事に共有するだけでなく、資料の閲覧状況とタイミング、興味・関心度をしっかりと分析することができます。 これにより戦略的に顧客をフォローアップし、より的確に契約締結・満足度向上につなげることができるのではないでしょうか。またエンゲージされた見込顧客を特定し新たなステークホルダーや意思決定社の発掘により、潜在的なビジネスチャンスを得ることにも役立つかもしれません。 また、仮想データ ルーム（VDR：Virtual Data Room）という複数のドキュメントを一つの場所にまとめることができる機能もあります。ここから一つののリンクで複数の資料を安全共有できます。 今までは使用言語が英語のみでしたが、この度日本語を含む14言語にも対応しました！   DocSendデモ どのくらいの詳細なデータが取れるのか、実際に使ってみます。 まずこちらがDocSendにログインした画面になります。 右上「コンテンツをアップロード」からデータをDocSendにアップロードできます。 ここに保存されるデータをDocSendの機能を使って共有ができます。   今回はこちらの「ログイン手順」という動画をアップロードしました。 こちらを共有して、相手がどのように内容を確認したか見ていきます。 画面右上「リンクを作成」からリンク作成をして、そのリンクを共有します。   下記画面のようなリンクに対しての設定画面が出てきますので、適切な条件を付けていきます。 閲覧にメール アドレスを必須とする：閲覧者はメール アドレスを入力しないとドキュメント を閲覧できません。 ダウンロードを許可する：閲覧者はファイルをダウンロードできます。 期限：リンクの有効期限 パスコード：パスワードの設定 アクセスを制限：ドキュメントについて、どの訪問者への表示を許可する、またはブロックするかを一覧表示します。メール アドレスを個別に指定することもドメインごとに指定することもできます。 メール認証：閲覧者は自分のメール アドレスに送信された安全なリンク経由で本人確認しないと ドキュメント を閲覧できません。 動画では以下の設定も可能です。 バックグラウンド動作時は一時停止にする ミュート時は一時停止する 再生速度の変更を無効にする 早送りを無効にする   リンクが作成できたのでメールやチャットで共有します。 共有前にDocSendを確認するとアクティビティのアクセス数が０で誰も見ていないことが確認できます。 共有相手にリンクを開いて動画を閲覧してもらいます。 リンクを開いた画面は下記画像のようになります。 記録確認のために、動画を飛ばしたり、倍速にしてもらいました。   動画の閲覧をしてもらった後に再度Docsendを確認すると、アクセス数が1に代わっているのが確認できます。   こちらの結果は以下のように確認できます。 まず閲覧時間ですが、全体55秒の動画に対して31秒だけ見たことが確認できます。 色の帯がないところは動画内で飛ばした箇所になります。 下画像の黒い吹き出し部分では、再生した速度が1倍で通常通りに閲覧していることが確認ができます。         以下部分では再生した速度が2倍であるk十や、音をミュートしていることが確認ができます。   PPT資料だと以下のような結果を確認できます。 各ページごとに資料見た時間がわかります。                 まとめ 実際にDocSendを使ってみましたが、かなり詳細に記録がとれていました。 共有相手がどこに興味を持ったか、どこを飛ばしたかを確認できると営業活動や社内教育に非常に役立つと思います。 また、管理・共有・分析が高いセキュリティの一つのリンクで完結できるのがとても効率的です。 企業や学校などでぜひご活用ください。 以下DocSendのリンクです。実際に見てみてください。 DocSend - Simple, intelligent, modern content sending DocSend helps you communicate more effectively by telling you what happens to content after you send them and letting you keep control in real time. docsend.com

はじめに Cato社が提供しているCASB機能は、クラウド環境におけるセキュリティ対策を行うための機能です。 CASBとはCloud Access Security Brokerの略で、クラウドサービスにアクセスする際のセキュリティを担保するために導入されます。 Cato社のCASB機能では、主に以下のような機能が提供されています。 クラウドアプリケーションの可視化 セキュリティイベントの評価と分析 アプリケーションの制御 データの検出と保護 このような機能により、クラウド環境におけるセキュリティリスクを抑え、セキュリティ対策の強化を図ることができます。また、Cato社のCASB機能は、柔軟性が高く、複数のクラウドサービスに対応しているため、多様なクラウド環境に適用することができます。   上記CASB機能のうちアプリケーションの制御は、Catoクラウドの「Application Control」で実施できます。 本記事ではCASB機能のApplication Controlの設定方法や実際にどのような制限ができるのかについて解説していきたいと思います。   CASBについての詳細は以下技術ブログに記載がございますので、ご確認いただければと思います。 CatoクラウドのCASBについて – TechHarmony (usize-tech.com)   Application Controlでできること CatoクラウドのApplication Controlではどのようなことができるのかご紹介させていただきます。 Catoクラウドでは数多くのアプリケーションおよびサービスが登録されており、それらを制御することが可能となっております。  登録されているアプリケーションの中でも、主要なアプリをピックアップし、Catoクラウドでどのような制御ができるのかご紹介いたします。 No. アプリケーション名 主な制御内容 1 Adobe Creative Cloud ファイルのアップロードやダウンロード 2 Amazon Web Services EC2インスタンスへのアクセス制御 3 Box ファイルのアップロードやダウンロード 4 Dropbox ファイルのアップロードやダウンロード 5 Evernote ノートのアップロードやダウンロード 6 Facebook メッセージの送受信や投稿 7 GitHub リポジトリへのアクセス制御 8 Gmail メールの送受信や添付ファイル 9 Google Apps ドキュメントやスプレッドシートのアクセス制御 10 Google Drive ファイルのアップロードやダウンロード 11 Apple iCloud ファイルのアップロードやダウンロード 12 LinkedIn メッセージの送受信や投稿 13 Microsoft Office 365 ドキュメントやスプレッドシートのアクセス制御 14 Salesforce データのアクセス制御 15 Slack メッセージの送受信や投稿 16 X/Twitter ツイートの投稿やメッセージの送受信 17 WebEx オンライン会議や画面共有 18 Zoom オンライン会議や画面共有 ファイルのアップロードダウンロード、メッセージの送信などが制御できる内容になっています。 上記アプリ以外にも、Catoクラウドは常にアプリケーションの更新を行っているので、これからもアプリ数・制御内容が拡充していくと思われます。   Cato社のサンプル設定 2023年10月以降に新規でCASB機能をご契約いただいたアカウントに関しまして、デフォルトでCato社の設定例が入っております。 投入されている設定を参考にし、既存設定を自社用にアレンジしていくことで効率よくアプリケーションを制御することが可能となります。 以下が設定内容となります。 No. ルール内容 対象アプリ 1 Microsoftへのログインを指定のテナント名のみ許可する   Microsoft   2 Microsoftへログインする上記以外のテナント名はログに残す 3 OneDriveのログインを対象のテナント名のみ許可する OneDrive 4 上記以外のテナント名の場合ログに残す 5 個人用のOneDriveテナントの場合ログに残す 6 Gmailアプリを使用してメールに添付ファイルを追加する際、ログに残す Gmail 7 オンラインストレージカテゴリのアプリを監視し、次のいずれかの条件に一致した場合、ログに残す。 Catoリスクスコアが3より高い(4以上) ISO 27001を満たしていない Online storage apps 8 Twitter/X にて全ての投稿をログに残す Twitter/X 9 OpenAIへのログインは、指定されたユーザとテナント名のみ許可する OpenAI 10 上記以外のユーザ、テナント名の場合ログに残す 11 OpenAIへのログインにてthird-partyの場合ログに残す 12 Google Driveにて許可されたフォルダの表示を制限する Google Drive 13 Google Driveにて許可されていないフォルダをログに残す   設定方法について それでは、実際のApplication Controlの設定方法について解説していきます。 CMA（管理画面）上で設定を入れる際は以下の画面にて操作を行っていきます。 Securty＞Application Control＞Application Control Policy＞App Control Rule   では、投入する設定項目についてみてみましょう。 まず、Applicationにて制御したい対象のアプリを選択します。 「Any Cloud Application」にてクラウドアプリケーション全体や、カテゴリーなどで大枠のアプリを選択することも可能です。   次に、Activitiesで制御したい内容を選択します。 内容については、選択したアプリケーション毎に異なってきます。 メール機能のアプリなどであれば、メール送付やファイル添付の制御が可能でしたり、アプリケーションへのログイン制御なども可能になってきます。 制御内容を①許可、②拒否、③監視（ログに残す）のいずれか選択してルールを反映させれば設定完了です。   実際に設定をいれてやってみた 設定の投入方法がわかったところで、上記設定例を参考にしつつ、実際にルールを設定して想定通りの制御ができるか確認してみましょう。 今回は、「Microsoftへのログインを制御する」というルールを設定してみます。 ルールは以下の内容を設定します。 1 Microsoftへのログインにてユーザー名に「SCSK」が含まれているものを許可する 2 Microsoftログインをブロックする まず、許可する対象のユーザー名を指定し、ログイン許可のルールを設定します。その配下に、Microsoftへのログインをブロックする設定を入れます。これにより、許可したユーザー名以外のアカウントをブロックし、ログイン制御をすることができます。   今回は「SCSK」のユーザー名が含まれるアカウントでログインを実施してみます。 SCSKドメインのアカウントでMicrosoftへログインをしていきます。 当然ながらログインができ、以下のようなログが出力されました。   続いて、ドメイン名に「SCSK」が入っていないアカウントでログインを実施してみます。 すると、想定通りMicrosoftへのログイン画面にてblockの表示がされました。該当のログは以下のようなものになります。   このようにアプリケーションへのログインの制御などが可能となります。   まとめ CatoクラウドのCASB機能にはセキュリティ強化、アプリケーション利用状況の可視化を行うことができ、柔軟性があるため多様なクラウド環境に適用することができ、セキュリティ対策を一元管理することができます。 CatoクラウドではCASB機能はセキュリティオプションとなりますが、クラウド環境においてセキュリティを強化するために、CASB機能を有効活用することをおすすめします。

はじめに Cato クラウドでは、Internet Firewall のベストプラクティスとして QUIC プロトコル (QUIC Service と GQUIC Application) の通信をブロックすることが推奨されています。これはドキュメントの Internet and WAN Firewall Policies – Best Practices のページだけでなく、他の複数のページにも同様のことが書かれています。 また、CASB 機能の1つである Application Control を有効にすると、QUIC プロトコルをブロックするルールが Internet Firewall の上位に自動的に作られるようにもなっています。 本記事では QUIC プロトコルの仕組みについて簡単に触れつつ、QUIC プロトコルをブロックすべき理由やブロックすることで生じる問題点について解説します。 QUIC プロトコルとは QUIC とは、2021年5月に IETF にてインターネット標準として定められた通信プロトコルであり、TCP と同様に信頼性の高い通信を行うためのトランスポート層のプロトコルです。現在のところ、トランスポート層として QUIC を利用するアプリケーションプロトコルとしては、HTTP/3 のみインターネット標準として定められています。 QUIC は比較的新しいプロトコルではあるものの、10年ほど前に Google が公開したプロトコルが基となっており、既に多くの Web サイトや Web サービスが QUIC および HTTP/3 を採用しています。また、主要なブラウザ (Google Chrome, Microsoft Edge, Mozilla Firefox など) も HTTP/3 に対応しており、ご自宅などの環境では HTTP/3 でインターネットと通信が行われているはずです。 実際、私の自宅から Google のトップページを Google Chrome で表示させ、デベロッパーツールで通信の内容を確認すると次のようになっていました。 デベロッパーツールの “Protocol” という列が “h3” となっているリクエストは、HTTP/3 で通信されたことを表しています。(“h2” は HTTP/2 で通信されたことを表しています。) また、私個人として Web サイトを AWS の CloudFront という CDN サービスを用いて公開していますが、CloudFront も HTTP/3 に対応していますので、私個人の Web サイトも HTTP/3 でアクセスできるようにしています。 このように、HTTP/3 は普通のインターネット利用者が気付かない形でどんどん普及しており、その下では QUIC プロトコルによるトラフィックも多く流れているという状況にあります。 QUIC プロトコルの構造 QUIC と HTTP/3 についてもう少し詳しく説明します。 QUIC はトランスポート層のプロトコルですが、IP ではなく UDP の上に構築されたプロトコルです。すなわち、IP パケットのデータ部に UDP パケットがあり、UDP パケットのデータ部に QUIC パケットがあるという構造となっています。   この構造により、ネットワーク機器が QUIC を扱えなくても、UDP 通信の制御により QUIC 通信の可否を制御できるようになっています。HTTP/3 は通常 443 番ポートを利用して通信しますので、アウトバウンド方向に UDP 443 番ポートの通信が許可されていれば、HTTP/3 通信を行えるということになります。 QUIC プロトコルをブロックすべき理由 さて、Cato クラウドでは Internet Firewall で QUIC プロトコルをブロックすることが推奨されていますが、ブロックしないとどのような問題が起きるのでしょうか。 ドキュメントの Internet and WAN Firewall Policies – Best Practices のページには次の一文が記載されています。 Since the QUIC protocol works over UDP 443, encapsulated HTTP traffic is not parsed. Cato クラウドは HTTP/3 通信の内容を解析しないと述べられています。つまり、HTTP/3 通信に対して Cato クラウドは TLS インスペクションを行わず、Application Control や DLP といった CASB の機能も働かないということを示しています。 CASB 機能は Cato クラウドの魅力の1つでもあり、この機能が働かないというのは困ります。そのため、QUIC プロトコルをブロックして HTTP/3 通信を行えないようにすることで、CASB 機能が働く HTTP/2 や HTTP/1.1 による通信に限定しようというのが先の Internet Firewall のブロックルールの意図です。 この対応は理想的な内容ではありませんが、Cato クラウドの現状の仕様を考慮すると最善の対応であると思います。 ブロックすることで生じる問題点 通信できなくならないか Cato クラウドで QUIC プロトコルをブロックすることで、別の問題が発生しないか気になるのではないでしょうか。これについては、問題は概ね発生しないと断言して良いと思います。 通常、ブラウザは最初に HTTP/2 や HTTP/1.1 で Web サーバと通信を開始し、レスポンスに Web サーバが HTTP/3 に対応しているかどうかを示すヘッダ (Alt-Svc ヘッダ) が含まれていれば、次からは HTTP/3 で通信しようとします。しかし、QUIC プロトコルがブロックされているとブラウザは Web サーバとの間で HTTP/3 接続を確立できないため、引き続き HTTP/2 や HTTP/1.1 で通信を行います。そのため、QUIC プロトコルをブロックしても Web サーバと通信ができなくなることはありません。 ただし、ブラウザ以外のソフトウェア (モバイルアプリケーションや PC 上で動作するデスクトップアプリケーションなど) については上記の限りではありません。通信を HTTP/3 にアップグレードしたり、HTTP/3 で通信できずにフォーバックしたりする仕組みはソフトウェアの実装依存ですので、ソフトウェアが適切に作られていないと正常に動作しないケースがあるかもしれません。 その他懸念点 他にもいくつか懸念点はあります。 最大の懸念点としては、Cato クラウドのベストプラクティスに従い QUIC プロトコル (QUIC Service と GQUIC Application) をブロックするようにしたとき、QUIC 以外の通信もブロックされてしまわないかという点です。UDP 通信の中身が QUIC かどうかを確実に見分ける方法はないため、Cato クラウドが QUIC ではない何らかの UDP 通信を誤ってブロックしてしまう可能性があります。 試しにインターネット上で 443 番ポートで適当な UDP サーバを起動し、Cato クラウド経由でアクセスしたところ、QUIC ではないデータを送信しているにもかかわらずブロックされてしまいました。 QUIC プロトコルをブロックするというルールが実際にどのような条件に該当する通信をブロックするのか仕様として公開されていないため、誤ったブロックの可能性を拭えません。そのため、イベントログにて誤ったブロックが発生していないか定期的に確認し、誤ったブロックが見つかれば明示的に Allow するルールを追加するといった運用が必要となります。 また、些細な懸念点としては、ブラウザが HTTP/3 通信を試みてから HTTP/2 や HTTP/1.1 にフォールバックするまで、通信が待たされてしまうという点です。実際にどの程度の時間待たされるのかはブラウザ次第であり、過去には数十秒待たされることがありましたが、現在はほとんど気にならない程度になっていると感じています。他にも、通信できない無駄な UDP トラフィックが発生するというのも少し気になります。 これについては、Cato クラウドが HTTP/2 や HTTP/1.1 通信のレスポンスヘッダから Alt-Svc ヘッダを除去してくれれば、ブラウザが HTTP/3 通信を試みることがなくなりますので、Cato クラウドの機能改善を待ちたいところです。 まとめ 本記事では QUIC プロトコルをブロックするというベストプラクティスに関して、技術的な背景や新たな課題について整理しました。 現状では CASB 機能を正しく働かせるために QUIC をブロックすべきなのは間違いありませんので、ベストプラクティスに従ってルールを追加することを推奨します。一方で、誤ったブロックが発生する可能性などの懸念点もありますので、利用者側でイベントログをもとにした運用も必要となってきます。 QUIC という新しい通信プロトコルは現在は HTTP/3 でしか利用されていないものの、他のアプリケーションプロトコルで活用するための議論が IETF で活発に行われています。将来 HTTP/3 以外で QUIC 通信が増えてくると、Cato クラウドの機能やベストプラクティス自体もまた変わってくるはずですので、通信プロトコル界隈の動向には今後も目を離せませんね。

こんにちは。SCSKの丸山です。 本日は、データベースの性能問題にお悩みの方必見！の新サービスのご紹介です。 マルチデータベース　パフォーマンスチューニングサービス｜SCSK株式会社 データベースの性能にお困りの方に、複数のDBに精通するエンジニアがデータベースの性能改善支援を実施します。 www.scsk.jp データベースの性能問題、システム開発をされた方は一度は経験があるのではないでしょうか。 開発中のシステムのDB性能が出ない… データ量が増えてきて性能が低下し始めた… SQLの改善方法がわからない… などなど、私たちのチームにも、データベースの性能に関する相談がよくあります。そこで、新しくデータベースのチューニングに関するサービスをリリースいたしました。その名も、 「SCSK マルチデータベース　パフォーマンスチューニングサービス」 データベースの性能にお困りの方に、複数のデータベースに精通するエンジニアがデータベースの性能改善支援を実施するサービスです。これまでも、データベースの性能問題については様々な事案を対応してきましたので、改めてサービスとして皆様に届けやすいサービスとなっております。 特徴としては、Oracle DB, MySQL, PostgreSQLをベースとしたDBについて オンプレクラウド問わずに対応できる こと※。 複数のデータベースに精通したエンジニアが対応 しますので、Oracle DBからPostgreSQLなどへの 異種DB移行時における性能問題にも対応可 能 です。 「データベースのことよくわからないので、まるっとお任せしたい」 というアプリ担当者から、 「原因のあるSQLは特定できているが、改善方法がわからない」 というDB担当者まで、幅広く対応するためのメニューをそろえております。 気になる方は、是非以下URLをご参照ください。 マルチデータベース　パフォーマンスチューニングサービス｜SCSK株式会社 データベースの性能にお困りの方に、複数のDBに精通するエンジニアがデータベースの性能改善支援を実施します。 www.scsk.jp 以上となります。 ※ただし、商用サポートがあるものを前提とします。  

みなさん、こんにちは。SCSKで飼われているひつじです。 最近は涼しくなってきて過ごしやすいです。 AWS Well-Architectedフレームワークが２年ぶりにメジャーアップデートされました。 結構いろいろ変わったので見てみましょう。 なにが変わったの？ 柱の構成要素である「ベストプラクティス」がトータルで増えました。 内容が更新されたものもあります。かなりの数です。さすがメジャーアップデート。   運用上の優秀性の柱 更新された質問 ワークロードをサポートする準備が整っていることはどうすれば確認できるでしょうか? どのようにデプロイのリスクを軽減しますか? どのように欠陥を減らし、修正を容易にして、本番環境へのフローを改善するのですか? ワークロードと運用イベントはどのように管理しますか? 優先順位はどのように決定すればよいでしょうか? ビジネスの成果をサポートするために、組織をどのように構築しますか? オペレーションの正常性をどのように把握しますか? オペレーションを進化させる方法 組織の文化はビジネスの成果をどのようにサポートしますか? 削除された質問 どのようにワークロードを設計して、その状態を理解できるようにするのですか? ワークロードの正常性をどのように把握しますか? 新しい質問 組織でワークロードのオブザーバビリティを活用する方法を教えてください。 ワークロードにオブザーバビリティを実装する方法を教えてください。 セキュリティの柱 更新された質問 ネットワークリソースをどのように保護しますか? 保管時のデータをどのように保護していますか? どのようにデータを分類していますか? コンピューティングリソースをどのように保護していますか? 転送時のデータをどのように保護していますか? ユーザー ID とマシン ID はどのように管理したらよいでしょうか? セキュリティイベントをどのように検出し、調査していますか？ 人とマシンのアクセス許可はどのように管理すればよいでしょうか? インシデントの予測、対応、復旧はどのように行いますか? ワークロードを安全に運用するには、どうすればよいですか? 新しい質問 設計、開発、デプロイのライフサイクル全体を通じて、アプリケーションのセキュリティ特性をどのように組み込み、検証すればよいのでしょうか?   信頼性の柱 更新された質問 ネットワークトポロジをどのように計画しますか? どのように信頼性をテストしますか? コンポーネントの障害に耐えるようにワークロードを設計するにはどうすればよいですか? ワークロードリソースをモニタリングするにはどうすればよいですか? ワークロードを保護するために障害分離をどのように使用しますか? 災害対策 (DR) はどのように計画するのですか? データはどのようにバックアップするのですか? どのようにワークロードサービスアーキテクチャを設計すればよいですか? 障害を緩和または耐えるために、分散システムの操作をどのように設計しますか? サービスクォータと制約はどのように管理しますか? 変更はどのように実装するのですか? 障害を防ぐために、分散システムの操作をどのように設計しますか? パフォーマンス効率の柱 更新された質問 ワークロードに適したクラウドリソースとアーキテクチャパターンを選択する方法を教えてください。 削除された質問 データベースソリューションをどのように選択していますか。 どのようにネットワーキングソリューションを選択するのですか? ストレージソリューションをどのように選択していますか? リソースが稼働していることを確実にするためのリソースのモニタリングはどのように行いますか? ワークロードを進化させるためにどのように新機能を取り込んでいますか？ トレードオフをどのように使用するとパフォーマンスが向上するのですか? コンピューティングソリューションはどのように選択するのですか? 新しい質問 ワークロードのパフォーマンス効率を高めるために、どのようなプロセスを使用していますか? ワークロード内のデータを保存、管理、アクセスする方法を教えてください。 ワークロードでネットワーキングリソースを選択して設定する方法を教えてください。 ワークロードでコンピューティングリソースをどのように選択して使用しますか? 信頼性の柱 更新された質問 ネットワークトポロジをどのように計画しますか? どのように信頼性をテストしますか? コンポーネントの障害に耐えるようにワークロードを設計するにはどうすればよいですか? ワークロードリソースをモニタリングするにはどうすればよいですか? ワークロードを保護するために障害分離をどのように使用しますか? 災害対策 (DR) はどのように計画するのですか? データはどのようにバックアップするのですか? どのようにワークロードサービスアーキテクチャを設計すればよいですか? 障害を緩和または耐えるために、分散システムの操作をどのように設計しますか? サービスクォータと制約はどのように管理しますか? 変更はどのように実装するのですか? 障害を防ぐために、分散システムの操作をどのように設計しますか? コスト最適化の柱 更新された質問 クラウド財務管理はどのように実装しますか? 不要なリソースをどのように削除しますか？ どのように需要を管理し、リソースを供給しますか? コストと使用状況をどのように監視していますか? コストターゲットに合わせて、リソースタイプ、リソースサイズ、およびリソース数を選択するには、どうすればよいですか? コストを削減するには、料金モデルをどのように使用したらよいでしょうか? サービスを選択するとき、どのようにコストを評価しますか? データ転送料金についてどのように計画していますか？ 新しいサービスをどのように評価していますか？ 使用状況をどのように管理しますか? 新しい質問 労力コストを評価するにはどうすればよいですか? 持続可能性 の柱 新しい質問 組織のプロセスは、持続可能性目標の達成にどのように役立ちますか? ソフトウェアとアーキテクチャのパターンをどのように利用して、持続可能性目標を目指しますか? データ管理のポリシーとパターンをどのように利用して、持続可能性目標を達成しますか? アーキテクチャでクラウドのハードウェアとサービスをどのように選択して、持続可能性目標を達成しますか? クラウドリソースを需要に合わせる方法 ワークロードにリージョンを選択する方法 まとめ 2年ぶりにメジャーアップデートで大きく内容が変わったので最新のベストプラクティスに沿ってAWS環境をより良いモノにできますね。 パフォーマンスの柱はトータルで設問が減りましたが、そのほかの柱は充足された内容になっております。 「効率化」と「充足化」の両方の性質を併せ持つアップデートだったかなと思います。 本項目を内部統制の仕組みやツールに組み込んでいる場合は大幅な改修が必要になると思うので無理せず頑張っていきましょう。

こんにちは、SCSK 林です！ 今回は先日の Google Cloud Next ’23 にてプレビュー版の提供が発表された、Duet AI in Google Cloud を触ってみました。 Duet AI とは 2023年5月の Google I/O で発表された Duet AI は、Google の Generative AI 基盤モデルを搭載した、様々なユーザーに必要な支援を提供するAI コラボレーターです。 Duet AI は大きく2つにわけられ、今回の Google Cloud Next ’23 で以下が発表されました。 Duet AI in Google Workspace：GA版がリリース Duet AI in Google Cloud：機能拡張、プレビュー版がリリース さらに「Duet AI in Google Cloud」にも様々な機能があり、、 アクティビティの種類 製品 アプリケーション開発支援 Cloud Workstations、Cloud Code for VS Code、Cloud Code for IntelliJ and other JetBrains IDEs、Colab Enterprise データ分析支援 BigQuery、Cloud Spanner オペレーション支援 Duet AI in Google Cloud Console、Cloud Logging、Error Reporting ということでこの記事では「Duet AI in Google Cloud Console」を触ってみた！という記事になります。   Duet AI in Google Cloud の公式ドキュメントはコチラ↓ Duet AI in Google Cloud overview Learn about Duet AI features and benefits. cloud.google.com Google Cloud Next ’23 にて発表された内容はコチラ↓ ユーザーをサポートする AI コラボレーター「Duet AI」を Google Cloud 全体で拡張 | Google Cloud 公式ブログ cloud.google.com   Duet AI in Google Cloud を有効にする 2023年8月時点では、Duet AI in Google Cloud はデフォルトで使用できるわけではなく、使用するにはフォームから申請が必要です。 ざっくり以下の手順になります。 フォームからプレビュー版の使用を申請 １～２日で Google からメールが届き、プロジェクト番号を入力し再度申請 ３～４日で Google から完了メールが届く 「 Cloud AI Companion API 」を有効化する（CLIからのみ可能） 詳しい手順はこちらのドキュメントに記載があります。 Set up Duet AI for a project  |  Google Cloud Learn how to set up Duet AI for a project before you use it. cloud.google.com   Duet AI in Google Cloud Console を触ってみる Duet AI in Google Cloud Console は右上のボタンから開けます。 英語表記になっていますが、日本語でも返してくれます。 返せない質問を投げると「Sorry, I can’t help you with this.」と返ってきます。 公式ドキュメントにあった例文を投げてみます。 それの日本語版。コマンドがワンクリックでコピーできるのはうれしいですね！ 返答のコマンド右上にある各アイコンを見てみます。 左から「クリップボードにコピー」、「Cloud Shell にコピー」、「Code Snippet を展開」です。 「Cloud Shell にコピー」をクリックすると、Cloud Shell が起動しコマンドが入力された状態になります。 「Code Snippet を展開」をクリックすると画面中央にプロンプトが現れてコマンド全体が見れるようになります。   Duet AI vs Bard 色々使ってみて Bard とどう回答が違うのかを比較してみました。 Google Cloud で画像認識サービスを開発する手順 質問文 コンピュータ ビジョン アプリケーションの開発に興味があります。たくさんの Google ドライブにあるラベル付けされていないトレーニング データがたくさんあります。どのように始めればよいのかわかりません。このデータを使って画像認識サービスを開発するには、まずどのようなステップを踏めばよいでしょうか？このデータを使って画像認識サービスを開発するために、まず何をすればいいのでしょうか？ ※公式ドキュメントに記載の例文の日本語訳です。（ https://cloud.google.com/duet-ai/docs/quickstart#more-duet-ai-examples ） Duet AI Google Cloud で具体的に何をすればよいかがわかりやすい！   Bard 質問文に「Google Cloud」というワードを入れていないので、Bard は一般的な回答になってしまったのかもしれないですね。。 Compute Engine を作成する gcloud コマンドの生成 質問文 Compute Engineを作成するgcloudコマンドを生成してください Duet AI コマンド全文 gcloud compute instances create [INSTANCE_NAME] –zone=[ZONE] –machine-type=[MACHINE_TYPE] –image-family=[IMAGE_FAMILY] –image-project=[IMAGE_PROJECT]   Bard Bard の方が圧倒的情報量。。 Google Cloud の ETL サービス紹介 質問文： Google CloudのETLサービスについて教えてください Duet AI Bard やはり情報量では Bard が勝る。。 Redshift と BigQuery の比較 質問文： Redshiftと比較してBigQueryの利点を教えてください Duet AI Bard やはり情報量では（以下略 番外編：AWS の ETL サービス紹介 質問文： AWSのETLサービスについて教えてください Duet AI さすがに AWS の質問は答えてくれませんでした。。 参考：Bard   さいごに Google Cloud の細かい技術内容、Google Cloud に特化した内容であれば、Duet AI in Google Cloud Console を使うのは有用だと感じました。 内容によっては Bard を使った方がいいかも、、とも思いますが、Duet AI はGoogle Cloud コンソールのサイドパネルでさくっと開けるので使い勝手はよいと思いました。返答も今後さらによくなることを期待します！ 今回はこんなところで次回、 Duet AI in BigQuery 編をぜひお待ちください！

昨年（2022年7月）より提供を開始しているCatoクラウドのFAQサイトについて話をします。 FAQサイト よくあるご質問 | Cato Cloud ケイトクラウド - SCSK Cato SASE Cloud Platform. powered by SCSK cato-scsk.dga.jp CatoクラウドのFAQサイトは、日々多くの方にアクセスいただいております。 （ 1日あたり平均700～800PV 　※2023年10月時点） ただし、Webアクセス元は、お客様というよりも Catoクラウドのリセラーやパートナーからのアクセスが多い傾向のようです。 ちなみに当社が導入事例としてリリースされているので、ご存知の方が多いと思いますがFAQサイトは、株式会社スカラコミュニケーションズの i-ask を利用しております。 SCSKが提供する「CATO クラウド」にi-askが導入されました – 株式会社スカラコミュニケーションズ scala-com.jp 導入事例 | SCSK株式会社 | 250社以上の導入実績「i-ask」| ナレッジ共有＆見つかるFAQ管理サービス | スカラコミュニケーションズ | コンテンツの出し分けでお客様が使いやすいFAQサイトを構築。スムーズな情報発信でお問い合わせを削減しました。 | i-ask 導入事例 lp.scala-com.jp i-ask を採用し、FAQコンテンツの出し分け（表示するページデザインや内容を変えて表示）を実施しております。 つまり、広く一般に公開している情報以外に、当社とご契約を頂いているお客様に対しては（契約者IDでのログインにて）より詳細な技術情報を始め、CatoのKnowledge Baseへのリンクや、当社が作成した手順書やマニュアルを添付資料としてご提供をしております。   一般利用者と契約者の違い FAQサイトにおける一般のご利用者と、ご契約者のカテゴリ別アクセス状況についてです。 広く一般に公開している情報については、「 1. トラブル・不具合 」、「 2. リリースノート 」、「 3. はじめに 」になっており、多くはトラブルや不具合を目的にFAQを利用されていることが分かります。リリースノートの閲覧数も多いことから、すでにCatoクラウドをご利用になられているお客様からのアクセスも多くあるのではないかと想定しております。 一方で、ご契約者のカテゴリ別アクセス状況は、「 1.手順書 」、「 2.リリースノート 」、「 3.機能 」となっており、ご契約を頂いているお客様は、手順書カテゴリ（このカテゴリは、ご契約者サイトにしかございません）を利用され、次に、Catoクラウドの毎週更新されるアップデート情報をご利用されていることが分かります。   検索語ランキング 次に一般に公開している情報への検索キーワード Top10です。 No. 検索キーワード 1 Socket、vSocket、ソケット 2 TLS、SSL 3 クライアント 4 ケイト 5 証明書 6 PoP 7 ログ 8 帯域 9 Authentication 10 認証 やはり、SASEの”エッジ”である「 Socket/vSocket 」や「 Catoクライアント 」に関する検索が多く、次に多いのは、「 TLS 」でありTLS Inspectionに関しての疑問が多くあるのではないかと想定しております。   アンケート（フリーフォーマット）について FAQのそれぞれ回答（文書）には、参考になったかどうかの[はい]、[いいえ]と、フリーのアンケート入力フォームがあるのですが、このアンケートへの記載内容、以下について話をしたいと思います。 FAQへの追加質問について FAQの間違い指摘について 便所の落書きについて   FAQへの追加質問について FAQの記載情報に対し、さらに追加の質問をアンケートに書かれる場合が多くあります。 「○○○とありますが、どういう意味でしょうか？」 「○○○とありますが、理由は何でしょうか？」 「○○○とは、△△△のことでしょうか？それとも×××のことでしょうか？」 匿名で連絡先の記載もないため、そもそも直接回答する手段がありません。 何かご質問があれば、当社の問い合わせ先までお願いいたします。 お問い合わせ 製品・サービスについて 入力 ｜ SCSK株式会社 SCSK株式会社 製品・サービスについてご意見・ご質問をお受けしております。 www.scsk.jp ただし、当社のFAQサイトは、前述の通り、一般公開情報とご契約者様とでコンテンツの出し分けを行っております。 当社のサポート窓口のご契約を頂いているお客様には、Catoクラウドの技術問い合わせをサービスとしてご提供しており（24H365Dの受付、回答は平日9:00-17:00）、さらに、FAQサイトの契約者IDをお渡しておりますので、一般公開していない情報についても、ご覧いただくことが可能になっています。 逆に、ご契約されていない方には、お問い合わせ対応や追加情報のご提供はしておりませんので、予めご了承ください。 もちろん、 現在Catoクラウドのご採用を検討中のお客様や、すでにCatoクラウドをご利用で、既存リセラー（パートナー）からの切り替えを検討されているお客様の質問であれば、遠慮なく当社の問い合わせ先までご連絡ください 。   FAQの間違い指摘について Catoクラウドは、ご存知の方も多いと思いますが、毎週サービス機能がアップデートされています。 リリースノート | よくあるご質問 | Cato Cloud ケイトクラウド - SCSK リリースノートについて cato-scsk.dga.jp ちなみに、 昨年（2022年）度は、年間 3,000を超える機能がリリースされています ので、FAQの情報はすぐに古くなります。 当社で適宜FAQの情報を更新していますが、やはり手が行き届かず、最新情報と異なる情報も多くあります。 アンケートで情報が古いという指摘をいただくことがありますが、これは非常にありがたいです。ありがとうございます。 ご指摘いただいた文書が間違った情報であることが確認できれば、速やかに修正しますので、引き続き間違いを発見された際には、ご指摘いただれば幸いです。   便所の落書きについて 具体的な内容は書けないですが、こちらを馬鹿にする内容などです。 今後も続くようであれば、アンケート入力フォームを停止しようと思っており、場合によっては、FAQサイトの一般公開を停止し、すべてご契約者限定にしようと考えております。 SCSKでは、ネットワークセキュリティのクラウドサービスである「SASE」さらに「Catoクラウド」が、そもそも新しい概念・サービスであるため、多くの疑問点や不明点が出てくるため、その解消を目的にFAQサイトの運営（一般公開）を行っております。 特に、Catoクラウドについては、日本語の情報が非常に少ないため、このエンジニアブログ（TechHarmony）も利用し、積極的な情報発信を行っております。 もちろん、SCSKとしてのマーケティングや販促効果も期待しておりますが、FAQ（i-ask）も無料ではありません。情報を無料で閲覧されるのはもちろん全く問題ないですが、アンケート入力フォームに、馬鹿にする内容、侮辱的な内容を記載されることは受け入れがたく、良識のある行動をお願いできれば幸いです。 もちろんですが、このような内容を書かれた時間、IPアドレスについてはすべて把握しております。   まとめ 毎度のことですが、SCSKでは、2021年からSASEの主要ソリューションを一同に紹介を行うオンラインセミナー「SCSK SASE Solution Summit（通称 S4）」を定期的に開催しており、これまで1,000名以上の方にご参加いただいております。 次回は、2023年10月12日（木）に開催を予定しておりますので、是非ご参加いただれば幸いです。 SCSKでは、Catoクラウドは、2019年より取り扱いを開始し、すでに多くのお客様の導入/運用をご支援させていただいております。 Catoクラウドの知名度向上に向けて、お客様導入事例の制作や、今回ご紹介したFAQサイトの運営、この技術ブログ（TechHarmony）で、さらに皆様のお役に立て、Catoクラウドの知名度UPに少しでも貢献できればと考えておりますので、引き続きよろしくお願いします。

こんにちは。一重です。 とある案件でS3のクロスアカウントアクセスの検証を行った際に、エラーでハマったので共有したいと思います。 VPCエンドポイント経由でアクセスをする際、接続がタイムアウトしているというメッセージが出ており、その原因について今回は記載していきます。 やりたかったこと 下記情報を参考にアカウントAに構築したLinuxサーバからAWS CLIを利用して、アカウントBのS3バケットにアクセスしようとしました。 EC2 インスタンスに S3 バケットへのクロスアカウントアクセス権限を付与する Amazon Elastic Compute Cloud (Amazon EC2) インスタンスを使用して、別のアカウントの Amazon Simple Storage Service (Amazon S3) バケットにアクセスしたいと考えています。インスタンスに認証情報を保存することなく、このアクセス権限を付与するに... repost.aws すると下記のエラーになってしまいました。 [ec2-user@XXXX ~]$ aws s3 ls s3://bucketname Connect timeout on endpoint URL: "https://sts.amazonaws.com/" 原因 エラーになっていた原因はAWS CLIのバージョンが古かったことでした。 AWS CLI バージョン 2 の新機能と変更点 - AWS Command Line Interface 新機能と、AWS CLI バージョン 1 と AWS CLI バージョン 2 の間の動作における変更について説明します。 docs.aws.amazon.com この記事によると「AWS CLI バージョン 1 はデフォルトで、AWS STS リクエストをグローバル AWS STS エンドポイントに送信する」設定になっているようです。 AWS CLIバージョン１はデフォルトで、AWS STSリクエストをグローバルAWS STSエンドポイントに送信するため、リージョン固有の設定によってタイムアウトが発生する AWS CLIバージョン２ではデフォルトでリージョンエンドポイントにSTSリクエストが送信されるため、この問題が発生しない 解決方法 AWS CLIバージョン1をアンインストールして、AWS CLIバージョン２をインストールすることで解決しました。 バージョン1からバージョン２への詳しい更新方法は下記をご参照ください。 AWS CLI バージョン 2 の移行手順 - AWS Command Line Interface AWS CLI バージョン 1 からAWS CLI バージョン 2 への移行方法を説明します。 docs.aws.amazon.com まとめ これまでにAWS CLIは多少触ったことがあったのですが、特にエラーや不都合がなかったのでバージョンを意識せずに利用していました。 原因で参照しているURL先を見ると、バージョン1とバージョン２の差異もかなりあったので、利用時にはきちんとバージョン意識して利用しないとダメですね。

こんにちは、SCSK 西山です。 AWS User Notifications を使用して、AWS から IAM ルートユーザー宛に配信される通知を、複数メールアドレスに送信する機能を実装しましたのでご紹介いたします！ やりたいこと ルートユーザーのメールアドレス宛に届くAWSの通知を、複数メールアドレスへ送信したい。 簡単な処理の流れ： Healthイベントが発生→User Notificationsで受信→登録したメールアドレスへ送信   AWS User Notifications AWS User Notificationsとは？ AWSサービスからの通知を、一元的に設定して表示できるサービスです。マネジメントコンソール上で、AWSサービスからの通知を確認できます。 新着 – AWS の通知を一元的に設定する | Amazon Web Services 5月3日、AWS User Notifications をリリースしました。これは、AWS コンソール内で、複 aws.amazon.com 利用料はかかる？ AWSに確認したところ、User Notifications自体の利用料は 無料 とのことです！   設定手順 下記ファイルに設定手順をまとめました。 ダウンロードしご確認ください。 AWS User Notifications設定手順書 Download Now! 15 Downloads   補足 Healthはベストエフォートベースでイベントを配信するため、ルートユーザーに届く通知を全て受信できるわけではないようです。 Monitoring AWS Health events with Amazon EventBridge - AWS Health Use Amazon EventBridge to monitor status changes and receive AWS Health events. docs.aws.amazon.com そのため、全ての通知を受信したい場合はHealth APIをLambda関数で定期的に呼び出し、新しいイベントがある場合には通知を行うといった構成を構築する必要があります。   まとめ 今回は、HealthイベントをUser Notificationsに設定しましたが、EC2やCloudWatchなどのAWSサービスも設定できるので、ご利用中のAWSサービスに合わせて是非お試しください！

Catoクラウドには以下のような様々なセキュリティオプションがあります。 これらのセキュリティ機能・ツールを組み合わせることで、さまざまな脅威から包括的に保護することが可能となります。 ・ 次世代型ファイアウォール（NGFW） ・ セキュア Web ゲートウェイ（SWG） ・ 次世代型アンチマルウェア（NGAM） ・ 不正侵入検知防御（IPS） ・ SaaS・アプリケーション利用の可視化/評価/制御（CASB） ・ 情報漏洩対策（DLP） ・ リモートブラウザ分離（RBI） ・ SaaS Security API この中から今回は、Catoクラウドの情報漏洩対策にあたる「DLP」について紹介していきます！ はじめに CatoクラウドのDLPは、標準搭載されている機能ではなくセキュリティオプションです。 また、DLPについては、同じくセキュリティオプションであるCASBのご契約が行われていることが前提となっております。 つまり、DLPは、CASBをベースとしてアプリケーション制御に追加するデータおよびコンテンツの検査を行う機能となります。 DLPのコンテンツ検査は、透過型（インライン）プロキシのため、CASBと同じくTLS Inspectionの有効化が必須です。 Catoクラウドのサービス体系については別記事で詳しく説明しておりますので是非ご参照ください！ Catoクラウドのサービス体系について Catoクラウドのサービス料金を含むサービス体系、オプションやマネージドサービスについて紹介します。 blog.usize-tech.com 2023.08.17 DLP（Data Loss Prevention）とは DLP（Data Loss Prevention）とは、機密情報や個人情報の損失および情報漏洩を防ぐセキュリティツールのことです。 従来の情報漏洩対策といえば、操作ログの取得のように、ユーザーが不審な行動をしていないかを監視する方法が主流でしたが、この方法では、ログやアラートの量が多くなってしまい、運用の負荷が高くなる点が課題となっていました。 それに対し、DLPは重要データそのものを監視するため、ログやアラートの数を必要最低限に抑えることができます。 さらに、データごとに操作制限を設けることで正規ユーザーによる機密データの持ち出しを防ぐことができるのがメリットといえます。 DLPの機能をざっくりまとめると、以下の3つです。 重要データの 識別 する機能 重要データに対して 操作制限 を設ける機能 インシデント 検出 機能 それでは、Catoクラウドにおけるそれぞれの機能について紹介していきます。 CatoクラウドのDLP 識別 重要データの識別方法は以下設定箇所にて、定義ができます。 ＊設定箇所：Security＞DLP Configuration（2023年10月時点） 定義の方法は次の3通りです。 Catoが事前に定義してくれている定義型を利用する ＊設定箇所：Security＞DLP Configuration＞ Data Types Catalog （2023年10月時点）                  Data Types Catalog にて事前定義型一覧の確認が可能です。 日本では”機密”という文字が記載されたデータや”マイナンバー情報”等個人情報が記載されたデータが定義されています。 カスタム定義型を作成する ＊設定箇所：Security＞DLP Configuration＞ User Defined Data Types （2023年10月時点）                  事前定義型でカバーできない場合は、 User Defined Data Types にてデータ型のカスタマイズが可能です。 KeyWordやDoctionary、正規表現 等、要件に沿って定義します。 Microsoft 365 のMIPラベルを利用する ＊設定箇所：Security＞DLP Configuration＞ DLP Connectors Settings （2023年10月時点） ＊設定箇所：Security＞DLP Configuration＞ Sensitivity Labels （2023年10月時点）                  DLP Connectors Settings にて APIコネクタを構成し、使用するMIPラベルを Sensitivity Labels より 自動的に取得します。 1の事前定義型を利用する方法が1番簡単そうですが、事前定義型でカバーできない場合は2や3を利用することでポリシーに沿った設定が自由にできます。 操作制限 ルールを作成するにあたり、以下設定箇所でProfileの作成をします。 ＊設定箇所：Security＞DLP Configuration＞Content Profiles（2023年10月時点） 作成したProfileを使って以下設定箇所でルールを作成することで、操作制限ができます。 ＊設定箇所：Security＞Application Control Policy（2023年10月時点） 検出 Catoクラウドには、DLP Dashboardがあり、指定時間内のDLPの検出結果を確認することができます。 ＊設定箇所：Monitoring＞DLP（2023年10月時点）   DLP Dashboardの画面左上、Top Violating Rulesには作成したルール毎にイベントの出力件数が表示されます。 数字をクリックすると、Monitoring＞Eventsページに遷移し、出力されたイベントのより詳細な情報を確認することもできます。（手動でFilterをかけて対象のイベントを探すより簡単です！）   DLPの動作 CatoクラウドのDLP機能について理解ができたところで、実際にDLPの設定を行い動作テストをしてみました！ 今回は、”機密”の文字が入ったテキストファイルをSlackでアップロードさせないという動作を再現しています。 CatoクラウドのDLP設定は以下 3Step のみで完了です。 Step1：重要データの識別方法を定義 Step2：Step1で定義したデータ型のProfileを作成 Step3：Step2で定義したProfileを利用したルールを作成 まずは Step1 。 データ型の定義は、事前定義型のConfidential document markers [Japan]が利用できそうなので、これを利用することにします。 次に Step2 。 ”test profile”という名前でProfileを作成していきます。 Profileが追加されました。 そして最後に Step3 。 ”test rule”という名前でルールを作成していきます。今回は以下通りの設定を行いました。 Source：Any Application：Slack Activities：Upload DLP Profiles：test profiles　※STEP2で作成したProfileを選択 Actions：Block Tracking：Event 以上でCMA設定が完了しましたので、実際にBlockされるのかSlackにログインして試してみると・・・ Cato ClientをOFF(Disconnected状態)の場合、”機密”の文字入りのテストファイルはアップロードされていますが、 その後、Cato ClientをON(Connected状態)にして再度アップロードを試してみると、想定通りBlockされました。 DLP Dashboardを確認すると、このように表示されています。 さらに、Monitoring＞Events画面でも今回のテストログ出力が確認できました。 まとめ 今回は、Catoクラウドの情報漏洩対策にあたる「DLP」について解説を行いましたが、冒頭でも記載の通りその他セキュリティ機能・ツールと組み合わせることで、さまざまな脅威から包括的に保護することが可能となります。 是非、その他セキュリティ機能を併せて導入をご検討ください。

みなさん、こんにちは。SCSKで飼育されているひつじです。 最近社内のWell-Architected Reviewの促進に取り組んでおります。 そんな中とても便利な機能「テンプレート」が発表されたので紹介します。 そもそもWell-Architected Reviewってなに？ AWSが提供するクラウドアーキテクチャのベストプラクティスに基づく評価サービスです。 AWSワークロードを評価し、最適化の機会やセキュリティの強化ポイントを特定するのに役立ちます。 マネジメントコンソール上のQA形式のフォーム(Well-Architected Tool)に登録することで評価することができます。 「テンプレート」機能ってなに？ 事前に回答情報を登録しておいて、使い回すことができます。 たとえば同一組織で運用されている複数のシステムがあるとします。 その時に統一的なポリシーや設定に関する設問はテンプレートに記載しておくことでレビュー時間を削減できるのです。 今までのやり方 各システム共通でログ管理の仕組みがあるにも関わらず 同じ質問を同じように回答する手間があった。 テンプレートを利用したやり方 テンプレートとして統一的なやり方を登録しておけば他のシステムは 「他のシステムと同じです」と回答を省エネできます。 実際にやってみた テンプレートというメニューが表示されていますね。     テンプレートの名前を記入します。※本記事執筆時点では日本語だとエラーになりました。 通常のレビューどおりテンプレートに登録情報を記載します。 テンプレートの情報を入力保存したあと、テンプレートから通常のレビューを起票することができます。便利！ まとめ ちょうどいま同一のお客様で複数のシステムをレビューする要件がありましたので さっそくテンプレートを活用して効率的にレビューを書いていこうと思います！

はじめに インターネットで Web サイトにアクセスするとき現在は HTTPS を用いるのが一般的であり、HTTPS を用いるとクライアント PC 上のブラウザと Web サーバとの間で暗号化通信を行えます。一方で、ネットワーク管理者やシステム管理者の立場になると、HTTPS 通信の中身をファイアウォール等では確認できないため、ウイルス・マルウェアのチェックや不正なサイトへのアクセスの検知が行えません。 Cato クラウドでは TLS Inspection という機能が用意されており、HTTPS 通信であってもウイルス・マルウェアチェックや不正サイトへのアクセス検知などのセキュリティ対策を一元的に行えるようになっています。 しかし、この機能を有効にすると TLS 証明書関連で躓いたり別の課題が生じたりすることが多いため、本記事では躓く原因でもある証明書関連の仕組みや課題について概要を解説します。 通常のインターネットアクセスにおけるサーバ証明書 まず、Cato 網を経由せずにインターネットにアクセスするときのサーバ証明書を確認してみます。 弊社の Web サイト にブラウザでアクセスすると、次の図のように GlobalSign によって発行された OV のワイルドカード証明書であることが確認できます。 また、OpenSSL コマンドを用いて “openssl s_client -connect www.scsk.jp:443” のように実行すればブラウザを使わなくても証明書の内容を確認でき、その中でも証明書のチェーンは次のようになっていました。 Certificate chain 0 s:C = JP, ST = Tokyo, L = Koto-ku, O = SCSK Corporation, CN = *.scsk.jp i:C = BE, O = GlobalSign nv-sa, CN = GlobalSign RSA OV SSL CA 2018 a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256 v:NotBefore: Jan 11 01:47:27 2023 GMT; NotAfter: Feb 12 01:47:26 2024 GMT 1 s:C = BE, O = GlobalSign nv-sa, CN = GlobalSign RSA OV SSL CA 2018 i:OU = GlobalSign Root CA - R3, O = GlobalSign, CN = GlobalSign a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256 v:NotBefore: Nov 21 00:00:00 2018 GMT; NotAfter: Nov 21 00:00:00 2028 GMT この結果からも、弊社の Web サイトでは GlobalSign によって署名された証明書を利用していることが確認できます。 Cato網を経由したインターネットアクセスにおけるサーバ証明書 次に、Cato 網を経由したインターネットアクセスにおけるサーバ証明書を確認してみます。今回は Windows マシンで Cato Client を用いて Cato 網に接続して試しました。 弊社の Web サイト にブラウザでアクセスすると、次の図のように “Cato Networks server tok2catod7a” という認証局によって発行された証明書に変わっていました。 OpenSSL コマンドでも確認すると、”Cato Networks server tok2catod7a” は中間認証局によって署名された証明書に変わっており、その上位には “Cato Networks CA” というルート認証局があるという結果になっていました。 Certificate chain 0 s:CN = www.scsk.jp i:CN = Cato Networks server tok2catod7a a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256 v:NotBefore: Sep 21 02:10:22 2023 GMT; NotAfter: Nov 23 02:10:22 2023 GMT 1 s:CN = Cato Networks server tok2catod7a i:C = IL, L = Tel Aviv, O = Cato Networks, CN = Cato Networks CA a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256 v:NotBefore: Aug 2 14:40:37 2023 GMT; NotAfter: Oct 11 14:40:37 2025 GMT 2 s:C = IL, L = Tel Aviv, O = Cato Networks, CN = Cato Networks CA i:C = IL, L = Tel Aviv, O = Cato Networks, CN = Cato Networks CA a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256 v:NotBefore: Nov 1 09:32:12 2015 GMT; NotAfter: Oct 29 09:32:12 2025 GMT TLS Inspection 機能を有効にしていると、Cato クラウドがクライアントPC と Web サーバ等の間に入って通信を中継します。このとき、Cato クラウドはクライアント PC に対して TLS サーバとして振る舞うとともに、実際の Web サーバ等に対する TLS クライアントとしても振る舞います。上記の確認結果は、Cato クラウドが TLS サーバとして振る舞うために、Cato 自身でサーバ証明書を発行していることを示しています。 さらに、Windows の証明書ストアを確認すると、”Cato Networks CA” が信頼されたルート証明機関として追加されていました。 クライアント PC では Cato クラウドのルート認証局を OS にて信頼することで、Cato によって発行されたサーバ証明書の検証が成功し、ブラウザでは証明書エラーになることなく通常通りインターネットにアクセスできるようになっています。 なお、Cato のルート認証局の証明書は Cato Client とともにインストールされています。Cato Client をインストールしていない PC には Cato のルート認証局証明書がインストールされていないため、Socket を使ってインターネットにアクセスするとブラウザでは次のように証明書エラーが表示されてしまいます。 TLS Inspection 機能を有効にしている場合、Socket を使って Cato 網を経由してインターネットにアクセスする PC には、ルート認証局証明書を別途インストールする必要があるという点は重要なので覚えておきましょう。 なお、Cato クラウドの標準のルート認証局 “Cato Networks CA” の代わりに、独自のルート認証局を用意し、その認証局を使って Cato クラウドにサーバ証明書を発行させることもできます。他のソリューションから Cato クラウドに乗り換える場合などで、既に独自のルート認証局証明書が PC にインストールされている場合には、その機能を使えば Cato クラウドの証明書をインストールしなくても済みます。 ブラウザ以外で証明書エラーが発生する場合 前述の通り、PC に Cato のルート認証局証明書をインストールしていないと証明書エラーとなってしまいますが、インストールしていても証明書エラーになる場合があります。一般的なブラウザ (Microsoft Edge や Google Chrome など) は OS の証明書ストアを参照するため基本的には問題は生じないものの、一部のソフトウェアは OS の証明書ストアを参照せずに自身で認証局ストアを持っているために問題が生じます。 証明書エラーが発生する場合、そのソフトウェアの証明書ストアに Cato のルート認証局証明書をインストールして解決するのが良く、Knowledge Base の How to Install the Cato Certificate のページではいくつかのソフトウェアについて証明書のインストール方法が案内されています。しかし、他にも多数のソフトウェアで証明書エラーが発生し、証明書のインストール方法は各ソフトウェアしだいですので、画一的な対応方法を案内できないというのが実情でもあります。 証明書エラーが出る場合は、まず OS に証明書がインストールされているか確認しましょう。OS に証明書がインストールされているのであれば、証明書エラーが出るソフトウェアにインストールが必要ですので、各ソフトウェアの開発元にお問い合わせいただくのが確実です。 なお、証明書の検証を無効にする機能がそのソフトウェアに用意されているのであれば、それを使って問題を回避することもできますが、これはあまり望ましい方法ではありません。 証明書をインストールできない場合 OSやソフトウェアに証明書をインストールできれば良いのですが、そうはいかないケースもあります。 PC ・サーバ・モバイル以外にも様々な機器がインターネットに接続しますが、そのような機器の大半は証明書をインストールできないでしょう。実際 TLS Inspection が原因でオフィスの複合機の一部機能が動作しなくなるという事例がありますし、機器のファームウェアの自動アップデートやその他インターネットと連携する機能が動作しなくなるという事象が発生することも予想されます。 また、PC 上で動かすソフトウェアに証明書をインストールする機能や検証を無効化する機能が用意されておらず、ソフトウェアが動作しないという事例も多々あります。 このような場合、該当する通信を TLS Inspection 機能のバイパス対象にすれば解決できます。イベントログのサブタイプ “Internet Firewall” で正常に動作しない機器がどの Web サーバ等と通信しているか確認し、その Web サーバのホスト名やIPアドレスをバイパス設定に追加してください。 証明書をインストールしてもエラーとなる場合 ソフトウェア内に Web サーバ等の証明書が埋め込まれているケースもあります。一般に証明書のピンニングと呼びますが、この仕組みはソフトウェアが本来期待する Web サーバとは異なる Web サーバと通信してしまったとしても、そのソフトウェア自身が気付けるようにする仕組みです。金融機関などセキュリティを重視するサービスが提供するソフトウェアやモバイルアプリで採用されていることがあります。 ソフトウェアにこの仕組みが導入されていると、たとえ OS に Cato クラウドのルート認証局の証明書がインストールされていたとしても、TLS Inspection 機能によって発行された証明書とソフトウェア内に埋め込まれた証明書が一致しないため、ソフトウェア側では証明書エラーとなって正常に動作しないということになります。 このような場合も、TLS Inspection 機能のバイパス対象にすることで解決できます。 Untrusted Server Certificates 設定について TLS Inspection 機能には “Untrusted Server Certificates” という重要な設定項目があります。 この設定項目のデフォルト値は Allow ですが、 Prompt または Block とするのが望ましい です。 TLS Inspection において、Cato クラウドが実際の Web サーバ等に対する TLS クライアントとして振る舞う際、Cato クラウドは Web サーバの証明書が正当なものであるかどうか検証しています。”Untrusted Server Certificates” は、Web サーバの証明書でエラーが発生する場合にクライアント PC に対してどのように振る舞うかを決める設定項目です。 この項目を Allow としていると、実際の Web サーバの証明書エラーが発生したとしても、Cato クラウドはエラーを無視して Web サーバに対して HTTPS リクエストを送信し、そのレスポンスをクライアント PC に対して返すようになります。このとき、クライアント PC では証明書エラーが発生せず、Web サーバの証明書エラーが発生していることに気付くこともなくアクセスできてしまいます。 仮に DNS サーバの侵害等により 中間者攻撃を受ける状況 になったとき、TLS Inspection 機能を利用しない場合は TLS の仕組みによってユーザは攻撃に気付くことができますが、 Allow を設定していると攻撃に気付くことができない という問題があります。 Allow ではなく Prompt や Block を設定していれば、クライアント PC では証明書エラーは発生しないものの Cato の警告・ブロック画面が表示されるため、ユーザは中間者攻撃に気付くことができます。 警告画面の例 (Prompt の場合) ブロック画面の例 (Block の場合) ただし、Prompt または Block にすると、別の問題を引き起こす場合もあります。 一部のセキュリティ製品は、サーバ証明書を独自に署名・発行し、クライアント PC にも証明書をインストールして利用するものがあります。このような場合、Cato クラウドがセキュリティ製品のサーバにアクセスする際に証明書エラーが発生するため、Prompt または Block を設定しているとセキュリティ製品には警告・ブロック画面のレスポンスが返り、期待通り動作しなくなります。 この問題を解消するには、そのような製品が通信するサーバを TLS Inspection 機能のバイパス対象に設定する必要があります。Cato のイベントログでは証明書エラーが発生するサーバに関するイベントが “TLS” というサブタイプで記録されていますので、証明書エラーになっているサーバのホスト名やIPアドレスを調べて、バイパス対象に設定を追加して解消しましょう。 まとめ Cato クラウドの TLS Inspection 機能で躓く原因である TLS 証明書関連の仕組みや課題について解説しました。 TLS Inspection 機能は非常に有用ではありますが、躓くことが多い機能でもありますので、躓いた時の解決のために本記事の内容をお役立てください。解決方法がわからない場合は弊社のサポートまで気軽にお問合せください。