Catoクラウドでは、現在のサービス状態や定期メンテナンスなどの情報を確認できるステータスサイトのページがあります。 今回はステータスページについて、見方や使用方法を確認していきたいと思います。 Loading... status.catonetworks.com Catoステータスページとは Catoステータス ページでは、Catoクラウド のステータス(サービスの状態)と、計画されたメンテナンスやアップグレードに関する情報が表示されています。 Catoクラウド内のPoPに関するリアルタイム情報と、Cato管理アプリケーションが稼働するサーバーに関する情報などが表示されます。 Catoに接続できない等といった際の障害の一次切り分けとしても活用できますので、ぜひご参照ください。 メンテナンスについてですが、PoPメンテナンス期間中は、ユーザー側で何か特別なことをする必要はありませんが、メンテナンスを行っている間は、約30秒間サービスが使えなくなることがあります。 定期メンテナンスについては、事前にステータスページを通じてアナウンスされます。 どのサービスがメンテナンスで影響を受けるのかの範囲や詳細、予想されるサービス停止時間などの情報が含まれておりますので、事前に確認できるとよいですね。 サイト内容 まず、ステータスページにどのような項目が記載されているか、全体的な内容についてみていきましょう。 掲載されている内容は以下となります。 PoP稼働状況 メンテナンスカレンダー サービス稼働状況 Uptime PoP稼働状況 サイトを開くと、このような画面が表示されます。 PoPのUP/DOWNなどの現在の稼働状況やメンテナンス情報、障害発生時にどのPoPでなにが起こっているか等の確認ができます。 メンテナンスカレンダー 稼働状況の下には、「Notifications」と「Maintenance」の項目があります。 「Notifications」では、PoPステータスが AFFECTED状態のもの に関する情報(発生日時や現在対処している内容)が表示されています。 「Maintenance」では、カレンダーに今後予定されているメンテナンスや、すでに実施されたメンテナンス履歴が記載されています。対象の日付を選択するとメンテナンス内容の確認ができます。 試しに、2024/1/24の箇所を選択してみますと、以下のようにメンテナンス実施時間や対象のサービス範囲、ダウンタイムの推定時間などが記載されており、今後予定されているメンテナンス情報について確認することができます。 サービス稼働状況 Service HistoryのListの表示ではEvents Cato APIやCMAなどのManagement機能、PoP接続のネットワークサービス全体についてのGlobal、各PoPのサービス稼働状況についての表示があります。 正常に稼働しているか、メンテナンスや障害の有無についての履歴が確認できます。 緑色 正常に稼働している 黄色 パフォーマンスに影響あり 赤色 サービスダウンあり 障害があった際は赤丸にて表示され、障害内容や対象時間、対処内容の記載があります。 また、Carendarを選択すると、1か月の履歴が確認できます。 確認したい内容があれば、該当日付の記載をクリックしますと、詳細内容が説明されたページへ移動されます。 試しに、1月4日の項目をクリックしてみますと、以下のように課題がいつ発見されたかや現在対処中である旨、課題がいつ解決されたかについての内容が確認できました。 Uptime Management機能の各サービスや各PoPのUptimeを、1日・1週間・1か月・1年単位で確認することが可能です。 CMAにログインできないや、ログが反映されないといった際はこちらの項目にてDOWNしている可能性があるか確認してみましょう。 サイトに記載されている内容については以上となります。 機能紹介 ステータスサイトで使用できる機能についても確認していきます。 SUBSCRIBE 例えば、拠点のCatoクラウド接続が切れてしまい、障害影響であるか確認したいや、東京・大阪PoPの今後のメンテナンス予定の通知を受領したい、などといった際に使用できる機能がございます。 それが以下の「SUBSCRIBE」です。 こちらをクリックすると以下の表示がされ、通知を受領したい項目を選択することができます。 通知設定について、試しにEmailにて設定を行ってみたいと思います。 「Email」を選択すると、メールアドレスの設定に移ります。 アドレスを入力し、同意にチェックを入れましたら通知してほしい内容のカスタマイズを行います。 ※All serviceを選択した場合、すべてのPoP障害・メンテナンス等の通知が来ることになります。 選択できる内容としては、Management機能のサービスと、各地域のPoPを選択することができます。 東京、大阪のPoP情報のみ通知が欲しいといった際には、「Tokyo,Japan」「Tokyo_DC2,Japan」「Osaka,Japan」「Osaka_DC2,Japan」にチェックをいれSaveボタンを押しますと、完了となります。 実際の通知メールは以下のようなものが送付されてきます。 対象PoP・サービスの選択 特定のPoPやサービス、例えば東京PoPだけのメンテナンス履歴や今後のメンテナンス予定を知りたいなどの際は、Service History >LIST 下付近にある検索欄の箇所で対象のPoP名・サービス名を入力いただくと該当のもののみ表示されるようになります。 他にもPoP名だけでなく、「JAPAN」など国名を入力することで対象国のPoP情報を確認することもできます。 また、ページ右上のタイムゾーンを「UTC」⇒「JST」に変更することで、メンテナンスカレンダーの表記時間が日本時間の表記に変更されるため見やすくなります。 機能紹介は以上となります。 他サービスとの比較 AWS AWSでは AWSサービスヘルスダッシュボード という機能にて各種サービスが正常稼働しているかどうかを公開しているサイトがあります。 こちらのサイトにてAWSステータスを確認し、各リージョンのサービス稼働状況が確認できるため、AWSにて利用してるサービスに何か問題が起きた場合は、チェックすることが可能です。過去に起きた問題等も時系列で閲覧することが可能となっています。 AWSサービスでも通知機能も備わっているため、外部ツールなどで指定した対象リージョンのサービスの通知を受け取ることも可能です。 Catoのステータスページとの比較してみると、AWSでは他のAWSサービスと統合・組み合わせをすることが可能になっています。例えば、AWS CloudWatchやAWS Lambda関数と組み合わせて、問題発生時の改善措置を自動化し、運用の負担減らすなどのことが可能となっております。AWSのサービスの豊富さを活用していると思います。 Azure Azure では「 Azure の状態 」ページにて、Azure の全サービスおよび全リージョンの稼働状況や障害情報の確認が可能となります。 また、よりパーソナルな情報を確認できる「Azure Service Health」というページもございます。 お客様ごとに利用しているサービスとリージョンごとに確認ができるページとなり、Service Health 内では、顧客が影響を受ける軽微なサービス停止から、計画メンテナンスの実施を始めとする正常性に関する通知まで、さまざまな情報を参照できます。 Catoとの違いでは、ダッシュボードの情報がパーソナライズされているため、お客様が利用中のサービスやリージョンが反映されるようになっております。お客様毎のページがあり、トラブルシューティングに役立つよう、各イベントによって影響を受ける可能性のあるリソースのリストを提示してくれております。 他のステータスページと比較し、Catoクラウドのステータスページの特徴としては、詳細な確認以外は1ページで完結している見やすさが特徴であると感じました。 まとめ 今回はCatoクラウドのサービス状況の確認ができるサイトステータスページのご紹介をしました。 Catoクラウドに接続できないといった事象が発生しましたら、障害が発生していないか、メンテナンスに該当していないかのご確認をしていただき、切り分け対応の切り分けにご活用いただければ幸いです。 ご覧いただきありがとうございました。
本記事の内容は、Cato Networks社の Avishay Zawoznik氏が投稿した以下のブログを元に日本語へ翻訳(意訳)し、再構成したものとなります。 Busting the App Count Myth (アプリ数神話を打ち破る) Busting the App Count Myth Many security vendors offer automated detection of cloud applications and services, classifying them into categories and exposing attributes such as security ri... www.catonetworks.com はじめに SSE、特にCASBを中心としたセキュリティソリューションで「約50,000以上のクラウドアプリケーションの検出が可能です」と謳われている事がよくありますが、本記事では、クラウドアプリケーションのセキュリティにおける”アプリケーション数”の重要性に対する疑問を呈し、アプリケーションの実際のトラフィックに焦点を当てた包括的なアプローチを提言するものとなります。 つまり、 アプリケーション数だけでなく、トラフィックから見たアプリケーションのカバレッジ(Coverage=網羅率)に注目すべき であり、数が増えても必ずしもセキュリティ向上につながらないことを示唆しています。 CatoクラウドのCASBについては、以下の記事を参照ください。 CatoクラウドのCASBについて Catoクラウドのセキュリティオプション CASB について解説します。 blog.usize-tech.com 2023.09.12 各セキュリティベンダーは、クラウドアプリケーションやサービスを自動検出し、カテゴリ分類して、セキュリティリスク、コンプライアンス、サービス提供企業のステータスなどの属性を公開しています。 ユーザーは、アプリケーションのカテゴリと属性に基づいて、ファイアウォール、CASB、DLPポリシーの設定など、さまざまなセキュリティ対策を適用することができます。 そのため、アプリケーションの分類数、登録されているアプリケーション数が多ければ多いほど良いという結論はとても理にかなっているように思えます。 ちなみに、Catoクラウドでは、独自のACE(Application Credibility Engine)を用いてアプリケーション分類が行われています。 ACEのアプリケーションカタログ(App Catalog)には、 2024年2月5日時点で10,352のアプリケーションが登録 されています。 アプリケーションを数えるのをやめてカバレッジを考えるべき まず、アプリケーションの数を数えるのをやめて、アプリケーションのカバレッジを考えるべきであるということです。 セキュリティベンダーが分類したアプリケーション数を議論しても、実際のトラフィックを考慮しなければ意味がありません。 10万のアプリケーションカタログを提供するベンダーと、一方で2千のアプリケーションカタログを提供するベンダーにおいて、両方のベンダーがカバーするのがともに同じ1千のアプリケーションであれば、提供している機能としては全く同じことです。 上の図で、左の円はセキュリティベンダーによって署名され、分類されたアプリケーションを表し、右の円は、顧客のネットワーク上の実際のアプリケーショントラフィックを表しています。 両方の交わった部分が、ユーザのアプリケーション適用(検出)数を表しています。 つまり、顧客のトラフィックに適用されるアプリケーションカタログです。 Catoは、一部のベンダーのようにカタログのアプリケーション数に重点を置くのではなくカバレッジを最大化することに重点を置いています。 クラウドベンダーとしてのデータ可視性により、Catoの調査チームは顧客ベース全体、または要求に応じて特定の顧客カテゴリー(地域、業種など)に対してアプリケーションのカバレッジを最適化することに力を入れています。 アプリケーション数とカバレッジの考察 アプリケーションのカバレッジに注目すると、やはり「 より多くのアプリケーションを登録すれば、カバレッジはどんどん向上するのは? 」という疑問が生じます。 アプリケーション数とカバレッジの関係を理解するために、Catoクラウド全体のトラフィックを1週間分収集し、分類されたトラフィックと分類されていないトラフィックを分析しました。 ※アプリケーションカタログの観点から主な関心事であるクラウドアプリケーション保護のシナリオに焦点を当てるため、Catoのデータレイクから収集したHTTPのアウトバウンド・フローのトラフィックに基づいています。 その結果、 10 のアプリケーションが、トラフィックの 45.42%をカバー 100 のアプリケーションが、トラフィックの 81.6%をカバー 1000 のアプリケーションが、トラフィックの 95.58%をカバー 2000 のアプリケーションが、トラフィックの 96.41%をカバー 4000 のアプリケーションが、トラフィックの 96.72%をカバー 9000 のアプリケーションが、トラフィックの 96.78%をカバー Catoのアプリケーションカタログに最後(4000→9000)に追加された5000のアプリケーションは、総カバレッジの+0.06%しか貢献していないことが判明しました。 つまり、アプリケーション数の増加は、カバレッジという点では収穫逓増(しゅうかくていぞう)※となっています。 ※アプリケーションを追加していくとカバレッジは増えるが、カバレッジの伸び率は次第に低下していくこと。 Catoクラウドが、9000 のアプリケーションだけで 96.78%という高いカバレッジとなってい るのは、実際の顧客トラフィックで見られたアプリケーションを、カバレッジへの貢献度に応じて優先的に分類する体系的なアプローチを行っている結果です。 ※2024年2月5日時点では10,352のアプリケーションが登録されています。 次に、Catoクラウドの総カバレッジよりもさらに踏み込んで、同様の手法でアカウントごとのカバレッジも調査しています。 Catoの顧客アカウントにおいて、 91%のアカウントが、90%(またはそれ以上)のカバレッジ 82%のアカウントが、95%(またはそれ以上)のカバレッジ 77%のアカウントが、96%(またはそれ以上)のカバレッジ カバレッジは、Catoクラウドのカバレッジに過ぎませんが、顧客設定とは無関係です。 Catoの新規顧客であれば、トラフィックの90%が分類される確率は91%という結論になります。図に表すと、次のようになります。 アプリケーション数は、マーケットにとって非常に分りやすい簡単な指標ですが、アプリケーションのカバレッジこそが真の価値です。 ピカピカのアプリケーションカタログを見せびらかしてもらった後、実際にそのベンダにアプリケーションのトラフィックの何パーセントを分類できているか聞いてみてはどうでしょうか?(96.78%以上でしょうか?) ちなみに、Catoクラウドでは、CASBをご契約のお客様のカバレッジが93%以上(未分類7%未満)になるように管理されています。 カバレッジ100%はあり得るか 次の疑問は「100%のアプリケーションのカバレッジは可能か?」です。 Catoクラウド上の1週間のトラフィックを注意深く調査し、現在Catoのアプリやカテゴリーに分類されていないトラフィックに焦点を当てました。アプリケーションを分類するために何が必要かを知るために、このトラフィックを(完全なサブドメインではなく)セカンドレベルドメインで分類しました。 つまり、Catoクラウドの96.78%カバー率の残り3.22%について、さらに詳細な分析を行った結果、 トラフィックの0.88%はドメイン名を示していないこ とがわかりました。これはIPアドレスからの直接アクセスが原因です。 3.22%の 残りの2.34%については、318万個の異なるセカンドレベルドメインにまたがっており、そのうち312万個は、5個未満のクライアントIP、または単一のCatoアカウントで発見 されました。 このことから、未分類のトラフィックには、常にロングテールが存在することがわかりました。 セキュリティベンダーとして、このことが「100%のカバレッジ率」を達成することを不可能にしていることが分かりました。 つまり、カバレッジを100%にすることは不可能ということになります。 未分類(Unclassified)への対応について ごくわずかなカバレッジを得るために、より多くのアプリケーションを分類することは、セキュリティの観点でも意味がありません。 ベンダーと顧客の両方に対して、未分類のトラフィックを追いかけるのではなく、未署名のアプリのロングテールを適切なセキュリティ緩和策で処理する必要があることをCatoクラウドでは提案します。 悪意のあるトラフィック(Malicious traffic)からの保護 C&Cサーバーとの通信、フィッシングサイトへのアクセス、マルウェア配信サイトなどの悪意のあるトラフィックの保護は、アプリケーションの分類がなくても保護を行う必要があります。 Catoでは、マルウェア保護とIPSは、アプリケーション分類から完全に独立しているため、ターゲットサイトが既知のアプリとして分類されていなくても保護されます。 シャドーITアプリ(認可されていないアプリケーション)への不正アクセスには、以下のような対策が必要です。 完全な可視性の確保 アプリケーション分類の有無にかかわらず、すべてのトラフィックを可視化することができます。 Catoのユーザーは、トラフィックがアプリ/カテゴリに分類されているかどうかにかかわらず、あらゆるアクティビティを監視するように選択できます。 データ損失防止(DLP) 未認可のクラウドストレージやファイル共有サービスを使用すると、機密データが社外に流出する可能性があります。 Catoは、アプリの分類に関係なく、すべてのHTTPトラフィックをDLPスキャンする機能を導入しました。 一般的には、未知のクラウドサービスに対してより制限的なポリシーを設定するためにこの機能を使用することをお勧めします。 カスタムアプリ検出 この機能は、Catoによって分類されていないアプリケーションの追跡を改善するために、トラフィックを追跡し、顧客ごとにアプリケーション分類する機能を導入しています。 リモートブラウザ分離(RBI) アプリ/カテゴリに分類されていない「Uncategorized(未分類)」および「Unknown(不明)」となるサイトは、エンドユーザのデバイスで直接アクセスさせるのではなく、Catoクラウド上の仮想マシンからアクセスを行い、その画面情報をエンドユーザへストリーミングするRBI機能があります。 まとめ クラウドアプリケーションのセキュリティ強度の指標として、アプリ・カタログのアプリケーション数に固執することが無意味であることを解説しました。 アプリケーション数の増加によるリターンの減少は、多ければ多いほど良いという一般的な考え方に疑問を投げかけるものです。 クラウドアプリケーションセキュリティを評価し、最適化するための重要な軸として、より意味のある指標であるカバレッジの採用がトレンドになっています。 効果的なセキュリティ戦略は、アプリの分類にとどまらず、完全な100%のカバレッジは実現不可能であることを認識する必要があります。 つまり、アプリケーション分類だけではなく、IPSやDLP、RBIなどの他のソリューションを適切に組み合わせることでセキュリティリスクを軽減し、アプリケーションのロングテールをカバーするギャップに対処する必要があります。 クラウドアプリケーションセキュリティの複雑な状況をナビゲートするには、適切なメトリクスと適切なセキュリティコントロールを組み合わせた微妙なアプローチが、包括的で適応性のある保護を確保するために最も重要になります。
こんにちは。SCSKのふくちーぬです。 みなさんは、コンテナ関連のサービスを利用したことありますでしょうか。 本記事では、ECSタスク定義をCloudFormationで管理・デプロイするときのちょっとしたテクニックをご紹介します。 ECSタスク定義をCFNで管理するとリビジョン保持することができない? ECSタスク定義をCloudFormationで管理すると、以前のリビジョン(バージョン)を保持することができない問題があります。つまり、CloudFomrationでデプロイすると、以前のリビジョン(バージョン)が削除されて、最新のリビジョン(バージョン)のみ保持する仕様になっています。 ECSタスク定義のCloudFormationドキュメントを確認すると、各プロパティを更新すると”置換”が発生してしまうことが記載されています。これがリビジョン保持することを妨げる原因となります。 AWS::ECS::TaskDefinition - AWS CloudFormation Use the AWS CloudFormation AWS::ECS::TaskDefinition resource for ECS. docs.aws.amazon.com 解決策:UpdateReplacePolicyを利用する “UpdateReplacePolicy”属性を利用して、”Retain”を指定しましょう。 UpdateReplacePolicy 属性 - AWS CloudFormation UpdateReplacePolicy 属性を使用して、AWS CloudFormation によるスタック更新オペレーション時にリソースの置き換えを処理する方法を指定します。 docs.aws.amazon.com 解決方法は、たったこれだけです。思ったより簡単ですね。 完成したCloudFromationテンプレート 以下のテンプレートを使用して、デプロイします。 AWSTemplateFormatVersion: 2010-09-09 Parameters: Env: Type: String AllowedValues: - TEST - STG - PROD Resources: # ================================ # ECS (Task Difinition) # ================================ ECSTaskDefinition: Type: "AWS::ECS::TaskDefinition" UpdateReplacePolicy: Retain #この記述を追加 Properties: Cpu: 256 ExecutionRoleArn: !Sub "arn:aws:iam::${AWS::AccountId}:role/ecsTaskExecutionRole" Family: !Sub "ECS-${Env}-helloworld-taskdef" Memory: 512 NetworkMode: awsvpc RequiresCompatibilities: - FARGATE ContainerDefinitions: - Name: helloworld Image: !Sub "${AWS::AccountId}.dkr.ecr.${AWS::Region}.amazonaws.com/helloworld-appliction:v1.0" LogConfiguration: LogDriver: awslogs Options: awslogs-group: !Sub "/ecs/ECS-${Env}-helloworld-service" awslogs-region: !Ref AWS::Region awslogs-stream-prefix: v1.0 PortMappings: - AppProtocol: http HostPort: 80 Protocol: tcp ContainerPort: 80 Name: helloworld-80-tcp ReadonlyRootFilesystem: false RuntimePlatform: CpuArchitecture: X86_64 OperatingSystemFamily: LINUX Tags: - Key: Name Value: !Sub "ECS-${Env}-helloworld-taskdef" ECSタスク定義の更新 上記でデプロイしたタスク定義を更新して、リビジョン2を作成することにします。 以下のテンプレートを使用して、スタックを更新します。 AWSTemplateFormatVersion: 2010-09-09 Parameters: Env: Type: String AllowedValues: - TEST - STG - PROD Resources: # ================================ # ECS (Task Difinition) # ================================ ECSTaskDefinition: Type: "AWS::ECS::TaskDefinition" UpdateReplacePolicy: Retain Properties: Cpu: 256 ExecutionRoleArn: !Sub "arn:aws:iam::${AWS::AccountId}:role/ecsTaskExecutionRole" Family: !Sub "ECS-${Env}-helloworld-taskdef" Memory: 512 NetworkMode: awsvpc RequiresCompatibilities: - FARGATE ContainerDefinitions: - Name: helloworld Image: !Sub "${AWS::AccountId}.dkr.ecr.${AWS::Region}.amazonaws.com/helloworld-appliction:v1.1" #コンテナイメージの更新 LogConfiguration: LogDriver: awslogs Options: awslogs-group: !Sub "/ecs/ECS-${Env}-helloworld-service" awslogs-region: !Ref AWS::Region awslogs-stream-prefix: v1.1 #ロググループの更新 PortMappings: - AppProtocol: http HostPort: 80 Protocol: tcp ContainerPort: 80 Name: helloworld-80-tcp ReadonlyRootFilesystem: false RuntimePlatform: CpuArchitecture: X86_64 OperatingSystemFamily: LINUX Tags: - Key: Name Value: !Sub "ECS-${Env}-helloworld-taskdef" タスク定義のリビジョン2が作成され、以前のバージョンも保持されていることが分かります。 注意事項 ・タスク定義のファミリー名は、慎重に名前付けを決定した後にデプロイすること タスク定義のリビジョンは、ファミリー名に基づいています。タスク定義を削除したとしても、内部でファミリー名が記録されているため、リビジョンを以前のものから引き継ぎます。リビジョンを”1″から採番したい場合は、異なるファミリー名で再作成することが必要です。 まとめ いかがだったでしょうか。以前のリビジョンのタスク定義をCloudFromationでも保持することができました。いざという時に、以前のリビジョンのタスク定義からコンテナを起動したいという要件も満たすことができます。 本記事が皆様のお役にたてば幸いです。 ではサウナラ~🔥
Catoクラウドにお客様拠点を接続する際、通常は専用機器であるCato Socketのご利用をおすすめしておりますが、別の方法として、お手持ちの物理ルータやファイアウォール機器からIPsecで接続することも可能です。 IPsecでの接続は、Socketに比べると機能が劣るのですが、既存の機器で接続できることから一時的な利用には有用です。IPsec接続時の機能制限については、以下の記事の「Socket/vSocketとIPsecの比較」にて紹介しておりますのでご参照ください。 Cato SSE 360 について Catoクラウドの「Cato SSE 360」「SSEライセンス」について説明します。 blog.usize-tech.com 2023.09.05 今回、テストとしてYAMAHAルータでのIPsec接続を行いましたので、設定内容や注意点をご紹介します。 接続前の事前確認 設定を行う前に、以下の情報を確認しておきます。 機器で使えるIPsecのパラメータを確認する Catoに限らず、異なる機器間でのIPsecの接続は難しいです。その理由は、IPsecでは暗号化方式をはじめ多数の設定項目があり、パラメータが両機器で完全に一致していないと接続に失敗するためです。機器によって項目の名前や実装が微妙に違ったりすることも原因のひとつです。 このため、CatoのIPsec接続時にも、まずは利用する機器の仕様を把握しておく必要があります。 CatoはIPsec IKEv1/v2の両方に対応しており、今回は一般的なv2の接続仕様をご紹介します。ご利用の機器がこれらのパラメータに対応しているかどうかと、各項目の設定コマンドを事前にご確認ください。 設定項目 Catoの対応パラメータ 認証方式 事前共有鍵 (Pre-shared key, PSK) のみ 暗号アルゴリズム (Encryption Algorithm) AES-CBC 128 / AES-CBC 256 / AES 128 GCM-16 / AES 256 GCM-16 ※AES-CBC 128および256は100Mbps未満の接続にのみ対応します。100M以上の場合はAES 128 GCM-16 または AES 256 GCM-16を使用してください。 ハッシュアルゴリズム (PRF Algorithm, Integrity Algorithm) SHA1 / SHA2 256 / SHA2 384 / SHA2 512 DHグループ (Diffie-Hellman Group) 2(1024bit) / 5(1536bit) / 14(2048bit) / 15(3072bit) / 16(4096bit) / 21(521bit ECP) 認証ID (Authentication Identifier) 原則IPv4。他にFQDN, Email, KEY_ID にも対応。 IKE SA(Phase1)のライフタイム 19,800 秒 Child SA(Phase2)のライフタイム 3,600 秒 ※2024年1月現在の仕様です。最新の情報はCato Knowledge Baseをご確認ください。 ※ライフタイムは2024年1月現在は変更不可ですが、近日中にCMAから値の指定ができるようになる予定です。 IPsecの冗長化構成を考える IPsec接続では、特定のPoPに対して接続するため、そのPoPで障害が発生すると接続不可となってしまいます。このため、 ロケーションの異なるPoPにSecondaryのIPsecを張っておくことが推奨 となっています。 今回は以下の構成でテストしました。PPPoE接続の回線1本を使い、東京とロンドンにIPsecを張ります。 それでは、実際に設定を行っていきます。 まずはPoP IPアドレスの取得 IPsecの接続先はCatoのPoPとなりますが、このPoPにて接続用の固定IPアドレスを取得する必要があります。PrimaryのPoPとSecondaryのPoPでそれぞれ取得します。 なお、Catoの推奨は、1つのSiteに対しに1つの固定IPを取得することですが、設定上は1つのIPアドレスに複数のSiteからIPsecを張ることも可能です。 IPアドレスの取得は、CMA(Cato管理画面)の Network > IP Allocation から行います。標準で3つまで取得可能で、4つめ以降は別途費用となります。 Siteの作成 続いて、IPsec用のSiteを作成します。Network > Site の「New」から作成します。 IPsec Siteの場合は、Connection Typeの選択で、「IPsec IKEv1」または「IPsec IKEv2」を選択します。どちらを利用するかはご利用の機器によりますが、今回利用するYAMAHA RTXシリーズはv1/v2両方対応のため、一般的なIKEv2とします。 Siteを作成すると、以下のように「IPsec」という設定項目がありますので、ここでIPsecの設定を行っていきます。 General 上記スクリーンショット、Generalのセクションでは、接続の基本設定を行います。 Connection Mode は、Cato側からIPsecを張りに行くかどうかの設定で、 通常は高速に接続するために「Bidirectional」とします 。「Responder Only」にした場合には、Catoは接続を受け付けるのみで、自分からは接続に行きません。 また、 Authentication Identifier は、接続相手をどの情報で識別するかの設定です。 通常はIPv4 です。Connection ModeをResponder Onlyにした場合には、他の選択肢も選べます。 Primary / Secondary 続いて、IPアドレス等の設定です。Primary/Secondaryともに設定項目は同じです。 Public IPの Cato IPに、PoPのアドレス をプルダウン選択します。今回はTokyoとLondonです。 Site IPは、拠点側のグローバルIPアドレス です。今回は回線が1本なので、Primary/Secondaryとも同じアドレスになります。 Private IPsは、BGPによるDynamic Routingを行う場合にPeer IPとして使用します。今回は使用しませんので空欄です。 Last-mile Bandwidthは、Siteの契約帯域 を指定します。 最後に、 Primary PSK, Secondary PSK を設定します。IPsec接続のパスワードとなるものです。8~64文字で、アルファベットの大文字小文字を区別します。機器によっては記号に対応していないことがあるため、アルファベットと数字での指定が無難です。 Init Message Parameters / Auth Message Parameters 暗号アルゴリズム等の設定です。 もっとも厄介な箇所ですが、 まずはすべてAuto設定とすることが推奨 となっています。ルータ側で方式を固定し、Cato側はAutoとすることで、設定をルータ側に合わせる意図です。Autoでうまく行かない場合には、エラーメッセージを見ながら調整していきます。エラーについては後述します。 なお、 Init MessageのDiffie-Hellman Groupだけは、AutoやNoneが設定できないため、利用する機器が対応している方式を選択し、設定します。 Routing 最後がRoutingのセクションです。 Initiate connection by Cato は、Cato側から接続を開始するかどうかです。 通常はONが推奨 です。 Network Ranges は、利用機器側の設定がポリシーベースのIPsecで、SAにNetwork Rangeが定義されている場合に、そのレンジを指定します。空欄の場合には、暗黙的にルートベースとして認識されます。 今回は空欄としています。 以上で、Cato側の設定は一旦完了です。 YAMAHAルータの設定 今回は以下の機器で動作を確認しています。先日EoLとなった機器ですが、Configは他のRTXシリーズもほぼ同じです。 ハードウェア YAMAHA RTX810 ファームウェア Rev.11.01.34 古い機器のため、以下の古めなパラメータを使用しました。最近の機種はより多くのアルゴリズムに対応していますので、Catoの対応範囲内でできるだけセキュリティの高い(数値の大きい)ものを選んでください。 設定項目 パラメータ 暗号アルゴリズム (Encryption Algorithm) AES-CBC 256 ハッシュアルゴリズム (PRF Algorithm, Integrity Algorithm) SHA2 256 DHグループ (Diffie-Hellman Group) 2(1024bit) IPsecサンプルConfig PPPoE等の設定を行い、Internetへ通信できることを確認の上、IPsec関連の設定を入れていきます。 tunnel select 1 tunnel name <ルータ上での表示名> ipsec tunnel 1 ipsec ike version 1 2 # IKEv2を利用すると明示的に指定する設定 ipsec ike group 1 modp1024 # DHグループ ipsec ike encryption 1 aes256-cbc # Phase1の暗号アルゴリズム ipsec ike hash 1 sha256 # Phase1のハッシュアルゴリズム ipsec sa policy 1 1 esp aes256-cbc sha256-hmac # Phase2の暗号・ハッシュアルゴリズム ipsec ike duration ike-sa 1 19800 # Phase1のライフタイム ipsec ike duration child-sa 1 3600 # Phase2のライフタイム ipsec ike keepalive use 1 on # Keepaliveを行う設定 ipsec ike keepalive log 1 off # Keepaliveのログを表示しない設定(大量に出るため) ipsec ike local address 1 <ルータのGlobal IPアドレス> ipsec ike local name 1 <ルータのGlobal IPアドレス> ipv4-addr ipsec ike remote address 1 <CatoPoPの固定グローバルIPアドレス> ipsec ike remote name 1 <CatoPoPの固定グローバルIPアドレス> ipv4-addr ipsec ike pre-shared-key 1 text <Pre-Shaerd Key文字列> ipsec ike proposal-limitation 1 on # 指定したアルゴリズム以外ではネゴシエーションしない設定 ip tunnel tcp mss limit auto tunnel enable 1 ipsec auto refresh on 上記でPrimary分の設定です。同様にtunnel2としてSecondaryの設定も投入します。 設定を忘れやすいのは「 ipsec ike proposal-limitation <tunnel番号> on 」です。 YAMAHAルータの仕様として、デフォルトではIPsecの設定不一致を解消するために、宣言したアルゴリズム以外も含め使えるアルゴリズムすべてを相手に提案します。その結果、Cato側が「想定と違うアルゴリズムが来た」とエラーを返してしまい、SAが確立しません。このコマンドを on に明示することで問題が解消します。 また、WANインターフェイス(今回はPPPoE接続を行うPPインターフェイスです)にて以下のフィルタを設定してください。IPsecの通信にて利用するプロトコル(ESP, UDP/500)の許可です。 ip filter <フィルタ番号> pass <CatoPoPの固定グローバルIPアドレス> <ルータのGlobal IPアドレス> esp * * ip filter <フィルタ番号> pass <CatoPoPの固定グローバルIPアドレス> <ルータのGlobal IPアドレス> udp * 500 ルーティングの設定にも注意点があります。 まず、以下のIPアドレスは必ずtunnelに向ける(Cato網へルーティングさせる)必要があります。 Catoの設備IPアドレス 10.254.254.1 / .5 / .253 Cato網内の他拠点のIPアドレスレンジ、モバイルユーザのIPアドレスレンジ 拠点のルーティング要件にもよりますが、通常は拠点内のすべての通信についてCato網を通すのが推奨ですので、以下のようなルーティングになるかと思います。 PrimaryのPoPに障害が発生した場合に備え、tunnel1がdownしてもtunnel2で通信継続できるように設定しておきましょう。 ip route default gateway tunnel 1 hide gateway tunnel 2 weight 0 # 基本的にすべての通信はtunnel1に向け、tunnel1のdown時はtunnel2を使う ip route <PrimaryのCatoPoPの固定グローバルIPアドレス> gateway pp 1 # CatoPoPとのIPsec確立にはpp1(PPPoEインターフェイス)を使う ip route <SecondaryのCatoPoPの固定グローバルIPアドレス> gateway pp 1 以上を設定したら、YAMAHAルータをInternetに接続し、接続できるかを確認します。 接続確認 IPsecが正常に張れているかどうかは、以下の方法で確認します。 YAMAHAルータでの状態確認 # show status tunnel <トンネル番号> 「トンネルインターフェースは接続されています」と出ていれば、正常にUPしています。 # show status tunnel 1 TUNNEL[1]: 説明: インタフェースの種類: IPsec トンネルインタフェースは接続されています 開始: 2024/01/29 18:38:23 通信時間: 21分6秒 受信: (IPv4) 105 パケット [9660 オクテット] (IPv6) 0 パケット [0 オクテット] 送信: (IPv4) 134 パケット [10872 オクテット] (IPv6) 0 パケット [0 オクテット] IKEキープアライブ: [タイプ]: rfc4306 [状態]: OK [次の送信]: 5 秒後 異常な場合には、「トンネルインタフェースは一度も接続されていません」と出たり、何も表示されなかったりします。 CMAでの状態確認 MonitoringのTopologyにて、Site Statusが Connected となっていることを確認します。 また、IPSEC DETAILS にて、PrimaryとSecondaryそれぞれの接続状況も確認できます。 接続できていない場合は、拠点が赤い表示となり、Site StatusはDisconnectedとなります。 また、IPsecの設定画面にて「Connection Status」ボタンを押すと、数秒した後、現在の接続情報が表示されます。待っても何も表示されない場合は、接続できていません。 正常に接続できたら、ルータのLAN側の端末から、他Siteやインターネットへの通信をご確認ください。 繋がらない場合のトラブルシュート 続いて、IPsecが繋がらないときの切り分け方法をご紹介します。 切り分けは時間がかかり、心が折れることもありますが、単純に鍵交換に一時的に失敗しているだけということも多いので、まずはトンネルのリセットをおすすめします。 トンネルのリセット YAMAHAルータ側からのトンネルリセット # ipsec sa delete all コマンド入力後何も出ませんが、すぐにSAが作り直しされます。allではなく特定のSAのみ作り直したいときは、show ipsec sa で SA番号を特定し、allの代わりに番号を指定します。 Cato側からのトンネルリセット Primary/Secondaryそれぞれ、IPsecの設定画面にある「Reset Tunnel」ボタンからResetが可能です。 リセットし、数分待っても接続されない場合、一時的な問題ではないと考えられるため、トラブルシュートに進みます。 Cato側ログの確認 まずはCato側のログを確認してみます。接続できない方のtunnelで「Timeline」をクリックすると、Cato側のログがcsv形式でダウンロードされます。 もしここで 「File not found」とエラーが出てファイルがダウンロードされない場合、ログが存在しません。 接続が全く到達していないということになりますので、以下の点を確認します。 ルータがInternetに接続できているか ルータのipsec ike remote address で指定したCato PoPのグローバルアドレスが間違っていないか ルータのフィルタで、PoPとのesp, udp500の通信が破棄されていないか ルータからCato PoPのグローバルIPアドレスに対してPingが通るか CMAに設定した、ルータのグローバルIPアドレスが間違っていないか ログがダウンロードできた場合は、直近のエラー内容を確認します。 基本的にはルータとCatoのパラメータ不一致が原因となるため、何が不一致なのかを調べ、修正していく作業となります。 一例として、当社の検証にて確認したCato側のエラーメッセージをご紹介します。 認証情報の不一致 Auth payload doesn't match the calculated one - wrong psk? Auth payload doesn't match dropping this sa 認証情報が一致しないというエラーです。PSKやnameの設定が双方で異なっている場合に発生しますので、以下を確認します。 PSK(パスワード)がCatoとルータとで一致しているか、再設定してみて改善するか ルータ側のipsec ike local name, ipsec ike remote name に相手と自分のグローバルIPアドレスが正しく設定されているか、コマンド末尾の「ipv4-addr」が抜けていないか DHグループの不一致 DH group number in the KE property doesn't match the selected proposal [selected: 14, in KE payload: 5] ルータが最初に宣言したDHグループと、実際に通信してきたDHグループが違うというエラーです。 DH group GROUP_5_MODP1536 (5) in our proposal does not match DH group GROUP_14_MODP2048 (14) in peer's proposal 1 Catoが提案したDHグループと、ルータが提案してきたDHグループが違うというエラーです。 いずれの場合も以下を確認します。 Cato側とルータ側のDHグループ設定(ipsec ike group)が一致しているか YAMAHAルータに ipsec ike proposal-limitation <tunnel番号> on が設定されているか ※この設定が抜けていると、指定していないDHグループで通信してしまいます その他各種アルゴリズムの不一致 Encryption algorithm length AES_256 (256) in our proposal does not match encryption algorithm length AES_128 (128) in peer's proposal 1 PRF algorithm HMAC_SHA2_256 (5) in our proposal does not match PRF algorithm HMAC_SHA1 (2) in peer's proposal 1 Integrity algorithm HMAC_SHA2_256_128 (12) in our proposal does not match integrity algorithm HMAC_SHA1_96 (2) in peer's proposal 1 Catoが提案した各種通信方式と、ルータが提案してきたアルゴリズムが違うというエラーです。いずれの場合も、以下を確認します。 YAMAHAルータに ipsec ike proposal-limitation <tunnel番号> on が設定されているか ※この設定が抜けていると、指定していないアルゴリズムで通信してしまいます エラーが出ている設定項目について、Catoのアルゴリズム設定をAutoにして改善するか エラーが出ている設定項目について、Catoのアルゴリズム設定をルータと同じ値で固定指定にして改善するか エラーが出ている設定項目について、Cato・ルータ双方のアルゴリズム方式を他の方式に変えて改善するか すべて確認してもエラーが解消されない場合、Cato PoP側の問題であるかどうかの切り分けとして、他のロケーションのCato PoPのIPアドレスを取得し、そちらとtunnelが張れるかご確認ください。 (ご参考)YAMAHAルータ側確認方法 問題切り分けの際は、Cato側のログとあわせて、YAMAHAルータ側でも状況をご確認ください。 確認コマンドの例 show ipsec sa SAが確立できているかどうかを確認できます。以下はtunnelを2本張った場合の正常例です。1つのtunnelに対し、phase1で1つ、phase2で2つのSAが確立されます。 このコマンドを見ることで、phase1の確立で失敗しているのか、またはphase2で失敗しているのかの切り分けができます。 # show ipsec sa Total: isakmp:2 send:2 recv:2 sa sgw isakmp connection dir life[s] remote-id ----------------------------------------------------------------------------- 1 1 - ike - 17106 <東京PoPのグローバルIPアドレス> 2 2 - ike - 18598 <ロンドンPoPのグローバルIPアドレス> 3 2 2 tun[002]esp send 2398 <ロンドンPoPのグローバルIPアドレス> 4 2 2 tun[002]esp recv 2398 <ロンドンPoPのグローバルIPアドレス> 5 1 1 tun[001]esp send 906 <東京PoPのグローバルIPアドレス> 6 1 1 tun[001]esp recv 906 <東京PoPのグローバルIPアドレス> show ipsec sa gateway <tunnel番号> detail さらにSAの詳細情報を見るコマンドです。以下は正常例です。 正常に表示されていない箇所や、意図しない設定になっている箇所がないか確認します。 # show ipsec sa gateway 1 detail SA[1] 状態: 確立済 寿命: 15014秒 プロトコル: IKEv2 ローカルホスト: <ルータのグローバルIPアドレス>:<ポート> リモートホスト: <東京PoPのグローバルIPアドレス>:<ポート> 暗号アルゴリズム: AES256_CBC PRF : HMAC_SHA2_256 認証アルゴリズム: HMAC_SHA2_256_128 DHグループ: MODP_1024 SPI: <SPI文字列> 鍵 : <鍵文字列> ---------------------------------------------------- SA[5] 状態: 確立済 寿命: 1522秒 送受信方向: 送信 プロトコル: ESP (モード: tunnel) ローカルID: <ルータのグローバルIPアドレス> (IPv4_ADDR) リモートID: <東京PoPのグローバルIPアドレス> (IPv4_ADDR) 暗号アルゴリズム: AES256_CBC 認証アルゴリズム: HMAC_SHA2_256_128 ESN: DISABLE 始点トラフィック セレクタ (タイプ / プロトコル / ポート / アドレス) IPv4-range / any / 0-65535 / 0.0.0.0-255.255.255.255 終点トラフィック セレクタ (タイプ / プロトコル / ポート / アドレス) IPv4-range / any / 0-65535 / 0.0.0.0-255.255.255.255 SPI: <SPI文字列> 鍵 : <鍵文字列> ---------------------------------------------------- SA[6] 状態: 確立済 寿命: 1522秒 送受信方向: 受信 プロトコル: ESP (モード: tunnel) ローカルID: <ルータのグローバルIPアドレス> (IPv4_ADDR) リモートID: <東京PoPのグローバルIPアドレス> (IPv4_ADDR) 暗号アルゴリズム: AES256_CBC 認証アルゴリズム: HMAC_SHA2_256_128 ESN: DISABLE SPI: <SPI文字列> 鍵 : <鍵文字列> ---------------------------------------------------- show log 通常のログにもSA確立成功・失敗等のログが出ますので、エラー内容や、どこで失敗しているのかを確認します。 なお、以下の設定をしておくことで、より詳細なログ・デバッグ情報が表示されるようになります。 ipsec ike log 1 key-info message-info payload-info syslog debug on ※ログが大量になるため、正常に接続できた後はOFFが推奨です まとめ 以上、長くなりましたが、YAMAHAルータでのIPsec接続のご紹介でした。 検証時、パラメータを正しく一致させているつもりなのに不一致のエラーで繋がらず、かなり悩まされましたが、ほとんどがYAMAHA側の設定の不足や相違が原因でした。今回ご紹介したサンプルConfigは正常に接続できた後のものですので、どなたかの参考になりましたら幸いです。 感想として、PoPとの接続やルーティング、障害切り替わりをすべて自動で行ってくれる Cato Socketの楽さが身にしみました…。 何らかの事情でSocketが利用できずIPsec接続を行われる際には、なかなか苦労しますので、準備・検証に十分な時間を取ることをおすすめします。
最近健康診断から人間ドックにランクアップした、潮です。 普段AWSのデータベース系サービス、特にAmazon RDSやAmazon Aurora等のRDB系のサービスを中心に検証や構築、チューニング等々しています。 今回はちょっと変わったDBとして、Oracle社がAWS上で動かすDBとして提供している「MySQL HeatWave on AWS」をご紹介します。 MySQL HeatWave on AWSとは? MySQL HeatWave on AWSは、OLTP系の処理はMySQLで捌き、OLAP系の処理は分析用にデザインされたHeatWaveノードにオフロードして捌く、という、OLTPとOLAPの両利きを目指したデータベースです。名前の通りAWS上で稼働するため、会社全体でAWSを基盤インフラとして全面採用している場合や、アプリはじめフロントエンドがAWS上にある場合に、レイテンシや通信セキュリティ上のメリットがあります。また、最近のアップデートで、MySQL HeatWave on AWS外からのインバウンドレプリケーションができるようになったことで、今あるMySQLに格納されているデータを分析にかけてみたい、という要望に対して、単にスレーブを追加する感覚で分析用DBを追加できるようになりました。 このMySQL HeatWaveは、元々はOracle Cloud Infrastructure(OCI)上で提供されているサービスでしたが、これがAWS上でも使えるようになりました、というのがMySQL HeatWave on AWSです。なお、on Azureも存在します。 アーキテクチャは以下の通りで、Oracle社管理のAWSアカウント上で稼働しているMySQL/HeatWaveノードに対して、カスタマーAWSアカウント(別にそれ以外でもいいですが)からアカウント越しにアクセスすることになります。 MySQLノードは通常のMySQL同様データを永続化ディスクに持ちますが、HeatWaveノードではインメモリです。全てのデータをHeatWaveノードに持たせる必要はなく、OLAP系処理が見込まれるテーブルのみHeatWaveノードにロードする、ということもできます。 全てのクエリは一度MySQLノードで受けるのですが、ここでオプティマイザがHeatWaveよりもMySQLで実行した方が早いと判断した場合は、たとえ対象テーブルがHeatWaveにロードされていてもMySQLノードで処理してくれます。 分析処理の高速化確認 MySQL HeatWave on AWSで分析処理がどの程度早くなるか、確認します。今回は、伝票処理でデータが大きく育ってしまってMySQLでは時間がかかるようになってきてしまった、という状況を想定します。クエリは実際にソフトウェア上で動いているものをベースにしており、処理の概要とレコードの概数は以下の通りです。 処理概要 対象テーブル内レコード数 特定条件ごとの仕訳伝票数出力 30,000,000 特定条件ごとの仕訳明細数出力 200,000,000 特定条件ごとの仕訳明細数出力+除外条件 200,000,000 特定条件ごとの台帳残高出力 90,000,000 これらクエリを、MySQLとHeatWaveそれぞれで処理させた場合の処理時間は以下でした。 処理概要 MySQL(InnoDB) HeatWave 特定条件ごとの仕訳伝票数出力 9 s 0.2 s 特定条件ごとの仕訳明細数出力 44 s 0.4 s 特定条件ごとの仕訳明細数出力+除外条件 55 s 0.4 s 特定条件ごとの台帳残高出力 210 s 0.2 s 処理時間は劇的に改善しており、クエリによっては1000倍以上のレスポンスです。これならほとんどの性能要求は満たしてくれそうです。 とはいえ、このくらいのレスポンス速度は、データウェアハウス系の製品であればそれほど特筆して早いというものでもありません。MySQL HeatWave on AWSのいいところは、この性能がOLTP用途で使っているDBそのもので出せること、フロントにMySQLがいるため従来のMySQL用に書かれたアプリでもアプリに大きな変更なく使えること、AWS上で動いているため他コンポーネントがAWS上にあるシステムでの性能上・セキュリティ上のメリットがあること、などです。 まとめ AWSではAmazon Athenaをはじめとして、MySQL中にあるデータを分析ツールからクエリできるようにするサービスもあります。しかしながら、既成のMySQL互換アプリがあって変更が困難な場合、Amazon Athena等の分析サービスでは十分な性能水準に達しない場合等、これまで分析を諦めざるを得なかったユースケースに対して、新たな選択肢として考えられそうです。
前回は、CSPMについて解説しましたが、今回はCWPPについて解説を行います。 CSPMをご存知ない方は、先に前回のCSPMの記事をご覧ください。 2024年最新版 CSPM(Cloud Security Posture Management)とは? クラウドセキュリティ CSPM(Cloud Security Posture Management)について、2024年の最新情報を解説しています。 blog.usize-tech.com 2024.01.09 CWPPとは? CWPPとは、 Cloud Workload Protection Platform (クラウドワークロードプロテクションプラットフォーム)で、日本語訳は「 クラウドワークロード保護プラットフォーム 」と訳されています。 クラウドワークロードとは、クラウドサービス上で実行される業務処理や作業(タスク)を意味し、具体的には、仮想マシン(IaaS)や、PaaS、コンテナ、サーバレス環境などで実行される処理やタスクのことです。 つまり、CWPPは、 クラウドサービス上の仮想マシン(VM)などのIaaS、データベースなどのPaaS、コンテナ、サーバレスなどに対して、セキュリティパッチ適用や脆弱性対策に不備がないかの監視を行い、リスクを検出した場合に、設定変更のアドバイスや、実際の設定変更を行うソリューション となります。 CWPPは、CSPMとクラウドセキュリティのツールとしては同じですが、CSPMはクラウドサービスの利用環境全体の保護を目的に、IaaS/PaaS環境におけるアカウントやサービスを対象にしていますが、CWPPは、クラウドワークロード保護を目的として、仮想マシン(VM)、コンテナ、サーバレスなど、IaaS/PaaSに限定せずに、様々なワークロードを対象にしています。 また、CSPMはクラウドサービスの提供するAPIを用いて設定情報やログを取得し、設定の確認をするのに対して、CWPPは、仮想マシンやコンテナなどにエージェントを導入し、セキュリティの監視をする場合が多いです。 セキュリティ設定不備や、OSのセキュリティパッチ適用状況、ミドルウェアの脆弱性有無、アンチマルウェアソフトのパターンファイル更新状況やスキャン状況をチェックします。 CWPPの背景 これまでのモノリシック(一枚岩)なサービス開発ではなく、最近のマイクロサービスアーキテクチャでは、複数の小規模かつ軽量で、互いに独立したサービスを組み合わせて実装する手法となっており、アプリケーションは、仮想マシンではなく、より利用するリソースが少ないコンテナ上で稼働する事例が増えてきています。 そのため、これまでのオンプレミスのサーバや、仮想マシンとは比較にならないほど多くのコンテナが稼働するようになっています。 コンテナは、パッケージ化が容易で、実行場所を選ばず、1台の仮想マシン上に、複数のコンテナを展開できることも可能となっており、仮想マシンから準備することも可能ですが、 CaaS(Container as a Serice) としてクラウドサービスとして提供されています。 次に、サーバレスアーキテクチャも増えています。サーバレスは、 FaaS(Function as a Service) とも言われますが、AWSの「Lambda(ラムダ)」、Azureの「Azure Functions」、GCPの「Google Cloud Functions」に代表されるこれまでの仮想マシンを利用せずに、アプリケーション開発を行う手法となります。 通常は、プログラムを実行するサーバが常に稼働し続けている必要がありますが、サーバレスでは、サーバを必要としないため、サーバ自体のコストが掛からず、運用や保守、利用のための準備期間の短縮が行えます。 サーバレスは、実際に仮想マシンを使っていない訳ではなく、クラウドサービスプロバイダー側が準備する仮想マシンを一時的に利用する形態となります。 このような マイクロサービスのような開発手法の変化や、クラウドサービスの進化により、コンテナやサーバレスの利用が増加しています 。 コンテナやサーバレスは、仮想マシンと大きくアーキテクチャが異なり、コンテナは常に稼働している訳ではなく、次々と新たに作成され、不要になるとすぐに削除されます。また、サーバレスはクラウドサービスプロバイダが準備する仮想マシンのため、利用者が管理することができないため、これまでのIT運用担当者の運用方法で対応が難しい場合が多いです。 IT運用者が管理ができず、脅威が見えなくなっても、セキュリティリスクは変わりません 。 コンテナやサーバレスについても、責任は、前回CSPMで記載したように「責任共有モデル」改め「責任分担モデル」にて、きちんと責任分界点が設定されており、殆どの責任については、利用者側が負うことになっています。 攻撃者により悪意のあるコンテナイメージがパブリックなレポジトリに登録され、それに気づかずに利用し、攻撃者が容易に不正侵入を許してしまう、コンテナの脆弱性をついて、ホストOSへアクセスされ不正プログラムを実行されることもあります。 コンテナ環境のKubernetesの設定ミスからホストOSを乗っ取られた事例もあります。 サーバレスでは、AWS Lambdaで提供されている脆弱性のあるWebサイトにて、URLに特定文字列を入れAWS Lambdaの情報を取得、さらにAWS Lambdaの環境変数を見るスクリプトでクレデンシャル情報(認証ID/パスワード、アクセスキー)を取得し、そのクレデンシャル情報を利用して管理者権限を付与すれば、AWS S3の情報を閲覧する可能となります。 AWS Lambdaは、これまでのように仮想マシンに、従来のセキュリティ対策ソフトウェアをインストールして仮想マシンごと守る方法は行えません。なぜなら責任分担モデルに則り、利用者は、クラウドサービスプロバイダーのAWS Lambdaの提供する仮想マシン(サーバレイヤ)にソフトウェアをインストールできないからです。 CWPPの5つの特徴 クラウドサービスのセキュリティ不備によるリスクを低減させるCWPPの主な機能としては、以下の5つとなります。 1. マルチクラウド対応 AWSだけではなく、Azure、GCPなどの複数のクラウドサービスプロバイダーをサポートしています。 マルチクラウド環境のクラウドワークロード(仮想マシン、コンテナ、サーバレス等)をサポートしており、管理コンソールか統一したポリシーにより一元的に管理することが可能です。 2.脆弱性管理 クラウドワークロードに存在する脆弱性を定期的に監視し、特定のセキュリティホールや問題を検出し、分析・管理を行う。 ソリューションによっては問題を修復する機能も含まれます。 3.侵入検知とランタイム防御 クラウドワークロードに対する不正アクセスや攻撃、疑わしい動作や、悪意のある動作・トラフィックを検出し、適切な対策、防御を行う。 4.コンプライアンス管理 様々な法規制や企業のセキュリティポリシーに従ってワークロードが運用されているかを監視し、ポリシー違反がないかを監視・管理します。また、今後新しく施行されるルールにもいち早く対応を行うことが可能になります。 5. 自動化とオーケストレーション セキュリティプロセスや対応策の自動化が組み込まれており、人手の対応を最小限に抑えつつ、効率的なセキュリティの実現が可能です。 イベントの自動対応やセキュリティタスクのオーケストレーションにより、迅速な対応が実現されます。 参考)クラウドセキュリティにおいて、CSPMを合わせてよく出現する言葉 CWPPと合わせてよく使われる言葉としては以下があります。CWPP、CIEM、CNAPPについては、別途改めて記事にする予定です。 ・ CSPM (Cloud Security Posture Manabement):クラウドサービスの態勢(状態)の管理 ・ CIEM (Cloud Infrastructure Entitlement Management) :クラウドサービスのアクセス権限の監視/管理 ・ CNAPP (Cloud Native Application Protection Platform):CSPM/CIEM/CWPPを含むプラットフォーム。シーナップと呼ばれます。 ・ CASB (Cloud Access Security Broker):クラウドサービスの利用を可視化/監視/適切なアクセス制限を実施。キャスビーと呼ばれます。 まとめ 前回CSPMについては、導入をいきなり検討するのではなく、脆弱性診断のようにまずはCSPMを利用したサービスを一度スポットでご利用されるのが良いのではないかと考えており、SCSKでは、 Palo Alto Networks(パロアルトネットワークス)社 のCSPM「 Prisma Cloud 」を採用したマネージドサービスを提供しておりますとお伝えしました。 CWPPについては、エージェント導入が必要なこともあり、現時点では残念ながらスポットでの診断サービス提供はしておりませんが、同じく「Prisma Cloud」がCWPPもサポートしておりますので、マネージドサービスを提供しております。 「Smart One Cloud Security」として、常時監視(Monitoring)するマネージドサービスをご提供しておりますので、ご興味をもたれた方は是非、お問い合わせください。 Smart One Cloud Security® パブリッククラウドのセキュリティ設定を診断/監視するマネージドCSPMサービスです。Palo Alto Networks社Prisma Cloud(CSPM機能)を使い易く、簡単に導入いただけます。 www.scsk.jp 前回の繰り返しですが、CSPMについては「 マルチクラウド設定診断サービス with CSPM 」として、スポットでの診断サービス(30万円~)を提供しておりますので、まずは自社のクラウドサービスの脆弱性診断(=クラウド設定診断)を実施されてみるのが良いと思います。 定期的(半年や四半期毎)にスポット診断を実施することも可能ですし、もちろん常時監視するサービスもご提供しており、以下のサービス紹介ページに当社オリジナルの日本語での診断レポートサンプルもございますので、ご興味を持たれた方は、是非ダウンロードをお願いします。 マルチクラウド設定診断サービス with CSPM| SCSK株式会社 マルチクラウド環境のセキュリティ設定リスクを手軽に確認可能なスポット診断サービスです。独自の診断レポートが、運用上の設定ミスや設計不備、クラウド環境の仕様変更などで発生し得る問題を可視化し、セキュリティインシデントの早期発見に役立ちます。 www.scsk.jp また、CSPM、CWPPなどクラウドセキュリティをご紹介するセミナーを随時開催しておりますので、是非ご参画ください。 以下は、「情報セキュリティマネジメントフォーラム2024」にて『DX推進にかかせないクラウド利用、そのセキュリティ対策とは? ~事例で学ぶ、ガバナンス強化手法と運用のポイント!~』で講演を行います。 情報セキュリティマネジメントフォーラム2024 実践事例と考えるセキュリティマネジメントの最前線伊勢丹ホールディングス。一般財団法人杏仁会、東亜建設工業株式会社、株式会社三越伊勢丹ホールディングスご登壇。情報セキュリティマネジメントフォーラム2024 r-management.jp
どうも、Catoクラウドを担当している佐々木です。 CatoユーザからPoP切替タイミングを制御したい、という問い合わせを多くいただきますので、 今回は PoPの切替に関する動作説明(仕様)と切替タイミングの変更 について紹介します。 ※画⾯は2024年1⽉時点のものです。機能アップデート等で変わる場合がありますので、あらかじめご了承ください。 PoP選択について 通常Catoクラウドへ接続を開始すると、自動的にユーザのロケーションに最も近い最寄りのPoPに接続されます。 また、優先して接続したいPoPを定義している場合、まず優先PoPとの接続を試みます。 詳細は、過去のブログ記事(「 経路選択の仕組み 」「 Site(拠点)を指定のPoPに接続する 」あたり)を参照ください。 Catoクラウド PoP (Point of Presence)について Catoクラウドの肝となる、インターネットを介してCatoクラウドのサービスを利用するためのアクセスポイント、PoP(Point of Presence)についてご紹介します! Catoクラウドでは世界中に自前のPoPを配備しグローバルでサービスを展開しています。 blog.usize-tech.com 2023.11.13 PoPが切り替わるときはどんな時? SocketとPoP間では、パケットロス、遅延などを常時監視しています。 常時監視する機能を「 Connection SLA 」と呼びます。 Connection SLAの監視項目の数値が閾値を下回ったりPoPとのトンネルが切断されると、Socketは通信復旧を自動で試みます。 この通信復旧手段の一つとして「 PoPの切り替わり 」も試みます。 つまり、 「 PoPの切り替わり 」が発生するのは、SiteとPoPとの通信が切断された時、 もしくは通信が不安定な時ということです。 PoPが切り替わるとどうなるの? PoP切り替えのタイミングで、瞬断~数秒程度の通信が発生する可能性があります。 「 PoPの切り替わり 」は通信が不安定なタイミングで発生するため、切り替わることで通信状況が改善される可能性があります。 PoPの切り替わりタイミングを制御したい 「PoPの切り替わり」は、SiteとPoPとの通信が切断されたとき、または通信が不安定なタイミングで発生します。 通信が不安定なタイミングとは、前述の Connection SLA(監視機能)の閾値を下回っている状態を指します。 閾値によっては、PoPの切り替わりが頻繁に起こったり、逆に切り替わりに時間がかかることがあるため、閾値をチューニングしたい、というお客様もいらっしゃると思います。 監視項目(Connection SLA)の閾値を変更することで、 PoP切り替えタイミングについて 制御する方法をご説明します。 閾値のチューニング方法~Connection SLA~ 「 Connection SLA 」は以下から設定可能です。 「 Network 」>「 Connection SLA 」を選択し、「 SLA Thresholds 」をクリックします。 デフォルトの状態だと以下の通り、「 Cato Smart SLA 」が選択されています。 デフォルト(Cato Smart SLA)の閾値は以下の通りです。 パケットロス:10% 遅延(レイテンシー):300 ms 評価期間:10分間 ※パケットロスと遅延はor条件です。 つまり、 パケットロスが10%、もしくは遅延が300ms以上の状態が10分間発生すると切り替わりが発生します。 任意の設定をする場合は、「 Use custom SLA thresholds for Packet Loss and Latency 」を選択いただき、表示される項目に任意の値を設定ください。 注意点 回線冗長構成の場合 シングル構成の場合は、PoPとのトンネルがダウンしたり、パケットロスが100%になったり、「Connection SLA」の閾値を下回ればすぐにPoPが切り替わりますが、回線冗長構成の場合、すべてのアクティブリンクが上記状態にならないとPoPの切り替わりが発生しません。 ※ 回線冗長構成:1台のSocketに複数のインターネット回線が接続されている構成 例えば、Activeポートのインターネット回線のみで障害が発生している場合、PoPは切り替わらずPassiveポートを利用します。 ※ ActiveポートとPassiveポートはそれぞれ独立してPoPとトンネルを常時接続していますが、Active/Passiveで必ず同じPoPを利用します。 閾値を厳しくすると逆に不安定になるかも 閾値を厳しくし過ぎると、頻繁にポートのステータスや接続PoPが変わり、逆に通信が不安定になってしまう可能性があります。 例えばフレッツ回線のようなベストエフォート回線をご利用の場合、数%のパケットロスが発生することは珍しくありません。 ご利用のインターネット回線の種類に応じて、適切な閾値を検討ください。 全Siteを対象とした設定と、Siteごとの設定が可能 上記の設定方法は、全Siteを対象とした設定になります。 特定のSiteのみ設定したい場合は、以下の方法で可能です。 「 Network 」>「 Sitesから設定したいサイト 」を選択します。 「 Site Configuration 」>「 Connection SLA 」>「 SLA thresholds 」で「 Override Account Settings 」をチェックし、 任意の閾値を設定ください。 まとめ 今回のポイントは以下になります。 ・「PoPの切り替わり」が発生する時は、「SiteとPoPとの通信が切断された時」と「通信が不安定な時」 ・通信の不安定さは監視項目(Connection SLA)の閾値を下回るかどうかで判断 ・監視項目(Connection SLA)の閾値は手動で変更可能 本機能含め、弊社の 「Catoに関するFAQサイト」 にはCatoに関する多数の情報ございますのでご参考にください。 よくあるご質問 | Cato Cloud ケイトクラウド - SCSK Cato SASE Cloud Platform. powered by SCSK cato-scsk.dga.jp 最後に、SCSKではPoCから導入、運用まで幅広くCatoに関する支援を行っております。 本番構成への移行を見据えたPoC構成や、PoCでつまづきやすい点のサポートなど、豊富な導入実績を基にご支援いたします。 ぜひお声がけください!
2024年2月以降のCatoクラウドの新しいサービス体系、基本・オプション料金、マネージドサービスについて解説を行います。これまで(2024年1月末まで)のサービス体系、および新旧の変更内容については以下の記事を参照ください。 Catoクラウドのサービス体系について Catoクラウドのサービス料金を含むサービス体系、オプションやマネージドサービスについて紹介します。 blog.usize-tech.com 2023.08.17 Catoクラウドの価格改定(Pricing Update)について 2023年11月にアナウンスされたCatoクラウドの価格改定(Pricing Update)について現行サービス体系との差異を中心に解説します。※実際の価格については記載していません。 blog.usize-tech.com 2023.12.25 サービス基本料金 Catoクラウドのサービス料金については、以下の3つに対して基本料金が発生します。 拠点毎のPoP接続帯域、またはPoP接続総帯域 モバイルユーザ Socket 拠点毎のPoP接続帯域、またはPoP接続総帯域 Catoクラウドでは、拠点は” Site(サイト)ライセンス “というものになります。接続する拠点毎の帯域として、最小 25Mbpsから、50M、100M、250M、500M、1,000M、2,000M、3,000M、最大 5,000Mbpsまで9つのメニューが設定されています。 本社・支店・営業所、データセンターなど物理的な拠点だけでなく、AWS、AzureなどのクラウドにもSiteライセンスが必要となります。 契約帯域以上の速度は出ません。それ以上の通信はQoS設定に従い、破棄(Discard)されます。 Siteライセンス以外に、接続する複数拠点の総帯域を購入する” Pooled(プールド)ライセンス “というものがあります。Pooledライセンスは、1,000Mbps以上(追加単位100Mbps)での購入となります。Siteライセンスとは異なり、10Mbps単位で拠点への分割でき、拠点帯域の増速/減速を行うことが可能です。 料金については、提供地域により異なります。Catoクラウドでは、世界各国を大きく3つのグループ( Group1 、 Group2 、 Stand-alone Countries )に分割しています。日本は、Group2 に所属します。 Stand-alone Countries(単独国)には3ヵ国(中国、ベトナム、モロッコ)が含まれ、それぞれの国毎に価格設定がされているため、全部で5つの料金体系となります。 Group1 (北アメリカ、ヨーロッパ) Group2 (日本を含むアジア、オーストラリア、アフリカ、メキシコ) Stand-alone Countries(中国) Stand-alone Countries(ベトナム) Stand-alone Countries(モロッコ) Group1、Group2、Stand-alone Countriesは以下(世界地図)の通りです。 Stand-alone Countriesについては、先ほどの25M、50M、・・・、5,000Mの9つのメニューではなく、国内(Regional)/国外(Global)向けの通信をそれぞれ1Mbps単位で契約を行います(最小2Mbps以上) 価格(料金)としては、(安い)Group1 < Group2 < Stand-alone Countries (高い)となります。 Pooledライセンスは、同じグループ内での分配が可能となっております。 Stand-alone Countries(中国、ベトナム、モロッコ)には、Pooledライセンスはございません。 通常は、SASEライセンスという後述のSocketの利用を前提としたライセンスになりますが、Socketを利用しない(IPsec接続)場合には、より安価なSSEライセンスというものを適用することも可能です。 モバイルユーザ モバイルユーザ(=SDP※ユーザ)は、アカウント数による課金となります。 ※SDP・・・Software Defined Perimeter(ソフトウェア定義境界)は、ZTNAの別名で、従来型のリモートアクセスとは異なり、ゼロトラストの原則に則ったセキュアなリモートアクセスです。Catoクラウドのリモート(モバイル)アクセスを意味します。 Group1、Gropup2については、共通の” Generalライセンス “となります。 Stand-alone Countries(中国、ベトナム、モロッコ)はそれぞれ別のメニュー体系となります。 購入したアカウント数以上は登録が行えません(エラーになります) また、予備でGeneralライセンスが5つ付与されています。 SDPユーザは、10ユーザライセンスから購入が可能となります。 Generalライセンスについては、10~500、501~1,000、1,001~5,000、5,001~10,000、10,001・・・、と契約ユーザ数毎にボリュームディスカウント料金が適応されます。 モバイルユーザは、端末にCatoクライアントをインストールしますが、1ユーザ(アカウント)で、3台(デバイス)まで利用することが可能です。 Socket Socket(ソケット)は、物理ハードウェア Socketを一切利用せず、仮想アプライアンス(vSocket)や、既存ルータやFirewall等を用いたIPsec接続のみを利用される場合は不要です。 Socketは、大きく X1500 、 X1600 、 X1700 の3機種があり、X1500が最大スループットが500Mbpsまで、X1600が1,000Mbpsまで、X1700が5,000Mbpsまでとなっております。 X1600については「ベーシックモデル」がリリースされており、今後、SIMを搭載可能な「LTEモデル」、「Wi-Fiモデル」、「5Gモデル」、「Wi-Fi+LTEモデル」などがリリースされる予定です。 Socketは、冗長(HA)構成を行うことが可能です。コールドスタンバイの予備機として手配することも可能です。 Socketは、一括購入するのではなく、サブスクリプション(サービス課金)となりますので、手配したSocketすべてに費用が発生します。 ラックマウントキットやウォールマウントキットも有り、同じくサブスクリプションで提供されています。 サブスクリプションのため、Catoクラウドのサービス終了時には、すべて返却いただく必要があります。 オプション料金(セキュリティオプション) 現在、以下 5つのセキュリティオプションがあります(2024年2月時点) No. セキュリティオプション オプションサービス内容 1 Threat Prevention アンチマルウェア(AM)、次世代型アンチマルウェア(NGAM)、IPS(Intrusion Prevention System)、DNS Security、Threat Intelligence、インラインAI/ML、アンチフィッシング 2 CASB Cloud Access Security Broker SaaS・アプリケーション利用の可視化/評価/制御 3 DLP Data Loss Prevention 機密情報や重要データの漏洩対策 4 RBI Remote Browser Isolation Webブラウザ分離 5 SaaS Security API 外部クラウドサービスのAPIによるセキュリティ検査(アンチマルウェア、DLP) セキュリティオプションは、サービス基本料金(Site/Pooledライセンス、SDPユーザ)への追加料金となります。 Site/PooledライセンスとSDPユーザは、必ず同じセキュリティオプションを選択する必要があります 。 (特定拠点のみセキュリティオプションなし、SDPユーザのみセキュリティオプションなしはできません) Threat Prevention ・・・ パターンファイルマッチングのアンチマルウェア(Anti-Malware)と、機械学習エンジンを用いた振る舞い検知を含む次世代型アンチマルウェア(Next Generation Anti-Malware)、Catoクラウドで最もセキュリティ効果が高い IPS、不正なドメインへのアクセスをブロックする”DNS Protection”や、不審なアクセスをモニタリングする”Suspicious Activity Monitoring(SAM)”、”Threat Intelligence”、”インライン AI/ML”、”アンチフィッシング”などがすべて含まれています。 CASB ・・・ SaaSアプリケーションやクラウドサービスの利用状況を可視化(=シャドーITの可視化)を行います。Cato社で各アプリケーションを独自のセキュリティ・コンプライアンス等の視点で評価した Application Credibility Evaluator(ACE)を利用しており、それを元に管理者が、アプリケーション毎に利用許可(Sanction)を行うことが可能になります。さらにアプリケーションのアクティビティ単位での制御を行うことが可能になります。例えば、DropboxやGmailでダウンロードは許可するが、アップロードは許可しないなどです。また、Office365の企業テナントのみの利用を許可するなども、CASBのオプションで実現が可能となります。 DLP ・・・ トラフィック上のすべてのファイルをスキャンして、機密情報の検出を行い、適切な措置を講じることができます。機密情報の特定には、事前にCato社で定義されたルール(データタイプ)を利用することも可能です。クレジットカードやマイナンバーカードなどは事前にルールが定義されていますが、個別に定義することも可能で、MIP(Microsoft Information Protection)ラベルとの連携も可能になっています。 RBI ・・・ ユーザーのエンドポイントデバイスの代わりに、Catoクラウドが、ユーザーのWeb閲覧セッションを実行し、その画面情報をユーザへ送信することによって、オンラインの脅威(不正プログラムのダウンロードや実行)を無力化するものです。 SaaS Security API ・・・ Catoクラウド以外から、SaaSアプリケーションやクラウドサービスを利用する場合、つまり外部とのコラボレーションを行う際の脅威を検出するために、SaaSアプリケーションへAPIを利用してセキュリティ検査(マルウェア検査やDLP)を行う機能となります。SaaS Security APIは、1つのSaaSだけ検査可能な「 SaaS Security API 1 App connector 」、2つのSaaSを検査する「 SaaS Security API 2 Apps connectors 」、3つ以上のSaaSを検査する「 SaaS Security API All Apps connectors 」の3ライセンスになっております。 セキュリティオプションには幾つかの前提条件があります。 ・DLPは、CASB契約が前提となります。 ・SaaS Security APIは、DLP契約が前提となります。 ・SaaS Security APIでマルウェア検査をする場合は、Threat Preventionの契約が前提となります。 ・SaaS Security APIのシングルコネクターは同じベンダーのアプリケーションはすべてで機能します。例えば、Microsoft app connectorは、Microsoft 365アプリケーション(One Drive、Sharepoint等)すべてで利用できます。 CASB、DLPは、2022年にリリースされており、RBI、SaaS Security APIは、2023年にリリースされています。 今後も新たなセキュリティオプションが順次リリースされますが、契約だけですぐに利用できるのが、SASE、Catoクラウドの最大のメリットです。 オプション料金(新しいセキュリティサービスとマネージドサービス) No. セキュリティサービス セキュリティサービス内容 1 XDR Security Pro Extended Detection and Response 拡張検出と対応 2 Endpoint Security(EPP) Endpoint Protection Platform エンドポイントプロテクションプラットフォーム 3 MDR Managed Detection & Response 専任のセキュリティアナリストによるSOCサービス 4 ILMM Intelligent Last Mile Management ラストマイルインターネット回線管理サービス まず、CatoのXDR Securityは、世界初のSASEベースのXDR(Extended Detection and Response)です。 XDR Securityには、CoreとProの2種類があり、 XDR Security Core については、Catoクラウドをご利用のすべてのお客様が無料でご利用可能です。ただし、XDR Security Coreは、セキュリティオプション IPSのログを元にセキュリティインシデントの分析をしていますので、Threat Preventionの契約が前提となります。 XDR Security Pro ・・・ セキュリティインシデントに対する対応(SOC通知の対応)が可能なお客様向けに提供される機能で、AIベースの脅威ハンティング(Threat Hunting)、ユーザー行動分析(User Behavioral Analysis)、インシデントライフサイクル管理を追加したセキュリティオプションとなります。 CatoのマネージドサービスであるMDRは、XDR Security Proの契約が前提になります。 Endpoint Security(EPP) ・・・ 世界初のSASEベースのエンドポイントセキュリティ(EPP)となります。これまでのSASEのカバレッジ範囲を、ネットワーク層を超えてエンドポイントにまで拡張する製品となり、CMAに完全に統合管理され、クラウドネイティブな他のセキュリティスタックと連携して動作します。 EPPは、端末にEPPソフトウェアをインストールします。SDPユーザの利用デバイス数上限と同様に3デバイスが上限となります。 MDR ・・・ Cato社の専任のセキュリティ専門家によるアセスメントから、ゼロデプロイメント、全てのトラフィック常時監視し、継続的な脅威ハンティングをサービス提供します。定期的なレポートとサービスレビュー(オンライン会議)が行われます。 残念ながら、 2024年2月時点では、MDRは英語対応のみ(レポートおよびオンラインのレビュー会議等)となっており、 日本語は未対応 となっております。 そのため後述しますが、SCSKでは個別に日本語対応したSOCサービスを提供しております。 XDR Security Pro、Endpoint Security(EPP)、MDRについては、 Knowledge Users(ナレッジユーザ)課金 となります。 Knowledge Usersとは、企業内のM365やG-Suite契約ユーザ数のことで、同ユーザ数での契約が前提となります。 ILMM ・・・ Cato社のNOC(Network Operations Center)が、ラストマイルのインターネット回線のブラウンアウト(回線の品質やレスポンスが規定に満たない状況)や、顕著なパフォーマンス低下やブラックアウト(回線断)をリアルタイムに監視(検知)します。NOCが問題を検知し、回線を特定すると、NOCは、直接ISPへ(日本国内の場合は日本語で)連絡を行い問題の解決を図ります。ISPと協力し、ネットワークの問題原因を特定し、問題解決を図り、お客様へ対応内容を適宜ご報告します。 ISPには、事前にお客様の委任状をいただくことで、ISPへの直接問い合わせを代理で実施します。 ILMMは、セキュリティオプションと同じくサービス基本料金(Site/Pooledライセンス、SDPユーザ)への追加料金となります。 課金(請求)および契約について SCSKでは、 月額課金(月額請求) となります(一括請求することも可能です) サービス基本料金とオプション料金(セキュリティオプション、セキュリティサービス、マネージドサービス)の合計を毎月ご請求いたします。 Siteライセンスの増速(例 25Mbps→50Mbps)や、モバイルユーザの追加(例 +10ユーザ)も、追加した月からの追加課金(請求増)となります。 Socketについてもサブスクリプションですのでアップグレードが可能です。X1500からX1600、X1700へのアップグレードを実施した場合は、アップグレード実施月からの追加課金(請求増)となります。 その他には、お客様毎に個別割り当てを行うグローバルIPアドレスも3つまでは基本契約に含まれますが、4つ目以上はオプション(追加課金)となります。 次に、Catoクラウドのご契約期間は、 最低1年間 となります。複数年契約を行われるお客様も多いです。 Catoクラウドの増速やモバイルユーザの追加、あるいはSocketのアップグレードは、契約期間中いつでも実施することが可能ですが、 拠点の解約、帯域減速、モバイルユーザ削減、Socketダウングレードについては、契約更新時(更新月)にしか実施することができません のでご注意ください。 また、契約期間中の増速・追加・アップグレードは、契約終了月までの契約になります。 例えば、2024年2月契約開始、2025年1月契約終了の1年契約の場合、2024年4月に拠点を増速した場合は、増速分の契約は2024年4月から2025年1月の10ヵ月契約となります。 Catoクラウドの最小構成は、1 Siteライセンス、10 SDPユーザ となります。 上記の最小構成は、モバイルユーザ 10名、拠点はクラウド(AWS)としてのSiteライセンス 25Mbpsとしています。 モバイルユーザ(日本)については、帯域の制限(上限)はありませんが、一部の地域(中国やベトナム等)については上限があります。 AWSのvSocketには料金は発生しません。ただし、AWSの利用量(仮想マシン利用、通信量等)は別途必要となります。 最小構成の費用感としては、定価ベースで年間65万以下(月額6万円以下)となりますので、他のSASEソリューションと比較すると、非常に安価でスモールスタートが可能なソリューションです。 ちなみに、Pooledライセンスは1,000Mbps以上の購入となりますが、Siteライセンスの100Mbpsをベースに価格設定されているため、100Mbps以下の拠点の合計帯域が1,000Mbps以上になる場合は、Pooledライセンスの購入検討を行われた方が賢明です。特に、25Mbps以下の狭帯域(10M,20M)拠点が多く存在する場合は非常にコストメリットがでます。 SCSKのマネージドサービスについて SCSKでは、2019年よりCatoクラウドの取り扱いを開始し、お客様からのニーズに応じて様々なマネージドサービスをご提供しております。 Catoクラウドをご検討中のお客様へのPoCの支援から、既存環境の現状調査、要件定義、設計・構築・導入支援、既存WANやセキュリティ機器からの移行設計/移行支援、拠点のインターネット回線の調達から、拠点のSocket設置作業など、ご要望に応じて、あらゆるサービスを提供することが可能です(もちろん、日本国内だけでなく海外も含みます) また、SASE、Catoクラウドは、既存WANやセキュリティ機器の置き換えになるため、初期の構築だけでなく、運用保守が非常に重要となります。 そこで、SCSKが提供しているマネージドサービス(一部)をご紹介します。 No. SCSKマネージドサービス サービス概要 1 サービス窓口(SPOC) 24時間365日の電話・メールでのサービス受付窓口をご提供します。 海外拠点向けの英語での24時間365日の受付窓口もご準備しています。 2 監視・障害一次切り分け 拠点の障害監視を行い、障害検知(またはお客様からの通報)時に、障害箇所(Catoクラウド/Socket/ネットワーク回線等)の一次切り分けを行います。 3 変更作業代行 お客様に代わってCatoクラウドの各種設定変更作業を実施します。 4 月次報告会 Catoクラウドから取得した各種データを分析して月次報告書を作成します。 ネットワークトラフィックの傾向分析、各種セキュリティログの分析結果を基にレポートを作成し、報告会を開催します。 5 Socketオンサイト保守 Socketのオンサイト24時間365日(駆付目標:4時間)保守サービス。 当社でSocket代替を事前手配した特別保守サービス。海外拠点向けのオンサイト保守サービスもご準備しています。 6 SOC監視サービス Catoクラウドのセキュリティログをセキュリティアナリストがリアルタイムで監視・分析を行い、必要に応じて、お客様へ電話・メールで通知を行います。 7 セキュリティ アドバイザリサービス お客様からの依頼に基づき、セキュリティアナリストが頂いた情報を調査・分析、知見をご提供します。 8 ログ保管サービス Catoクラウドではログ保管期間が定められているため、3年間の長期保管を行います。お客様のご依頼に応じてログを抽出してご提供します。 9 設定診断サービス ※すでにCatoクラウドをご利用のお客様が対象 セキュリティ・アーキテクト・コスト(経済性)の3つの観点からCatoクラウドを推奨設定に基づき、現状の設定内容を確認し、報告書を作成します。 サービス窓口 ・・・ 24時間365日の電話、およびメールの窓口となります。障害のお問い合わせを始め、Catoクラウドの技術的なお問い合わせについても、サービス窓口で受付を行います。なお、技術問い合わせの回答については、平日9:00-17:00対応となります。 また、サービス窓口のご契約で、当社が運営するFAQサイトの契約者IDをお知らせします。FAQサイトには、一般公開情報とは別の追加情報や、Knowledge Baseへのリンク、当社作成の手順書・マニュアルなどをご提供しております。 よくあるご質問 | Cato Cloud ケイトクラウド - SCSK Cato SASE Cloud Platform. powered by SCSK cato-scsk.dga.jp 月次報告会 ・・・ Catoクラウドから取得できるトラフィックデータや各種ログ(Events)をAPIで取得し、集計・分析した結果から月次報告書を作成します。ネットワークトラフィックの分析(当月度、および過去半年間の傾向分析)、各セキュリティログの集計・分析、さらに、毎週リリースされるCatoクラウドの最新情報をとりまとめて月次報告書として作成し、報告会(オンライン)を開催します。 Cato クラウド向け月次レポートサービスの紹介と技術的な仕組みの解説 SCSKでは Cato クラウドの導入から運用まで一貫した技術サポートやサービスを提供しております。本記事はサービスメニューの1つである月次レポートサービスのご紹介と、その裏側の技術的な仕組みについて解説いたします。 blog.usize-tech.com 2024.01.22 Socketオンサイト保守 ・・・ Socketのハードウェア障害時の日本全国4時間駆け付け目標のオンサイト保守サービスとなります。交換を行うSocketの代替機も、SCSKにて事前に準備しておりますので、お客様で予備機を手配しておく必要がありません。(予備機費用が削減できます) SOC監視サービス 、 セキュリティアドバイザリサービス は、以下をご覧ください。 SASE「Catoクラウド」のセキュリティ・マネージドサービス機能を強化 SCSK株式会社(本社:東京都江東区、代表取締役 執行役員 社長 最高執行責任者:谷原 徹、以下 SCSK)は、SASEの概念を実装したネットワークセキュリティクラウドサービス「Catoクラウド」のセキュリティにおける検知・対応・復旧を強化する各マネージドサービスを2022年1月28日より提供開始します。 www.scsk.jp ログ保管サービス ・・・ 2023年11月よりCatoクラウドのログを含むデータ保管期間(標準)が6ヵ月から3ヵ月に短縮されました。一方で3ヵ月を6ヵ月、12ヵ月に延長を行うオプション( Data Lake Storage )がリリースされていますが、SCSKにてログを 3年間 保管するサービスとなります。 設定診断サービス ・・・ Catoクラウドの現状設定内容について確認をして欲しいというご要望が多く、セキュリティ・アーキテクト・コスト(経済性)の3つの観点から、SCSKの推奨設定に基づき、現状の設定内容を確認し、報告書を作成し、報告を行うサービスとなります。すでにCatoクラウドをご利用になられているお客様が対象となります。 今後は、当社の推奨設定やノウハウを取りまとめた「 Catoクラウド リファレンスガイド 」や「 APIツールキット 」のサービス提供も計画しております。 まとめ Catoクラウドのサービス体系、基本料金、オプション、マネージドサービス、課金・契約について解説をしました。 さらに、SCSKのマネージドサービスについても合わせてご紹介させていただきましたが、もし興味がお持ちの方がいらっしゃれば、ご遠慮なくお問い合わせください。 “SASE”自体の知名度も低く、”Cato Networks社”、”Catoクラウド(Cato Cloud/Cato SASE Cloud)”の知名度もはまだまだ低い状況です。 SCSKでは、2021年からSASEの主要ソリューションを一同に紹介を行うオンラインセミナー「SCSK SASE Solution Summit(通称 S4 エスフォー)」を定期的に開催しております。これまで13回開催し、1,600名以上の方にご参加いただいております。 次回は、来月2024年2月15日に開催いたしますので、是非ご興味のある方はご参加ください。 【好評につき追加開催決定!】SCSK SASE Solution Summit (S4)ー主要4製品の違いや強みを横並びでご紹介!ー 弊社グループにて取り扱っている4つのSASE製品の気になるポイントをギュッと凝縮しており、製品比較や選定行っていくための情報を一度に収集できるため、「SASEの関する情報収集中の方」だけでなく、「自社の課題解決に最適なSASEを知りたい方」、「他社の導入成功事例を聞きたい方」のご参加を心よりお待ちしております! www.scsk.jp Catoクラウドデモセミナー~Catoクラウドの主要機能を2時間で網羅~ 本セミナーでは、世界初のSASEである「Catoクラウド」の概要をたっぷり2時間、デモ形式でご覧いただきます。 また、ご希望の方(先着10名様)は、デモ環境に対して、お手元の環境からハンズオン形式でCatoクラウドに触れて頂くことが可能な参加型セミナーです。 www.scsk.jp SASEセミナー以外に、Catoクラウドのお客様導入事例の制作、FAQサイト運営、この TechHarmony(技術ブログ)で、皆様のお役に立て、Catoクラウドの知名度アップに少しでも貢献できればと考えております。
こんにちは。SCSK橋本と申します。 早速でございますが、Azureサービスである「Azure NAT Gateway」について紹介したいと思います。 Azure仮想マシンを作成して、パブリックIPアドレスを付与していないにも関わらず インターネット通信が必要である Windows Update が出来ていることに疑問を持ったことはないでしょうか。 実は、Azure仮想マシンを作成した際にAzure側で「azure-default-snat」と呼ばれるインターネットとの通信経路が作成されております。 「仮想マシン→azure-default-snat→インターネット」の経路が存在することにより Windows Update が実現出来ているのですが、 azure-default-snatに任意のパブリックIPアドレスが割り振りされています。 Azure仮想マシンとインターネットのやり取りが Windows Update やWeb閲覧などのグローバルIPアドレス制限のない内容であればデフォルトで実装されるazure-default-snatでも問題ないのですが、 azure-default-snatに実装されているグローバルIPアドレスは「仮想マシンの再起動」や「Azure側の任意のタイミング」で変更されてしまう仕様があるため、IPアドレスの固定はされずSaaSとの連携には向いていない状態となります。 今回は、SaaS側で特定のグローバルIPアドレスのみに通信を許可するケースを「Azure NAT Gateway」を用いた方法で解決する方法を記載いたします。 Azure NAT Gatewayとは Azure NAT GatewayとはAzureで提供されているNAT機能です。 先ほど記述した「azure-default-snat」とは異なり、利用するグローバルIPを固定することが可能となります。 以下に簡易的なアーキテクチャ図を記載いたします。 <アーキテクチャ図> サブネットとAzure NAT Gatewayを紐づけすることにより サブネット内部に作成した仮想マシンのグローバルIPアドレスを関連付けが可能となります。 注意点 以下のケースに該当する場合は、Azure NAT Gatewayを利用できません。 ・サブネット内にパブリックIPアドレスを付与している仮想マシンが存在する場合 ・サブネット内にロードバランサを利用している場合 構築方法 ①Azure Portal にて「NATゲートウェイ」と検索してサービス画面まで遷移し、NATゲートウェイの作成を押下する ②基本タブ内で、リソースグループやNATゲートウェイ名を決定する。 ③送信IPタブ内でパブリックIPアドレスを追加する。 ※既にテナント内でパブリックIPアドレスを用意している場合は、流用しても問題ございません ④サブネットタブ内で、Azure NAT Gateway と紐づけ可能なサブネットが出現するので紐づけしたいサブネットにチェックを入れる ⑤タグタブ内で、任意のタグを作成する ⑥確認 先ほど紐づけを実施しサブネットのプロパティを開き、「NATゲートウェイ」に作成した Azure NAT Gateway が紐づけされているか確認する。 また、Azure NAT Gateway にパブリックIPアドレスが紐づいているので、対象サブネット内のサーバからグローバルIPアドレスを調査して紐づけがされているか確認。 まとめ いかがでしたでしょうか。手数もそんなに多くないので簡単に実現できたと思われる方もいらっしゃるのではないでしょうか。 注意点で記載した条件に引っかからなければ構築可能となりますので、是非グローバルIPアドレスを固定化したいとのことであればお試しいただけますと幸いです。
はじめに こんにちは、最近AI画像生成にハマっている兒玉です。 今日は AWS Control Tower ( 以下Control Tower ) に管理されている S3 Log のライフサイクルを変更しようとしたことで想定していなかった課金が発生したやらかしをご紹介します。 Control Tower では、Log Archive アカウントに CloudTrail のログを作成してくれています。しかし、だいぶ前に作成したので、一体どのくらいの期間ログを保持しているかとか、どのくらいの量ログが溜まっているのか確認していませんでした。 気になって確認してみると… S3 がトップじゃないですか!(金額はたいしたことないですが、アカウントを維持しているだけで毎月料金を近く取られるのが気になる) というわけで、少しでも節約するために 古いログを S3 Glacier Flexible Retrieval (旧Glacier) に移すことにしました。 このときは悲劇が起こるとは思っても見ませんでした。 S3バケットのライフサイクルを変更(失敗) Control Tower のユーザーガイドを一通り探してみたのですが、それっぽいユースケースの説明がありませんでした。仕方ないので、自力で手探りしてみることにします。 Control Tower のログは Log Archive アカウントにあります。Log Archive アカウントにアクセスして、S3バケットを確認しました。 180日で期限切れになって削除される設定になっているようですね。変更してみましょう。 あれ? Access Denied ? ああ、そうですよね、Control Tower の管理するログなので、直接変更はできないですよね。Control Tower よくできていますよね!(すっとぼけ) ここでやめておけばよかったのですが… Control Tower のコンソールからログ設定の変更(要確認?) というわけで、気を取り直して Control Tower の方から変更していきましょう。 管理アカウントでログインし直して、Control Tower の左のメニューから 共有アカウント > ログアーカイブ をクリック ベースラインの設定 の CloudFormation StackSet を表示する をクリック Log Archive アカウントにControl Tower がデプロイした際の StackSet の情報が表示されるので、 スタックインスタンス タブを選択して中身を確認します。AWS アカウントの箇所にLog Archive アカウントが表示されています。ということは、これを変更しろということでしょうかね? 更に パラメータ のタブを見ると、 RetentionDays が 180 RetntionDaysForAccessLogs が 180 、その下のTransitionDays が 90 TransitionToGlacier が No になっています。ここを変えれば良さそうですね。 右上の アクション から、 StackSet のパラメータを上書き を選択 RetentionDays と RetntionDaysForAccessLogs と TransitionToGlacier を選択して StackSet 値の上書きを選択 TransitionToGlacier を Yesにし、RetentionDays と RetentionDaysForAccessLogs は 編集できたことわかりやすいように 180 -> 200 としました。 デプロイがかかって… SUCCEEDED になりました。 LogArchive アカウントに入り直して、S3バケットのライフサイクル設定を確認すると90日でGracier Flexible Retrieval に移動して、200日で削除されるようにきちんと更新されていました! しかし、Control Tower の 画面の Amazon S3 ログを確認すると、 180日のままでした。 うーん、なぜだろう。と、当日は調査をやめて作業を終了しました。 翌日、異常事態の通知が! AWS から、連絡用のメールアドレスに、見慣れない通知が来ました。 AWS Cost Management: Cost anomaly(ies) summary for account: <アカウント名称> (<AWS アカウントID>) [2024-01-24] まずい! なにか乗っ取りでも発生したのか! と、真っ青になって確認してみると… $242.31 !? …調査開始… アカウントID 下3桁 911 Log Archive アカウントの S3 … まさか… 震える手で Anomary Detection Dashboard のボタンを押します… あああ… $242.31 605775% …. アカウントID 末尾 911 は昨日の Control Tower の Log Archive アカウントでしかも料金は S3 で発生しています。この時点でほぼほぼ昨日の自分の作業が原因だとわかりました。でも、なぜ? 考えられる根本原因のトップランキング のところをスクロールして、 根本原因の表示 のリンクから確認します 検証時にしか使っていないアカウントなので、通常の場合日毎のアクセス料金は 0 Request です。ところが、昨日ののみ S3 の API アクセスがなんと 7,072,658 Requests になっています! あれ? でもAPIコールだけではそんなに金額かからないんでは? S3 標準 の PUT、COPY、POST、LIST リクエスト (1,000 リクエストあたり) は 0.0047USD S3 標準 の GET、SELECT、他のすべてのリクエスト (1,000 リクエストあたり) は 0.00037USD 7,072,658(件) x 0.0047(USD/1000件) / 1000(件) =33.2414926 (USD) 7,072,658(件) x 0.00037USD(USD/1000件) / 1000(件) =2.61688346 (USD) 合いませんね。 ちょっと調べてみると、 Amazon S3 ライフサイクルを使用したオブジェクトの移行 - Amazon Simple Storage Service S3 ライフサイクル設定を使用してオブジェクトを移行します。 docs.aws.amazon.com 注記 PUT、COPY、または ライフサイクルルールを使用してデータを任意の S3 ストレージクラスに移動する場合 、リクエストごとに取り込み料金がかかります。オブジェクトをストレージクラスに移動する前に、取り込みまたは移行のコストを検討してください。コストに関する考慮事項の詳細については、[ Amazon S3 の料金 ] を参照してください。 しまったぁぁぁぁぁ… ライフサイクル移行リクエストの料金 か… S3 Glacier Flexible Retrieval への移行料金は 0.03USD / 1000 件(*2024/01/25現在) 7,072,658(件) x 0.03426USD(USD/1000件) / 1000(件) = 242.30926308 (USD) ぴったりです。確定です。自分のやらかしでしたね。あぁ、ライフサイクル移行の料金ってかなり割高だったんですね… 終わりに 今回は一気に90日分ほど移動したので 242.31 USD の料金が発生しました。しかし、 このままでは、毎月この1/3程度の料金が毎月発生してしまい毎月1USD節約するどころか毎月約70USDずつ課金されてしまいます。これはたまらないので、次回はなにか対策を検討しようと思います。
こんにちは、Masedatiです。1月ももう終わりますが、今年もよろしくお願いいたします。 最近Amazon Bedrockのドキュメントを眺めていたのですが、「プロンプトエンジニアリングガイドライン」なるものがあることに気がつきました。 プロンプトエンジニアリングガイドライン - Amazon Bedrock Amazon Bedrock のプロンプトエンジニアリングについて説明します。 docs.aws.amazon.com 本記事は上記ドキュメントを追っていく内容となっています。 また、 「 やってみた 」ではドキュメントに基づいたプロンプトエンジニアリングを実際に行います。 プロンプトエンジニアリングとは 生成AIが期待していたものと違う内容が出力されて、もやもやした経験はないでしょうか? 一生懸命自分で調整した結果、ググったほうが早かったということが、以前私はありました。 そのような無駄な時間をなくし、一発で期待したものを得る「良い命令の仕方」が プロンプトエンジニアリング です。 一応Bedrockくんにも聞いてみましょう。 Prompt:「What is prompt engineering?」 ?!。すごいですね。長くて読む気が失せてしまいました… 命令を変えてみます。 Prompt:「What is prompt engineering? Answer the above question in one sentence.」 「 Prompt engineering is the process of designing and creating prompts that are effective and engaging for a specific task or audience. 」 直感的でわかりやすい回答が返ってきました。 おめでとうございます!これもプロンプトエンジニアリングの一つであり、その一歩を踏み出すことができました。 ガイドラインまとめ ドキュメント記載のガイドラインを以下にまとめました。詳細はドキュメントをご確認ください。 シンプル、明確、完全な指示を行う プロンプトの 最終文 でタスクの指示を行う 私は今まで、一番最初に命令を書いていたので衝撃でした。 簡潔な答えが欲しい場合など出力形式を指定する指示を命令文に付け加える 先ほどの例のような「Answer the above question in one sentence .」命令文が有効です。 段階的に処理してほしい場合、命令文は「 Think step-by-step to come up with the right answer 」とする 小学生の算数問題を想像してもらえればわかりやすいと思います。 例えば、「奈菜さんはお母さんから500円おこづかいをもらいました。駄菓子屋で1個100円のお菓子を3個買いました。帰宅途中ジュースを買い、残金80円となりました。ジュースの値段はいくらでしょう。」といったタスクを解いてもらう際に有効です。 それっぽい情報を出力することを防ぐため、命令文に「If you don’t know a proof, respond by saying “I don’t know.”」のような指示を加える プロンプトに解答例を付け加える 単純タスクの場合、3~5個で十分です。 生成AIを 励ます ネタかと思ったのですが、パフォーマンスが向上する場合があるようです。ネタじゃないですよね…? Temperature? Top P? Amazon Bedrock PlaygroundのTextやChatを使っている方は、右側にパラメータ調整できる”Configurations”欄があるとお気づきでしょうか。 こちらの調整もドキュメントによると “プロンプトエンジニアリング” の一環のようです。 Amazon Bedrock LLM ユーザー向けの一般的なガイドライン - Amazon Bedrock Amazon Bedrock でプロンプトエンジニアリングを使用する方法に関する一般的なガイドラインです。 docs.aws.amazon.com なかなか調整する機会もなく、そのままの方が多いのではないでしょうか。また、いざ調整してみるとどのようにすればいいかわからないと思います。まずは、それぞれのパラメータの説明を見てみましょう。 各パラメータの説明 Temperature 指定範囲:0~1 「0」にするとより厳密な回答となり、「1」に近づくほどより異色や独自性のある回答となるようです。 数回試したのですが、「0」だと同じ回答が出力され、「1」だと毎回異なる回答が出力されました。 Maximum generation length/maximum new tokens 指定範囲:1~モデルによる Amazon Titan → ~8,000トークン Anthropic Claude → ~4,096トークン AI21 Labs Jurassic-2 → ~2,048 or ~8,191トークン Cohere → ~4,096トークン Meta Llama 2 Chat 13B → ~2,048トークン 生成されるトークンの最大数を指定します。クラス分類のようなタスクの場合、ラベル出力のような短い回答が期待されるため、トークン数を少なく設定します。 Top-p 指定範囲:0.1~1 0.1~1の数字は確率を表しており、「1」に設定すると可能性のあるすべてのトークンから次のトークンが選ばれます。逆に、「0.1」に近づくにつれて可能性の低いトークンが除外され、トークンの選択肢は限定的となります。 Top-k Top-kのパラメータがあるのは、「Anthropic ClaudeとCohere」のみです。 指定範囲:0~500 Top-pと似ているのですが、Top-kの値は次に出力される可能性のあるトークンの上限の数です。 例えば、「10」を指定すると次に出力されるトークンは、確率の高い上位10個の単語からランダムで選ばれます。 End token/end sequence 指定したトークンの前で出力を止めることができます。 例えば「is」を追加した場合、「Prompt: What is AWS?」の出力として、以下のようになります。 追加前:「AWS (Amazon Web Services) is a comprehensive, evolving…」 追加後:「AWS (Amazon Web Services)」 基本的に設定しなくてもよい項目のようです。 パラメータ調整難しくないですか? パラメータ調整難しくないですか? lengthやtoken系は直感的ですが、”Temperature”や”Top-p”の組み合わせは無限にあり、タスクに適した調整はなかなか難しいと感じています… ありがたいことに、AWS公式からプロンプトやパラメータの設定例が提供されています。 Playgrounds上でモデルを選び、”Configurations”の上部の「 Load examples 」を押してみましょう。 さまざまなモデルで計28件のプロンプト例が提供されています。 試しにClaudeで提供されている「Character Roleplay」を開いてみます。生成AIがキャリアアドバイザーになりきる設定の例です。 青枠がパラメータですが、「Temperature=1、Top-p=1、Top-k=250」とランダム性が高く、アドバイスを求める出力の際はより創造的に調整するようです。 プロンプトは大きく分けて3パートに分かれています。最初にルール付けを行い、中間で解答例や必要なデータ、そして最終文に簡潔な命令を入力する形となっています。 またルール付けの際、ガイドラインまとめ5に記載したとおり、”それっぽい情報”を出力させないために「 If you are unsure how to respond, say “Sorry, I didn’t understand that. Could you rephrase your question?” 」のルールを追記しています。 やってみる プロンプトエンジニアリング” なし “と” あり “で、弊社の新しいキャッチフレーズを考えてもらおうと思います。 パラメータはキャリアアドバイザーと同じ値とし、” なし/ あり “共通とします。 Temperature:1 Top-p:1 Top-k:250 まずは、何も考えず命令してみます。 Prompt:SCSK株式会社のキャッチフレーズを考えてください 「テクノロジーで未来を創造する」 「イノベーションのパートナー」 「デジタルトランスフォーメーションを共に」 「可能性を形に」 ううむ。ありきたりで個性がありませんね… では、今まで学んできたことをPromptに詰め込んでみましょう。 まずはルール付けとして「SCSK株式会社」とはどのような企業なのか教えてあげます。 弊社ホームページ から引用しましょう。 SCSKグループは、50年以上にわたり、ビジネスに必要なITサービスからBPOに至るまで、 フルラインアップで提供し、8,000社以上のお客様のさまざまな課題を解決してきました。 そして、次の飛躍に向けて、ITを軸としたお客様やパートナー、社会との共創による、 さまざまな業種・業界や社会の課題解決に向けた新たな挑戦に取り組んでいます。 また、追加ルールとして 弊社CM特設サイト 記載の「MESSAGE」を引用したいと思います。 SCSKグループには、50年以上にわたり、あらゆる課題をITで解決してきた知見と実績による、ITの無限の可能性があります。 より多くのみなさんにSCSKという会社を知ってもらい、ITの力で、夢ある未来を共に創っていきたい。 今後のSCSKグループに、ご期待ください。 ルール付けのあとは複数例を挙げ、単純明快な指示を与えれば完成です。 上記まとめたPromptが以下のとおりです。※引用文章の「グループ」から「株式会社」に変更し、一部抜粋します。 SCSK株式会社とは日本のシステムインテグレータ会社です。 SCSK株式会社は、50年以上にわたり、ビジネスに必要なITサービスからBPOに至るまで、フルラインアップで提供し、8,000社以上のお客様のさまざまな課題を解決してきました。 そして、次の飛躍に向けて、ITを軸としたお客様やパートナー、社会との共創による、さまざまな業種・業界や社会の課題解決に向けた新たな挑戦に取り組んでいます。 SCSK株式会社には以下の熱い思いがあります。 「より多くのみなさんにSCSKという会社を知ってもらい、ITの力で、夢ある未来を共に創っていきたい。」 以下が過去のキャッチフレーズの例です。 <example> 2022年:「無いぞ、知名度。SCSK あるぞ、ITの可能性。SCSK」 2023年:「会社名だよ。SCSK あるぞ、ITの可能性。SCSK」 </example> 2022年、2023年のキャッチフレーズから繋がるように、2024年のSCSK株式会社のキャッチフレーズを考えてください。 いざ、出力! 「 つなぐぞ、夢と現実。SCSK 」 まとめ 私も生成AIも褒めたら伸びるタイプです。
こんにちは、SCSKでAWSの内製化支援『 テクニカルエスコートサービス 』を担当している貝塚です。 今回は、AWS Network Firewallの話題です。これまでにもAWS Network Firewallの記事を書いておりますので、ご興味ありましたらそちらもご覧ください。 AWS Network FirewallでアウトバウンドトラフィックをTLSインスペクションする AWS Network Firewallで、アウトバウンド(egress)のTLSインスペクション機能を検証しました。アウトバウンドTLSインスペクションにより、クライアントPC(社内)から外部のウェブサーバへのHTTPS通信の内容を検査することができるようになります。 blog.usize-tech.com 2023.12.27 AWS Network FirewallでインバウンドトラフィックをTLSインスペクションする AWS Network Firewallで、インバウンド(ingress)のTLSインスペクション機能を検証しました。インバウンドTLSインスペクションにより、自身で管理するウェブサーバへのHTTPS通信の内容を検査することができるようになります。 blog.usize-tech.com 2024.01.09 AWS Network FirewallのIDS・IPS機能について AWS Network FirewallはIDS・IPS機能とファイアウォール機能を備えていますが、簡易に導入する場合、IDS・IPS機能はAWSマネージドグループをそのまま適用するということもあるのではないでしょうか。 AWS Network Firewallには、AWSが予め用意したAWSマネージドグループというものが複数あり、これを組み合わせることで利用者側は難しい設定をせずにIDS・IPSとして機能させることができるのです。 ドメインおよび IP ルールグループの一覧 脅威署名ルールグループの一覧 AWSマネージドグループは、 AWSがルールを自動的にアップデートしてくれる ので、新しい脅威が発見されるたびに自分たちでルールを更新する必要もありません。 AWSマネージドグループの問題点 このように便利なAWSマネージドグループですが、少々困ることがあります。 運用上、通常のパケットフィルタリングで通信をブロックしたときのアラートは運用担当に通知してほしくないけれど、IDS・IPSでブロックした場合は通知したい、というケースはあり得そうです。ところが、ログから、これはAWSマネージドグループのルールに合致したログであるという判断ができません。 以下にCloudWatchに出力されたIDS・IPSのアラートログを2つ掲載します。 判断に使えそうなフィールドとしては、event.alert.signatureとevent.alert.signature_idがありそうですが、signatureの方は共通する文字列がありません。一方、signature_idの方は28から始まる7桁の数字という共通点がありそうですが、AWSサポートに問い合わせたところ、この範囲のidが使われるという確実な情報はないようでした。 独自作成したルールグループのログ出力を制御する そこで、「独自作成したルールグループから出力されたログ 以外 」を通知する設定を考えてみます。 標準ステートフルルール形式 [1] で記述したルールに合致したログは以下のようになります。 [1] AWS Network Firewallにおけるルール記述方法のひとつ。パケットフィルタリングのルールを比較的簡単に記述できる。他にSuricata互換ルール文字列という形式もある。 event.alert.signatureがない(厳密には、空文字 “”になっている)ことが分かります。 また、標準ステートフルルール形式のルールにはオプションで任意のsignature文字列(設定時はmsgキーワードで指定)を付与できるので、文字列の先頭に決まった文字列をつけるのもよいでしょう。次の例は先頭に”PACKET_FILTER_ALERT:”をつけるようにしてみました。 さらに、独自作成ルールグループのルールではないのですが、TCP 3ウェイハンドシェイクを暗黙的に許可したときなど、どのルールにも合致しなかったパケットがアラートログに出力される場合があります。一例がこちらです。 signatureが”aws:”という文字列で始まっていることが分かります。 独自作成したルールグループのログ以外を通知するフィルターを作成する それではフィルターを作成してみます。CloudWatch Logsからメールなどの通知につなげる方法として代表的なものにメトリクスフィルターを使う方法とサブスクリプションフィルターを使う方法がありますが、本稿ではサブスクリプションフィルターを設定してみます。 なお、メトリクスフィルターとサブスクリプションフィルターのフィルターパターン構文は一緒なので、以下で説明するパターンはメトリクスフィルターでも使用することができます。 作成するフィルターは、signatureが” PACKET_FILTER_ALERT: “、” aws: “ではじまるもの 以外 を通知するフィルター [2] とします。 [2] “”も除外条件に含めようとしたのですが、サブスクリプションフィルターでは正規表現を2パターンまでしか指定できず、また正規表現”()”をサポートしていないということで、私の知識の範囲では三つすべてを除外する設定が書けませんでした。ルールには必ず特定の文字列から始まるsignatureを入力する(msgキーワードを指定する)という運用にすれば、””を除外条件に含められなくても実用上は問題ないかと思います。 サブスクリプションフィルターの作成 サブスクリプションフィルターの作成時に、既存のログからフィルタパターンのテストをすることができますので、一通り必要なログを出力してから作成を実施することをお勧めします。 CloudWatchのロググループから対象のロググループを選択し、「アクション」→「サブスクリプションフィルター」→「Lambdaサブスクリプションフィルターを作成」をクリック 「Lambda サブスクリプションフィルターを作成」画面で入力をしていきます。 ログの送り先となるLambda関数を指定する必要がありますが、本稿は特定の文字列を除外するフィルターのテストまでを扱いますので、指定を省略します。実際には、Lambda関数の作成~SNS通知の部分を作る必要がありますので、インターネット上の各種ブログ記事等をご参照の上、設定してください。 CloudWatch Logs サブスクリプションフィルターの使用 - Amazon CloudWatch Logs AWS CloudTrail イベントを含むロググループにサブスクリプションフィルターを関連付けます。 docs.aws.amazon.com ログの形式にJSONを指定します。 サブスクリプションフィルターのパターンに以下を指定します。 { $.event.alert.signature != %^PACKET_FILTER_ALERT:.*% && $.event.alert.signature != %^aws:.*% } サブスクリプションフィルターのテスト 「パターンをテスト」の「テストするログデータを選択」のところで、テストしたいログのあるログストリームを選択し、「パターンをテスト」をクリックします。 表示されたテスト結果を見ると、意図通り、signatureが”PACKET_FILTER_ALERT:”または”aws:”で始まるログを除外できていることが確認できました。 まとめ CloudWatch Logsのサブスクリプションフィルターを使ってAWS Network FirewallのAWSマネージドルールのログのみを通知する方法を解説してみました。 本稿では、AWSマネージドルールで使用されるsignature_idは分からないという前提に立ちましたが、公式ドキュメントに公開されていないだけで実際には使用されるIDの範囲が決まっているのではないかと思われますので、AWSのサポートを受けつつsignature_idでフィルターをかける方式を検討するのもありかもしれません。
はじめに 当社では Cato クラウドの導入から運用まで一貫した技術サポートやサービスを提供しております。 Catoクラウド 変化する働き方に必要な「ゼロトラスト」を実現する「ネットワークとセキュリティを統合したクラウドサービス(SASE)」であるCatoクラウドをご紹介しています。 www.scsk.jp 今回はサービスメニューの1つである月次レポートサービスのご紹介と、その裏側の技術的な仕組みについて解説いたします。 月次レポートサービスの紹介 月次レポートサービスの概要 月次レポートサービスは、お客様が Cato クラウドを利用する中で、ネットワーク回線やトラフィックに問題が発生していないかどうかといった観点や、セキュリティ上の問題や懸念が起きていないかどうかといった観点などで分析したレポートを毎月ご提供するサービスです。また、Cato クラウドの新機能のご紹介や当社のサポートサービスのご利用状況の実績報告なども月次レポートの中で行っております。 レポートの中身についてもう少し詳しく紹介すると、例えば次のような分析を行っています。 各サイト(拠点)のトラフィック分析 スループット、パケットロス・破棄率、ラストマイルなどグラフ化・傾向分析 イベント分析 Socket の接続履歴やアップグレード履歴の確認 セキュリティ機能(各 Firewall 機能、Suspicious Activity、DNS Protection など)の集計・分析 ユーザ分析 長期未ログインな SDP ユーザの抽出 ご提供する月次レポートには、データの集計・分析やグラフ化をプログラムで行って自動生成した別紙と、その内容をもとに当社エンジニアが最終的な考察やその他情報を記載した本紙があります。別紙のサンプルは [こちら] からご確認いただけます。 こういったデータは Cato の管理画面 (CMA) 上で参照できますので、定期的に確認して運用に活用しているお客様もいらっしゃるかと思います。ただ、サイト数が多くなってくるとトラフィックのグラフを確認するだけで手間がかかりますし、個々のイベントログを確認できても集計することはできませんし、データは一定期間(3か月 or 6か月 or 12か月) までしか遡って確認できないといった課題もあります。そういった課題は月次レポートサービスで解消いたします。 月次レポートサービスの目的 月次レポートサービスの本質的な目的は、お客様に Cato クラウドを快適・安全にご利用いただくために、お客様の運用作業を支援することにあります。例えば次のような運用作業が必要になってくるかと思います。 帯域が不足しつつあるサイトがあれば、帯域を増速する インターネット回線の不調があれば、回線事業者・ISPへの調査依頼を行う 不審な通信が行われていれば、調査や通信の遮断を行う 退職した社員のアカウントの棚卸を行う 提供する月次レポートを運用作業のインプット情報としてて役立てていただければと考えています。 自動生成の仕組み [こちら] の別紙のサンプルを自動生成する仕組みについても仕組みについても少し解説いたします。具体的には次のようなことをプログラムで行っています。 Cato の API から必要なデータを取得する 取得したデータを集計・分析する トラフィックに関するデータから時系列グラフを作成する 集計・分析結果やグラフから1つのPDFファイルを作成する Cato API からデータ取得 月次レポートを生成するにあたり、Cato API の次の API を利用してデータを取得しています。 entityLookup : サイトやユーザの一覧 accountSnapshot : サイトの詳細情報 accountMetrics : トラフィックの時系列データ events : イベントの集計結果 Cato API の利用方法については別記事で紹介しておりますので、そちらを参照ください。 Cato API の利用方法と制限事項 Cato API の具体的な利用方法や注意事項を Python コードを交えて解説しています。 blog.usize-tech.com 2023.08.08 データの集計・分析とグラフ作成 API から取得したデータの集計・分析には pandas を利用し、グラフ作成には Matplotlib を利用しています。どちらも Python のライブラリで、データ分析の際に広く利用されるものです。 PDFファイルの作成 PDFファイルの作成には、 Asciidoctor という文書化ツールを利用しています。AsciiDoc というマークアップ言語で文書を用意すれば、電子書籍のような綺麗なフォーマットのファイルに変換できるという優れものです。日本語フォントも用意すれば、サンプルのような PDF も作成できます。 AsciiDoc で書かれた文書の作成には Jinja というテンプレートエンジンを利用し、あらかじめ用意しておいたテンプレートにデータの集計・分析結果などを埋め込んで自動生成しています。 仕組みのまとめ 自動生成の仕組みをまとめると、次のようなフローで月次レポートを自動生成しています。 API でデータを取得できれば後はプログラムで大抵のことは実現できますし、将来 Cato API で取得できるデータが増えてくれば月次レポートも充実させていく考えでおります。当社にて開発しているプログラムをご提供することはできませんが、お客様自身で Cato API を利用して運用作業に役立てることもできるかと思います。 まとめ Cato クラウドのお客様向けの月次レポートサービスを紹介し、その裏側の技術的な仕組みについても簡単に説明しました。 Cato クラウドの利用時における運用作業として実施すべきことを整理した情報やノウハウ(≒運用に関する非機能要件や設計書のサンプル)はご提供できておりませんが、一般的に実施が必要であろうと考える運用作業に役立つデータは月次レポートサービスとして提供しておりますので、ご興味があればぜひ当社にご相談ください。お試しとして月次レポートのサンプルの提供もいたします。 また、月次レポートサービスという形でなくとも、お客様固有の運用要件を Cato API を利用して実現する仕組みの開発支援も行えますので、気軽にご相談ください。
こんにちは、広野です。 AWS AppSync を使用したアプリケーションを開発する機会があり、リゾルバ、主に VTL の書き方に関してまとまった知識が得られたので紹介します。前回の続きもので、BatchGetItem の書き方を紹介します。 本記事では、VTL の書き方にフォーカスしています。ご了承ください。 AWS AppSync、リゾルバ、VTL の説明については以下の記事をご覧下さい。 AWS AppSync リゾルバ (VTL) の書き方サンプル No.1 - Amazon DynamoDB GetItem Amazon DynamoDB に VTL で GetItem をかけるときの基本的な書き方を紹介します。 blog.usize-tech.com 2024.01.09 AWS AppSync を使って React アプリからキックした非同期ジョブの結果をプッシュ通知で受け取る 非同期ジョブを実行した後、結果をどう受け取るか?というのは開発者として作り込み甲斐のあるテーマです。今回は React アプリが非同期ジョブを実行した後に、AWS AppSync 経由でジョブ完了のプッシュ通知を受け取る仕組みを紹介します。 blog.usize-tech.com 2022.12.01 Amazon DynamoDB に BatchGetItem する VTL 例えば、AWS AppSync から以下のリクエストを受けたとします。Amazon DynamoDB には適切なデータがある想定です。テーブル名はリゾルバの別の設定 (Data Source) で行います。 引数となるパラメータ: パーティションキー pkey、ソートキー skey 必要なレスポンス: data1, data2 という属性の値、ただし予め決まったルールで2アイテム分のデータが必要 今回は受け取った1つのソートキーパラメータを加工して、2種類のソートキーを VTL で作成します。 もちろん最初から引数として2つのソートキーを渡すこともできますし、パーティションキーを変えてもいいです。いずれにしても、同じテーブルに対して複数の GetItem を 1回のクエリで取得したいときに便利で、かつアプリに結果を戻すときに複数のクエリ結果を融合して返すことが可能です。 マッピングテンプレートは JSON 形式で記述します。その中に VTL が混在する感じです。 リクエストマッピングテンプレート #set($skey1 = "skey1#"+$context.arguments.skey) #set($skey2 = "skey2#"+$context.arguments.skey) { "version": "2018-05-29", "operation": "BatchGetItem", "tables": { "DynamoDBTableName": { "keys": [ { "pkey": $util.dynamodb.toDynamoDBJson($context.arguments.pkey), "skey": $util.dynamodb.toDynamoDBJson($skey1) }, { "pkey": $util.dynamodb.toDynamoDBJson($context.arguments.pkey), "skey": $util.dynamodb.toDynamoDBJson($skey2) } ] } } } operation には、BatchGetItem を書きます。これは Amazon DynamoDB に BatchGetItem をするぞ、という意思表示です。 DynamDB テーブル名も入れる必要があります。DynamoDBTableName の部分は、実際にクエリをかけるテーブル名に書き換えます。 アプリから受け取った引数はマッピングテンプレート内では $context.arguments 内に格納されます。keys に受け取った引数を埋め込みたいのですが、ここでは、pkey はそのまま。skey に対してテンプレート冒頭で #set() で値を2種類に加工しています。変数名は $skey1, $skey2 にしています。加工後の変数を BatchGetItem のソートキーの引数として指定していると思って下さい。 これで Amazon DynamoDB に GetItem をかけることができます。 レスポンスマッピングテンプレート 2つの GetItem が行われた結果は実行順に配列に格納されます。値を取り出して、任意の JSON データ構造にして返すことになります。 $util.toJson({ "skey1data1": $context.result.data.DynamoDBTableName[0].data1 "skey1data2": $context.result.data.DynamoDBTableName[0].data2 "skey2data1": $context.result.data.DynamoDBTableName[1].data1 "skey2data2": $context.result.data.DynamoDBTableName[1].data2 }) VTL に関しては以下の AWS 公式ドキュメントも必要に応じてご確認ください。 Resolver mapping template reference for DynamoDB - AWS AppSync Resolver Mapping Template Reference for DynamoDB for AWS AppSync. docs.aws.amazon.com まとめ いかがでしたでしょうか。 BatchGetItem の使い方は他にもあると思いますが、今回は単純に2つのGetItemをベタに書く方法を紹介いたしました。 Amazon DynamoDB への BatchGetItem が必要となる局面はあると思います。是非、何ができるか押さえておいて、必要になったときの引き出しとして持っておいて頂けたらと思います。 本記事が皆様のお役に立てれば幸いです。
こんにちは。自称ネットワーク技術者の貝塚です。SCSKでAWSの内製化支援『 テクニカルエスコートサービス 』を担当しています。 多くのAWSサービスを使う上で、ログ管理や監視・通知は欠かせませんが、通常これらの機能を目的のサービス自身が持っていることはなく、どうしても他サービス(例えばCloudWatch)との連携が出てきてしまいます。しかも連携パターンも1パターンではなく、運用上の要件・制約などによって複数の連携パターンが考えられるので、この部分を設計するだけでも一苦労なのではないでしょうか。 本記事執筆の動機 今回は、AWSのネットワーク系サービス(の中で私になじみのあるもの)がどこにログを出力できて、どのように監視や通知ができて、ログの分析をどうすればよいのか、自分の中で整理したいと考えたのが本記事の執筆動機です。 先行する記事として以下の記事があります。本稿の執筆にあたっても参考にさせて頂きました。 AWSにおけるログの出力先、可視化、監視のまとめ - Qiita はじめにAWSにおける主要サービスのログの出力先をまとめていきます。ログの種類と出力先ログと出力先、S3に関しては対応する暗号化方式を記載します。S3の場合、バケットポリシー、KMSを利用す… qiita.com 私がこの記事を書く必要はないのでは……と思うくらいよくまとまっているのですが、以下のモチベーションのため自分でも記事としてまとめることにしました。 ネットワーク系サービス(Transit Gateway, Network Firewall)の情報を充実させたかった 通知まで含めて明示したかった なおシステムを監視するにあたっては、各サービスの出力するメトリクス(パフォーマンス等に関する定量的な時系列データ)や各サービスが発生させるイベント(たとえばEC2の停止)も重要な情報になりますが、本稿ではあえてログの取り扱いのみをターゲットにしています。 ネットワーク系サービスのロギング・監視・通知・分析 まずは一枚の図にまとめてみましたのでこちらをご覧ください。(文字が小さいので拡大して見ることをお勧めします) 左側に主なネットワーク系サービスを並べ、それがどのサービスにログを出力できるのかを矢印で結んでいます。さらにそのログ出力先からどのサービスに連携すると監視・通知・分析につなげられるのかも矢印で示しました。 GuardDutyは通常ネットワーク系サービスに分類されませんが、ネットワーク系のログ(VPCフローログやRoute 53クエリログ)をインプットにして脅威検出をしてくれるため、あえてこの図に含めています。 ログ出力先 出力先候補の選択肢は基本的に3つ。CloudWatch Logs、S3、Kinesis Firehoseです。この3つのいずれかから選択可能なサービスが多いですが、中にはそうではないサービスもあります。 CloudWatch Logs CloudWatch Logsに出力しておけば、その後の監視・通知や分析もしやすいですが、 ログの取り込みや分析で料金が高額になることもある ようです。 今回調査対象にしたサービスの多くはCloudWatch Logsへのログ出力に対応しており、Route 53についてはCloudWatch Logsのみとなっています S3 S3はログの保管だけに限ればおそらく最適ですが、監視・通知や分析をしようとするとひと手間かかります。 ALBやCloudFrontは、S3のみの出力となっています。 また、今回あえて対象範囲にしたGuardDutyで検出した脅威は、GuardDuty自体が決まった件数の検出結果を保持してくれますが、長期間保管するのであればS3への出力となります。 Kinesis Firehose Kinesis Firehoseはリアルタイムの分析やETLが必要な場合の出力先です。ストリーミングデータをリアルタイムで配信するためのサービスであり、Firehose自体はログのストレージではありません。具体的なログ活用のユースケースがあった上での選択肢と言えます。 まとめ ロギング・監視・通知・分析と銘打ちましたが、この記事では説明はロギングの部分までにとどめ、以降の説明は別記事としてまとめることにしました。(きっちり書こうとすると調査や検証がかなり大変と気づいたので……) よろしければ続編をお待ちくださいませ。 参考資料 CloudWatchの料金に関するAWSの記事です。 CloudWatch の料金を把握し、今後の料金を抑える AWS の請求書に記載されている Amazon CloudWatch の料金が高額でした。CloudWatch の使用状況を把握し、今後の料金を抑えたいと考えています。 repost.aws
こんにちは、広野です。 以前、以下の記事で AWS AppSync に Mutation をかける AWS Lambda 関数コードを以下の記事内で紹介していたのですが、Node.js で書いたものでした。先日 Node.js 16 が EoL になったことを受けて、AWS Lambda 関数を Python 3.12 で書き換えたので書き残しておきます。 AWS AppSync を使って React アプリからキックした非同期ジョブの結果をプッシュ通知で受け取る 非同期ジョブを実行した後、結果をどう受け取るか?というのは開発者として作り込み甲斐のあるテーマです。今回は React アプリが非同期ジョブを実行した後に、AWS AppSync 経由でジョブ完了のプッシュ通知を受け取る仕組みを紹介します。 blog.usize-tech.com 2022.12.01 AWS Lambda 関数コード 前置きなしでいきなりコード紹介に入ります。 mutation で渡す値は架空のものです。 import boto3 import json import requests from requests_aws_sign import AWSV4Sign session = boto3.session.Session() credentials = session.get_credentials() auth = AWSV4Sign(credentials, 'ap-northeast-1', 'appsync') #AppSyncがデプロイされているリージョンを指定 def lambda_handler(event, context): try: endpoint = 'AppSyncEndpointUrl' #AppSyncのURLを指定 headers = {'Content-Type': 'application/json'} query = """ mutation updateJobstatus( $serviceiduser: String!, $datetime: String!, $url1: String, $url2: String, $status: String ) { updateJobstatus(input: { serviceiduser: $serviceiduser, datetime: $datetime, url1: $url1, url2: $url2, status: $status }) { serviceiduser } } """ variables = { 'serviceiduser': 'xxxxxxxx', 'datetime': 'xxxxxxxx', 'url1': 'xxxxxxxx', 'url2': 'xxxxxxxx', 'status': 'xxxxxxxx' } payload = {'query': query, 'variables': variables} result = requests.post(endpoint, auth=auth, json=payload, headers=headers).json() if 'errors' in result: print(result['errors']) except Exception as error: print(error) result = {'errors': [{'message': str(error)}]} AWS AppSync は受けた Mutation を実行してよいのかどうか、実行元 (AWS Lambda 関数) から送られてきた IAM 情報と照合します。そのため、送信時に Signature V4 という仕組みを使用して情報を署名化し、リクエストのヘッダーに入れる処理が必要になります。 以下、前提事項です。 AWS Lambda 関数に、appsync:GraphQL を実行できる IAM ロールを関連付けていること。 AWS AppSync のスキーマ設定で、該当する Mutation の設定に IAM でアクセス可能な記述をしていること。 import している requests モジュールはどノーマルの AWS Lambda 関数では import できないので、requests の Lambda レイヤーを作成しておくこと。requests をインストールして、同時にインストールされたモジュールとセットで ZIP で固めます。 Lambda レイヤーの作成方法は以下の記事を参考にしてください。 AWS Lambda (Python 3.12) で使用可能な pandas の Lambda Layer を準備する データ分析や加工でよく使われるライブラリに、pandas があると思います。本記事では、AWS Lambda (Python 3.12) で動作する pandas の Lambda Layer を準備する手順を紹介します。 blog.usize-tech.com 2022.06.07 詳細な AWS AppSync 関連設定情報は、繰り返しになりますが以下の参考記事をご覧下さい。 AWS AppSync を使って React アプリからキックした非同期ジョブの結果をプッシュ通知で受け取る 非同期ジョブを実行した後、結果をどう受け取るか?というのは開発者として作り込み甲斐のあるテーマです。今回は React アプリが非同期ジョブを実行した後に、AWS AppSync 経由でジョブ完了のプッシュ通知を受け取る仕組みを紹介します。 blog.usize-tech.com 2022.12.01 まとめ いかがでしたでしょうか。 AWS AppSync を使用しているアプリでアプリ外から画面更新させたいときには AWS Lambda 関数からの Mutation が必要となるケースが多いと思います。 本記事が皆様のお役に立てれば幸いです。
こんにちは。SCSKの江木です。 Google Cloud Generative AI Summit Osakaでも紹介されていた、BigQuery MLのML.GENERATE_TEXT関数を使って、テキストのデータセットを要約してみたので、実装方法を紹介します。 Google Cloud Generative AI Summit Osakaでの詳しい内容は過去の記事をご確認いただけますと幸いです。 Google Cloud Generative AI Summit Osakaに参加してみた! Google Cloud Generative AI Summit Osakaに参加したので、イベントの内容と感想を投稿します。2023年12月14日に大阪のコングレコンベンションセンターで開催されたカンファレンスイベントです。 blog.usize-tech.com 2023.12.20 BigQuery MLとは? BigQuery MLとは、Google Cloudの機械学習サービスで、BigQuery上で機械学習モデルを作成、評価、実行することができます。BigQuery MLを利用することで、機械学習の専門知識がなくても、BigQueryで蓄積されたデータから機械学習モデルを作成することができます。 より詳しい内容は公式ドキュメントを参照ください BigQuery ML とは | Google Cloud cloud.google.com 実装 文章データの準備 データをCSVファイルに変換 json形式の 要約用のデータセット を用いました。csvファイルとして扱いたかったので、以下のプログラムを用いて、テキスト部分を抽出したdataset.csvファイルを作成します。 import pandas as pd import json from pandas.io.json import json_normalize #変換したいJSONファイルを読み込む df = pd.read_json('./japanese_test.jsonl',orient='records', lines=True) # read_jsonした結果だとネストしたjsonを展開できないのでnormalizeで展開させる df_json = df['text'].iloc[:20] #csvファイルで出力 df_json.to_csv("dataset.csv", encoding='utf-8') Cloud Storageにアップロード ロケーション、ストレージクラスを指定し、Cloud Storageのバケットを作成します。 バケットにdataset.csvをアップロードします。 文章データをBigQueryへインポート データセットの作成 BigQueryにテキストデータをインポートするためにデータセットを作成します。 BigQuery Studioのエクスプローラでプロジェクトの右側にある[︙]→[データセットを作成]を選択します データセットIDとリージョンを指定して、データセットを作成します。 テーブルの作成 データをインポートするためのテーブルをデータセットの中に作成します。 作成したデータセットの右側にある[︙]→[テーブルを作成]を選択します テーブルの作成元にはGoogle Cloud Storageを選択します。dataset.csvファイルを選択し、プロジェクト、データセットおよびテーブルを指定し、設定を行います。 作成したデータセットをプレビューすると以下の通りです。 余計な行と列ができてしまったので、データセットを整形します。また、データの数が多すぎるので、データの数を調整します。以下のクエリで整形しつつ、先頭から20個のデータのテーブルを作成します。 SELECT string_field_1 FROM `プロジェクト名.データセット名.テーブル名` LIMIT 20 OFFSET 1 上記のクエリを実行するためにクエリ作成画面を開きます。エクスプローラにある[+]を押下します。 先ほどのクエリを入力し、[実行]を押下し、データ整形を行います。 整形したデータをテーブルに保存します。[クエリ結果]→[結果を保存]→[BigQueryテーブル]を選択します。 データセットを選択し、テーブル名を入力した後、[エクスポート]を選択します。 整形した結果を出力したテーブルが以下の通りです。 これでデータの準備ができました。このデータに対して、ML.GENERATE_TEXT関数を使って要約していきます。 ML.GENERATE_TEXT関数を使うための準備 APIの有効化 Google CloudコンソールからBigQuery API,BigQuery Connection API,Vertex AI APIを有効にします。 コンソールの[APIとサービス]→[有効なAPIとサービス]→[APIとサービスの有効化]を選択します。 APIライブラリが開くので、🔍の検索欄で有効にするAPIの検索を行います。 検索一覧から有効にするAPIを選択することで、以下のような画面(図はBigQuery APIの場合)に遷移するので、[有効にする]を選択します。 接続の作成 Cloudリソース接続を作成し、サービスアカウントを取得します。 BigQueryコンソールのエクスプローラの右側にある[︙]→[+追加]を選択します。 [一般的なソース]→[外部データソースへの接続]を選択します。 接続IDを決め、接続タイプ、リージョンを設定し、[接続を作成]を選択します。 接続情報を確認するため、エクスプローラの[外部接続]から作成した接続を選択します。 接続のサービスアカウントを確認し、コピーしておきます。 サービスアカウントにVertex AIへのアクセス権を付与 先ほどコピーしたサービスアカウントにVertex AIユーザロールを付与します。 コンソールの[IAMと管理]→[IAM]→[権限]→[アクセス権を付与]を選択します。 新しいプリンシパルに先ほどコピーしたサービスアカウントを入力、ロールにVertex AI ユーザーを選択し、[保存]を押下します。 モデルの作成 以下のクエリを実行することで、要約文章を生成するためのモデルを作成します。 CREATE OR REPLACE MODEL `プロジェクト名.データセット名.llm_model` REMOTE WITH CONNECTION `プロジェクト名.接続のロケーション.接続名` OPTIONS (REMOTE_SERVICE_TYPE = 'CLOUD_AI_LARGE_LANGUAGE_MODEL_V1'); エクスプローラで作成したデータセットの中にモデルが出来ていることを確認できます。 これで準備は完了です。 ML.GENERATE_TEXT関数を使って文章データを要約 ML.GENERATE_TEXT関数を使った要約クエリは以下の通りです。 SELECT * FROM ML.GENERATE_TEXT( MODEL `データセット名.llm_model`, ( SELECT CONCAT('文章を要約してください。', string_field_1) AS prompt FROM `データセット名.整形後のテーブル名` ), STRUCT( 0.2 AS temperature, 650 AS max_output_tokens, 0.2 AS top_p, 15 AS top_k, TRUE AS flatten_json_output)); 今回は要約させたいので、上記クエリの6行目のCONCAT内の第一引数を「’文章を要約してください。’」としています。文章のタイトルをつけたい場合は「’文章のタイトルをつけてください。’」とします。(いわゆるプロンプトエンジニアリングです。) STURCT以下はモデルのパラメータです。詳しい設定は公式ドキュメントを参照ください。 ML.GENERATE_TEXT 関数 | BigQuery | Google Cloud cloud.google.com 要約結果は以下の通りです。ml_generate_text_llm_result列が要約結果を表しています。 データの先頭3つの元の文章と要約結果を表にしてみました。 元の文章 要約結果 トム・エッジントン BBCリアリティー・チェック(ファクトチェック)チーム かつて労働党党首も務めたブレア氏は、BBCラジオ4の番組「Today」で、「議会は行き詰まった。議会が決められないなら、国民が決める形に戻ろう」と語った。 労働党の公式な立場は、テリーザ・メイ英首相が欧州連合(EU)と合意した離脱協定案が議会で否決された場合、解散総選挙の圧力をかけるというもの。もし総選挙が実現しなかった場合は、再度の国民投票を支持するのも選択肢になりうると、労働党は表明している。 しかしメイ首相は、再国民投票の予測を否定している。メイ氏は下院議員らに対し、2016年に実施した国民投票の結果が「尊重されるべきだ」と繰り返し語ってきた。 だが、もしブレア氏が求めている通り、下院がブレグジットをめぐる膠着(こうちゃく)状態を打ち破るために2度目の国民投票を実施すると決定したら、どうなるのだろうか? 英選挙管理委員会はBBCニュースに対し、「適切な対応策」を有しており、「あらゆる予定外の投票に迅速に対応する」準備ができていると語った。 期限は迫っている イギリスのEU離脱予定日は、2019年3月29日。残り100日を切り、時間が最も差し迫った問題だ。 英議会が2度目の国民投票実施を採択した場合、投票規則や選挙運動規則を定める法律にも上下両院の支持が必要になる。 2016年の国民投票では、投票日の7カ月前に関連法案が議決された。 しかし、今回はもっと早い法制化が可能なのだろうか? 法制化の速度を上げるため、前回の国民投票に関する諸規則を定めた2015年国民投票法をひな型にし、実質的に大部分を写してしまうのが、あり得る選択肢の1つだ。 英ユニヴァーシティー・コレッジ・ロンドン公共政策大学院憲法ユニットのアラン・レンウィック副ユニット長は、「理論上、このやり方は非常に素早く完了できる」と話す。 もしこのやり方が採用されても、法案の議会通過はおよそ11週間かかるとレンウィック氏は推計している。 この予定表を基にすると、法案通過は2月後半になると予想される。ただし、法制過程を今開始すればの話だ。 投票用紙の選択肢を、2016年の国民投票における「離脱」か「残留」かの2択ではなくし、複数の選択肢を含めるよう下院が要求した場合、かかる時間はもっとずっと長くなると、レンウィック氏は付け加える。 2016年の国民投票でEU残留派として活動したトニー・ブレア元首相は、2度目の国民投票が議会の膠着状態を解消する可能性があると主張する 何を問うのか あり得る選択肢の範囲からどんな質問を選ぶかは、最終的には英議会の決定に委ねられる。 離脱協定の最終合意に国民投票を求める「People’s Vote (人民の投票)」運動の見解では、テリーザ・メイ首相の離脱協定とEU残留のどちらかを選ぶのが推奨される選択肢だが、投票参加者に3つの選択肢から選ばせる可能性も除外しないという。 再び国民投票が実施されるなら、投票用紙に「残留」の選択肢はあるべきでなく、メイ首相の離脱協定か、合意なしでのEU離脱かの二者択一であるべきとの主張もある。 他の選択肢もある。デイヴィッド・キャメロン内閣で運輸相や国際開発相、メイ内閣で教育相や女性・平等担当相を歴任し、2度目の国民投票を支持しているジャスティーン・グリーニング氏は以前、3つの選択肢を求めた――。 複数の選択肢がある場合、下院はどんな投票制度を使うかも決定する必要がある。たとえば、選択肢を1つ選ぶのか、望ましいほうから順番をつけるのか、というように。 選挙管理委員会は、提案された質問を試験し、それらが「明白に、単純に、そして中立に」示されていると確認する必要もある。 選挙運動を行う公認団体の選定も必要だ。 選挙管理委員会はそれから、国民投票の参加方法を有権者に情報提供する必要がある。また、全国で開票担当者の確保も必要だ。 これらの準備が終わると、選挙運動期間が始まる。運動期間は、通常4週間続く。そしてやっと、投票そのものが実施される。 ジャスティーン・グリーニング氏は2度目の国民投票案を支持し、国民には3つの選択肢が与えられるべきだと主張する 選管はBBCニュースに対し、2000年制定の政党、選挙、国民投票法で定められている法案通過から投票当日までの全ての手順には、最短でも10週間かかると説明した。 このことから、法案通過と選挙過程の両方が、イギリスがEUを離脱する予定期日である2019年3月29日までに終わる可能性は極めて低いと示唆される。 発表から10日での国民投票 しかし、非常に厳しい時期内に国民投票を実施した前例が他国にないわけではない。 3年前、ギリシャは1週間ほどの準備期間で国民投票をとりまとめた。有権者はこの国民投票で、同国の経済危機に対する国際債権団の救済案を否決した。 しかし、国民投票をあまりに早急に実施してしまうと、「通常の手続きに従っていない」との印象を与え、有権者が最終結果を非合法なものとみてしまう可能性があると、レンウィック氏は語る。 たとえば、2015年のギリシャと似た準備期間で国民投票をすると、郵送による投票を受け付けたり、投票用紙に書かれる質問を評価したりする十分な時間の確保が許されないことになる。 リスボン条約50条で定められた期間の延長 イギリスはEUに対し、EU基本条約(リスボン条約)第50条で定められた離脱交渉期間を延長するよう求める可能性もある。リスボン条約は、メイ首相が第50条を発動した2017年3月29日から2年間を、離脱条件の合意に必要な期間として定めている。この期間が延長されれば、新たな国民投票を実施するための時間が増える。 しかし、英ケンブリッジ大学で欧州法を研究するキャスリン・バーナード教授によると、2019年3月29日という離脱期限を延長するあらゆる試案には、他のEU加盟27カ国の全会一致での支持が必要になる。 EUは、イギリスの離脱延期を認める可能性があると示唆している。ただし、たとえば総選挙もしくは新たな国民投票が実施されるなど、政局が変化した場合のみだという。すでに合意された離脱協定について、単に再交渉するための追加時間の確保は認められない。 また、期間延長にはイギリス議会の同意も必要になる。 <関連記事> さらに欧州司法裁判所(ECJ)は先に、イギリスは他国の承認を得ずにリスボン条約第50条の発動を完全に取り消す権限を持つとの判断を下した。 しかしこれは、ブレグジットの過程全体を中止できるという意味だ。単に延期するという意味ではない。 なので結局、イギリスが2度目の国民投票実施を望むなら、まずは第50条で定められた離脱期間の延長を模索することになるだろう。 そして、投票の結果に従って、イギリスは投票後に第50条の発動を撤回するかどうか決められる。 イギリスのEU離脱予定日後に国民投票を実施するのも代替案かもしれない。しかし、この案はかなり現実的な困難を引き起こしかねない。特に、既に離脱したにもかかわらず、イギリス国民がEUの一員であり続ける選択をした場合には。 (英語記事 Brexit: How could another referendum on leaving the EU work?) トニー・ブレア元首相は、イギリスのEU離脱をめぐる行き詰まりを打開するため、2度目の国民投票を実施すべきだと主張しています。しかし、2度目の国民投票を実施するためには、多くの課題があります。 まず、2度目の国民投票を実施するための法律を制定する必要があります。この法律には、投票のルールや選挙運動のルールなどが定められます。2016年の国民投票では、投票日の7カ月前に関連法案が議決されましたが、今回はもっと早い法制化が可能なのでしょうか? 次に、2度目の国民投票で何を問うのかを決める必要があります。2016年の国民投票では、「離脱」と「残留」の2択でしたが、今回は複数の選択肢を含めることも検討されています。 また、2度目の国民投票を実施するための費用も問題です。2016年の国民投票では、約1億2,000万ポンド(約170億円)の費用がかかりました。 さらに、2度目の国民投票を実施した場合、イギリスのEU離脱が遅れる可能性があります。イギリスは2019年3月29日にEUを離脱する予定ですが、2度目の国民投票を実施した場合、この期限が延長される可能性があります。 このように、2度目の国民投票を実施するためには、多くの課題があります。しかし、ブレア元首相は、2度目の国民投票が議会の膠着状態を解消する可能性があると主張しています。 イングランドWTBメイは2分間で2つのトライを決めた 前回大会で1次リーグ敗退の屈辱を味わったイングランドにとっては、3大会ぶりの準決勝進出。 26日に横浜で開かれる準決勝で、大会3連覇を狙う世界王者ニュージーランドと対戦する。ニュージーランドはこの日、準々決勝の2試合目でアイルランドを破って4強入りした。 イングランドは3勝無敗(1試合は雨天引き分け)で1次リーグC組を1位突破。一方、オーストラリアは、D組を3勝1敗で2位通過していた。 イングランドは1次リーグ最終戦が台風の影響で中止となり、5日以来2週間ぶりの試合だった。たっぷりと休養を取った一方、すぐに本来の動きを発揮できるのか不安視する声もあったが、無用の心配だった。 トライですぐ逆転 先制点はオーストラリアが挙げた。 前半11分、イングランドが危険なハイタックルの反則を犯すと、オーストラリアのSOクリスチャン・リアリーファノがペナルティゴール決めた。 しかし、イングランドの反撃は早かった。 前半17分、イングランドは右サイドから左サイドへと大きくパスをつなぎ、最後はWTBジョニー・メイが左サイドに飛びこんで逆転。SOオウエン・ファレルがコンバージョンキックを決めた。 その3分後、メイが再びトライを決める。オーストラリアのパスをインターセプトしたCTBヘンリー・スレイドが駆け上がり、前方にゴロのキックを蹴り出した。それをメイがつかみ、またも左サイドに滑り込んだ。 コンバージョンキックも決まり、イングランドは14-3とリードを広げた。この日、キッカーのファレルは抜群の安定性を見せた。 トライ狙わず確実に得点 前半25分、イングランドは自陣ゴールから10メートル足らずの場所で反則を犯す。オーストラリアはこの好機に、迷わずペナルティキックを選択。トライに固執せず着実に点差を詰める、決勝トーナメントらしい戦術をとった。 これをリアリーファノが確実に決め、6-14に点差を縮めた。 イングランドは前半29分、ファレルが相手反則から約30メートルのペナルティゴールを成功させた。 しかし前半終了間際、オーストラリアのリアリーファノもペナルティゴールを決め返し、9-17の8点差でハーフタイムを迎えた。 猛追を予感させたが 1次リーグの試合では後半に得点を集中させ、スロースターターぶりを見せたオーストラリアは、この日も後半、猛追を予感させる見事な動きから再始動した。 後半2分、WTBマリカ・コロイベティが見事なスピードとステップでディフェンスをかわすと、一気にゴールエリアまで駆け込んだ。 コンバージョンキックも成功。1点差に詰め寄った。 しかし、イングランドは落ち着きを失わず、自分たちのペースを乱さなかった。 イングランドのPRシンクラーのトライは、反撃ムードのオーストラリアにとって痛手となった 後半5分、パスを受けたPRカイル・シンクラーが相手ディフェンスラインのすき間を突破し、ゴール中央部分にトライ。コンバージョンキックも決め、再び8点差に戻した。 後半10分にはファレルがゴールポスト正面からペナルティゴールに成功。リードを27-16に広げた。 勝負決めた攻防 一方、オーストラリアは後半18分、ゴール目前のマイボールのスクラムから波状攻撃を展開。フォワード陣の突進でゴール2メートルまで迫る場面もあったが、イングランドは体を張って押し戻し続け、ついにはボールを奪うことに成功した。 オーストラリアにとっては大きなチャンスを逃した場面だった。これで気落ちしたのか、オーストラリアは以降、見せ場をほとんど作れなかった。 反対にイングランドは、後半25分と33分に、ファレルがこの試合3つ目と4つ目のペナルティゴールをともに成功させ、オーストラリアを突き放した。 後半35分には、オーストラリアが左に放った長いパスをイングランドのWTBアントニー・ワトソンがインターセプトし、ゴールまで駆け上がってダメ押しのトライを決めた。 オーストラリアは後半37分、コロイベティが再び快足を飛ばし、ディフェンスを振り切ってゴールエリアまで駆け込んだ。しかし、その前のプレーでパスがスローフォワードの反則と判断され、トライは無効になった。 直後、試合終了の鐘が鳴った。 <関連記事> イングランドのエディ・ジョウンズ監督は試合後、「最初の20分間は相手にボールを75%支配されていたが、選手たちは見事に粘った。うまく守り、流れを取り戻した」と選手たちを称えた。 さらに、「後半、相手が反撃してきて、『かかってこい』となったが、うまく対応できた」と振り返った。 「準決勝進出に、みんなすごく盛り上がっている。まだ最高潮になっていないので、その状態にどうやってたどりつくかが課題だ」 21歳のイングランドのFLカリーは終始素晴らしい動きを見せ続けた この試合の最優秀選手:トム・カリー(イングランド) この試合の最優秀選手には、16回のタックルをするなど、終始見事なプレーを見せたイングランドのFLトム・カリーが選ばれた。 (英語関連記事 England beat Australia to make semis) イングランドは、26日に横浜で行われる準決勝で、大会3連覇を狙う世界王者ニュージーランドと対戦する。イングランドは、オーストラリアとの準々決勝で、前半に2トライを挙げてリードを広げ、後半はオーストラリアの猛追を振り切って27-19で勝利した。 このワクチンは複数の動物実験で、安全性や、効果的な免疫反応を引き起こすことが示されている。 今回の第1段階の後には、6000人を対象とした別の臨床試験が今年10月に予定されている。 インペリアル・コレッジ・ロンドンのチームは、2021年の早い時期からイギリスや海外でワクチンを配布できるようにしたいとしている。 <関連記事> 世界中では約120のワクチンの開発が進められている。英オックスフォード大学の専門家たちはすでに臨床試験を開始している。 新しいアプローチ 多くの従来のワクチンは、弱体化させたウイルスや改変したウイルスなどがもとになっている。しかし今回のワクチンは新しいアプローチに基づいたもので、遺伝子のRNA(リボ核酸)を使う。 筋肉に注射すると、RNAは自己増殖し、新型ウイルスの表面にみられるスパイクタンパク質のコピーをつくるよう、体内の細胞に指示を出す。 この方法で、COVID-19(新型ウイルスによる感染症)を発症することなく新型ウイルスを認識して戦うための免疫システムを訓練できるという。 シャトック教授は、「我々はゼロからワクチンを製造し、わずか数カ月で臨床試験に持ち込むことができた」と述べた。 「我々のアプローチがうまくいって、ワクチンがこの病気を効果的に防御できれば、将来的なアウトブレイク(大流行)への対応方法に革命をもたらす可能性がある」 主任研究員のカトリーナ・ポロック博士は、ワクチンの効果に期待している この研究の主任研究員、カトリーナ・ポロック博士は、「参加者に大きな免疫反応がみられるだろうと、慎重ながらも楽観的に感じられなかったら、私はこの臨床試験に取り組んでいなかっただろう」と付け加えた。 「前臨床データは非常に期待がもてるものだった。感染から保護しておきたい免疫反応である中和抗体応答は確認できているが、このワクチンを評価するにはまだ道のりは長い」 この研究は英政府から4100万ポンド(約54億5500万円)の資金提供を受けている。ほかにも500万ポンド(約6億6500万円)の寄付が寄せられている。 「ウイルスを倒すのに協力したくて志願」 金融業界で働くキャシーさん(39)は、インペリアル・コレッジ・ロンドンの臨床試験に参加している最初のボランティアの1人だ。 新型ウイルスとの戦いの一端を担いたくて志願したという。 「自分に何ができるのかあまりよく分かっていなかったけど、これが私にできることだったと分かった」 「それに、ワクチンができるまで日常に戻れる可能性は低いことを理解したことで、ワクチン開発の一端を担いたいと思った」 キャシーさんは、インペリアル・コレッジ・ロンドンの臨床試験に参加している最初のボランティア300人の1人 こうした中、ケンブリッジ公爵ウィリアム王子はオックスフォード大学の臨床試験に参加しているボランティアたちと、オックスフォード市内のチャーチル病院で面会した。 ウィリアム王子はボランティアに対し、「みなさん全員が参加しているのは、信じられないくらい胸が躍る、非常に待ち望まれたプロジェクトだ。だからみんなが心を奪われている」と述べた。 初日の被験者は1人だけ BBCのファーガス・ウォルシュ医療担当編集委員によると、すべての臨床試験は安全性のリスク軽減のために慎重に、ゆっくり開始される。オックスフォード大学で4月に臨床試験が開始された際には、初日に接種を受けたのはボランティア2人だけで、1週間以内に100人に接種された。 これに対して、インペリアル・コレッジ・ロンドンの臨床試験では初日には1人だけにワクチンを接種する。その後48時間ごとに3人に接種し、徐々に被験者を増やしていく。 また、1回分の投与量を使用するオックスフォード大学とは異なり、インペリアル・コレッジ・ロンドンの臨床試験では4週間の間隔をあけて、2回の接種を行うという。 シャトック教授らのチームは、慎重に進めている理由について、ワクチンに特段の安全性の懸念があるからではなく、単にアプローチが新しいからだと説明している。 新型コロナウイルス特集 感染対策 在宅勤務・隔離生活 (英語記事 Human trial of new coronavirus vaccine starts in UK) インペリアル・カレッジ・ロンドンは、新型コロナウイルスに対する新しいワクチンの第1段階の臨床試験を開始しました。このワクチンは、遺伝子のRNA(リボ核酸)を使用しており、筋肉に注射すると、自己増殖して新型ウイルスの表面にみられるスパイクタンパク質のコピーをつくるよう、体内の細胞に指示を出します。この方法で、COVID-19(新型ウイルスによる感染症)を発症することなく新型ウイルスを認識して戦うための免疫システムを訓練できるという。 このワクチンは複数の動物実験で、安全性や、効果的な免疫反応を引き起こすことが示されている。今回の第1段階の後には、6000人を対象とした別の臨床試験が今年10月に予定されている。インペリアル・カレッジ・ロンドンのチームは、2021年の早い時期からイギリスや海外でワクチンを配布できるようにしたいとしている。 文章がかなり短くなっているので、要約自体は成功であると思われます。しかし、うまく要約できていない箇所があるので、そこはプロンプトエンジニアリングの腕の見せ所であると考えています。 終わりに 今回はBigQuery MLのML.GENERATE_TEXT関数を使った要約について紹介させていただきました。今回は要約でしたが、プロンプト次第で様々なタスクが可能となります。 最後まで読んでいただき、ありがとうございました!
こんにちは。SCSKの田中です。 本記事ではUSiZEシェアードモデルのランサムウェア対策に向けたサービスを新しく検討するにあたり、ランサムウェアについて調べたことを記載します。 USiZEシェアードモデルに興味を持っていただけた方は以下のページをご参照ください。 運用付きの国産クラウドサービス│SCSK株式会社 VMwareベースで構築された、高可用性、高機密を備えた国産のプライベートクラウドです。ファシリティスタンダード最高レベルのティア4に適合する日本国内のデータセンター上で稼働し、お客様データの保護とデータ主権を確保します。 www.scsk.jp ランサムウェアとは ランサムウェアの定義についてIPAが公開している「ランサムウェア対策特設ページ」で以下の定義がされています。 ランサムウェアとは、『身代金』と『Software(ソフトウェア)』を組み合わせた造語です。 感染したパソコンに特定の制限をかけ、その制限の解除と引き換えに金銭を要求する挙動から、 このような不正プログラムがランサムウェアと呼ばれています。 IPA「ランサムウェア対策特設ページ」 から引用 ランサムウェアのタイプについて ランサムウェアには大きく分けて2種類のタイプがあります。 ランサムウェアのタイプ 制限をかける対象 攻撃を受けたファイルが暗号化され、開けなくなるタイプ 画像や文書等のファイル 端末のスクリーンがロックされ、操作ができないようにタイプ 端末のOSなど どちらも制限解除と引き換えに身代金等の対価を要求する画面を表示します。 画面の表示方法は、テキストやブラウザ画面、画像など、ファイル形式やメッセージの内容は様々なものが確認されています。 現在、主流となっているランサムウェアはファイル暗号化型です。 ランサムウェアがファイル暗号化するまでの大まかな流れは以下の通りです。 また最近は暗号化をせずにデータの公開と身代金等の対価を要求する「ノーウェアランサム」と呼ばれるタイプが観測されています。 暗号化の手間を省くことができるというメリットがあります。 ランサムウェアの感染経路 ランサムウェアの感染経路はVPN機器からの侵入が63件で62%、 リモートデスクトップからの侵入が19件で18%を占めます。 警察庁「令サイバー空間をめぐる脅威の情勢等」 内、令和4年におけるサイバー空間をめぐる脅威の情勢等について図表6(CSV)参照 VPN機器へのサイバー攻撃では、認証に利用するVPNの情報や、VPNの脆弱性が悪用されます。 例①不正に入手したVPNのアカウントの認証情報を使い、ネットワークや組織内部に侵入を図ります。 例②VPNの脆弱性を攻撃し内部に侵入します。安全なはずのVPNが攻撃の侵入口になってしまいます。 最近(2023年)のランサムウェアに関する流れ 近年、様々な企業でランサムウェアによる被害が確認されています。企業・団体等におけるランサムウェア被害として、 令和4年に都道府県警察から警察庁に報告のあった件数は以下の推移であり、令和2年下半期以降、右肩上がりで増加しています。 警察庁「令サイバー空間をめぐる脅威の情勢等」 内令和4年におけるサイバー空間をめぐる脅威の情勢等について図表1(CSV)参照 こうした被害発生件数の増加などもあってか、 IPAの「情報セキュリティ10大脅威」 の組織編にて2021年度から2023年度まで3年連続して1位となっております。 このことからランサムウェアが大きな脅威と感じられており、各企業でランサムウェアの対策が重要視されていることがわかります。 2021 年 2022 年 2023 年 1位 ランサムウェアによる被害 ランサムウェアによる被害 ランサムウェアによる被害 2位 標的型攻撃による機密情報の窃取 標的型攻撃による機密情報の窃取 サプライチェーンの弱点を悪用した攻撃 3位 テレワーク等のニューノーマルな働き方を狙った攻撃 サプライチェーンの弱点を悪用した攻撃 標的型攻撃による機密情報の窃取 ランサムウェアに感染しないようにするためにはどうしたらよいか – ユーザ側 ユーザ側でとれる対策と予防策については以下のものがあります。 フィッシングメールなど、侵入時に使用される攻撃手法を理解し、騙されないようにする。 不審なメールやリンクを安易にクリックしない。 所属組織のセキュリティポリシーを順守し、ソフトウェアを最新の状態に保つ トレンドマイクロ 脅威解説-ランサムウェア から引用 ランサムウェアに感染しないようにするためにはどうしたらよいか – 管理者側 管理者側でとれる対策と予防策については以下のものがあります。 エンドポイントやサーバには総合的なセキュリティソフトを導入する メールサーバにおいて攻撃メールを検出するソリューションを導入する 外部への不正なネットワーク通信・接続を検出するソリューションを導入する ネットワーク内部の監視と不審な挙動を可視化するためのソリューションを導入する セキュリティポリシーを策定し、管理者権限の管理やシステムの脆弱性管理を適切に行う 3-2-1ルールに則り、データの冗長性を十分に担保できるようなバックアップポリシーを策定する インシデント対応体制を構築する 従業員に対するセキュリティ教育、注意喚起を実施する トレンドマイクロ 脅威解説-ランサムウェア から引用 3-2-1ルールは以下のルールのことを指します。 ルール① : データは少なくとも「3つ」のバックアップコピーを持つ ルール② : バックアップデータを「2種類」以上の異なる媒体に保存する ルール③ : データ保管先のうち「1つ」は物理的所在地が遠隔地にあるものを選定 万が一、ランサムウェアに感染してしまったら やってはいけないこと 1.再起動 感染が確認された端末を再起動すると、暗号化が進み被害が拡大する恐れがあります。 2.調査前の駆除 調査完了前に駆除されてしまうとランサムウェアの侵入経路などの情報が失われ、調査ができなくなる恐れがあります。 今後の感染予防策の見直しのためには調査が必要であり、調査を行う場合は、駆除の前に調査を行ってください。 3.駆除前のバックアップの取得 感染中にバックアップを取得することでバックアップデータの保管先で被害が拡大する恐れがあります。 必ずランサムウェアを駆除した後にバックアップを取得しましょう。 4.調査、駆除前のバックアップデータによる復元 調査完了前に復元されると前述2.と同様に調査に必要な情報が失われ、調査ができなくなる恐れがあります。 また感染中時点のバックアップデータにより復元されると再度感染する恐れがあります。 5.専門家や警察へ相談せずに身代金を払う 身代金を支払っても暗号化の解除がされるとは限りません。また1度払うことでその後も繰り返し、狙われる恐れがあります。 そのため専門家や警察に相談することが重要です。 やるべきこと 1.ネットワークから遮断 感染が確認された端末はネットワークから遮断する必要があります。 これによってネットワーク上の他の端末に感染が広がるのを防ぎます。 2.ランサムウェアの種類を特定&駆除 ランサムウェアの種類によっては解除ツールが配布されていたり、駆除できる場合があります。 また適切な解除・復号ツールを探すためにもランサムウェアの種類を特定することが重要になります。 ただし駆除されてしまうとランサムウェアの侵入経路や攻撃情報などの調査を行ったができなくなる恐れがあります。 そのため、調査を行う場合は、駆除の前に調査を行ってください。 3.データを復元 復号ツールは「ID Ransomware」や「No More Ransom」で探すことができるほか、トレンドマイクロ株式会社やマカフィーなどのセキュリティベンダーでもランサムウェアに対応した復号ツールを配布しています。 また定期的にバックアップを取得することで感染前の状態に復元できます。 4.感染予防策の見直し 繰り返し標的にされることを避けるために、感染経路となるセキュリティの穴を塞ぐことが重要です。 よって使用しているネットワーク機器・システムの脆弱性、社内のアクセスログ監視体制や対応フローを見直す必要があります。 終わりに USiZEシェアードモデルではランサムウェアの攻撃に備えた新規サービスの開発中です。 サービスの詳細な情報が決まりましたら、こちらで発表したいと思います。 最後まで読んでいただきありがとうございました。 参考資料 IPA「ランサムウェア対策特設ページ」 ランサムウェア対策特設ページ | 情報セキュリティ | IPA 独立行政法人 情報処理推進機構 情報処理推進機構(IPA)の「ランサムウェア対策特設ページ」に関する情報です。 www.ipa.go.jp IPA「情報セキュリティ10大脅威」 情報セキュリティ10大脅威 | 情報セキュリティ | IPA 独立行政法人 情報処理推進機構 情報処理推進機構(IPA)の「情報セキュリティ10大脅威」に関する情報です。 www.ipa.go.jp 警察庁「サイバー空間をめぐる脅威の情勢等」 サイバー空間をめぐる脅威の情勢等|警察庁Webサイト www.npa.go.jp トレンドマイクロ「VPN、サイバー攻撃被害に共通するセキュリティの注意点」 VPN、サイバー攻撃被害に共通するセキュリティの注意点 | トレンドマイクロ VPN機器へのサイバー攻撃に起因する被害が続いています。ランサムウェア被害では、その多くがVPN機器が侵入の起点になっているとの調査もあります。これらの攻撃により、結果的に事業停止といった事態に追い込まれた組織もあり、注意が必要です。VPN機器のセキュリティ対策を解説します。 www.trendmicro.com トレンドマイクロ「脅威解説-ランサムウェア」 ランサムウェア | トレンドマイクロ トレンドマイクロのセキュリティエキスパートが解説するランサムウェアについてのページです。ランサムウェアの概要、攻撃の手法と特徴、対策と予防、当社ソリューションをご紹介します。ランサムウェアとは、マルウェアの一種で、感染したコンピュータをロックしたり、ファイルを暗号化したりすることによって使用不能にしたのち、元に戻すこと... www.trendmicro.com
こんにちは、SCSK 池田です。 2024年が始まり、あっという間に半月が経ってしまい、時の速さに恐怖を覚えつつも、今年も新しいことを仕掛けていこうと考えている今日この頃です。 さて1月17日に、 LifeKeeperのサイトを新しくしました! ※クリックすると新サイトに移動します。 1.これまでのサイトの課題と改善 昨年8月頃からサイト刷新プロジェクトがスタートし、まずは旧サイトの問題点をひとつずつ整理し、それぞれをどのように変えていくことで改善に繋がるかを議論していきました。 旧サイトの主な課題 新サイトでの改善 1 文字ばかりで解りづらい イメージ図を活用することで解りやすく 2 LifeKeeper自体の価値が説明できていない LifeKeeperの価値を解りやすく訴求 3 「お悩み」の解決策が判らない お悩みをCaseで別け、各々を解りやすく解説 4 SCSKの強みが判りづらい SCSKの強みである、パブリッククラウドや各ミドルウェアの専任部隊の存在によるトータルな提案力を訴求 5 導入事例が文字のみで解りづらい 写真やシステム構成図を配置し、簡潔に解りやすく 旧サイト(左)と新サイト(右)で並べてみると、情報量が格段に増えていることと、イメージ図を多用しているので、解りやすさが増していることが一目瞭然ですね。 2.2種類のリーフレットも作成しました。 このタイミングでSCSKとしての初のLifeKeeperリーフレットを作成しました。 LifeKeeperの特徴や、SCSKの強みといった情報を簡潔に表現した内容となっています。 ※クリックするとpdfが表示されます。 また昨年実施したZabbix製品をLifeKeeperで冗長することのメリットを訴求したリーフレットも作成しました。 Zabbix独自の可用性の仕組みだけではカバーできない箇所をLifeKeeperを使うことで解決することができる、と言った内容をご紹介しています。 ※クリックするとpdfが表示されます。 新サイトはこちらから SCSK HAクラスターソフトウェア「LifeKeeper」
こんにちは。SCSKのひるたんぬです。 2024年になり、早二週間が経過しました。時間の経過が早く感じるようになった今日このごろです。 早速余談なのですが、「人生の体感時間は年齢を重ねるごとに短くなる」と言われており、これを数式を用いて表現したものを「ジャネーの法則」と言うそうです。この法則に従い計算をすると、私はすでに人生の約75%を終えた¹ことになっているみたいですね…一日一日を大切に生きたいと思います。 ¹寿命については、厚生労働省が発表した「 令和4年簡易生命表 」より、男性の平均寿命である81.05歳で計算しています。計算ツールは こちら で提供されているものを使用しました。 ジャネーの法則について原著(と思われる文書)は こちら です。 フランス語ですが、興味のある方は是非読んでみてください。 本題に戻ります。今回は新人である私が、配属されてからおよそ3ヶ月ほどで取り組んだ「 AWSを活用したサービスの構築 」についてご紹介しようと思います。構築の際に用いた開発環境については、 前回の私の記事 にてご紹介しておりますので、よろしければご覧ください。 サービスの概要 今回は、「 各種サービスで設定値を控えておくパラメータシートを読み込み、そこからCloudFormationで用いる事のできるYAMLファイルを自動的に生成する 」という機能を構築しました。全体的なアーキテクチャを下図に示します。Cloud9上で開発を行い、構築したプログラムをCodeCommitへコミットしています。 利用者が設定値の記載されたパラメータシートをCodeCommitにコミットすると、最終的にCloudFormationテンプレートであるYAMLファイルがS3バケットに格納されるという流れです。 目的 成果物を作成するにあたり、指導員の方と相談していたところ、 現状では人手で作成したCloudFormationテンプレートで構築したリソースの値と、パラメータシートに記載された値を 人間が一つずつ手作業で比較・確認 しており、非効率かつ間違いが起きる 可能性がある というお話をいただき、それぞれの設定値を自動で比較するサービスを作ろう!ということになりました。 …ですが、その後の話し合いの中で、 そもそも CloudFormationのテンプレートをパラメータシートから自動で生成 してくれれば、このような問題は起こらない ということになり、先述したサービスを構築する運びとなりました。 これが実現することにより、AWSに精通している人はもちろんのこと、そこまで詳しくない人でも簡単にパラメータシートを作成できるようになることが期待されます。 パラメータシート自動生成プログラム このプログラムは下図に示すような流れで動作をします。それぞれの処理について、コードの一部²を交えながらご紹介します。 ²コードについては読みにくい箇所や非効率な処理を行っている箇所も多々あると思いますが、ご容赦ください。 パラメータシートの作成 まずは、パラメータシートを作成します。パラメータシートはリソースの種類ごとに作成する必要があります。 以下にLambda用 IAM – Role パラメータシートの一例を示します。 パラメータシートの読み込み 次にCodeCommitにコミットされたパラメータシートを確認します。パラメータシートのファイル名を基に、プログラム内でどのパラメータシートがどのリソースの内容を記述しているのかを判別します。判別を行ったら、パラメータシートから設定値を取り込みます。以下は、Excelで作成されたパラメータシートから設定値を取得し、リストに格納するプログラムです。 def convert(source_dir: str) -> list: book = openpyxl.load_workbook(source_dir) ws = book.worksheets[0] # Read Key and Value data_from_ps = [] # Read from row 1 for row in ws.rows: # list型として各行の値を格納 key = [] for col_num in range(len(row)): # 条件:値が存在するセルのみ取り込み(最終列を除く) if col_num != (len(row) - 1) and (row[col_num].value == None or row[col_num].value == ""): pass else: key.append(row[col_num].value) data_from_ps.append(key) book.close() return data_from_ps このリストをリソースに応じた辞書型に変換します。API Gateway – Accountの例を以下に示します。 class AWSApiGatewayAccount: def __init__(self): self.logical_id = "" self.type = "AWS::ApiGateway::Account" self.properties = { "CloudWatchRoleArn" : "" } # Setter def set_resource(self, data: list) -> None: for i in range(len(data)): # 各項目から設定項目・値を取得 setting_type = data[i][len(data[i])-2] setting_value = data[i][len(data[i])-1] # 項目に応じて値を格納 if not setting_value: continue if setting_type == "Logical ID": self.logical_id = setting_value elif setting_type == "CloudWatchRoleArn": self.properties["CloudWatchRoleArn"] = setting_value CloudFormationテンプレートの作成 設定値を取り込んだらCloudFormationテンプレートの形に変換し、YAMLファイルを生成します。 組み込み関数(!Sub xxx など)を認識させるためにはクォーテーションを外す必要があったのですが、ワイルドカードである「*」についてはクォーテーションを付けないとエラーが出てしまうという点に少々苦戦しました。 def output(source: dict, file_name: str) -> None: with open(file_name, "w") as f: yaml.dump(source, f, sort_keys=False) with open(file_name, "r") as f: contents = f.read() contents = contents.replace("'", "") # *はクォーテーションで括っていないとエラー contents = contents.replace(" *", " '*'") with open(file_name, "w") as f: f.write(contents) リソースの試験構築 YAMLファイルが生成されたら、このファイルを用いてCloudFormationでリソースの構築を実行し、正しく構築ができるか確認を行います。後段の作業のためにwaiterを設定し、構築が終わるまで待機します。 今回は”create_stack”関数を直接呼び出していますが、これではスタック作成に失敗した際に例外エラーとなるので、例外をキャッチする仕組みや、事前にテンプレートの妥当性を検証する “validate_template”関数 を挿入しても良いと思います。 def convert(yaml_path: str, stack_name: str) -> None: f = open(yaml_path, "r") template_body = f.read() f.close() cfn = boto3.client("cloudformation") response = cfn.create_stack( StackName=stack_name, TemplateBody=template_body, Capabilities=[ "CAPABILITY_NAMED_IAM", ], ) waiter = cfn.get_waiter("stack_create_complete") waiter.wait(StackName=stack_name) 上記コードでスタックを作成する関数「create_stack」の引数に「Capabilities」を追加しています。これは、IAMに関連するリソースを作成するために行っているものです。 正しく構築できたら、構築されたリソースにアクセスし、リソースの設定値を取得します。 # Get properties from AWS def get_resource(self, logical_resource_id: str, physical_resource_id: str, stack_name: str) -> None: # 構成情報の取得 client = boto3.client("apigateway") response = client.get_account() self.logical_id = logical_resource_id self.properties["CloudWatchRoleArn"] = response["cloudwatchRoleArn"] 取得したリソースの設定値と、パラメータシートの値を一つのクラスに集約します。 # 2つのリソースファイルの結果を一つにまとめる def summarize_properties(self, cfn_template: dict) -> dict: logical_ids = [self.logical_id, cfn_template.logical_id] summary = template.summary.Summary(logical_ids, self.type) if self.properties["CloudWatchRoleArn"]: key = summary.key_default.copy() key.append("CloudWatchRoleArn") value = [self.properties["CloudWatchRoleArn"], cfn_template.properties["CloudWatchRoleArn"]] summary.properties[tuple(key)] = value return summary 設定値の比較 取得した設定値と、パラメータシートの値が等しいかどうかを確認します。 def compare(all_resources: list) -> list: compared_resources = all_resources.copy() # 1つずつのリソースの値を比較 for resource in compared_resources: property = resource.properties # 1つずつの設定値を比較 for key, values in property.items(): # 設定値の型により処理を分岐 if type(values[0]) == list: for val in values: result = val[0] == val[1] val.append(result) else: # 設定値の確認 result = values[0] == values[1] values.append(result) property[key] = values return compared_resources ファイルの出力・最終処理 最終的に、生成したYAMLファイルと値の比較結果をまとめたExcelファイルをS3に出力した後に、試験構築したリソースを削除し、処理は完了です。 取り組んだ感想 今回は新人としての取り組みということで、LambdaやAPI Gatewayの一部のリソースのみを対象にしました。構築する際にそれぞれのCloudFormationのドキュメントを読み込んだので、CloudFormationの仕組みについて理解を深めることができたほか、リソースがどのように構築されるのか、それぞれがどのようなオプションを持っているのかを詳しく知ることができました。特にAPI Gatewayでは、異なるリソースで同じような設定項目がいくつもあったことが興味深かったです。 一方でリソースの値を取得するboto3の関数(get_xxxxx)の出力について、同じような項目でも表記方法が異なるものがあり、戸惑うことがありました。 例えばタグについて見てみると、IAMロールの情報を入手する”get_role”では、 'Tags' : [ { 'Key' : 'string' , 'Value' : 'string' }, ] となっているのに対して、Lambda関数の情報を入手する”get_function”では、 'Tags' : { 'string' : 'string' } となっており、KeyとValueの格納方法が異なっていることが分かります。また、API Gatewayのステージの情報を取得する”get_stage”では、 ' tags ' : { 'string' : 'string' } と、タグのKeyそのものが小文字で表記されています。 なぜ格納方法や表記が異なっているのかは私には分かりませんが、統一してくれると分かりやすくなるのではないかなぁと感じました。 get_role - Boto3 1.34.6 documentation boto3.amazonaws.com get_function - Boto3 1.34.6 documentation boto3.amazonaws.com get_stage - Boto3 1.34.6 documentation boto3.amazonaws.com 今後は、最初の工程であるパラメータシートの作成をより分かりやすく改良していき、そして他のリソースについても対応できるように拡張させていきたいなと考えております。 最後までご覧いただき、ありがとうございました!