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つ目と４つ目のペナルティゴールをともに成功させ、オーストラリアを突き放した。 後半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%を占めます。 警察庁「令サイバー空間をめぐる脅威の情勢等」 内、令和４年におけるサイバー空間をめぐる脅威の情勢等について図表６(CSV)参照 VPN機器へのサイバー攻撃では、認証に利用するVPNの情報や、VPNの脆弱性が悪用されます。 例①不正に入手したVPNのアカウントの認証情報を使い、ネットワークや組織内部に侵入を図ります。 例②VPNの脆弱性を攻撃し内部に侵入します。安全なはずのVPNが攻撃の侵入口になってしまいます。   最近(2023年)のランサムウェアに関する流れ 近年、様々な企業でランサムウェアによる被害が確認されています。企業・団体等におけるランサムウェア被害として、 令和4年に都道府県警察から警察庁に報告のあった件数は以下の推移であり、令和2年下半期以降、右肩上がりで増加しています。 警察庁「令サイバー空間をめぐる脅威の情勢等」 内令和４年におけるサイバー空間をめぐる脅威の情勢等について図表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のサイトを新しくしました！ ※クリックすると新サイトに移動します。 １．これまでのサイトの課題と改善 昨年8月頃からサイト刷新プロジェクトがスタートし、まずは旧サイトの問題点をひとつずつ整理し、それぞれをどのように変えていくことで改善に繋がるかを議論していきました。   旧サイトの主な課題 新サイトでの改善 1 文字ばかりで解りづらい   イメージ図を活用することで解りやすく 2 LifeKeeper自体の価値が説明できていない LifeKeeperの価値を解りやすく訴求 3 「お悩み」の解決策が判らない         お悩みをCaseで別け、各々を解りやすく解説 4 SCSKの強みが判りづらい               SCSKの強みである、パブリッククラウドや各ミドルウェアの専任部隊の存在によるトータルな提案力を訴求 5 導入事例が文字のみで解りづらい         写真やシステム構成図を配置し、簡潔に解りやすく   旧サイト（左）と新サイト（右）で並べてみると、情報量が格段に増えていることと、イメージ図を多用しているので、解りやすさが増していることが一目瞭然ですね。 ２．2種類のリーフレットも作成しました。 このタイミングでSCSKとしての初のLifeKeeperリーフレットを作成しました。 LifeKeeperの特徴や、SCSKの強みといった情報を簡潔に表現した内容となっています。 ※クリックするとpdfが表示されます。 また昨年実施したZabbix製品をLifeKeeperで冗長することのメリットを訴求したリーフレットも作成しました。 Zabbix独自の可用性の仕組みだけではカバーできない箇所をLifeKeeperを使うことで解決することができる、と言った内容をご紹介しています。 ※クリックするとpdfが表示されます。   新サイトはこちらから 　 SCSK ＨＡクラスターソフトウェア「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 今後は、最初の工程であるパラメータシートの作成をより分かりやすく改良していき、そして他のリソースについても対応できるように拡張させていきたいなと考えております。 最後までご覧いただき、ありがとうございました！

こんにちは、広野です。 React アプリに Amazon Bedrock に問い合わせる画面をつくってみたのでコードを紹介します。よくある生成系 AI チャットボットのように、回答文が作成されながら表示されるやつです。↓ アーキテクチャ 生成系 AI の基盤モデルには、Amazon Bedrock の Anthropic Claude 2.1 を使用しています。 Amazon Bedrock に問い合わせるのは AWS Lambda 関数 (Node.js 20) です。 AWS Lambda 関数は関数 URL を持たせており、React アプリから直接呼び出します。 AWS Lambda 関数からのレスポンスはレスポンスストリーミング対応にしています。それにより、Amazon Bedrock が回答を作成しつつ、レスポンスを画面に表示できるようにしています。Amazon Bedrock を呼び出す API はレスポンスストリーミング対応のInvokeModelWithResponseStreamCommand を使用しています。 補足ですが、React アプリから AWS Lambda 関数 URL を認証付きで呼び出す構成は以下参考記事の構成にしています。本記事では説明を割愛します。 やってみたら面倒くさい、React アプリからの Amazon Cognito 認証付き AWS Lambda 関数 URL 呼出 Amazon Cognito 認証を施した React アプリから、認証済みユーザのみ AWS Lambda 関数を呼び出せるようにする React コードを紹介します。 blog.usize-tech.com 2024.01.15 AWS Lambda 関数コード AWS Lambda 関数に関数 URL を持たせる設定や、レスポンスストリーミングを有効にする設定は以下 AWS 公式ドキュメントを参照ください。この点において難しいことはありません。 Lambda 関数 URL の作成と管理 - AWS Lambda Lambda 関数の URL を設定して、他の AWS のサービスとの統合を必要とせずに、HTTP エンドポイントを Lambda 関数に割り当てます。 docs.aws.amazon.com ストリームレスポンスに Lambda 関数を設定する - AWS Lambda レスポンスをストリーミングする Lambda 関数を作成します。 docs.aws.amazon.com 難しいのは関数コードです。 invokeModelWithStreamResponseCommand の API が Amazon Bedrock からのレスポンスを chunk 分割された状態で受け取るので、chunk ごとに React アプリへのレスポンス用ストリーム responseStream に放り込んで (write) います。レスポンスは Blob なので、途中で人が読み取れるテキストデータに変換する処理が入っています。 const { BedrockRuntimeClient, InvokeModelWithResponseStreamCommand } = require("@aws-sdk/client-bedrock-runtime"); const bedrock = new BedrockRuntimeClient({region: "ap-northeast-1"}); exports.handler = awslambda.streamifyResponse(async (event, responseStream, _context) => { try { console.log((JSON.parse(event.body)).prompt); const prompt = (JSON.parse(event.body)).prompt; if (prompt == '') { responseStream.write("No prompt"); responseStream.end(); } const enclosed_prompt = "\n\nHuman: " + prompt + "\n\nAssistant:"; const body = { "prompt": enclosed_prompt, "max_tokens_to_sample": 3000, "temperature": 0.5, "top_k": 250, "top_p": 1, "stop_sequences": ["\n\nHuman:"], "anthropic_version": "bedrock-2023-05-31" }; const input = { modelId: 'anthropic.claude-v2:1', accept: 'application/json', contentType: 'application/json', body: JSON.stringify(body) }; const command = new InvokeModelWithResponseStreamCommand(input); const res = await bedrock.send(command); const actualStream = res.body.options.messageStream; const chunks = []; for await (const value of actualStream) { const jsonString = new TextDecoder().decode(value.body); const base64encoded = JSON.parse(jsonString).bytes; const decodedString = Buffer.from(base64encoded,'base64').toString(); try { const streamingCompletion = JSON.parse(decodedString).completion; chunks.push(streamingCompletion); responseStream.write(streamingCompletion); } catch (error) { console.error(error); responseStream.write(null); responseStream.end(); } } //log entire chunks 結合されたレスポンス。今後履歴データとしてDynamodBに放り込む予定 console.log("stream ended: ", chunks.join("")); responseStream.end(); } catch (error) { console.error(error); responseStream.write("error"); responseStream.end(); } }); Python を採用していない理由は、AWS 公式ドキュメントにもありますが AWS Lambda 関数がレスポンスストリーミングをネイティブにサポートしているランタイムが Node.js のみだからです。※執筆時点 Node.js のコードを ES2015 (ES6) 構文にしていない理由は、私が AWS Lambda 関数を AWS CloudFormation でデプロイしていることに起因しています。AWS CloudFormation で Node.js の Lambda 関数をデプロイすると Lambda 関数コードファイルの拡張子が .js になってしまうため、ES2015 を使用できない (CommonJS 一択になる) のです。まあ他の方法でデプロイしろよって話なのですが、CFn テンプレート一撃で全アプリ環境を作りたいのでそこにこだわっております・・・。 React コード React アプリ側は、Lambda 関数 URL を呼び出すために fetch を使用します。レスポンスストリーミング対応にするには fetch が良いのだとか。 AWS Lambda 関数 URL から chunk 分割されたレスポンスが送られてくるので、それを順次、直前の chunk と繋げて state に突っ込むだけの、非常に原始的なループのコードです。もっと簡単かつ効率的な処理になる SDK を AWS が開発してくれることを期待しております。SSR 対応フレームワーク限定になってしまうのかもですが。 //レスポンス表示用state const [response, setResponse] = useState(""); //送信したいプロンプト const body = { prompt: prompt }; //Lambda関数URL呼出 try { const res = await window.fetch( "https://xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.lambda-url.ap-northeast-1.on.aws", { method: 'POST', body: JSON.stringify(body), headers: signedRequest.headers //認証用の署名(説明割愛) } ); const reader = res.body.getReader(); const decoder = new TextDecoder(); const sleep = ms => new Promise(resolve => setTimeout(resolve, ms)); while (true) { const { value, done } = await reader.read(); if (done) break; const chunk = decoder.decode(value, { stream: true }); if (chunk) { setResponse(prevData => prevData + chunk); } await sleep(100); //100msごとに届いたchunkを処理(=画面更新) } } catch (error) { console.error('Error fetching:', error); } sleep のミリ秒数を調整することで、受け取ったレスポンス文章表示の流暢さを調整できます。 まとめ いかがでしたでしょうか。 レスポンスストリーミングの仕組みが未だ根本的に理解できていませんが、経験を積んで理解を深めたいと思います。今回は参考になるドキュメントが少なくて苦労しました。 本記事が皆様のお役に立てれば幸いです。

こんにちは。自称ネットワーク技術者の貝塚です。SCSKでAWSの内製化支援『 テクニカルエスコートサービス 』を担当しています。 業務でヤバいくらいお世話になっているひつじちゃんがVPCエンドポイントについての記事を書いていました。 Amazon VPC エンドポイントについて整理してみる VPC エンドポイントの役割について説明したいと思います。 blog.usize-tech.com 2023.12.10 ひつじちゃんリスペクト記事として、VPCエンドポイントに関する役立ちそうで役立たない豆知識を書きます。 問題 インターフェース型のエンドポイントの IPはプライベート となります。 ( Amazon VPC エンドポイントについて整理してみる より引用) とありますが、プライベートIPアドレスがつけられたエンドポイント(例えばSystems Manager用のインターフェース型エンドポイント)に、VPC内のEC2インスタンスなどがアクセスできているのはどうしてでしょうか？ 答え Route 53 Resolverが返すIPアドレスが書き換わっているから。 解説 Route 53 Resolverとは、Amazon Provided DNSなどとも呼ばれる、EC2インスタンスを作成したときにデフォルトで指定されているDNSのことです。 さて、AWSの各種サービスにアクセスするためのインターフェース型エンドポイントにはDNS名がついています。 たとえばec2messagesサービスの場合はこうです。 ec2messagesインターフェース型エンドポイントが ない VPCからこの名前を解決してみると以下のようになります。 [ec2-user@ip-10-32-1-157 ~]$ dig ec2messages.ap-northeast-1.amazonaws.com (略) ;; ANSWER SECTION: ec2messages.ap-northeast-1.amazonaws.com. 58 IN A 52.119.223.180 (略) グローバルIPアドレスが返ってきています。 ec2messagesインターフェース型エンドポイントが ある VPCから名前解決するとこうなります。 [ec2-user@ip-10-33-1-124 ~]$ dig ec2messages.ap-northeast-1.amazonaws.com (略) ;; ANSWER SECTION: ec2messages.ap-northeast-1.amazonaws.com. 32 IN A 10.33.1.68 (略) VPC内のIPアドレスが返ってきます。 このようにDNSの名前解決の仕組みによって、本来インターネット上にあるAWSのサービスエンドポイントを、利用者が意識することなくVPC内の通信にしてくれているわけです。 インターネットゲートウェイがなくてもとりあえずVPC内にssmとssmmessagesとec2messagesのエンドポイントを作っておけばSession ManagerでEC2インスタンスにログインできるようになる、とおまじないのように覚えている方の理解を深める一助になれば幸いです。 役に立たない豆知識 インターフェース型エンドポイントは、どこのVPCからの通信か、とか気にしてないので、たとえばVPCピアリングしたお隣のVPCにいるEC2インスタンスのhostsにこんな感じで書いてあげれば、お隣VPCのインスタンスにもSession Managerで接続できるようになります。 [ec2-user@ip-10-32-1-157 ~]$ cat /etc/hosts 127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 ::1 localhost6 localhost6.localdomain6 # Added for connection to VPC interface endpoints 10.33.1.68 ec2messages.ap-northeast-1.amazonaws.com 10.33.1.138 ssmmessages.ap-northeast-1.amazonaws.com 10.33.1.21 ssm.ap-northeast-1.amazonaws.com いちいちこれ設定するくらいなら各VPCにエンドポイント作った方が面倒がなくてよくない？というのはあります……。 それではご査収ください。

こんにちは、広野です。 AWS Lambda 関数 URL がサポートしているレスポンスストリーミングを使用したくて、React アプリから Amazon Cognito ID プール (フェデレーテッドアイデンティティ) の一時的なクレデンシャルを取得し IAM 認証付きの AWS Lambda 関数 URL を呼び出せるようにしようとしたところ、激ハマリしました。 やりたいことは↓コレなんですが、一時的なクレデンシャルを取得して以降の Lambda 関数 URL 呼出に関する AWS 公式情報が具体的なものがなく、ネット上の有志の方のブログ情報を見ても環境の違いやモジュールのバージョン違いのためそのままでは動かず、苦労しました。 認証情報の取得 - Amazon Cognito Amazon Cognito を使用して権限が制限されている一時的な認証情報をアプリケーションに提供し、ユーザーが AWS リソースにアクセスできるようにすることが可能です。このセクションでは、認証情報を取得する方法と、ID プールから Amazon Cognito ID を取得する方法について説明します。 docs.aws.amazon.com Lambda 関数 URL におけるセキュリティと認証モデル - AWS Lambda リソースベースのポリシーに加え AuthType パラメータを使用して、Lambda 関数 URL へのアクセスを保護および制限します。 docs.aws.amazon.com 以降、動いたコードなどを紹介します。 あらためて、やりたいこと React アプリに Amazon Cognito でユーザ認証する。 認証済みユーザに、AWS Lambda 関数 URL を呼び出せる権限を付与する。(AWS IAM ロールによる) React アプリから、AWS Lambda 関数 URL を呼び出す。 これにより、アプリの認証済みユーザだけが AWS Lambda 関数 URL を呼び出せることになるので、セキュアな仕組みを構築できます。AWS Lambda 関数 URL は CORS もサポートしていますし、アクセスが少なく重要度の低いビジネスロジックであれば API Gateway は不要になります。 (余談) 関数 URL は Amazon API Gateway と違って IPv6 もサポートしています。Amazon CloudWatch Logs に残した AWS Lambda 関数のログを見ると、アクセス元デバイスの IPv6 アドレスが残っていました。AWS WAF はアタッチできないのと、スロットリングとかはできないのでそういう要件が必要になると Amazon API Gateway と統合しないとです。 参考までに、同様の構成で「Amazon Cognito 認証済みユーザのみが Amazon S3 バケットに書き込める」構成を以下ブログに書いておりましたが、このときは AWS が Amazon S3 に書き込むための SDK を用意してくれていたので簡単でした。 AWS Amplify Storage を AWS CloudFormation でマニュアルセットアップする サーバーレス WEB アプリ (SPA) から、ファイルをバックエンドにアップロードして処理したいことがあります。AWS Amplify と連携させた Amazon S3 バケット「AWS Amplify Storage」を使用すると、アプリとセキュアに連動したストレージを簡単に作ることができます。 blog.usize-tech.com 2022.05.31 Amazon Cognito ID プールから払い出される IAM ロールに AWS Lambda 関数 URL を呼び出す権限をどのように付けるかは、以下に書いてあるように、”Action”: “lambda:InvokeFunctionUrl” を許可してあげれば OK なので簡単です。 Lambda 関数 URL におけるセキュリティと認証モデル - AWS Lambda リソースベースのポリシーに加え AuthType パラメータを使用して、Lambda 関数 URL へのアクセスを保護および制限します。 docs.aws.amazon.com 続いて AWS Lambda 関数 URL を呼び出す情報は以下に書いてあるんですが、「いや、聞きたいのはそんなことじゃなくてね・・・もちょっと具体的なコードを教えてくれない？」って思う内容でして。 Lambda 関数 URL の呼び出し - AWS Lambda ウェブブラウザ、curl、Postman、または任意の HTTP クライアントを使用して、専用の HTTP エンドポイントを介して Lambda 関数を呼び出します。 docs.aws.amazon.com ドキュメントを読んで何がわからないかと言うと。 関数 URL が AWS IAM 認証を使用する場合、リクエストには AWS Signature Version 4 (SigV4) による署名が必要。 って何？ ここについて、実用的な説明がないんですね。細かい、内部仕様？の説明はあるんですが、私の実力ではそれだけじゃコードに落とせなくて。Amazon S3 に書き込むときには、この部分を Wrap した SDK を AWS が用意してくれていたので署名について何も意識せずに済んでいたのです。 で、ネット上をめっちゃ調べて、何とか動くようになった React コードを紹介します。（前置き長っ） 動いた React コード 執筆時点の React モジュール環境は以下です。今後、バージョンアップ等で動かなくなる可能性大です。 react 18.2.0 aws-amplify 6.0.12 axios 1.6.5 @smithy/protocol-http 3.0.12 @smithy/signature-v4 2.0.19 @aws-crypto/sha256-universal 5.2.0 ちなみに本記事ではアプリ稼働環境に AWS Amplify Console は使っていませんが、Amplify 関連モジュールはあくまでもモジュールなので使えます。 import { fetchAuthSession } from 'aws-amplify/auth'; import { HttpRequest } from '@smithy/protocol-http'; import { Sha256 } from '@aws-crypto/sha256-universal'; import { SignatureV4 } from '@smithy/signature-v4'; import axios from 'axios'; const sample = async () => { //Lambda関数URLを指定 const apiUrl = new URL("https://xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.lambda-url.ap-northeast-1.on.aws"); //Cognito ID プールから一時的なクレデンシャル(IAMアクセスキー等)を取得 const { credentials } = await fetchAuthSession(); //このあたりからが、SigV4 署名をするコード。以下のパラメータは絶対必須。 const signer = new SignatureV4({ service: 'lambda', region: 'ap-northeast-1', credentials: { accessKeyId: credentials.accessKeyId, secretAccessKey: credentials.secretAccessKey, sessionToken: credentials.sessionToken }, sha256: Sha256 }); //Lambda関数に POST したいパラメータ const body = { test: 'test' }; //以下も変更不可。POSTの場合bodyを含めないとAWS側で署名をverifyしたときにエラーになる。 const httpRequest = new HttpRequest({ headers: { 'Content-Type': 'application/json', 'Host': apiUrl.hostname }, hostname: apiUrl.hostname, method: 'POST', protocol: 'https:', path: apiUrl.pathname, body: JSON.stringify(body) }); const signedRequest = await signer.sign(httpRequest); //axiosでLambda関数URLを呼び出す。改めてbodyに加え、署名済みのヘッダー情報を付加する。 const res = await axios.post( "https://xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.lambda-url.ap-northeast-1.on.aws", body, { headers: signedRequest.headers } ); //とりあえずレスポンス確認だけ console.log(res); }; 前提として、App.js 等に Amplify.configure で Amazon Cognito ユーザープールと ID プールの情報を定義できていないと、fetchAuthSession が機能しません。 Set up Amplify Auth - React - AWS Amplify Documentation Amplify uses Amazon Cognito as the main authentication provider. Learn how to handle user registration, authentication, account recovery and other operations. A... docs.amplify.aws ちなみに axios ではなく fetch を使う場合は以下の記述になります。axios と入れ替える部分だけ紹介します。AWS Lambda のストリームレスポンスを使用する場合は fetch でないと動作しないようです。 const res = await window.fetch( "https://xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.lambda-url.ap-northeast-1.on.aws", { method: 'POST', body: JSON.stringify(body), headers: signedRequest.headers } ); 紹介したコードには固定値が入ってしまっているので適宜修正ください。 まとめ いかがでしたでしょうか。 AWS Lambda 関数 URL を使えば Amazon API Gateway はいらなくなるぞー、と息巻いていたのですが、Amazon API Gateway の Cognito オーソライザーと同等の認証をしようとすると やたらめんどくさい w。AWS がそれ用の SDK を出してくれることを待っております・・・。 本記事が皆様のお役に立てれば幸いです。

Catoクラウドのモバイル接続では、接続できる端末を制限したい場合(例.会社支給の端末に限りたいなど)の機能として、 デバイス認証(Device Authentication)機能 があります。 指定した電子証明書(デバイス証明書、別名クライアント証明書)がインストールされている端末からのみ、Catoクラウドへの接続を許可する 機能で、Catoクライアントが対応するすべてのOS(※)にて利用可能です。 ※ Windows, macOS, iOS(iPhone/iPad), Android, Linux デバイス認証は多くのお客様で利用いただいている機能ですが、導入時の注意点がいくつかあります。そこで、この記事ではデバイス認証の概要と設定の流れ、各OSでの注意点などをご紹介します。 前提と制約 Catoクラウドのデバイス認証には、以下の前提および制約がありますので、ご留意ください。 前提 デバイス認証機能は、Catoクライアントでの接続時に、その端末にインポートされているデバイス証明書(クライアント証明書)が、Catoの管理画面(CMA)にアップロードされている認証局証明書(CA証明書)で、検証(Verify)できるかどうかを判定し、OKであれば接続を許可する機能です。 Catoクラウドでの制約 以下は2024年1月時点の仕様です。Catoクラウドは毎週機能拡張されているため、以下の内容についても、今後機能強化される可能性があります。 ユーザまたはデバイスと証明書の紐づけ情報は保持していません。このため、 同じデバイス証明書を複数ユーザ・複数端末が利用していても、認証OK となります。 証明書失効リスト(CRL)には対応していません。 認証局にて対象のデバイス証明書を失効させても、Catoクラウドのデバイス認証機能には影響せず、認証OKとなります。 端末がSocketの配下にいるとき(=Catoクライアントによるユーザ認証が行われないとき)には、デバイス認証機能による証明書確認は行われません。 Catoクラウドにアップロードできる認証局証明書(CA証明書)の上限は5つです。6つ以上の認証局を利用することはできません。 サポートされている認証局証明書(CA証明書)の最大ファイルサイズは4096byteです。 サポートされているデバイス証明書(CRTファイル)の最大ファイルサイズは2048byteです。 ※ .p12ファイルのサイズではなく、その元となる.crtファイルの制限です デバイス証明書の準備 まずは、認証に使用するデバイス証明書(=クライアント証明書)を準備します。 証明書の発行方法 証明書の発行方法は、大きく分けて2つあります。 自前の認証局から証明書を発行する 証明書発行サービスを利用する 1. 自前の認証局から発行する 社内のActive DirectoryにてADCS(Active Directory Certificate Services)機能を使って発行する方法や、OpenSSLを利用しプライベート認証局を構築して発行する方法などがあります。 安価に構築可能ですが、認証局の管理・運用を自分で行う必要があります。 2. 証明書発行サービスを利用する 有償のサービスを利用する方法です。「クライアント証明書発行サービス」などで検索するといくつかのサービスが見つかります。提供元で認証局を管理しており、利用者は管理画面からの簡単な操作でデバイス証明書を発行できるサービスです。利用者が認証局を管理しなくて良いため、手軽に利用できます。 サービス選定のポイントは、認証局がセキュアに管理されている、信頼できるサービス提供元を選ぶこと、また、提供元によって価格体系が異なる(証明書×費用、ユーザ数×費用、等)ため、必要な証明書の数と費用感を比較検討することです。 なお、Catoクラウドでは前述のとおり、ユーザとデバイスの紐づけや、失効リストに対応していないため、証明書発行サービスの機能を十分には生かせない点をご了承ください。 各端末へのデバイス証明書配布 デバイス証明書が準備できたら、各端末へ配布し、インポートします。 配布方法は様々ですが、端末が多い場合の配布手段として、端末管理システムやMDM経由で配布する、Active Directoryからグループポリシーで適用するなどの方法があります。 また、OSごとにインポート時の注意点がありますので、以下にご説明します。 全OS共通の準備 端末へ配布する デバイス証明書は .p12形式 で準備します。OSバージョンによってはインポートパスワードが必須なものがあるため、 インポートパスワードを設定 しておきます。 Windowsの注意点 Catoクライアントはデバイス認証の際、「ローカル コンピューター > 個人」にある証明書を参照します。このため 証明書をインポートする際は必ず、保存場所に「ローカル コンピューター」を、証明書ストアに「個人」を指定 してください。 MacOSの注意点 対象のデバイス証明書が、 キーチェーンアクセスの「ログイン」 にインポートされている必要があります。 インポート後、以下の画面例のように「証明書が信頼されていない」旨の警告が表示される場合には、証明書をダブルクリックし、信頼する設定に変更してください。 また、Catoクライアントでの接続時、クライアントからキーチェーンへのアクセスを許可するかどうか、確認画面が表示されますので、アクセスを許可してください。 なお、.p12ファイルのインポート時、パスワードの入力画面が繰り返されインポートできない場合、以下をご確認ください。 .p12ファイルにインポートパスワードが正しく設定されているか。 ※パスワードなしの.p12がインポートできなかった事例があります .p12ファイルをOpenSSL3系で作成している場合、legacyオプションを付与して再作成し、改善するか。 ※OpenSSL3系のデフォルト設定で作成した.p12ファイルが、MacOS13でインポートできなかった事例があります iOS(iPhone/iPad)の注意点 iPhone/iPadに直接証明書をインストールせずに、MDM等で作成した 構成プロファイルで証明書とVPN設定を配布することが必須 です。詳細は以下の記事をご参照ください。 【Catoクラウド】iPhoneでのデバイス証明書認証 Androidの注意点 OSバージョンによって表記が異なりますが、以下が注意点です。 デバイス証明書のインポート時に選択肢が出た場合は「VPNとアプリユーザ証明書」を選択する デバイス証明書が、設定 >セキュリティ > 暗号化と認証情報 > ユーザ認証情報 にインポートされていること、「VPNとアプリ用」になっていることを確認する 証明書が認識されていれば、Catoクライアントの接続時に、利用する証明書の選択画面が出るので、該当の証明書を選択する なお、証明書のインポート自体に失敗する場合には、.p12ファイルにインポートパスワードが正しく設定されているかをご確認ください。 ※パスワードなしの.p12がインポートできなかった事例があります Linuxの注意点 初回接続時のみ、以下のコマンドでデバイス証明書をインポートします。その後は通常どおり接続してください。 cato-sdp import-cert <.p12ファイルの場所> Catoクラウド側の設定 端末側の準備ができたら、Catoの管理画面(CMA)から、デバイス証明書認証の設定を行います。 CA証明書のアップロード CMAに、デバイス証明書を検証(Verify)するCA証明書をアップロードします。 アップロードは、CMA の Access > Client Access > Device Authentication の箇所で行います。「New」ボタンを押し、任意の名前を指定の上、CA証明書をアップロードします。 なお、ここでは デバイス証明書を署名したCAの証明書をアップロードする 必要があります。つまり、デバイス証明書が中間CAから発行されている場合には中間CA証明書、そうでない場合にはルートCA証明書になります。 証明書の発行元を確認したい際は、Windowsの場合、「コンピューター証明書の管理」から「個人」を開き、対象のデバイス証明書の「証明のパス」を参照します。階層の一番下が証明書で、そのひとつ上が発行元の証明機関です。 以下の図の例1は、中間CAが存在し、中間CAからデバイス証明書が発行されている例です。この場合、CMAには中間CA証明書をアップロードします。例2はルートCAから発行されており、ルートCA証明書をアップロードする例です。 証明書認証のテスト 接続テストを行うにあたり、デバイス証明書認証の設定を全体に適用すると影響が大きいため、 まずは接続テストを実施するユーザのみに適用 することをおすすめします。 CMA の Access > Users で、テストを行うユーザを選択します。 User Configuration > Device Authentication で、「Override account Device Authentication settings」にチェックを入れ、証明書認証をテストしたいOSを選択し「Save」します。この設定で、このユーザのみにデバイス証明書認証を有効化できます。 設定を保存したら、対象のユーザにて、デバイス証明書をインポートした端末でのCatoクライアント接続をテストします。 デバイス証明書での認証に成功すると、CMAのEventsにて、Event Type Connectivity に以下のようなログが記録されます。通常の接続情報に加えて、証明書有効期限と証明書情報が表示されます。 Catoクライアントでエラーが表示され接続できない場合には、このあとの「トラブルシュート」の項目をご参照ください。 証明書認証の本番設定 テストにて問題がなければ、CMA の Access > Client Access > Device Authentication にて、全ユーザへ設定を適用します。 なお、デバイス証明書による認証は、上記 Device Authentication でのOSごとの適用の他に、Client Connectivity Policy にて、他の条件と組み合わせてより細かな設定も可能 です。Client Connectivity Policy については本記事の最後にて補足します。 トラブルシュート デバイス証明書認証を有効化した後、Catoクライアントにて接続エラーが表示される場合は、以下をご参照ください。 ※2023年12月時点のCatoクライアントバージョンでの確認内容です なお、問題の切り分けとして、デバイス証明書認証を無効化し、正常に接続できるかどうかをご確認ください。無効化しても接続できない場合は、原因が証明書関連ではないと考えられます。 Windowsクライアントのエラー Device certificate error. No matching certificate found. Please contact you network administrator. 端末内の、ローカル コンピューター > 個人 に証明書が存在しません。「コンピューター証明書の管理」から「個人」に対象のデバイス証明証が正しくインポートされているか確認してください。 Device certificate error. Please contact you network administrator. デバイス証明書は存在するものの、CA証明書での検証に失敗しています。「コンピューター証明書の管理」から「個人」に対象のデバイス証明証が正しくインポートされていること、またCMAにアップロードしたCA証明書と正しく紐づいていることをご確認ください。 MacOSクライアントのエラー Failed to authenticate with Certificate. デバイス証明書が認識されていない、またはCA証明書で検証できない状態です。以下の点をご確認ください。 キーチェーンアクセスの「ログイン」に、対象のデバイス証明書がインポートされていること そのデバイス証明書が信頼されていること CatoクライアントからキーチェーンへのアクセスがOS内で許可されていること デバイス証明書と、CMA上のCA証明書が正しく紐づいていること iOSクライアントのエラー 下記記事の「トラブルシュート」をご参照ください。 【Catoクラウド】iPhoneでのデバイス証明書認証 Androidクライアントのエラー 赤文字で「C=JP, ST=XXX, O=XXX …」といった、CAのSubject Name情報が表示される。 デバイス証明書が認識されていない、またはCA証明書で検証できない状態です。以下の点をご確認ください。 デバイス証明書が 設定 >セキュリティ > 暗号化と認証情報 > ユーザ認証情報 にインポートされていること ※設定の項目名はAndroidのバージョンや端末によって異なります 上記の証明書が「VPNとアプリ用」になっていること Catoクライアントでのアクセス時に、その証明書を選択したこと (拒否していないこと) デバイス証明書と、CMA上のCA証明書が正しく紐づいていること Linuxクライアントのエラー Certificate error. [C=JP, ST=XXX, O=XXX …] デバイス証明書が認識されていない、またはCA証明書で検証できない状態です。以下の点をご確認ください。 接続前にデバイス証明書のインポート (cato-sdp import-cert …) を行っていること デバイス証明書と、CMA上のCA証明書が正しく紐づいていること 上記を確認後も接続不可の場合、一度認証情報をリセットするため、CLIより 「–reset-cred」を付けて接続をお試しください。 補足情報  Client Connectivity Policy について Client Connectivity Policyは、端末が指定の条件に一致している場合にのみCatoクライアントの接続を許可する(または拒否する)機能です。 本記事にてご説明したデバイス認証(Device Authentication)と機能が重複していますが、Client Connectivity Policyでは、 クライアント証明書の有無やOSの他、指定のセキュリティソフトの指定のバージョンが動作しているかどうか、Real time protectionが有効になっているか等のDevice Posture条件を細かく指定 できます。また、ポリシーの適用範囲として、全体・ユーザ個人の他、ユーザグループを指定することが可能です。 デバイス認証(Device Authentication)では設定したい条件を満たせない場合、Client Connectivity Policyで実現可能かご検討ください。 まとめ デバイス証明書認証は、いざ導入しようとすると、デバイスにうまくインポートできなかったり、Cato固有の制約にひっかかったりすることが多いため、PoC時の検証をおすすめしております。 デバイス証明書以外にも、Catoクラウドでお困りの際は、ぜひ当社FAQサイト「よくあるご質問」もご参照ください。 よくあるご質問 | Cato Cloud ケイトクラウド - SCSK Cato SASE Cloud Platform. powered by SCSK cato-scsk.dga.jp

こんにちは。自称ネットワークエンジニアの貝塚です。SCSKでAWSの内製化支援『 テクニカルエスコートサービス 』を担当しています。 先日、EC2 Amazon Linuxを使って検証をしておりまして、付け焼刃でネットワーク周りの設定ファイルを変更してOSを再起動したところ、インスタンスに接続できなくなりました。その時回復するためにやったことを本稿にメモとして残したいと思います。 まずは状況整理 使用していたOSはAmazon Linux 2023。AWSの公式AMIから作成したものです。 OSにはセッションマネージャーを使用してログインしていました。OSのIPアドレス周りの設定を変更しOSの再起動をしたところ、セッションマネージャーで接続ができなくなりました。細かい切り分けはしていませんが、状況的にインスタンス側のネットワークの問題と断定してよいでしょうから、sshなどIPアドレスを使ってログインする手段はいずれもダメだと考えられます。 EC2シリアルコンソール 何か手段なかったか……？と考えていたところ、そういえばシリアルコンソールの機能があったな、と思い当たります。でも普段使っているEC2ではシリアルコンソールの接続ボタンは押せなかったような記憶が……などと考えつつ、藁にもすがる思いで画面を開きます。 Nitroかあ……。実はNitro Systemというのにあまり興味がなく、どのインスタンスタイプがNitroなのか全く知りません。まずは調べるところから。 インスタンスタイプ - Amazon Elastic Compute Cloud Amazon EC2 では、コンピューティング、メモリ、ストレージ、ネットワークの能力が異なるさまざまなインスタンスタイプが提供されています。 docs.aws.amazon.com T3がNitroのようです。……よかった。どんな高額インスタンスが必要なのかドキドキしてしまいました。t2.microが好きすぎてT3すらほとんど使ったことありませんでした。早速インスタンスタイプを変更して起動。今度は接続ボタンが押せるようになっていて、一安心。コンソールを流れていく文字列を眺めていると、cloud-initが169.254.169.254に接続できません、みたいなログが出ています。やっぱりネットワーク設定が悪かったんだな、さてどこをどう直せばいいのだろうな…… あー……パスワード設定してあるユーザ、いないですね。 ルートボリュームのデタッチ＆アタッチ レスキューモード(エマージェンシーモード？)で起動すればいける気がするけれど、GRUB起動メニューにアクセスしなければいけないはずで、シリアルコンソールの画面を起動したときにはとっくにOS起動処理が始まっていたから、EC2ではGRUB起動メニューにアクセスできないのかなあ。あ、そういえばEC2ではルートボリュームをデタッチして別のインスタンスにアタッチできると聞いたことがあるような。 少々検索し、こちらの記事にたどり着きます。 起動できないEC2インスタンスをレスキューインスタンスを使って修復する blog.k-bushi.com まさに探していた情報そのものです。レスキュー用のLinuxインスタンスを準備し、早速試します。 インスタンス一覧から起動しなくなったインスタンスをチェックし、「ストレージ」タブからルートボリュームを特定。 ルートボリュームを選択し、アクション→ボリュームのデタッチを実行。 レスキュー用インスタンスにアタッチするために再度そのボリュームを選択し、アクション→ボリュームのアタッチを選択。 一覧からレスキュー用インスタンスを選択。デバイス名はデフォルトで表示されていた/dev/sdfとしました。(スクリーンショットに表示されているインフォメーションの通り、レスキュー用インスタンスのOS側では/dev/xvdf に変更されていました) レスキュー用インスタンスにデバイスが認識されていることを確認し、mount。 [ec2-user@ip-10-32-1-157 ~]$ sudo lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS xvda 202:0 0 8G 0 disk ├─xvda1 202:1 0 8G 0 part / ├─xvda127 259:0 0 1M 0 part └─xvda128 259:1 0 10M 0 part /boot/efi xvdf 202:80 0 8G 0 disk ├─xvdf1 202:81 0 8G 0 part ├─xvdf127 259:2 0 1M 0 part └─xvdf128 259:3 0 10M 0 part [ec2-user@ip-10-32-1-157 ~]$ [ec2-user@ip-10-32-1-157 ~]$ sudo mount -t xfs /dev/xvdf1 /mnt/ mount: /mnt: wrong fs type, bad option, bad superblock on /dev/xvdf1, missing codepage or helper program, or other error. あれれ。だめですね。wrong fs type とか言われていますが、ファイルシステムはxfsで間違いないはず……。 またしばし検索……。 うん、これですね。 Change the UUID on a xfs file system Change the UUID on a xfs file system www.it3.be なるほど、そういえば、起動しなくなったインスタンスも、レスキュー用インスタンスも、同じAMIから作ったAmazon Linux 2023のインスタンスでした。/ のUUIDが同じだからエラーになったのですね。確認してみたところ、確かに同じUUIDでした。 [ec2-user@ip-10-32-1-157 ~]$ sudo lsblk --fs NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINTS xvda ├─xvda1 xfs / 439aed1d-715f-48fd-bfa0-0e5f1a23088b 6.4G 20% / ├─xvda127 └─xvda128 vfat FAT16 C86C-DC3E 8.7M 13% /boot/efi xvdf ├─xvdf1 xfs / 439aed1d-715f-48fd-bfa0-0e5f1a23088b ├─xvdf127 └─xvdf128 vfat FAT16 C86C-DC3E 上記記事の手順に従ってUUIDの変更を実施し、再びmount。 [ec2-user@ip-10-32-1-157 ~]$ sudo uuidgen 12e50054-6690-41a6-b532-e75946ba9c6b [ec2-user@ip-10-32-1-157 ~]$ sudo xfs_admin -U 12e50054-6690-41a6-b532-e75946ba9c6b /dev/xvdf1 Clearing log and setting UUID writing all SBs new UUID = 12e50054-6690-41a6-b532-e75946ba9c6b [ec2-user@ip-10-32-1-157 ~]$ [ec2-user@ip-10-32-1-157 ~]$ sudo mount -t xfs /dev/xvdf1 /mnt/rescue/ [ec2-user@ip-10-32-1-157 ~]$ [ec2-user@ip-10-32-1-157 ~]$ ls /mnt/rescue/ bin boot dev etc home lib lib64 local media mnt opt proc root run sbin srv sys tmp usr var OKですね！ 起動しなくなった原因のファイルを取り除き、umountした上で、今度はレスキュー用インスタンスからボリュームをデタッチします。そして再び起動しなくなったインスタンスにボリュームをアタッチ。ルートボリュームなのでデバイス名は /dev/xvda を指定します。 インスタンス起動！シリアルコンソールで起動を見届け…… grub> あれえ……。 そういえばすっかり読み流していましたが、先ほどの記事の末尾に Finallly, we can start digging into the content of the device mount on  /mnt  and do whatever was required. Perhaps, one note if this device will be moved back to the original EC2 instance do not forget to updat the  /mnt/etc/fstab  file with the updated UUID of this modified boot device. ※ Change the UUID on a xfs file system  より引用 UUIDが変わったから /etc/fstab の変更を忘れるなよって書いてありました。ドキュメントはよく読もう！ 再度、ルートボリュームをレスキュー用インスタンスにアタッチし、fstabを修正します。 今度こそ！ grub> あっれえ…。 その後、 AWS re:Postの関連しそうな記事 を参照し、fstabのオプションを変更してファイルシステムのチェックを無効にしたり、XFSのリペアをしたりいろいろ試しますが、相変わらずgrubのプロンプトになってしまいます。ひとつ試すたびにボリュームの付け替えをしているので、ひたすら面倒です。 最終的には、fstab以外におそらくgrubの設定ファイルにもUUIDが含まれていそうな気がする！だけどもう調べるの面倒くさい！となって、一度変更したファイルシステムのUUIDを元のUUIDに戻してあげることでOSの起動に成功したのでした。 教訓 パスワードを設定したOSユーザ作っておくの大事。(でも軽い検証のときはそのひと手間も面倒ですよね) UUID被りを避けるため、レスキュー用インスタンスはレスキューされるインスタンスとは異なるOSバージョンにしておくと面倒がない。(でも違うディストリビューションとかにしちゃうと操作感が違って面倒くさいしねえ) ドキュメントはよく読もう(でもちゃんと読んでもうまくいかないことはある) 後日談 その1 後日確認したら、grubの設定ファイルにUUIDが書かれていました。検証してないけれど、ここも追加で書き換えれば起動できていたはず。 $ sudo cat /boot/loader/entries/e8e94dc055b04f2484035693fbb04115-6.1.56-82.125.amzn2023.x86_64.conf title Amazon Linux (6.1.56-82.125.amzn2023.x86_64) 2023 version 6.1.56-82.125.amzn2023.x86_64 linux /boot/vmlinuz-6.1.56-82.125.amzn2023.x86_64 initrd /boot/initramfs-6.1.56-82.125.amzn2023.x86_64.img options root=UUID=439aed1d-715f-48fd-bfa0-0e5f1a23088b ro console=tty0 console=ttyS0,115200n8 nvme_core.io_timeout=4294967295 rd.emergency=poweroff rd.shell=0 selinux=1 security=selinux quiet grub_users $grub_users grub_arg --unrestricted grub_class amzn その2 この記事を書くために資料整理していたら、先述のルートボリュームのデタッチ・アタッチを解説した記事から以下の記事へリンクが張られているのを発見しました。 Amazon EBSマウント時の「wrong fs type, bad option, bad superblock on…」というエラーを解決する方法を教えてください | DevelopersIO Amazon EBSマウント時にUUIDの重複エラーが発生した時の解決方法を紹介します。 dev.classmethod.jp 1. 一時的にマウントするために、UUIDの重複を無視する アタッチしたボリュームは一時的にマウントするためのものであり、本来のEC2にアタッチし直す場合は、このアプローチを採用します。 マウント時にUUIDの重複を無視するオプション( -o nouuid )を渡します。 ※ Amazon EBSマウント時の「wrong fs type, bad option, bad superblock on…」というエラーを解決する方法を教えてください より引用。 UUIDの重複を無視するオプションがあったようですね。もう少しだけ丁寧に調べていればこんな苦労しなくて済んだのに……(よくある) まとめ 疲れました。

こんにちは、SCSKでAWSの内製化支援『 テクニカルエスコートサービス 』を担当している貝塚です。 先日、AWS Network FirewallのアウトバウンドTLSインスペクション使ってみた記事を投稿しました。  AWS Network FirewallでアウトバウンドトラフィックをTLSインスペクションする AWS Network Firewallで、アウトバウンド(egress)のTLSインスペクション機能を検証しました。アウトバウンドTLSインスペクションにより、クライアントPC(社内)から外部のウェブサーバへのHTTPS通信の内容を検査することができるようになります。 blog.usize-tech.com 2023.12.27 アウトバウンド(Egress) TLS インスペクションを記事にしたのだから、以前からあるインバウンド(Ingress) TLS インスペクションも記事にしてしまおう、ということで、追加で検証してみました。 TLSインスペクションとは SSL/TLSで暗号化された通信内容をチェックする機能です。 HTTPSなどのSSL/TLSで保護された通信は、クライアント-サーバ間で通信内容が暗号化されているため、通常、中継するネットワークデバイスで通信内容をチェックすることができません。SSLサーバ証明書をうまく使って中継デバイスで通信内容をチェックできるようにしたのがTLSインスペクションです。 インバウンド(Ingress) TLSインスペクション インバウンド(AWSのドキュメントではIngressと呼ばれる)TLSインスペクションは、自サイトでTLSを用いて暗号化通信をしているウェブサーバ等を保護するために使用されます。たとえば自サイトでwww.example.comというサーバ証明書をインストールしたサイトを運営しているとしたら、Network Firewallにも同じwww.example.comの証明書をインストールしてやります。Network Firewallはウェブサーバに向かう通信を、そのサーバ証明書を用いて復号化し、検査した後に再びサーバ証明書を用いて暗号化して、何食わぬ顔でウェブサーバに転送します。 検査したい対象サーバのサーバ証明書を入手しなければ検査ができないので、必然的に自身の管理下にあるサーバのみが検査対象になります。 本稿でも、前の記事と同様、Network Firewallの基本的な設定については扱いません。Network Firewallのデプロイ、ファイアウォールポリシーの作成、ルールグループの作成などの基本的な設定手順については以下の記事などを参考にしてください。 AWS Network Firewallについて学んでみた！ AWS Network Firewallについて、学んだことをアウトプットしたいと思います。 blog.usize-tech.com 2023.12.24 アウトバウンド(Egress) TLSインスペクション アウトバウンド(AWSのドキュメントではEgressと呼ばれる)方向、つまり、自分たちの管理下にあるクライアントPCが、自分たちの管理下にないSSLサーバ証明書をインストールした外部のサーバと通信するときに通信内容を検査する機能です。こちらの機能の検証記事は下記をご覧ください。 AWS Network FirewallでアウトバウンドトラフィックをTLSインスペクションする AWS Network Firewallで、アウトバウンド(egress)のTLSインスペクション機能を検証しました。アウトバウンドTLSインスペクションにより、クライアントPC(社内)から外部のウェブサーバへのHTTPS通信の内容を検査することができるようになります。 blog.usize-tech.com 2023.12.27 Ingress TLSインスペクション設定の流れ Ingress TLSインスペクション機能検証のために実施した設定は以下の通りです。 ACMでサーバ証明書を作成する Network FirewallのTLS検査設定を作成する Network Firewallのファイアウォールポリシーを作成する Network Firewallをデプロイしてファイアウォールポリシーを関連付ける なお、既に作成済みのファイアウォールポリシーにTLS検査設定を追加することはできません。Network Firewallデプロイ時の流れで空のファイアウォールポリシーを作成することができますが、空のファイアウォールポリシーに後からTLS検査設定は追加できないので注意が必要です。 動作確認の流れ Ingress TLSインスペクションの動作確認で実施した内容は以下の通りです。 Network Firewallのルールグループに検証用のルールを追加する クライアントPCからHTTPSアクセスして挙動を確認する Network FirewallのAlertログを確認する Ingress TLSインスペクション設定 ACMでサーバ証明書を作成する まず、ACMで証明書を作成します。Network Firewallのドキュメントによると、 インポートでもACMからリクエストするのでもどちらでも問題ありません が、 自己署名証明書はサポートされていません 。 証明書の作成手順については、 AWSの公式ドキュメント やインターネット上の各種記事をご参照ください。 なお、今回は、ACMでリクエストして証明書を作成しました。 Network FirewallのTLS検査設定を作成する AWSマネジメントコンソール、ネットワークファイアウォールのTLS検査設定から「TLS検査設定を作成」をクリックします。 「インバウンド SSL/TLS 検査用のサーバー証明書」で、作成した証明書を選択します。証明書は複数追加できるようなので、今回は、複数のサイトをインスペクションできることを確認するために、ACMで作成した証明書をふたつ選択しました。 「TLS 検査設定の詳細」を埋めた後、「スコープ設定」で検査対象とする送信元/送信先IPとポートを指定します。なお、ここで指定した範囲に含まれるTLS通信が上で選択した証明書を使用 していない 場合、正常な通信ができなくなってしまうようなので、検査に必要な最小限の範囲を指定するようにしましょう。 以降の設定項目も適切に入力して、TLS検査設定を作成します。 Network Firewallのファイアウォールポリシーを作成する ファイアウォールポリシー作成時にTLS検査設定を指定します。 作成途中で「TLS検査設定を追加」というステップがありますので、先ほど作成したTLS検査設定を指定します。それ以外は通常のファイアウォールポリシー作成と同様の手順で、ファイアウォールポリシーの作成を完了させます。 Network Firewallをデプロイしてファイアウォールポリシーを関連付ける Network Firewallをデプロイし、前項で作成したファイアウォールポリシーを指定します。手順はNetwork Firewallのドキュメントなどをご参照ください。 動作確認 Network Firewallのルールグループに検証用のルールを追加する TLSインスペクションが行われることにより、HTTPSの通信はHTTP用のルールで検査できるようになっているはずです。今回の検証ではルールグループに、以下のSuricata互換ルールを追加しました。 drop http $EXTERNAL_NET any -> $HOME_NET 443 (msg:"Detected access to tcp port 443 /index.html"; http.uri; content:"index.html"; sid:1000102; rev:1;) alert http $EXTERNAL_NET any -> $HOME_NET 443 (msg:"Detected access to tcp port 443 /scsk.html"; http.uri; content:"scsk.html"; sid:1000111; rev:1;) pass http $EXTERNAL_NET any -> $HOME_NET 443 (http.uri; content:"scsk.html"; sid:1000112; rev:1;) alert tls $EXTERNAL_NET any -> $HOME_NET 443 (msg:"TLS: Can't inspect this"; sid:1000121; rev:1;) pass tls $EXTERNAL_NET any -> $HOME_NET 443 (sid:1000122; rev:1;) 1～3行目のルールで、HTTPのURIをチェックしてindex.htmlへのアクセスはドロップし、scsk.htmlへのアクセスはアラートログに出力した上で通信自体は許可するように設定しています。 4～5行目のルールは、TLSインスペクションが行われない事態を検出するために入れた念のためのルールです。HTTPS(TLS)通信だった場合にアラートログに出力した上で通信自体は許可するように設定しています。もし万が一HTTPS(TLS)通信に対してTLSインスペクションが行われなかった場合はこのルールにマッチするはずです。 クライアントPCからHTTPSアクセスして挙動を確認する クライアントPCからウェブサーバにHTTPSアクセスします。 今回、ウェブサーバは、自前で立てたHTTPサーバの前にELBを置き、前述のTLS検査設定で指定したものと同じ証明書を用いてHTTPS化しています。 /index.htmlにアクセスしてみます。想定通り、コンテンツは表示されません。 次に、/scsk.htmlにアクセスしてみます。こちらも想定通り、問題なくコンテンツを表示できました。TLSインスペクションが働き、HTTPをチェックするルールが適用されていることが確認できました。 念のため証明書を確認してみます。 アウトバウンドTLSインスペクションの時 とは違い、発行者(Issued By)がAmazonになっている、ACMでリクエストした何の変哲もない証明書です。 今回、TLS検査設定でふたつ証明書を指定しているので、もうひとつの証明書に対応したFQDNでも同じことを試しましたが、同様の結果になりました。複数の証明書を設定しても問題なく動作するようです。 Network FirewallのAlertログを確認する Network Firewallのアラートログを確認したところ、以下のログが出力されていました。意図通りにHTTPの内容をチェックし、URIに基づいて通信を制御できていることがログからも分かりました。 また、同じサーバ証明書をインストールした別の(IPアドレスが異なる)ウェブサーバにアクセスしたところ、以下のログが出力されました。スコープ設定で検査対象に含まれていない通信はNetwork Firewallで復号されずにTLSプロトコルと認識されて通過していったことが分かります。 まとめ Network FirewallのIngress TLS Inspectionについて、簡単な検証の結果をまとめてみました。 AWSのマネージドサービスを使って高度なネットワークセキュリティを確保したいというニーズはわりとあるのではないかと感じているので、今後もNetwork Firewallのノウハウを蓄積して記事にしていきたいと考えています。

2024年最新版の CSPM について解説します。 クラウドセキュリティの代表的なツールのひとつがCSPMです。クラウドセキュリティとは、クラウドコンピューティング環境（クラウドサービス）におけるユーザー、データ、アプリ、インフラストラクチャーを保護するために設計された一連のセキュリティポリシー、手順、ツール、テクノロジーを指します。 本記事では、クラウドサービスとは、Amazon Web Services (以下、AWS)、Microsoft Azure（以下、Azure）、Google Cloud Platform（以下、GCP）、Oracle Cloud Infrastructure（OCI）などに代表されるのIaaS/PaaS/SaaSの各サービスを意味します。 クラウドサービスプロバイダー（CSP）は、ベンダーとしてのAWS、Microsoft、Googleを意味します。グローバルにサービスを大規模で展開するクラウドサービスプロバイダーは、ハイパースケーラーと言われますが、この記事では、クラウドサービスプロバイダーとして表記します。 CSPMとは？ CSPMとは、 Cloud Security Posture Management （ クラウドセキュリティポスチャマネジメント ）で、日本語訳は「 クラウドセキュリティ態勢管理 」で、クラウドサービスのセキュリティ設定の状況を可視化し、不適切な設定や、コンプライアンス違反、脆弱性の有無などのチェックし、アドバイス、または設定変更を行うソリューションのことです。 具体的には、 AWS、Azure、GCPなどのIaaS/PaaSを中心としたクラウドサービスにおける設定不備やミスで発生する情報漏洩やサイバー攻撃などのインシデントに対し、セキュリティ設定やコンプライアンス監視を行い、セキュリティリスクを検出し、設定変更のアドバイスや、実際の設定変更を行うソリューションとなります 。 Posture（ポスチャ）とは、姿勢・態度を意味し、”態勢（たいせい）”として略されていますが、”状態”の方が理解しやすいかと思います。 エンドポイント端末のセキュリティ状態をチェックして、アクセス制限をする Device Posture （デバイスポスチャ）については、以前からありますが、クラウドサービスを対象としたCSPMを始め、それ以外にも、 Data Security Posture Management （DSPM）、 SaaS Security Posture Management （SSPM）、 API Security Posture Management （ASPM）、 Application Security Posture Management （ASPM）など管理対象を変えたSecurity Posture Management（ xSPM ）が次々と出現しています。   クラウドサービスのセキュリティ不備によるリスク Is The Cloud Secure Gartner offers recommendations for developing a cloud computing strategy and predictions for the future of cloud security. www.gartner.com 今から5年前（2019年）にアメリカ調査会社のガートナーが「 クラウドは安全か？ （Is the Cloud Secure?）」のレポートで予測した通り、昨年2023年だけでも不適切な設定による機密情報の漏えい（リスク）が数多く発生しました。 レポートには、クラウド予測に基づいて、以下の3点が予想されていました。 1. 2025年まで、パブリッククラウドの利用を管理できない組織の90%は、機密データを不適切に共有する。 2. 2024年まで、大半の企業はクラウドのセキュリティリスクを適切に測定することに苦慮し続けるだろう。 3. 2025年まで、クラウドのセキュリティ障害の99%は顧客の責任となる。 実際に、昨年2023年7月 トヨタ自動車 が同社の「T-Connect」「G-Link」サービス利用者の車両から収集した 約230万人分の個人データが、約10年間に渡って外部から閲覧できる状態 にあり、個人データの漏えいが発生したおそれのある事態が発覚（同日、個人情報保護委員会から指導を受け、再発防止策を公表） 企業規模の大小には関係なく、2023年10月には、若い世代を人気の位置情報共有アプリ「 NauNau 」で、 230万人以上のユーザー位置情報やチャットデータなどが外部から閲覧できる状態 になっており、データ漏えいのおそれがあった。 まさにクラウドサービス利用を適切に管理できない組織において、機密データが知らない間に不適切に共有（公開）され、そのことに気が付かずに長期間放置されていたことが明らかとなっています。不適切な共有は、今もなお数多く存在し、今後も同様のセキュリティインシデントは継続するものと思われます。 もちろん 責任は、クラウドサービス事業者ではなく、すべて利用者側 です。 ちなみに、一般企業だけではなく、自身がクラウドサービスプロバイダーである マイクロソフト でさえも、2023年9月にクラウドストレージ（Azure Storage）の設定ミスにより、同社の内部情報である、従業員の使用するパソコンのバックアップデータ、3万件以上のTeamsの会話履歴など 38TBのデータが外部からアクセス可能な状態になっていた ことも判明しています。   セキュリティ不備によるリスク発生の原因 クラウドサービスにおける 設定不備やミスの主な原因は、設定者の知識不足 です。 クラウドサービスは非常に複雑で、新しいサービスや機能が次々とリリースされていくため、そのスピードに設定者が追従することは困難です。 ひとつのクラウドサービスにおいても、最新の技術動向や仕様を正確に把握することが困難になっている上に、利用するクラウドサービスも、単一ではなく複数利用する（＝マルチクラウド）が今や当たり前となっており、 複数のクラウドサービスそれぞれの最新技術動向や仕様を正確に把握し、それぞれで設定不備やミスがないことを、人手でチェックするのは至難の業 となっています。 マルチクラウドの最大のメリットは、クラウドサービスプロバイダーによるロックインのリスクを低減することですが、特定ユースケースに最適な機能を提供するクラウドサービスプロバイダーを選択することで、機能面以外に、俊敏性・拡張性・弾力性などのメリットを享受することができ、全体システムとしての復元力や移行機会も得ることも可能となります。 単一クラウドサービス、AWSであれば、AWSのみを対象とするCSPMとして「AWS Security Hub」があります。 AWS Security Hubで十分という方もおられますが、クラウドサービスはAWSしか利用されていないのであれば、AWSの最新技術動向や仕様を把握し、AWS Security Hub、さらに、その他ツール（AWS Config 等）を活用し、セキュリティ設定やコンプライアンス監視を実施し、セキュリティリスクを検出した場合には、メール通知し、適切に設定変更を行うことも可能かと思います。 しかしながら、AWS以外にAzureを利用される場合は、同じように「Azure Security Center」、さらにGCPも利用される場合は「Security Command Center」と、次々とそれぞれクラウドサービスプロバイダーが提供するCSPMや各種ツールをカバーして行く必要があります。 クラウドサービスの利用や運用を、すべて外部の開発ベンダーに任せている場合も同じです。 その委託先の開発ベンダーは、最新の技術動向や仕様を正確に把握し、設定不備やミスがないことをツール等を利用して確認しているでしょうか？ クラウドサービスプロバイダーであるマイクロソフト自身でさえ設定ミスをし、外部から指摘されて初めて気が付く状況において、現実問題としては不可能だと言えるでしょう。   責任共有モデルの誤解 クラウドサービス利用する上の責任について最初に「 責任共有モデル 」というものが使われる場合が殆どです。 AWSにおける「 Shared Responsibility Model 」のことですが、マーケティング色の強い日本語訳「責任共有モデル」という言葉に訳されていますが、実際には責任の共有はしておらず、きちんと責任分界点を設けた「 責任分担モデル 」が正しい日本語訳といえます。 この「Shared Responsibility Model」の図を見てもらうと一目瞭然ですが、AWS側は一言でいうとインフラのみで、 セキュリティ設定の不備によるリスク発生率を考慮すると殆ど（=99%）は利用者側の責任 になります。 利用者は、AWSのインフラ（データセンターやハードウェア）が強固であるため、AWSを利用するだけで、セキュリティレベルが高くなる（高くなった）と勘違いをしている場合が多いのですが、実際には 99% の責任は利用者側に残ったままで、セキュリティレベルは、オンプレミスの時と何ら変わりません。 逆に、 簡単な設定でインターネット上にデータを共有（公開）できてしまうリスクはオンプレミスと比較すると非常に高くなっています 。 社外へ公開しているグローバルIPアドレス（WebサーバやFirewall）に対しては、年に数回（半年や四半期毎）は、脆弱性診断やペネトレーションテストを実施している企業は多いですが、同じようにクラウドサービスに対して、定期的に設定診断を実施している企業は殆ど存在しないのが現状です。 そのため、10年間以上に渡って不適切な共有を放置する事案が頻繁に発生しています。   CSPMの5つの機能 クラウドサービスのセキュリティ不備によるリスクを低減させるCSPMの主な機能としては、以下の5つとなります。 1. マルチクラウド対応 AWSだけではなく、Azure、GCPなどの複数のクラウドサービスプロバイダーをサポートしています。 マルチクラウド環境を1つの管理コンソールから管理することが可能で、単一クラウドにおいても、複数アカウントを管理コンソールから統一したポリシーにより一元的に管理することが可能となります。 2. 最新チェックルールによる確認 CSPMには、あらかじめチェックルールが準備されており、さらにルールは定期的に見直し（更新）や追加が行われます。セキュリティリスクを引き起こす設定不備やミスがあるかどうかは、このルールに基づいてチェックが行われます。 企業や組織ごとのセキュリティポリシーやコンプライアンス要件に合わせたカスタムルール設定などのカスタマイズも可能となっています。 3. 設定不備・脆弱性の検出・通知・修復 設定不備やミス、脆弱な箇所を識別し、リスクとなり得る設定や状態を自動で検出し、アラート通知を行うことができます。 「誰が、いつ、どのように」原因となる設定変更をしたのかも確認が可能となります。 インシデントを未然に防ぐとともに、適切な対応を促し、CSPMによっては設定を自動で修復する機能もあります。 4. 設定不備・脆弱性の可視化 セキュリティリスクやコンプライアンス違反の状況を具体的に、ダッシュボードやレポートとして可視化できます。これにより早期のリスク発見ができ、リスクの重要度から、対応の優先順位付けを行い、迅速に対応を行うことが可能になります。 5. グローバル標準のセキュリティコンプライアンスに対応 CSPMは、PCI DSS、HIPPA、GDPR、ISO/IEC 27017、NIST CSF、NIST SP 800-53、SOC 2 TYPE 2などの国際基準のセキュリティフレームワークとチェックルールが紐づけされています。 また、今後新しく施行されるルールにもいち早く対応を行うことが可能になります。 クラウドサービスを利用する上で、セキュリティ不備によるインシデント発生リスクを図るためのチェックシートを以下に示します。 単発でチェックするのではなく、継続的に実施できるのか？クラウドサービスの最新技術動向・仕様への追従だけではなく、セキュリティフレームワーク（各種規制）への対応も行えるのか？などが重要となります。   参考）クラウドセキュリティにおいて、CSPMを合わせてよく出現する言葉 様々なSecurity Posture Managementが出現していると前述しましたが、xSPMとしては以下があります。 ・ DSPM （Data Security Posture Management）：データセキュリティ態勢管理 ・ SSPM （SaaS Security Posture Management）：SaaSセキュリティ態勢管理 ・ ASPM （API Security Posture Management）：APIセキュリティ態勢管理 ・ ASPM （Application Security Posture Management）：アプリケーションセキュリティ態勢管理 ・ KSPM （Kubernetes Security Posture Management）：Kubernetesセキュリティ態勢管理 その他にも、CSPMと合わせてよく使われる言葉としては以下があります。CWPP、CIEM、CNAPPについては、別途改めて記事にする予定です。 ・ CIEM (Cloud Infrastructure Entitlement Management) ：クラウドサービスのアクセス権限の監視/管理 ・ CWPP （Cloud Workload Protection Platform）：コンテナやサーバレスをはじめとするクラウドワークロードの監視/保護 ・ CNAPP （Cloud Native Application Protection Platform）：CSPM/CIEM/CWPPを含むプラットフォーム。シーナップと呼ばれます。 ・ CASB （Cloud Access Security Broker）：クラウドサービスの利用を可視化/監視/適切なアクセス制限を実施。キャスビーと呼ばれます。 まとめ 企業がクラウドサービスによる真のメリットを享受するには、クラウドサービスを正しく理解し、システムインテグレータに丸投げせずに「自分たちで運転」できるエンジニアを自社内に増やしていく必要があると言われています。 企業規模にもよりますが、マルチクラウドすべてを自社で正しく理解するのは、要員リソースも含めて難しいため、不適切な設定や、コンプライアンス違反、脆弱性の有無などのチェックは、人手に頼るのではなく、CSPMなどツールによる自動化を行うことが最適解だと考えています。 https://www.soumu.go.jp/main_content/000843318.pdf 令和4年（2022年）10月31日に総務省から公表された「 クラウドサービス提供・利用における適切な設定に関するガイドライン 」のベストプラクティスにおいても「 ルールの文書化だけでなく、 SASE（Secure Access Service Edge）などのセキュリティゲートウェイを必ず通すことや、CSPM (Cloud Security Posture Management)などの管理部門が把握できる監視ツールを使用する ことなどの対策も併せて実施することを推奨する 」とあります。 重大なセキュリティインシデントが発生する前に、CSPMを検討されてはいかがでしょうか？ もしかすると、すでに長期間、機密データを不適切に共有し続けているかもしれません。 一方で、CSPMソリューション導入をいきなり検討するのではなく、脆弱性診断のようにまずはCSPMを利用したサービスを一度スポットでご利用されるのが良いのではないかと考えており、SCSKでは、Palo Alto Networks（パロアルトネットワークス）社のCSPM「Prisma Cloud」を採用したマネージドサービスを提供させていただいております。 「 マルチクラウド設定診断サービス with CSPM 」として、スポットでの診断サービス（30万円～）を提供しておりますので、まずは自社のクラウドサービスの脆弱性診断（＝クラウド設定診断）を実施されてみるのはいかがでしょうか？ 定期的（半年や四半期毎）にスポット診断を実施することも可能ですし、もちろん常時監視するサービスもご提供しております。 以下のサービス紹介ページに当社オリジナルの日本語での診断レポートサンプルもございますので、ご興味を持たれた方は、是非ダウンロードをお願いします。 マルチクラウド設定診断サービス with CSPM｜ SCSK株式会社 マルチクラウド環境のセキュリティ設定リスクを手軽に確認可能なスポット診断サービスです。独自の診断レポートが、運用上の設定ミスや設計不備、クラウド環境の仕様変更などで発生し得る問題を可視化し、セキュリティインシデントの早期発見に役立ちます。 www.scsk.jp