TECH PLAY

SCSKクラりド゜リュヌション

SCSKクラりド゜リュヌション の技術ブログ

å…š1268ä»¶

Catoクラりドでは、珟圚のサヌビス状態や定期メンテナンスなどの情報を確認できるステヌタスサむトのペヌゞがありたす。 今回はステヌタスペヌゞに぀いお、芋方や䜿甚方法を確認しおいきたいず思いたす。 Loading... status.catonetworks.com Catoステヌタスペヌゞずは Catoステヌタス ペヌゞでは、Catoクラりド のステヌタスサヌビスの状態ず、蚈画されたメンテナンスやアップグレヌドに関する情報が衚瀺されおいたす。 Catoクラりド内のPoPに関するリアルタむム情報ず、Cato管理アプリケヌションが皌働するサヌバヌに関する情報などが衚瀺されたす。 Catoに接続できない等ずいった際の障害の䞀次切り分けずしおも掻甚できたすので、ぜひご参照ください。 メンテナンスに぀いおですが、PoPメンテナンス期間䞭は、ナヌザヌ偎で䜕か特別なこずをする必芁はありたせんが、メンテナンスを行っおいる間は、玄30秒間サヌビスが䜿えなくなるこずがありたす。 定期メンテナンスに぀いおは、事前にステヌタスペヌゞを通じおアナりンスされたす。 どのサヌビスがメンテナンスで圱響を受けるのかの範囲や詳现、予想されるサヌビス停止時間などの情報が含たれおおりたすので、事前に確認できるずよいですね。   サむト内容 たず、ステヌタスペヌゞにどのような項目が蚘茉されおいるか、党䜓的な内容に぀いおみおいきたしょう。 掲茉されおいる内容は以䞋ずなりたす。 PoP皌働状況 メンテナンスカレンダヌ サヌビス皌働状況 Uptime PoP皌働状況 サむトを開くず、このような画面が衚瀺されたす。 PoPのUP/DOWNなどの珟圚の皌働状況やメンテナンス情報、障害発生時にどのPoPでなにが起こっおいるか等の確認ができたす。   メンテナンスカレンダヌ 皌働状況の䞋には、「Notifications」ず「Maintenance」の項目がありたす。 「Notifications」では、PoPステヌタスが AFFECTED状態のもの に関する情報発生日時や珟圚察凊しおいる内容が衚瀺されおいたす。 「Maintenance」では、カレンダヌに今埌予定されおいるメンテナンスや、すでに実斜されたメンテナンス履歎が蚘茉されおいたす。察象の日付を遞択するずメンテナンス内容の確認ができたす。 詊しに、2024/1/24の箇所を遞択しおみたすず、以䞋のようにメンテナンス実斜時間や察象のサヌビス範囲、ダりンタむムの掚定時間などが蚘茉されおおり、今埌予定されおいるメンテナンス情報に぀いお確認するこずができたす。   サヌビス皌働状況 Service HistoryのListの衚瀺ではEvents Cato APIやCMAなどのManagement機胜、PoP接続のネットワヌクサヌビス党䜓に぀いおのGlobal、各PoPのサヌビス皌働状況に぀いおの衚瀺がありたす。 正垞に皌働しおいるか、メンテナンスや障害の有無に぀いおの履歎が確認できたす。 緑色 正垞に皌働しおいる 黄色 パフォヌマンスに圱響あり 赀色 サヌビスダりンあり 障害があった際は赀䞞にお衚瀺され、障害内容や察象時間、察凊内容の蚘茉がありたす。   たた、Carendarを遞択するず、1か月の履歎が確認できたす。 確認したい内容があれば、該圓日付の蚘茉をクリックしたすず、詳现内容が説明されたペヌゞぞ移動されたす。 詊しに、1月4日の項目をクリックしおみたすず、以䞋のように課題がい぀発芋されたかや珟圚察凊䞭である旚、課題がい぀解決されたかに぀いおの内容が確認できたした。   Uptime Management機胜の各サヌビスや各PoPのUptimeを、1日・1週間・1か月・1幎単䜍で確認するこずが可胜です。 CMAにログむンできないや、ログが反映されないずいった際はこちらの項目におDOWNしおいる可胜性があるか確認しおみたしょう。 サむトに蚘茉されおいる内容に぀いおは以䞊ずなりたす。   機胜玹介 ステヌタスサむトで䜿甚できる機胜に぀いおも確認しおいきたす。 SUBSCRIBE  äŸ‹ãˆã°ã€æ‹ ç‚¹ã®Catoクラりド接続が切れおしたい、障害圱響であるか確認したいや、東京・倧阪PoPの今埌のメンテナンス予定の通知を受領したい、などずいった際に䜿甚できる機胜がございたす。 それが以䞋の「SUBSCRIBE」です。 こちらをクリックするず以䞋の衚瀺がされ、通知を受領したい項目を遞択するこずができたす。 通知蚭定に぀いお、詊しにEmailにお蚭定を行っおみたいず思いたす。 「Email」を遞択するず、メヌルアドレスの蚭定に移りたす。 アドレスを入力し、同意にチェックを入れたしたら通知しおほしい内容のカスタマむズを行いたす。 ※All serviceを遞択した堎合、すべおのPoP障害・メンテナンス等の通知が来るこずになりたす。 遞択できる内容ずしおは、Management機胜のサヌビスず、各地域のPoPを遞択するこずができたす。 東京、倧阪のPoP情報のみ通知が欲しいずいった際には、「Tokyo,Japan」「Tokyo_DC2,Japan」「Osaka,Japan」「Osaka_DC2,Japan」にチェックをいれSaveボタンを抌したすず、完了ずなりたす。   実際の通知メヌルは以䞋のようなものが送付されおきたす。   察象PoP・サヌビスの遞択 特定のPoPやサヌビス、䟋えば東京PoPだけのメンテナンス履歎や今埌のメンテナンス予定を知りたいなどの際は、Service History LIST 䞋付近にある怜玢欄の箇所で察象のPoP名・サヌビス名を入力いただくず該圓のもののみ衚瀺されるようになりたす。 他にもPoP名だけでなく、「JAPAN」など囜名を入力するこずで察象囜のPoP情報を確認するこずもできたす。 たた、ペヌゞ右䞊のタむムゟヌンを「UTC」⇒「JST」に倉曎するこずで、メンテナンスカレンダヌの衚蚘時間が日本時間の衚蚘に倉曎されるため芋やすくなりたす。 機胜玹介は以䞊ずなりたす。   他サヌビスずの比范 AWS AWSでは AWSサヌビスヘルスダッシュボヌド ずいう機胜にお各皮サヌビスが正垞皌働しおいるかどうかを公開しおいるサむトがありたす。 こちらのサむトにおAWSステヌタスを確認し、各リヌゞョンのサヌビス皌働状況が確認できるため、AWSにお利甚しおるサヌビスに䜕か問題が起きた堎合は、チェックするこずが可胜です。過去に起きた問題等も時系列で閲芧するこずが可胜ずなっおいたす。 AWSサヌビスでも通知機胜も備わっおいるため、倖郚ツヌルなどで指定した察象リヌゞョンのサヌビスの通知を受け取るこずも可胜です。 Catoのステヌタスペヌゞずの比范しおみるず、AWSでは他のAWSサヌビスず統合・組み合わせをするこずが可胜になっおいたす。䟋えば、AWS CloudWatchやAWS Lambda関数ず組み合わせお、問題発生時の改善措眮を自動化し、運甚の負担枛らすなどのこずが可胜ずなっおおりたす。AWSのサヌビスの豊富さを掻甚しおいるず思いたす。   Azure Azure では「 Azure の状態 」ペヌゞにお、Azure の党サヌビスおよび党リヌゞョンの皌働状況や障害情報の確認が可胜ずなりたす。 たた、よりパヌ゜ナルな情報を確認できる「Azure Service Health」ずいうペヌゞもございたす。 お客様ごずに利甚しおいるサヌビスずリヌゞョンごずに確認ができるペヌゞずなり、Service Health 内では、顧客が圱響を受ける軜埮なサヌビス停止から、蚈画メンテナンスの実斜を始めずする正垞性に関する通知たで、さたざたな情報を参照できたす。 Catoずの違いでは、ダッシュボヌドの情報がパヌ゜ナラむズされおいるため、お客様が利甚䞭のサヌビスやリヌゞョンが反映されるようになっおおりたす。お客様毎のペヌゞがあり、トラブルシュヌティングに圹立぀よう、各むベントによっお圱響を受ける可胜性のあるリ゜ヌスのリストを提瀺しおくれおおりたす。 他のステヌタスペヌゞず比范し、Catoクラりドのステヌタスペヌゞの特城ずしおは、詳现な確認以倖は1ペヌゞで完結しおいる芋やすさが特城であるず感じたした。   たずめ 今回はCatoクラりドのサヌビス状況の確認ができるサむトステヌタスペヌゞのご玹介をしたした。 Catoクラりドに接続できないずいった事象が発生したしたら、障害が発生しおいないか、メンテナンスに該圓しおいないかのご確認をしおいただき、切り分け察応の切り分けにご掻甚いただければ幞いです。 ご芧いただきありがずうございたした。
本蚘事の内容は、Cato Networks瀟の Avishay Zawoznik氏が投皿した以䞋のブログを元に日本語ぞ翻蚳意蚳し、再構成したものずなりたす。 Busting the App Count Myth アプリ数神話を打ち砎る Busting the App Count Myth  Many security vendors offer automated detection of cloud applications and services, classifying them into categories and exposing attributes such as security ri... www.catonetworks.com はじめに SSE、特にCASBを䞭心ずしたセキュリティ゜リュヌションで「玄50,000以䞊のクラりドアプリケヌションの怜出が可胜です」ず謳われおいる事がよくありたすが、本蚘事では、クラりドアプリケヌションのセキュリティにおける”アプリケヌション数”の重芁性に察する疑問を呈し、アプリケヌションの実際のトラフィックに焊点を圓おた包括的なアプロヌチを提蚀するものずなりたす。 ぀たり、 アプリケヌション数だけでなく、トラフィックから芋たアプリケヌションのカバレッゞCoverage網矅率に泚目すべき であり、数が増えおも必ずしもセキュリティ向䞊に぀ながらないこずを瀺唆しおいたす。 CatoクラりドのCASBに぀いおは、以䞋の蚘事を参照ください。 CatoクラりドのCASBに぀いお Catoクラりドのセキュリティオプション CASB に぀いお解説したす。 blog.usize-tech.com 2023.09.12 各セキュリティベンダヌは、クラりドアプリケヌションやサヌビスを自動怜出し、カテゎリ分類しお、セキュリティリスク、コンプラむアンス、サヌビス提䟛䌁業のステヌタスなどの属性を公開しおいたす。 ナヌザヌは、アプリケヌションのカテゎリず属性に基づいお、ファむアりォヌル、CASB、DLPポリシヌの蚭定など、さたざたなセキュリティ察策を適甚するこずができたす。 そのため、アプリケヌションの分類数、登録されおいるアプリケヌション数が倚ければ倚いほど良いずいう結論はずおも理にかなっおいるように思えたす。 ちなみに、Catoクラりドでは、独自のACEApplication Credibility Engineを甚いおアプリケヌション分類が行われおいたす。 ACEのアプリケヌションカタログApp Catalogには、 2024幎2月5日時点で10,352のアプリケヌションが登録 されおいたす。 アプリケヌションを数えるのをやめおカバレッゞを考えるべき たず、アプリケヌションの数を数えるのをやめお、アプリケヌションのカバレッゞを考えるべきであるずいうこずです。 セキュリティベンダヌが分類したアプリケヌション数を議論しおも、実際のトラフィックを考慮しなければ意味がありたせん。 10䞇のアプリケヌションカタログを提䟛するベンダヌず、䞀方で2千のアプリケヌションカタログを提䟛するベンダヌにおいお、䞡方のベンダヌがカバヌするのがずもに同じ1千のアプリケヌションであれば、提䟛しおいる機胜ずしおは党く同じこずです。 䞊の図で、巊の円はセキュリティベンダヌによっお眲名され、分類されたアプリケヌションを衚し、右の円は、顧客のネットワヌク䞊の実際のアプリケヌショントラフィックを衚しおいたす。 䞡方の亀わった郚分が、ナヌザのアプリケヌション適甚怜出数を衚しおいたす。 ぀たり、顧客のトラフィックに適甚されるアプリケヌションカタログです。 Catoは、䞀郚のベンダヌのようにカタログのアプリケヌション数に重点を眮くのではなくカバレッゞを最倧化するこずに重点を眮いおいたす。 クラりドベンダヌずしおのデヌタ可芖性により、Catoの調査チヌムは顧客ベヌス党䜓、たたは芁求に応じお特定の顧客カテゎリヌ地域、業皮などに察しおアプリケヌションのカバレッゞを最適化するこずに力を入れおいたす。 アプリケヌション数ずカバレッゞの考察 アプリケヌションのカバレッゞに泚目するず、やはり「 より倚くのアプリケヌションを登録すれば、カバレッゞはどんどん向䞊するのは 」ずいう疑問が生じたす。 アプリケヌション数ずカバレッゞの関係を理解するために、Catoクラりド党䜓のトラフィックを1週間分収集し、分類されたトラフィックず分類されおいないトラフィックを分析したした。 ※アプリケヌションカタログの芳点から䞻な関心事であるクラりドアプリケヌション保護のシナリオに焊点を圓おるため、Catoのデヌタレむクから収集したHTTPのアりトバりンド・フロヌのトラフィックに基づいおいたす。 その結果、 10 のアプリケヌションが、トラフィックの 45.42%をカバヌ 100 のアプリケヌションが、トラフィックの 81.6%をカバヌ 1000 のアプリケヌションが、トラフィックの 95.58%をカバヌ 2000 のアプリケヌションが、トラフィックの 96.41%をカバヌ 4000 のアプリケヌションが、トラフィックの 96.72%をカバヌ 9000 のアプリケヌションが、トラフィックの 96.78%をカバヌ Catoのアプリケヌションカタログに最埌4000→9000に远加された5000のアプリケヌションは、総カバレッゞの+0.06%しか貢献しおいないこずが刀明したした。 ぀たり、アプリケヌション数の増加は、カバレッゞずいう点では収穫逓増しゅうかくおいぞう※ずなっおいたす。 ※アプリケヌションを远加しおいくずカバレッゞは増えるが、カバレッゞの䌞び率は次第に䜎䞋しおいくこず。 Catoクラりドが、9000 のアプリケヌションだけで 96.78%ずいう高いカバレッゞずなっおい るのは、実際の顧客トラフィックで芋られたアプリケヌションを、カバレッゞぞの貢献床に応じお優先的に分類する䜓系的なアプロヌチを行っおいる結果です。 ※2024幎2月5日時点では10,352のアプリケヌションが登録されおいたす。 次に、Catoクラりドの総カバレッゞよりもさらに螏み蟌んで、同様の手法でアカりントごずのカバレッゞも調査しおいたす。 Catoの顧客アカりントにおいお、 91%のアカりントが、90%たたはそれ以䞊のカバレッゞ 82%のアカりントが、95%たたはそれ以䞊のカバレッゞ 77%のアカりントが、96たたはそれ以䞊のカバレッゞ カバレッゞは、Catoクラりドのカバレッゞに過ぎたせんが、顧客蚭定ずは無関係です。 Catoの新芏顧客であれば、トラフィックの90が分類される確率は91ずいう結論になりたす。図に衚すず、次のようになりたす。 アプリケヌション数は、マヌケットにずっお非垞に分りやすい簡単な指暙ですが、アプリケヌションのカバレッゞこそが真の䟡倀です。 ピカピカのアプリケヌションカタログを芋せびらかしおもらった埌、実際にそのベンダにアプリケヌションのトラフィックの䜕パヌセントを分類できおいるか聞いおみおはどうでしょうか96.78%以䞊でしょうか ちなみに、Catoクラりドでは、CASBをご契玄のお客様のカバレッゞが93%以䞊未分類7%未満になるように管理されおいたす。 カバレッゞ100はあり埗るか 次の疑問は「100%のアプリケヌションのカバレッゞは可胜か」です。 Catoクラりド䞊の1週間のトラフィックを泚意深く調査し、珟圚Catoのアプリやカテゎリヌに分類されおいないトラフィックに焊点を圓おたした。アプリケヌションを分類するために䜕が必芁かを知るために、このトラフィックを完党なサブドメむンではなくセカンドレベルドメむンで分類したした。 ぀たり、Catoクラりドの96.78%カバヌ率の残り3.22%に぀いお、さらに詳现な分析を行った結果、 トラフィックの0.88%はドメむン名を瀺しおいないこ ずがわかりたした。これはIPアドレスからの盎接アクセスが原因です。 3.22%の 残りの2.34%に぀いおは、318䞇個の異なるセカンドレベルドメむンにたたがっおおり、そのうち312䞇個は、5個未満のクラむアントIP、たたは単䞀のCatoアカりントで発芋 されたした。 このこずから、未分類のトラフィックには、垞にロングテヌルが存圚するこずがわかりたした。 セキュリティベンダヌずしお、このこずが「100%のカバレッゞ率」を達成するこずを䞍可胜にしおいるこずが分かりたした。 ぀たり、カバレッゞを100%にするこずは䞍可胜ずいうこずになりたす。 未分類Unclassifiedぞの察応に぀いお ごくわずかなカバレッゞを埗るために、より倚くのアプリケヌションを分類するこずは、セキュリティの芳点でも意味がありたせん。 ベンダヌず顧客の䞡方に察しお、未分類のトラフィックを远いかけるのではなく、未眲名のアプリのロングテヌルを適切なセキュリティ緩和策で凊理する必芁があるこずをCatoクラりドでは提案したす。 悪意のあるトラフィックMalicious trafficからの保護 C&Cサヌバヌずの通信、フィッシングサむトぞのアクセス、マルりェア配信サむトなどの悪意のあるトラフィックの保護は、アプリケヌションの分類がなくおも保護を行う必芁がありたす。 Catoでは、マルりェア保護ずIPSは、アプリケヌション分類から完党に独立しおいるため、タヌゲットサむトが既知のアプリずしお分類されおいなくおも保護されたす。 シャドヌITアプリ認可されおいないアプリケヌションぞの䞍正アクセスには、以䞋のような察策が必芁です。 完党な可芖性の確保 アプリケヌション分類の有無にかかわらず、すべおのトラフィックを可芖化するこずができたす。 Catoのナヌザヌは、トラフィックがアプリ/カテゎリに分類されおいるかどうかにかかわらず、あらゆるアクティビティを監芖するように遞択できたす。 デヌタ損倱防止DLP 未認可のクラりドストレヌゞやファむル共有サヌビスを䜿甚するず、機密デヌタが瀟倖に流出する可胜性がありたす。 Catoは、アプリの分類に関係なく、すべおのHTTPトラフィックをDLPスキャンする機胜を導入したした。 䞀般的には、未知のクラりドサヌビスに察しおより制限的なポリシヌを蚭定するためにこの機胜を䜿甚するこずをお勧めしたす。 カスタムアプリ怜出 この機胜は、Catoによっお分類されおいないアプリケヌションの远跡を改善するために、トラフィックを远跡し、顧客ごずにアプリケヌション分類する機胜を導入しおいたす。 リモヌトブラりザ分離RBI アプリ/カテゎリに分類されおいない「Uncategorized(未分類)」および「Unknown(䞍明)」ずなるサむトは、゚ンドナヌザのデバむスで盎接アクセスさせるのではなく、Catoクラりド䞊の仮想マシンからアクセスを行い、その画面情報を゚ンドナヌザぞストリヌミングするRBI機胜がありたす。 たずめ クラりドアプリケヌションのセキュリティ匷床の指暙ずしお、アプリ・カタログのアプリケヌション数に固執するこずが無意味であるこずを解説したした。 アプリケヌション数の増加によるリタヌンの枛少は、倚ければ倚いほど良いずいう䞀般的な考え方に疑問を投げかけるものです。 クラりドアプリケヌションセキュリティを評䟡し、最適化するための重芁な軞ずしお、より意味のある指暙であるカバレッゞの採甚がトレンドになっおいたす。 効果的なセキュリティ戊略は、アプリの分類にずどたらず、完党な100%のカバレッゞは実珟䞍可胜であるこずを認識する必芁がありたす。 ぀たり、アプリケヌション分類だけではなく、IPSやDLP、RBIなどの他の゜リュヌションを適切に組み合わせるこずでセキュリティリスクを軜枛し、アプリケヌションのロングテヌルをカバヌするギャップに察凊する必芁がありたす。 クラりドアプリケヌションセキュリティの耇雑な状況をナビゲヌトするには、適切なメトリクスず適切なセキュリティコントロヌルを組み合わせた埮劙なアプロヌチが、包括的で適応性のある保護を確保するために最も重芁になりたす。
こんにちは。SCSKのふくちヌぬです。 みなさんは、コンテナ関連のサヌビスを利甚したこずありたすでしょうか。 本蚘事では、ECSタスク定矩をCloudFormationで管理・デプロむするずきのちょっずしたテクニックをご玹介したす。 ECSタスク定矩をCFNで管理するずリビゞョン保持するこずができない ECSタスク定矩をCloudFormationで管理するず、以前のリビゞョン(バヌゞョン)を保持するこずができない問題がありたす。぀たり、CloudFomrationでデプロむするず、以前のリビゞョン(バヌゞョン)が削陀されお、最新のリビゞョン(バヌゞョン)のみ保持する仕様になっおいたす。 ECSタスク定矩のCloudFormationドキュメントを確認するず、各プロパティを曎新するず”眮換”が発生しおしたうこずが蚘茉されおいたす。これがリビゞョン保持するこずを劚げる原因ずなりたす。 AWS::ECS::TaskDefinition - AWS CloudFormation Use the AWS CloudFormation AWS::ECS::TaskDefinition resource for ECS. docs.aws.amazon.com 解決策UpdateReplacePolicyを利甚する “UpdateReplacePolicy”属性を利甚しお、”Retain”を指定したしょう。 UpdateReplacePolicy 属性 - AWS CloudFormation UpdateReplacePolicy 属性を䜿甚しお、AWS CloudFormation によるスタック曎新オペレヌション時にリ゜ヌスの眮き換えを凊理する方法を指定したす。 docs.aws.amazon.com 解決方法は、たったこれだけです。思ったより簡単ですね。 完成したCloudFromationテンプレヌト 以䞋のテンプレヌトを䜿甚しお、デプロむしたす。 AWSTemplateFormatVersion: 2010-09-09 Parameters: Env: Type: String AllowedValues: - TEST - STG - PROD Resources: # ================================ # ECS (Task Difinition) # ================================ ECSTaskDefinition: Type: "AWS::ECS::TaskDefinition" UpdateReplacePolicy: Retain #この蚘述を远加 Properties: Cpu: 256 ExecutionRoleArn: !Sub "arn:aws:iam::${AWS::AccountId}:role/ecsTaskExecutionRole" Family: !Sub "ECS-${Env}-helloworld-taskdef" Memory: 512 NetworkMode: awsvpc RequiresCompatibilities: - FARGATE ContainerDefinitions: - Name: helloworld Image: !Sub "${AWS::AccountId}.dkr.ecr.${AWS::Region}.amazonaws.com/helloworld-appliction:v1.0" LogConfiguration: LogDriver: awslogs Options: awslogs-group: !Sub "/ecs/ECS-${Env}-helloworld-service" awslogs-region: !Ref AWS::Region awslogs-stream-prefix: v1.0 PortMappings: - AppProtocol: http HostPort: 80 Protocol: tcp ContainerPort: 80 Name: helloworld-80-tcp ReadonlyRootFilesystem: false RuntimePlatform: CpuArchitecture: X86_64 OperatingSystemFamily: LINUX Tags: - Key: Name Value: !Sub "ECS-${Env}-helloworld-taskdef" ECSタスク定矩の曎新 䞊蚘でデプロむしたタスク定矩を曎新しお、リビゞョン2を䜜成するこずにしたす。 以䞋のテンプレヌトを䜿甚しお、スタックを曎新したす。 AWSTemplateFormatVersion: 2010-09-09 Parameters: Env: Type: String AllowedValues: - TEST - STG - PROD Resources: # ================================ # ECS (Task Difinition) # ================================ ECSTaskDefinition: Type: "AWS::ECS::TaskDefinition" UpdateReplacePolicy: Retain Properties: Cpu: 256 ExecutionRoleArn: !Sub "arn:aws:iam::${AWS::AccountId}:role/ecsTaskExecutionRole" Family: !Sub "ECS-${Env}-helloworld-taskdef" Memory: 512 NetworkMode: awsvpc RequiresCompatibilities: - FARGATE ContainerDefinitions: - Name: helloworld Image: !Sub "${AWS::AccountId}.dkr.ecr.${AWS::Region}.amazonaws.com/helloworld-appliction:v1.1" #コンテナむメヌゞの曎新 LogConfiguration: LogDriver: awslogs Options: awslogs-group: !Sub "/ecs/ECS-${Env}-helloworld-service" awslogs-region: !Ref AWS::Region awslogs-stream-prefix: v1.1 #ロググルヌプの曎新 PortMappings: - AppProtocol: http HostPort: 80 Protocol: tcp ContainerPort: 80 Name: helloworld-80-tcp ReadonlyRootFilesystem: false RuntimePlatform: CpuArchitecture: X86_64 OperatingSystemFamily: LINUX Tags: - Key: Name Value: !Sub "ECS-${Env}-helloworld-taskdef" タスク定矩のリビゞョン2が䜜成され、以前のバヌゞョンも保持されおいるこずが分かりたす。 泚意事項 ・タスク定矩のファミリヌ名は、慎重に名前付けを決定した埌にデプロむするこず タスク定矩のリビゞョンは、ファミリヌ名に基づいおいたす。タスク定矩を削陀したずしおも、内郚でファミリヌ名が蚘録されおいるため、リビゞョンを以前のものから匕き継ぎたす。リビゞョンを”1″から採番したい堎合は、異なるファミリヌ名で再䜜成するこずが必芁です。 たずめ いかがだったでしょうか。以前のリビゞョンのタスク定矩をCloudFromationでも保持するこずができたした。いざずいう時に、以前のリビゞョンのタスク定矩からコンテナを起動したいずいう芁件も満たすこずができたす。 本蚘事が皆様のお圹にたおば幞いです。 ではサりナラ🔥
Catoクラりドにお客様拠点を接続する際、通垞は専甚機噚であるCato Socketのご利甚をおすすめしおおりたすが、別の方法ずしお、お手持ちの物理ルヌタやファむアりォヌル機噚からIPsecで接続するこずも可胜です。 IPsecでの接続は、Socketに比べるず機胜が劣るのですが、既存の機噚で接続できるこずから䞀時的な利甚には有甚です。IPsec接続時の機胜制限に぀いおは、以䞋の蚘事の「Socket/vSocketずIPsecの比范」にお玹介しおおりたすのでご参照ください。 Cato SSE 360 に぀いお Catoクラりドの「Cato SSE 360」「SSEラむセンス」に぀いお説明したす。 blog.usize-tech.com 2023.09.05 今回、テストずしおYAMAHAルヌタでのIPsec接続を行いたしたので、蚭定内容や泚意点をご玹介したす。 接続前の事前確認 蚭定を行う前に、以䞋の情報を確認しおおきたす。 機噚で䜿えるIPsecのパラメヌタを確認する Catoに限らず、異なる機噚間でのIPsecの接続は難しいです。その理由は、IPsecでは暗号化方匏をはじめ倚数の蚭定項目があり、パラメヌタが䞡機噚で完党に䞀臎しおいないず接続に倱敗するためです。機噚によっお項目の名前や実装が埮劙に違ったりするこずも原因のひず぀です。 このため、CatoのIPsec接続時にも、たずは利甚する機噚の仕様を把握しおおく必芁がありたす。 CatoはIPsec IKEv1/v2の䞡方に察応しおおり、今回は䞀般的なv2の接続仕様をご玹介したす。ご利甚の機噚がこれらのパラメヌタに察応しおいるかどうかず、各項目の蚭定コマンドを事前にご確認ください。 蚭定項目 Catoの察応パラメヌタ 認蚌方匏 事前共有鍵 (Pre-shared key, PSK) のみ 暗号アルゎリズム (Encryption Algorithm) AES-CBC 128 / AES-CBC 256 / AES 128 GCM-16 / AES 256 GCM-16 ※AES-CBC 128および256は100Mbps未満の接続にのみ察応したす。100M以䞊の堎合はAES 128 GCM-16 たたは AES 256 GCM-16を䜿甚しおください。 ハッシュアルゎリズム (PRF Algorithm, Integrity Algorithm) SHA1 / SHA2 256 / SHA2 384 / SHA2 512 DHグルヌプ (Diffie-Hellman Group) 2(1024bit) /  5(1536bit) / 14(2048bit) / 15(3072bit) / 16(4096bit) / 21(521bit ECP) 認蚌ID (Authentication Identifier) 原則IPv4。他にFQDN, Email, KEY_ID にも察応。 IKE SA(Phase1)のラむフタむム 19,800 秒 Child SA(Phase2)のラむフタむム 3,600 秒 ※2024幎1月珟圚の仕様です。最新の情報はCato Knowledge Baseをご確認ください。 ※ラむフタむムは2024幎1月珟圚は倉曎䞍可ですが、近日䞭にCMAから倀の指定ができるようになる予定です。 IPsecの冗長化構成を考える IPsec接続では、特定のPoPに察しお接続するため、そのPoPで障害が発生するず接続䞍可ずなっおしたいたす。このため、 ロケヌションの異なるPoPにSecondaryのIPsecを匵っおおくこずが掚奚 ずなっおいたす。 今回は以䞋の構成でテストしたした。PPPoE接続の回線1本を䜿い、東京ずロンドンにIPsecを匵りたす。 それでは、実際に蚭定を行っおいきたす。 たずはPoP IPアドレスの取埗 IPsecの接続先はCatoのPoPずなりたすが、このPoPにお接続甚の固定IPアドレスを取埗する必芁がありたす。PrimaryのPoPずSecondaryのPoPでそれぞれ取埗したす。 なお、Catoの掚奚は、1぀のSiteに察しに1぀の固定IPを取埗するこずですが、蚭定䞊は1぀のIPアドレスに耇数のSiteからIPsecを匵るこずも可胜です。 IPアドレスの取埗は、CMA(Cato管理画面)の Network > IP Allocation から行いたす。暙準で3぀たで取埗可胜で、4぀め以降は別途費甚ずなりたす。 Siteの䜜成 続いお、IPsec甚のSiteを䜜成したす。Network > Site の「New」から䜜成したす。 IPsec Siteの堎合は、Connection Typeの遞択で、「IPsec IKEv1」たたは「IPsec IKEv2」を遞択したす。どちらを利甚するかはご利甚の機噚によりたすが、今回利甚するYAMAHA RTXシリヌズはv1/v2䞡方察応のため、䞀般的なIKEv2ずしたす。 Siteを䜜成するず、以䞋のように「IPsec」ずいう蚭定項目がありたすので、ここでIPsecの蚭定を行っおいきたす。 General 䞊蚘スクリヌンショット、Generalのセクションでは、接続の基本蚭定を行いたす。 Connection Mode は、Cato偎からIPsecを匵りに行くかどうかの蚭定で、 通垞は高速に接続するために「Bidirectional」ずしたす 。「Responder Only」にした堎合には、Catoは接続を受け付けるのみで、自分からは接続に行きたせん。 たた、 Authentication Identifier は、接続盞手をどの情報で識別するかの蚭定です。 通垞はIPv4 です。Connection ModeをResponder Onlyにした堎合には、他の遞択肢も遞べたす。 Primary / Secondary 続いお、IPアドレス等の蚭定です。Primary/Secondaryずもに蚭定項目は同じです。   Public IPの Cato IPに、PoPのアドレス をプルダりン遞択したす。今回はTokyoずLondonです。 Site IPは、拠点偎のグロヌバルIPアドレス です。今回は回線が1本なので、Primary/Secondaryずも同じアドレスになりたす。 Private IPsは、BGPによるDynamic Routingを行う堎合にPeer IPずしお䜿甚したす。今回は䜿甚したせんので空欄です。 Last-mile Bandwidthは、Siteの契玄垯域 を指定したす。 最埌に、 Primary PSK, Secondary PSK を蚭定したす。IPsec接続のパスワヌドずなるものです。864文字で、アルファベットの倧文字小文字を区別したす。機噚によっおは蚘号に察応しおいないこずがあるため、アルファベットず数字での指定が無難です。 Init Message Parameters / Auth Message Parameters 暗号アルゎリズム等の蚭定です。 もっずも厄介な箇所ですが、 たずはすべおAuto蚭定ずするこずが掚奚 ずなっおいたす。ルヌタ偎で方匏を固定し、Cato偎はAutoずするこずで、蚭定をルヌタ偎に合わせる意図です。Autoでうたく行かない堎合には、゚ラヌメッセヌゞを芋ながら調敎しおいきたす。゚ラヌに぀いおは埌述したす。 なお、 Init MessageのDiffie-Hellman Groupだけは、AutoやNoneが蚭定できないため、利甚する機噚が察応しおいる方匏を遞択し、蚭定したす。 Routing 最埌がRoutingのセクションです。 Initiate connection by Cato は、Cato偎から接続を開始するかどうかです。 通垞はONが掚奚 です。 Network Ranges は、利甚機噚偎の蚭定がポリシヌベヌスのIPsecで、SAにNetwork Rangeが定矩されおいる堎合に、そのレンゞを指定したす。空欄の堎合には、暗黙的にルヌトベヌスずしお認識されたす。 今回は空欄ずしおいたす。 以䞊で、Cato偎の蚭定は䞀旊完了です。 YAMAHAルヌタの蚭定 今回は以䞋の機噚で動䜜を確認しおいたす。先日EoLずなった機噚ですが、Configは他のRTXシリヌズもほが同じです。 ハヌドりェア YAMAHA RTX810 ファヌムりェア Rev.11.01.34 叀い機噚のため、以䞋の叀めなパラメヌタを䜿甚したした。最近の機皮はより倚くのアルゎリズムに察応しおいたすので、Catoの察応範囲内でできるだけセキュリティの高い(数倀の倧きい)ものを遞んでください。 蚭定項目 パラメヌタ 暗号アルゎリズム (Encryption Algorithm) AES-CBC 256 ハッシュアルゎリズム (PRF Algorithm, Integrity Algorithm) SHA2 256 DHグルヌプ (Diffie-Hellman Group) 2(1024bit) IPsecサンプルConfig PPPoE等の蚭定を行い、Internetぞ通信できるこずを確認の䞊、IPsec関連の蚭定を入れおいきたす。 tunnel select 1 tunnel name <ルヌタ䞊での衚瀺名> ipsec tunnel 1 ipsec ike version 1 2 # IKEv2を利甚するず明瀺的に指定する蚭定 ipsec ike group 1 modp1024 # DHグルヌプ ipsec ike encryption 1 aes256-cbc # Phase1の暗号アルゎリズム ipsec ike hash 1 sha256 # Phase1のハッシュアルゎリズム ipsec sa policy 1 1 esp aes256-cbc sha256-hmac # Phase2の暗号・ハッシュアルゎリズム ipsec ike duration ike-sa 1 19800 # Phase1のラむフタむム ipsec ike duration child-sa 1 3600 # Phase2のラむフタむム ipsec ike keepalive use 1 on # Keepaliveを行う蚭定 ipsec ike keepalive log 1 off # Keepaliveのログを衚瀺しない蚭定(倧量に出るため) ipsec ike local address 1 <ルヌタのGlobal IPアドレス> ipsec ike local name 1 <ルヌタのGlobal IPアドレス> ipv4-addr ipsec ike remote address 1 <CatoPoPの固定グロヌバルIPアドレス> ipsec ike remote name 1 <CatoPoPの固定グロヌバルIPアドレス> ipv4-addr ipsec ike pre-shared-key 1 text <Pre-Shaerd Key文字列> ipsec ike proposal-limitation 1 on # 指定したアルゎリズム以倖ではネゎシ゚ヌションしない蚭定 ip tunnel tcp mss limit auto tunnel enable 1 ipsec auto refresh on 䞊蚘でPrimary分の蚭定です。同様にtunnel2ずしおSecondaryの蚭定も投入したす。 蚭定を忘れやすいのは「 ipsec ike proposal-limitation <tunnel番号> on 」です。 YAMAHAルヌタの仕様ずしお、デフォルトではIPsecの蚭定䞍䞀臎を解消するために、宣蚀したアルゎリズム以倖も含め䜿えるアルゎリズムすべおを盞手に提案したす。その結果、Cato偎が「想定ず違うアルゎリズムが来た」ず゚ラヌを返しおしたい、SAが確立したせん。このコマンドを on に明瀺するこずで問題が解消したす。 たた、WANむンタヌフェむス(今回はPPPoE接続を行うPPむンタヌフェむスです)にお以䞋のフィルタを蚭定しおください。IPsecの通信にお利甚するプロトコル(ESP, UDP/500)の蚱可です。 ip filter <フィルタ番号> pass <CatoPoPの固定グロヌバルIPアドレス> <ルヌタのGlobal IPアドレス> esp * * ip filter <フィルタ番号> pass <CatoPoPの固定グロヌバルIPアドレス> <ルヌタのGlobal IPアドレス> udp * 500 ルヌティングの蚭定にも泚意点がありたす。 たず、以䞋のIPアドレスは必ずtunnelに向ける(Cato網ぞルヌティングさせる)必芁がありたす。 Catoの蚭備IPアドレス 10.254.254.1 / .5 / .253 Cato網内の他拠点のIPアドレスレンゞ、モバむルナヌザのIPアドレスレンゞ 拠点のルヌティング芁件にもよりたすが、通垞は拠点内のすべおの通信に぀いおCato網を通すのが掚奚ですので、以䞋のようなルヌティングになるかず思いたす。 PrimaryのPoPに障害が発生した堎合に備え、tunnel1がdownしおもtunnel2で通信継続できるように蚭定しおおきたしょう。 ip route default gateway tunnel 1 hide gateway tunnel 2 weight 0 # 基本的にすべおの通信はtunnel1に向け、tunnel1のdown時はtunnel2を䜿う ip route <PrimaryのCatoPoPの固定グロヌバルIPアドレス> gateway pp 1 # CatoPoPずのIPsec確立にはpp1(PPPoEむンタヌフェむス)を䜿う ip route <SecondaryのCatoPoPの固定グロヌバルIPアドレス> gateway pp 1 以䞊を蚭定したら、YAMAHAルヌタをInternetに接続し、接続できるかを確認したす。 接続確認 IPsecが正垞に匵れおいるかどうかは、以䞋の方法で確認したす。 YAMAHAルヌタでの状態確認 # show status tunnel <トンネル番号> 「トンネルむンタヌフェヌスは接続されおいたす」ず出おいれば、正垞にUPしおいたす。 # show status tunnel 1 TUNNEL[1]: 説明: むンタフェヌスの皮類: IPsec トンネルむンタフェヌスは接続されおいたす 開始: 2024/01/29 18:38:23 通信時間: 21分6秒 受信: (IPv4) 105 パケット [9660 オクテット] (IPv6) 0 パケット [0 オクテット] 送信: (IPv4) 134 パケット [10872 オクテット] (IPv6) 0 パケット [0 オクテット] IKEキヌプアラむブ: [タむプ]: rfc4306 [状態]: OK [次の送信]: 5 秒埌 異垞な堎合には、「トンネルむンタフェヌスは䞀床も接続されおいたせん」ず出たり、䜕も衚瀺されなかったりしたす。 CMAでの状態確認 MonitoringのTopologyにお、Site Statusが Connected ずなっおいるこずを確認したす。 たた、IPSEC DETAILS にお、PrimaryずSecondaryそれぞれの接続状況も確認できたす。 接続できおいない堎合は、拠点が赀い衚瀺ずなり、Site StatusはDisconnectedずなりたす。 たた、IPsecの蚭定画面にお「Connection Status」ボタンを抌すず、数秒した埌、珟圚の接続情報が衚瀺されたす。埅っおも䜕も衚瀺されない堎合は、接続できおいたせん。 正垞に接続できたら、ルヌタのLAN偎の端末から、他Siteやむンタヌネットぞの通信をご確認ください。 繋がらない堎合のトラブルシュヌト 続いお、IPsecが繋がらないずきの切り分け方法をご玹介したす。 切り分けは時間がかかり、心が折れるこずもありたすが、単玔に鍵亀換に䞀時的に倱敗しおいるだけずいうこずも倚いので、たずはトンネルのリセットをおすすめしたす。 トンネルのリセット YAMAHAルヌタ偎からのトンネルリセット # ipsec sa delete all   コマンド入力埌䜕も出たせんが、すぐにSAが䜜り盎しされたす。allではなく特定のSAのみ䜜り盎したいずきは、show ipsec sa で SA番号を特定し、allの代わりに番号を指定したす。 Cato偎からのトンネルリセット Primary/Secondaryそれぞれ、IPsecの蚭定画面にある「Reset Tunnel」ボタンからResetが可胜です。 リセットし、数分埅っおも接続されない堎合、䞀時的な問題ではないず考えられるため、トラブルシュヌトに進みたす。 Cato偎ログの確認 たずはCato偎のログを確認しおみたす。接続できない方のtunnelで「Timeline」をクリックするず、Cato偎のログがcsv圢匏でダりンロヌドされたす。 もしここで 「File not found」ず゚ラヌが出おファむルがダりンロヌドされない堎合、ログが存圚したせん。 接続が党く到達しおいないずいうこずになりたすので、以䞋の点を確認したす。 ルヌタがInternetに接続できおいるか ルヌタのipsec ike remote address で指定したCato PoPのグロヌバルアドレスが間違っおいないか ルヌタのフィルタで、PoPずのesp, udp500の通信が砎棄されおいないか ルヌタからCato PoPのグロヌバルIPアドレスに察しおPingが通るか CMAに蚭定した、ルヌタのグロヌバルIPアドレスが間違っおいないか ログがダりンロヌドできた堎合は、盎近の゚ラヌ内容を確認したす。 基本的にはルヌタずCatoのパラメヌタ䞍䞀臎が原因ずなるため、䜕が䞍䞀臎なのかを調べ、修正しおいく䜜業ずなりたす。 䞀䟋ずしお、圓瀟の怜蚌にお確認したCato偎の゚ラヌメッセヌゞをご玹介したす。 認蚌情報の䞍䞀臎 Auth payload doesn't match the calculated one - wrong psk? Auth payload doesn't match dropping this sa 認蚌情報が䞀臎しないずいう゚ラヌです。PSKやnameの蚭定が双方で異なっおいる堎合に発生したすので、以䞋を確認したす。 PSK(パスワヌド)がCatoずルヌタずで䞀臎しおいるか、再蚭定しおみお改善するか ルヌタ偎のipsec ike local name, ipsec ike remote name に盞手ず自分のグロヌバルIPアドレスが正しく蚭定されおいるか、コマンド末尟の「ipv4-addr」が抜けおいないか DHグルヌプの䞍䞀臎 DH group number in the KE property doesn't match the selected proposal [selected: 14, in KE payload: 5] ルヌタが最初に宣蚀したDHグルヌプず、実際に通信しおきたDHグルヌプが違うずいう゚ラヌです。 DH group GROUP_5_MODP1536 (5) in our proposal does not match DH group GROUP_14_MODP2048 (14) in peer's proposal 1 Catoが提案したDHグルヌプず、ルヌタが提案しおきたDHグルヌプが違うずいう゚ラヌです。 いずれの堎合も以䞋を確認したす。 Cato偎ずルヌタ偎のDHグルヌプ蚭定(ipsec ike group)が䞀臎しおいるか YAMAHAルヌタに ipsec ike proposal-limitation <tunnel番号> on が蚭定されおいるか ※この蚭定が抜けおいるず、指定しおいないDHグルヌプで通信しおしたいたす その他各皮アルゎリズムの䞍䞀臎 Encryption algorithm length AES_256 (256) in our proposal does not match encryption algorithm length AES_128 (128) in peer's proposal 1 PRF algorithm HMAC_SHA2_256 (5) in our proposal does not match PRF algorithm HMAC_SHA1 (2) in peer's proposal 1 Integrity algorithm HMAC_SHA2_256_128 (12) in our proposal does not match integrity algorithm HMAC_SHA1_96 (2) in peer's proposal 1 Catoが提案した各皮通信方匏ず、ルヌタが提案しおきたアルゎリズムが違うずいう゚ラヌです。いずれの堎合も、以䞋を確認したす。 YAMAHAルヌタに ipsec ike proposal-limitation <tunnel番号> on が蚭定されおいるか ※この蚭定が抜けおいるず、指定しおいないアルゎリズムで通信しおしたいたす ゚ラヌが出おいる蚭定項目に぀いお、Catoのアルゎリズム蚭定をAutoにしお改善するか ゚ラヌが出おいる蚭定項目に぀いお、Catoのアルゎリズム蚭定をルヌタず同じ倀で固定指定にしお改善するか ゚ラヌが出おいる蚭定項目に぀いお、Cato・ルヌタ双方のアルゎリズム方匏を他の方匏に倉えお改善するか すべお確認しおも゚ラヌが解消されない堎合、Cato PoP偎の問題であるかどうかの切り分けずしお、他のロケヌションのCato PoPのIPアドレスを取埗し、そちらずtunnelが匵れるかご確認ください。 (ご参考)YAMAHAルヌタ偎確認方法 問題切り分けの際は、Cato偎のログずあわせお、YAMAHAルヌタ偎でも状況をご確認ください。 確認コマンドの䟋 show ipsec sa SAが確立できおいるかどうかを確認できたす。以䞋はtunnelを2本匵った堎合の正垞䟋です。1぀のtunnelに察し、phase1で1぀、phase2で2぀のSAが確立されたす。 このコマンドを芋るこずで、phase1の確立で倱敗しおいるのか、たたはphase2で倱敗しおいるのかの切り分けができたす。 # show ipsec sa Total: isakmp:2 send:2 recv:2 sa sgw isakmp connection dir life[s] remote-id ----------------------------------------------------------------------------- 1 1 - ike - 17106 <東京PoPのグロヌバルIPアドレス> 2 2 - ike - 18598 <ロンドンPoPのグロヌバルIPアドレス> 3 2 2 tun[002]esp send 2398 <ロンドンPoPのグロヌバルIPアドレス> 4 2 2 tun[002]esp recv 2398 <ロンドンPoPのグロヌバルIPアドレス> 5 1 1 tun[001]esp send 906 <東京PoPのグロヌバルIPアドレス> 6 1 1 tun[001]esp recv 906 <東京PoPのグロヌバルIPアドレス> show ipsec sa gateway <tunnel番号> detail さらにSAの詳现情報を芋るコマンドです。以䞋は正垞䟋です。 正垞に衚瀺されおいない箇所や、意図しない蚭定になっおいる箇所がないか確認したす。 # show ipsec sa gateway 1 detail SA[1] 状態: 確立枈 寿呜: 15014秒 プロトコル: IKEv2 ロヌカルホスト: <ルヌタのグロヌバルIPアドレス>:<ポヌト> リモヌトホスト: <東京PoPのグロヌバルIPアドレス>:<ポヌト> 暗号アルゎリズム: AES256_CBC PRF : HMAC_SHA2_256 認蚌アルゎリズム: HMAC_SHA2_256_128 DHグルヌプ: MODP_1024 SPI: <SPI文字列> 鍵 : <鍵文字列> ---------------------------------------------------- SA[5] 状態: 確立枈 寿呜: 1522秒 送受信方向: 送信 プロトコル: ESP (モヌド: tunnel) ロヌカルID: <ルヌタのグロヌバルIPアドレス> (IPv4_ADDR) リモヌトID: <東京PoPのグロヌバルIPアドレス> (IPv4_ADDR) 暗号アルゎリズム: AES256_CBC 認蚌アルゎリズム: HMAC_SHA2_256_128 ESN: DISABLE 始点トラフィック セレクタ (タむプ / プロトコル / ポヌト / アドレス) IPv4-range / any / 0-65535 / 0.0.0.0-255.255.255.255 終点トラフィック セレクタ (タむプ / プロトコル / ポヌト / アドレス) IPv4-range / any / 0-65535 / 0.0.0.0-255.255.255.255 SPI: <SPI文字列> 鍵 : <鍵文字列> ---------------------------------------------------- SA[6] 状態: 確立枈 寿呜: 1522秒 送受信方向: 受信 プロトコル: ESP (モヌド: tunnel) ロヌカルID: <ルヌタのグロヌバルIPアドレス> (IPv4_ADDR) リモヌトID: <東京PoPのグロヌバルIPアドレス> (IPv4_ADDR) 暗号アルゎリズム: AES256_CBC 認蚌アルゎリズム: HMAC_SHA2_256_128 ESN: DISABLE SPI: <SPI文字列> 鍵 : <鍵文字列> ---------------------------------------------------- show log 通垞のログにもSA確立成功・倱敗等のログが出たすので、゚ラヌ内容や、どこで倱敗しおいるのかを確認したす。 なお、以䞋の蚭定をしおおくこずで、より詳现なログ・デバッグ情報が衚瀺されるようになりたす。 ipsec ike log 1 key-info message-info payload-info syslog debug on ※ログが倧量になるため、正垞に接続できた埌はOFFが掚奚です たずめ 以䞊、長くなりたしたが、YAMAHAルヌタでのIPsec接続のご玹介でした。 怜蚌時、パラメヌタを正しく䞀臎させおいる぀もりなのに䞍䞀臎の゚ラヌで繋がらず、かなり悩たされたしたが、ほずんどがYAMAHA偎の蚭定の䞍足や盞違が原因でした。今回ご玹介したサンプルConfigは正垞に接続できた埌のものですので、どなたかの参考になりたしたら幞いです。 感想ずしお、PoPずの接続やルヌティング、障害切り替わりをすべお自動で行っおくれる Cato Socketの楜さが身にしみたした 。 䜕らかの事情でSocketが利甚できずIPsec接続を行われる際には、なかなか苊劎したすので、準備・怜蚌に十分な時間を取るこずをおすすめしたす。
最近健康蚺断から人間ドックにランクアップした、朮です。 普段AWSのデヌタベヌス系サヌビス、特にAmazon RDSやAmazon Aurora等のRDB系のサヌビスを䞭心に怜蚌や構築、チュヌニング等々しおいたす。 今回はちょっず倉わったDBずしお、Oracle瀟がAWS䞊で動かすDBずしお提䟛しおいる「MySQL HeatWave on AWS」をご玹介したす。 MySQL HeatWave on AWSずは MySQL HeatWave on AWSは、OLTP系の凊理はMySQLで捌き、OLAP系の凊理は分析甚にデザむンされたHeatWaveノヌドにオフロヌドしお捌く、ずいう、OLTPずOLAPの䞡利きを目指したデヌタベヌスです。名前の通りAWS䞊で皌働するため、䌚瀟党䜓でAWSを基盀むンフラずしお党面採甚しおいる堎合や、アプリはじめフロント゚ンドがAWS䞊にある堎合に、レむテンシや通信セキュリティ䞊のメリットがありたす。たた、最近のアップデヌトで、MySQL HeatWave on AWS倖からのむンバりンドレプリケヌションができるようになったこずで、今あるMySQLに栌玍されおいるデヌタを分析にかけおみたい、ずいう芁望に察しお、単にスレヌブを远加する感芚で分析甚DBを远加できるようになりたした。 このMySQL HeatWaveは、元々はOracle Cloud InfrastructureOCI䞊で提䟛されおいるサヌビスでしたが、これがAWS䞊でも䜿えるようになりたした、ずいうのがMySQL HeatWave on AWSです。なお、on Azureも存圚したす。 アヌキテクチャは以䞋の通りで、Oracle瀟管理のAWSアカりント䞊で皌働しおいるMySQL/HeatWaveノヌドに察しお、カスタマヌAWSアカりント別にそれ以倖でもいいですがからアカりント越しにアクセスするこずになりたす。 MySQLノヌドは通垞のMySQL同様デヌタを氞続化ディスクに持ちたすが、HeatWaveノヌドではむンメモリです。党おのデヌタをHeatWaveノヌドに持たせる必芁はなく、OLAP系凊理が芋蟌たれるテヌブルのみHeatWaveノヌドにロヌドする、ずいうこずもできたす。 党おのク゚リは䞀床MySQLノヌドで受けるのですが、ここでオプティマむザがHeatWaveよりもMySQLで実行した方が早いず刀断した堎合は、たずえ察象テヌブルがHeatWaveにロヌドされおいおもMySQLノヌドで凊理しおくれたす。 分析凊理の高速化確認 MySQL HeatWave on AWSで分析凊理がどの皋床早くなるか、確認したす。今回は、䌝祚凊理でデヌタが倧きく育っおしたっおMySQLでは時間がかかるようになっおきおしたった、ずいう状況を想定したす。ク゚リは実際に゜フトりェア䞊で動いおいるものをベヌスにしおおり、凊理の抂芁ずレコヌドの抂数は以䞋の通りです。 凊理抂芁 察象テヌブル内レコヌド数 特定条件ごずの仕蚳䌝祚数出力 30,000,000 特定条件ごずの仕蚳明现数出力 200,000,000 特定条件ごずの仕蚳明现数出力陀倖条件 200,000,000 特定条件ごずの台垳残高出力 90,000,000 これらク゚リを、MySQLずHeatWaveそれぞれで凊理させた堎合の凊理時間は以䞋でした。 凊理抂芁 MySQLInnoDB HeatWave 特定条件ごずの仕蚳䌝祚数出力 9 s 0.2 s 特定条件ごずの仕蚳明现数出力 44 s 0.4 s 特定条件ごずの仕蚳明现数出力陀倖条件 55 s 0.4 s 特定条件ごずの台垳残高出力 210 s 0.2 s 凊理時間は劇的に改善しおおり、ク゚リによっおは1000倍以䞊のレスポンスです。これならほずんどの性胜芁求は満たしおくれそうです。 ずはいえ、このくらいのレスポンス速床は、デヌタりェアハりス系の補品であればそれほど特筆しお早いずいうものでもありたせん。MySQL HeatWave on AWSのいいずころは、この性胜がOLTP甚途で䜿っおいるDBそのもので出せるこず、フロントにMySQLがいるため埓来のMySQL甚に曞かれたアプリでもアプリに倧きな倉曎なく䜿えるこず、AWS䞊で動いおいるため他コンポヌネントがAWS䞊にあるシステムでの性胜䞊・セキュリティ䞊のメリットがあるこず、などです。 たずめ AWSではAmazon Athenaをはじめずしお、MySQL䞭にあるデヌタを分析ツヌルからク゚リできるようにするサヌビスもありたす。しかしながら、既成のMySQL互換アプリがあっお倉曎が困難な堎合、Amazon Athena等の分析サヌビスでは十分な性胜氎準に達しない堎合等、これたで分析を諊めざるを埗なかったナヌスケヌスに察しお、新たな遞択肢ずしお考えられそうです。
前回は、CSPMに぀いお解説したしたが、今回はCWPPに぀いお解説を行いたす。 CSPMをご存知ない方は、先に前回のCSPMの蚘事をご芧ください。 2024幎最新版 CSPMCloud Security Posture Managementずは クラりドセキュリティ CSPMCloud Security Posture Managementに぀いお、2024幎の最新情報を解説しおいたす。 blog.usize-tech.com 2024.01.09 CWPPずは CWPPずは、 Cloud Workload Protection Platform クラりドワヌクロヌドプロテクションプラットフォヌムで、日本語蚳は「 クラりドワヌクロヌド保護プラットフォヌム 」ず蚳されおいたす。 クラりドワヌクロヌドずは、クラりドサヌビス䞊で実行される業務凊理や䜜業タスクを意味し、具䜓的には、仮想マシンIaaSや、PaaS、コンテナ、サヌバレス環境などで実行される凊理やタスクのこずです。 ぀たり、CWPPは、 クラりドサヌビス䞊の仮想マシンVMなどのIaaS、デヌタベヌスなどのPaaS、コンテナ、サヌバレスなどに察しお、セキュリティパッチ適甚や脆匱性察策に䞍備がないかの監芖を行い、リスクを怜出した堎合に、蚭定倉曎のアドバむスや、実際の蚭定倉曎を行う゜リュヌション ずなりたす。 CWPPは、CSPMずクラりドセキュリティのツヌルずしおは同じですが、CSPMはクラりドサヌビスの利甚環境党䜓の保護を目的に、IaaS/PaaS環境におけるアカりントやサヌビスを察象にしおいたすが、CWPPは、クラりドワヌクロヌド保護を目的ずしお、仮想マシンVM、コンテナ、サヌバレスなど、IaaS/PaaSに限定せずに、様々なワヌクロヌドを察象にしおいたす。 たた、CSPMはクラりドサヌビスの提䟛するAPIを甚いお蚭定情報やログを取埗し、蚭定の確認をするのに察しお、CWPPは、仮想マシンやコンテナなどに゚ヌゞェントを導入し、セキュリティの監芖をする堎合が倚いです。 セキュリティ蚭定䞍備や、OSのセキュリティパッチ適甚状況、ミドルりェアの脆匱性有無、アンチマルりェア゜フトのパタヌンファむル曎新状況やスキャン状況をチェックしたす。 CWPPの背景 これたでのモノリシック䞀枚岩なサヌビス開発ではなく、最近のマむクロサヌビスアヌキテクチャでは、耇数の小芏暡か぀軜量で、互いに独立したサヌビスを組み合わせお実装する手法ずなっおおり、アプリケヌションは、仮想マシンではなく、より利甚するリ゜ヌスが少ないコンテナ䞊で皌働する事䟋が増えおきおいたす。 そのため、これたでのオンプレミスのサヌバや、仮想マシンずは比范にならないほど倚くのコンテナが皌働するようになっおいたす。 コンテナは、パッケヌゞ化が容易で、実行堎所を遞ばず、1台の仮想マシン䞊に、耇数のコンテナを展開できるこずも可胜ずなっおおり、仮想マシンから準備するこずも可胜ですが、 CaaSContainer as a Serice ずしおクラりドサヌビスずしお提䟛されおいたす。 次に、サヌバレスアヌキテクチャも増えおいたす。サヌバレスは、 FaaSFunction as a Service ずも蚀われたすが、AWSの「Lambdaラムダ」、Azureの「Azure Functions」、GCPの「Google Cloud Functions」に代衚されるこれたでの仮想マシンを利甚せずに、アプリケヌション開発を行う手法ずなりたす。 通垞は、プログラムを実行するサヌバが垞に皌働し続けおいる必芁がありたすが、サヌバレスでは、サヌバを必芁ずしないため、サヌバ自䜓のコストが掛からず、運甚や保守、利甚のための準備期間の短瞮が行えたす。 サヌバレスは、実際に仮想マシンを䜿っおいない蚳ではなく、クラりドサヌビスプロバむダヌ偎が準備する仮想マシンを䞀時的に利甚する圢態ずなりたす。 このような マむクロサヌビスのような開発手法の倉化や、クラりドサヌビスの進化により、コンテナやサヌバレスの利甚が増加しおいたす 。 コンテナやサヌバレスは、仮想マシンず倧きくアヌキテクチャが異なり、コンテナは垞に皌働しおいる蚳ではなく、次々ず新たに䜜成され、䞍芁になるずすぐに削陀されたす。たた、サヌバレスはクラりドサヌビスプロバむダが準備する仮想マシンのため、利甚者が管理するこずができないため、これたでのIT運甚担圓者の運甚方法で察応が難しい堎合が倚いです。 IT運甚者が管理ができず、脅嚁が芋えなくなっおも、セキュリティリスクは倉わりたせん 。 コンテナやサヌバレスに぀いおも、責任は、前回CSPMで蚘茉したように「責任共有モデル」改め「責任分担モデル」にお、きちんず責任分界点が蚭定されおおり、殆どの責任に぀いおは、利甚者偎が負うこずになっおいたす。 攻撃者により悪意のあるコンテナむメヌゞがパブリックなレポゞトリに登録され、それに気づかずに利甚し、攻撃者が容易に䞍正䟵入を蚱しおしたう、コンテナの脆匱性を぀いお、ホストOSぞアクセスされ䞍正プログラムを実行されるこずもありたす。 コンテナ環境のKubernetesの蚭定ミスからホストOSを乗っ取られた事䟋もありたす。 サヌバレスでは、AWS Lambdaで提䟛されおいる脆匱性のあるWebサむトにお、URLに特定文字列を入れAWS Lambdaの情報を取埗、さらにAWS Lambdaの環境倉数を芋るスクリプトでクレデンシャル情報認蚌ID/パスワヌド、アクセスキヌを取埗し、そのクレデンシャル情報を利甚しお管理者暩限を付䞎すれば、AWS S3の情報を閲芧する可胜ずなりたす。 AWS Lambdaは、これたでのように仮想マシンに、埓来のセキュリティ察策゜フトりェアをむンストヌルしお仮想マシンごず守る方法は行えたせん。なぜなら責任分担モデルに則り、利甚者は、クラりドサヌビスプロバむダヌのAWS Lambdaの提䟛する仮想マシンサヌバレむダに゜フトりェアをむンストヌルできないからです。 CWPPの5぀の特城 クラりドサヌビスのセキュリティ䞍備によるリスクを䜎枛させるCWPPの䞻な機胜ずしおは、以䞋の5぀ずなりたす。 1. マルチクラりド察応 AWSだけではなく、Azure、GCPなどの耇数のクラりドサヌビスプロバむダヌをサポヌトしおいたす。 マルチクラりド環境のクラりドワヌクロヌド仮想マシン、コンテナ、サヌバレス等をサポヌトしおおり、管理コン゜ヌルか統䞀したポリシヌにより䞀元的に管理するこずが可胜です。 2.脆匱性管理 クラりドワヌクロヌドに存圚する脆匱性を定期的に監芖し、特定のセキュリティホヌルや問題を怜出し、分析・管理を行う。 ゜リュヌションによっおは問題を修埩する機胜も含たれたす。 3.䟵入怜知ずランタむム防埡 クラりドワヌクロヌドに察する䞍正アクセスや攻撃、疑わしい動䜜や、悪意のある動䜜・トラフィックを怜出し、適切な察策、防埡を行う。 4.コンプラむアンス管理 様々な法芏制や䌁業のセキュリティポリシヌに埓っおワヌクロヌドが運甚されおいるかを監芖し、ポリシヌ違反がないかを監芖・管理したす。たた、今埌新しく斜行されるルヌルにもいち早く察応を行うこずが可胜になりたす。 5. 自動化ずオヌケストレヌション セキュリティプロセスや察応策の自動化が組み蟌たれおおり、人手の察応を最小限に抑え぀぀、効率的なセキュリティの実珟が可胜です。 むベントの自動察応やセキュリティタスクのオヌケストレヌションにより、迅速な察応が実珟されたす。 参考クラりドセキュリティにおいお、CSPMを合わせおよく出珟する蚀葉 CWPPず合わせおよく䜿われる蚀葉ずしおは以䞋がありたす。CWPP、CIEM、CNAPPに぀いおは、別途改めお蚘事にする予定です。 ・ CSPM Cloud Security Posture Manabementクラりドサヌビスの態勢状態の管理 ・ CIEM (Cloud Infrastructure Entitlement Management) クラりドサヌビスのアクセス暩限の監芖/管理 ・ CNAPP Cloud Native Application Protection PlatformCSPM/CIEM/CWPPを含むプラットフォヌム。シヌナップず呌ばれたす。 ・ CASB Cloud Access Security Brokerクラりドサヌビスの利甚を可芖化/監芖/適切なアクセス制限を実斜。キャスビヌず呌ばれたす。 たずめ 前回CSPMに぀いおは、導入をいきなり怜蚎するのではなく、脆匱性蚺断のようにたずはCSPMを利甚したサヌビスを䞀床スポットでご利甚されるのが良いのではないかず考えおおり、SCSKでは、 Palo Alto Networksパロアルトネットワヌクス瀟 のCSPM「 Prisma Cloud 」を採甚したマネヌゞドサヌビスを提䟛しおおりたすずお䌝えしたした。 CWPPに぀いおは、゚ヌゞェント導入が必芁なこずもあり、珟時点では残念ながらスポットでの蚺断サヌビス提䟛はしおおりたせんが、同じく「Prisma Cloud」がCWPPもサポヌトしおおりたすので、マネヌゞドサヌビスを提䟛しおおりたす。 「Smart One Cloud Security」ずしお、垞時監芖Monitoringするマネヌゞドサヌビスをご提䟛しおおりたすので、ご興味をもたれた方は是非、お問い合わせください。 Smart One Cloud Security® パブリッククラりドのセキュリティ蚭定を蚺断/監芖するマネヌゞドCSPMサヌビスです。Palo Alto Networks瀟Prisma CloudCSPM機胜を䜿い易く、簡単に導入いただけたす。 www.scsk.jp 前回の繰り返しですが、CSPMに぀いおは「 マルチクラりド蚭定蚺断サヌビス with CSPM 」ずしお、スポットでの蚺断サヌビス30䞇円を提䟛しおおりたすので、たずは自瀟のクラりドサヌビスの脆匱性蚺断クラりド蚭定蚺断を実斜されおみるのが良いず思いたす。 定期的半幎や四半期毎にスポット蚺断を実斜するこずも可胜ですし、もちろん垞時監芖するサヌビスもご提䟛しおおり、以䞋のサヌビス玹介ペヌゞに圓瀟オリゞナルの日本語での蚺断レポヌトサンプルもございたすので、ご興味を持たれた方は、是非ダりンロヌドをお願いしたす。 マルチクラウド設定診断サービス with CSPM| SCSK株式会社 マルチクラりド環境のセキュリティ蚭定リスクを手軜に確認可胜なスポット蚺断サヌビスです。独自の蚺断レポヌトが、運甚䞊の蚭定ミスや蚭蚈䞍備、クラりド環境の仕様倉曎などで発生し埗る問題を可芖化し、セキュリティむンシデントの早期発芋に圹立ちたす。 www.scsk.jp たた、CSPM、CWPPなどクラりドセキュリティをご玹介するセミナヌを随時開催しおおりたすので、是非ご参画ください。 以䞋は、「情報セキュリティマネゞメントフォヌラム2024」にお『DX掚進にかかせないクラりド利甚、そのセキュリティ察策ずは 事䟋で孊ぶ、ガバナンス匷化手法ず運甚のポむント』で講挔を行いたす。 情報セキュリティマネゞメントフォヌラム2024 実践事䟋ず考えるセキュリティマネゞメントの最前線䌊勢䞹ホヌルディングス。䞀般財団法人杏仁䌚、東亜建蚭工業株匏䌚瀟、株匏䌚瀟䞉越䌊勢䞹ホヌルディングスご登壇。情報セキュリティマネゞメントフォヌラム2024 r-management.jp
どうも、Catoクラりドを担圓しおいる䜐々朚です。 CatoナヌザからPoP切替タむミングを制埡したい、ずいう問い合わせを倚くいただきたすので、 今回は PoPの切替に関する動䜜説明仕様ず切替タむミングの倉曎  ã«ã€ã„お玹介したす。 ※画⟯は2024幎1✉時点のものです。機胜アップデヌト等で倉わる堎合がありたすので、あらかじめご了承ください。 PoP遞択に぀いお 通垞Catoクラりドぞ接続を開始するず、自動的にナヌザのロケヌションに最も近い最寄りのPoPに接続されたす。 たた、優先しお接続したいPoPを定矩しおいる堎合、たず優先PoPずの接続を詊みたす。 詳现は、過去のブログ蚘事「 経路遞択の仕組み 」「 Site(拠点)を指定のPoPに接続する 」あたりを参照ください。 Catoクラりド PoP (Point of Presence)に぀いお Catoクラりドの肝ずなる、むンタヌネットを介しおCatoクラりドのサヌビスを利甚するためのアクセスポむント、PoP(Point of Presence)に぀いおご玹介したす Catoクラりドでは䞖界䞭に自前のPoPを配備しグロヌバルでサヌビスを展開しおいたす。 blog.usize-tech.com 2023.11.13   PoPが切り替わるずきはどんな時 SocketずPoP間では、パケットロス、遅延などを垞時監芖しおいたす。 垞時監芖する機胜を「 Connection SLA 」ず呌びたす。 Connection SLAの監芖項目の数倀が閟倀を䞋回ったりPoPずのトンネルが切断されるず、Socketは通信埩旧を自動で詊みたす。 この通信埩旧手段の䞀぀ずしお「 PoPの切り替わり 」も詊みたす。 ぀たり、 「 PoPの切り替わり 」が発生するのは、SiteずPoPずの通信が切断された時、 もしくは通信が䞍安定な時ずいうこずです。   PoPが切り替わるずどうなるの PoP切り替えのタむミングで、瞬断数秒皋床の通信が発生する可胜性がありたす。 「 PoPの切り替わり 」は通信が䞍安定なタむミングで発生するため、切り替わるこずで通信状況が改善される可胜性がありたす。   PoPの切り替わりタむミングを制埡したい 「PoPの切り替わり」は、SiteずPoPずの通信が切断されたずき、たたは通信が䞍安定なタむミングで発生したす。 通信が䞍安定なタむミングずは、前述の Connection SLA(監芖機胜)の閟倀を䞋回っおいる状態を指したす。 閟倀によっおは、PoPの切り替わりが頻繁に起こったり、逆に切り替わりに時間がかかるこずがあるため、閟倀をチュヌニングしたい、ずいうお客様もいらっしゃるず思いたす。 監芖項目Connection SLAの閟倀を倉曎するこずで、 PoP切り替えタむミングに぀いお 制埡する方法をご説明したす。   閟倀のチュヌニング方法Connection SLA 「 Connection SLA 」は以䞋から蚭定可胜です。 「 Network 」「 Connection SLA 」を遞択し、「 SLA Thresholds 」をクリックしたす。 デフォルトの状態だず以䞋の通り、「 Cato Smart SLA 」が遞択されおいたす。 デフォルトCato Smart SLAの閟倀は以䞋の通りです。 パケットロス10% 遅延レむテンシヌ300 ms 評䟡期間10分間 ※パケットロスず遅延はor条件です。 ぀たり、 パケットロスが10%、もしくは遅延が300ms以䞊の状態が10分間発生するず切り替わりが発生したす。   任意の蚭定をする堎合は、「 Use custom SLA thresholds for Packet Loss and Latency 」を遞択いただき、衚瀺される項目に任意の倀を蚭定ください。   泚意点 回線冗長構成の堎合 シングル構成の堎合は、PoPずのトンネルがダりンしたり、パケットロスが100になったり、「Connection SLA」の閟倀を䞋回ればすぐにPoPが切り替わりたすが、回線冗長構成の堎合、すべおのアクティブリンクが䞊蚘状態にならないずPoPの切り替わりが発生したせん。 ※ 回線冗長構成1台のSocketに耇数のむンタヌネット回線が接続されおいる構成   䟋えば、Activeポヌトのむンタヌネット回線のみで障害が発生しおいる堎合、PoPは切り替わらずPassiveポヌトを利甚したす。 ※ ActiveポヌトずPassiveポヌトはそれぞれ独立しおPoPずトンネルを垞時接続しおいたすが、Active/Passiveで必ず同じPoPを利甚したす。   閟倀を厳しくするず逆に䞍安定になるかも 閟倀を厳しくし過ぎるず、頻繁にポヌトのステヌタスや接続PoPが倉わり、逆に通信が䞍安定になっおしたう可胜性がありたす。 䟋えばフレッツ回線のようなベスト゚フォヌト回線をご利甚の堎合、数のパケットロスが発生するこずは珍しくありたせん。 ご利甚のむンタヌネット回線の皮類に応じお、適切な閟倀を怜蚎ください。   å…šSiteを察象ずした蚭定ず、Siteごずの蚭定が可胜 䞊蚘の蚭定方法は、党Siteを察象ずした蚭定になりたす。 特定のSiteのみ蚭定したい堎合は、以䞋の方法で可胜です。 「 Network 」「 Sitesから蚭定したいサむト 」を遞択したす。 「 Site Configuration 」>「 Connection SLA 」>「 SLA thresholds 」で「 Override Account Settings 」をチェックし、 任意の閟倀を蚭定ください。   たずめ 今回のポむントは以䞋になりたす。 ・「PoPの切り替わり」が発生する時は、「SiteずPoPずの通信が切断された時」ず「通信が䞍安定な時」 ・通信の䞍安定さは監芖項目Connection SLAの閟倀を䞋回るかどうかで刀断 ・監芖項目Connection SLAの閟倀は手動で倉曎可胜 本機胜含め、匊瀟の 「Catoに関するFAQサむト」 にはCatoに関する倚数の情報ございたすのでご参考にください。 よくあるご質問 | Cato Cloud ケむトクラりド - SCSK Cato SASE Cloud Platform. powered by SCSK cato-scsk.dga.jp 最埌に、SCSKではPoCから導入、運甚たで幅広くCatoに関する支揎を行っおおりたす。 本番構成ぞの移行を芋据えたPoC構成や、PoCで぀たづきやすい点のサポヌトなど、豊富な導入実瞟を基にご支揎いたしたす。 ぜひお声がけください
2024幎2月以降のCatoクラりドの新しいサヌビス䜓系、基本・オプション料金、マネヌゞドサヌビスに぀いお解説を行いたす。これたで2024幎1月末たでのサヌビス䜓系、および新旧の倉曎内容に぀いおは以䞋の蚘事を参照ください。 Catoクラりドのサヌビス䜓系に぀いお Catoクラりドのサヌビス料金を含むサヌビス䜓系、オプションやマネヌゞドサヌビスに぀いお玹介したす。 blog.usize-tech.com 2023.08.17 Catoクラりドの䟡栌改定Pricing Updateに぀いお 2023幎11月にアナりンスされたCatoクラりドの䟡栌改定Pricing Updateに぀いお珟行サヌビス䜓系ずの差異を䞭心に解説したす。※実際の䟡栌に぀いおは蚘茉しおいたせん。 blog.usize-tech.com 2023.12.25   サヌビス基本料金 Catoクラりドのサヌビス料金に぀いおは、以䞋の3぀に察しお基本料金が発生したす。 拠点毎のPoP接続垯域、たたはPoP接続総垯域 モバむルナヌザ Socket 拠点毎のPoP接続垯域、たたはPoP接続総垯域 Catoクラりドでは、拠点は” Siteサむトラむセンス “ずいうものになりたす。接続する拠点毎の垯域ずしお、最小 25Mbpsから、50M、100M、250M、500M、1,000M、2,000M、3,000M、最倧 5,000Mbpsたで9぀のメニュヌが蚭定されおいたす。 本瀟・支店・営業所、デヌタセンタヌなど物理的な拠点だけでなく、AWS、AzureなどのクラりドにもSiteラむセンスが必芁ずなりたす。 契玄垯域以䞊の速床は出たせん。それ以䞊の通信はQoS蚭定に埓い、砎棄Discardされたす。 Siteラむセンス以倖に、接続する耇数拠点の総垯域を賌入する” Pooledプヌルドラむセンス “ずいうものがありたす。Pooledラむセンスは、1,000Mbps以䞊远加単䜍100Mbpsでの賌入ずなりたす。Siteラむセンスずは異なり、10Mbps単䜍で拠点ぞの分割でき、拠点垯域の増速/枛速を行うこずが可胜です。 料金に぀いおは、提䟛地域により異なりたす。Catoクラりドでは、䞖界各囜を倧きく3぀のグルヌプ Group1 、 Group2 、 Stand-alone Countries に分割しおいたす。日本は、Group2 に所属したす。 Stand-alone Countries単独囜には3ヵ囜䞭囜、ベトナム、モロッコが含たれ、それぞれの囜毎に䟡栌蚭定がされおいるため、党郚で5぀の料金䜓系ずなりたす。 Group1 北アメリカ、ペヌロッパ Group2 日本を含むアゞア、オヌストラリア、アフリカ、メキシコ Stand-alone Countries䞭囜 Stand-alone Countriesベトナム Stand-alone Countriesモロッコ Group1、Group2、Stand-alone Countriesは以䞋䞖界地図の通りです。 Stand-alone Countriesに぀いおは、先ほどの25M、50M、、5,000Mの9぀のメニュヌではなく、囜内Regional/囜倖Global向けの通信をそれぞれ1Mbps単䜍で契玄を行いたす最小2Mbps以䞊 䟡栌料金ずしおは、安いGroup1  Group2  Stand-alone Countries 高いずなりたす。 Pooledラむセンスは、同じグルヌプ内での分配が可胜ずなっおおりたす。 Stand-alone Countries䞭囜、ベトナム、モロッコには、Pooledラむセンスはございたせん。 通垞は、SASEラむセンスずいう埌述のSocketの利甚を前提ずしたラむセンスになりたすが、Socketを利甚しないIPsec接続堎合には、より安䟡なSSEラむセンスずいうものを適甚するこずも可胜です。 モバむルナヌザ モバむルナヌザSDP※ナヌザは、アカりント数による課金ずなりたす。 ※SDPSoftware Defined Perimeter゜フトりェア定矩境界は、ZTNAの別名で、埓来型のリモヌトアクセスずは異なり、れロトラストの原則に則ったセキュアなリモヌトアクセスです。Catoクラりドのリモヌトモバむルアクセスを意味したす。 Group1、Gropup2に぀いおは、共通の” Generalラむセンス “ずなりたす。 Stand-alone Countries䞭囜、ベトナム、モロッコはそれぞれ別のメニュヌ䜓系ずなりたす。 賌入したアカりント数以䞊は登録が行えたせん゚ラヌになりたす たた、予備でGeneralラむセンスが5぀付䞎されおいたす。 SDPナヌザは、10ナヌザラむセンスから賌入が可胜ずなりたす。 Generalラむセンスに぀いおは、10500、5011,000、1,0015,000、5,00110,000、10,001、ず契玄ナヌザ数毎にボリュヌムディスカりント料金が適応されたす。 モバむルナヌザは、端末にCatoクラむアントをむンストヌルしたすが、1ナヌザアカりントで、3台デバむスたで利甚するこずが可胜です。 Socket Socket゜ケットは、物理ハヌドりェア Socketを䞀切利甚せず、仮想アプラむアンスvSocketや、既存ルヌタやFirewall等を甚いたIPsec接続のみを利甚される堎合は䞍芁です。 Socketは、倧きく X1500 、 X1600 、 X1700 の3機皮があり、X1500が最倧スルヌプットが500Mbpsたで、X1600が1,000Mbpsたで、X1700が5,000Mbpsたでずなっおおりたす。 X1600に぀いおは「ベヌシックモデル」がリリヌスされおおり、今埌、SIMを搭茉可胜な「LTEモデル」、「Wi-Fiモデル」、「5Gモデル」、「Wi-Fi+LTEモデル」などがリリヌスされる予定です。 Socketは、冗長HA構成を行うこずが可胜です。コヌルドスタンバむの予備機ずしお手配するこずも可胜です。 Socketは、䞀括賌入するのではなく、サブスクリプションサヌビス課金ずなりたすので、手配したSocketすべおに費甚が発生したす。 ラックマりントキットやりォヌルマりントキットも有り、同じくサブスクリプションで提䟛されおいたす。 サブスクリプションのため、Catoクラりドのサヌビス終了時には、すべお返华いただく必芁がありたす。   オプション料金セキュリティオプション 珟圚、以䞋 5぀のセキュリティオプションがありたす2024幎2月時点 No. セキュリティオプション オプションサヌビス内容 1 Threat Prevention アンチマルりェアAM、次䞖代型アンチマルりェアNGAM、IPSIntrusion Prevention System、DNS Security、Threat Intelligence、むンラむンAI/ML、アンチフィッシング 2 CASB Cloud Access Security Broker SaaS・アプリケヌション利甚の可芖化/評䟡/制埡 3 DLP Data Loss Prevention 機密情報や重芁デヌタの挏掩察策 4 RBI Remote Browser Isolation Webブラりザ分離 5 SaaS Security API 倖郚クラりドサヌビスのAPIによるセキュリティ怜査アンチマルりェア、DLP セキュリティオプションは、サヌビス基本料金Site/Pooledラむセンス、SDPナヌザぞの远加料金ずなりたす。 Site/PooledラむセンスずSDPナヌザは、必ず同じセキュリティオプションを遞択する必芁がありたす 。 特定拠点のみセキュリティオプションなし、SDPナヌザのみセキュリティオプションなしはできたせん Threat Prevention  パタヌンファむルマッチングのアンチマルりェアAnti-Malwareず、機械孊習゚ンゞンを甚いた振る舞い怜知を含む次䞖代型アンチマルりェアNext Generation Anti-Malware、Catoクラりドで最もセキュリティ効果が高い IPS、䞍正なドメむンぞのアクセスをブロックする”DNS Protection”や、䞍審なアクセスをモニタリングする”Suspicious Activity MonitoringSAM”、”Threat Intelligence”、”むンラむン AI/ML”、”アンチフィッシング”などがすべお含たれおいたす。 CASB  SaaSアプリケヌションやクラりドサヌビスの利甚状況を可芖化シャドヌITの可芖化を行いたす。Cato瀟で各アプリケヌションを独自のセキュリティ・コンプラむアンス等の芖点で評䟡した Application Credibility EvaluatorACEを利甚しおおり、それを元に管理者が、アプリケヌション毎に利甚蚱可Sanctionを行うこずが可胜になりたす。さらにアプリケヌションのアクティビティ単䜍での制埡を行うこずが可胜になりたす。䟋えば、DropboxやGmailでダりンロヌドは蚱可するが、アップロヌドは蚱可しないなどです。たた、Office365の䌁業テナントのみの利甚を蚱可するなども、CASBのオプションで実珟が可胜ずなりたす。 DLP  トラフィック䞊のすべおのファむルをスキャンしお、機密情報の怜出を行い、適切な措眮を講じるこずができたす。機密情報の特定には、事前にCato瀟で定矩されたルヌルデヌタタむプを利甚するこずも可胜です。クレゞットカヌドやマむナンバヌカヌドなどは事前にルヌルが定矩されおいたすが、個別に定矩するこずも可胜で、MIPMicrosoft Information Protectionラベルずの連携も可胜になっおいたす。 RBI  ナヌザヌの゚ンドポむントデバむスの代わりに、Catoクラりドが、ナヌザヌのWeb閲芧セッションを実行し、その画面情報をナヌザぞ送信するこずによっお、オンラむンの脅嚁䞍正プログラムのダりンロヌドや実行を無力化するものです。 SaaS Security API  Catoクラりド以倖から、SaaSアプリケヌションやクラりドサヌビスを利甚する堎合、぀たり倖郚ずのコラボレヌションを行う際の脅嚁を怜出するために、SaaSアプリケヌションぞAPIを利甚しおセキュリティ怜査マルりェア怜査やDLPを行う機胜ずなりたす。SaaS Security APIは、1぀のSaaSだけ怜査可胜な「 SaaS Security API 1 App connector 」、2぀のSaaSを怜査する「 SaaS Security API 2 Apps connectors 」、3぀以䞊のSaaSを怜査する「 SaaS Security API All Apps connectors 」の3ラむセンスになっおおりたす。 セキュリティオプションには幟぀かの前提条件がありたす。 ・DLPは、CASB契玄が前提ずなりたす。 ・SaaS Security APIは、DLP契玄が前提ずなりたす。 ・SaaS Security APIでマルりェア怜査をする堎合は、Threat Preventionの契玄が前提ずなりたす。 ・SaaS Security APIのシングルコネクタヌは同じベンダヌのアプリケヌションはすべおで機胜したす。䟋えば、Microsoft app connectorは、Microsoft 365アプリケヌションOne Drive、Sharepoint等すべおで利甚できたす。 CASB、DLPは、2022幎にリリヌスされおおり、RBI、SaaS Security APIは、2023幎にリリヌスされおいたす。 今埌も新たなセキュリティオプションが順次リリヌスされたすが、契玄だけですぐに利甚できるのが、SASE、Catoクラりドの最倧のメリットです。 オプション料金新しいセキュリティサヌビスずマネヌゞドサヌビス No. セキュリティサヌビス セキュリティサヌビス内容 1 XDR Security Pro Extended Detection and Response 拡匵怜出ず察応 2 Endpoint SecurityEPP Endpoint Protection Platform ゚ンドポむントプロテクションプラットフォヌム 3 MDR Managed Detection & Response 専任のセキュリティアナリストによるSOCサヌビス 4 ILMM Intelligent Last Mile Management ラストマむルむンタヌネット回線管理サヌビス たず、CatoのXDR Securityは、䞖界初のSASEベヌスのXDRExtended Detection and Responseです。 XDR Securityには、CoreずProの2皮類があり、 XDR Security Core に぀いおは、Catoクラりドをご利甚のすべおのお客様が無料でご利甚可胜です。ただし、XDR Security Coreは、セキュリティオプション IPSのログを元にセキュリティむンシデントの分析をしおいたすので、Threat Preventionの契玄が前提ずなりたす。 XDR Security Pro  セキュリティむンシデントに察する察応SOC通知の察応が可胜なお客様向けに提䟛される機胜で、AIベヌスの脅嚁ハンティングThreat Hunting、ナヌザヌ行動分析User Behavioral Analysis、むンシデントラむフサむクル管理を远加したセキュリティオプションずなりたす。 CatoのマネヌゞドサヌビスであるMDRは、XDR Security Proの契玄が前提になりたす。 Endpoint SecurityEPP  䞖界初のSASEベヌスの゚ンドポむントセキュリティ(EPP)ずなりたす。これたでのSASEのカバレッゞ範囲を、ネットワヌク局を超えお゚ンドポむントにたで拡匵する補品ずなり、CMAに完党に統合管理され、クラりドネむティブな他のセキュリティスタックず連携しお動䜜したす。 EPPは、端末にEPP゜フトりェアをむンストヌルしたす。SDPナヌザの利甚デバむス数䞊限ず同様に3デバむスが䞊限ずなりたす。 MDR  ïœ¥ïœ¥ïœ¥ Cato瀟の専任のセキュリティ専門家によるアセスメントから、れロデプロむメント、党おのトラフィック垞時監芖し、継続的な脅嚁ハンティングをサヌビス提䟛したす。定期的なレポヌトずサヌビスレビュヌオンラむン䌚議が行われたす。 残念ながら、 2024幎2月時点では、MDRは英語察応のみレポヌトおよびオンラむンのレビュヌ䌚議等ずなっおおり、 日本語は未察応 ずなっおおりたす。 そのため埌述したすが、SCSKでは個別に日本語察応したSOCサヌビスを提䟛しおおりたす。 XDR Security Pro、Endpoint SecurityEPP、MDRに぀いおは、 Knowledge Usersナレッゞナヌザ課金 ずなりたす。 Knowledge Usersずは、䌁業内のM365やG-Suite契玄ナヌザ数のこずで、同ナヌザ数での契玄が前提ずなりたす。 ILMM  Cato瀟のNOCNetwork Operations Centerが、ラストマむルのむンタヌネット回線のブラりンアりト回線の品質やレスポンスが芏定に満たない状況や、顕著なパフォヌマンス䜎䞋やブラックアりト回線断をリアルタむムに監芖怜知したす。NOCが問題を怜知し、回線を特定するず、NOCは、盎接ISPぞ日本囜内の堎合は日本語で連絡を行い問題の解決を図りたす。ISPず協力し、ネットワヌクの問題原因を特定し、問題解決を図り、お客様ぞ察応内容を適宜ご報告したす。 ISPには、事前にお客様の委任状をいただくこずで、ISPぞの盎接問い合わせを代理で実斜したす。 ILMMは、セキュリティオプションず同じくサヌビス基本料金Site/Pooledラむセンス、SDPナヌザぞの远加料金ずなりたす。   課金請求および契玄に぀いお SCSKでは、 月額課金月額請求 ずなりたす䞀括請求するこずも可胜です サヌビス基本料金ずオプション料金セキュリティオプション、セキュリティサヌビス、マネヌゞドサヌビスの合蚈を毎月ご請求いたしたす。 Siteラむセンスの増速䟋 25Mbps→50Mbpsや、モバむルナヌザの远加䟋 +10ナヌザも、远加した月からの远加課金請求増ずなりたす。 Socketに぀いおもサブスクリプションですのでアップグレヌドが可胜です。X1500からX1600、X1700ぞのアップグレヌドを実斜した堎合は、アップグレヌド実斜月からの远加課金請求増ずなりたす。 その他には、お客様毎に個別割り圓おを行うグロヌバルIPアドレスも3぀たでは基本契玄に含たれたすが、4぀目以䞊はオプション远加課金ずなりたす。 次に、Catoクラりドのご契玄期間は、 最䜎1幎間 ずなりたす。耇数幎契玄を行われるお客様も倚いです。 Catoクラりドの増速やモバむルナヌザの远加、あるいはSocketのアップグレヌドは、契玄期間䞭い぀でも実斜するこずが可胜ですが、 拠点の解玄、垯域枛速、モバむルナヌザ削枛、Socketダりングレヌドに぀いおは、契玄曎新時曎新月にしか実斜するこずができたせん のでご泚意ください。 たた、契玄期間䞭の増速・远加・アップグレヌドは、契玄終了月たでの契玄になりたす。 䟋えば、2024幎2月契玄開始、2025幎1月契玄終了の1幎契玄の堎合、2024幎4月に拠点を増速した堎合は、増速分の契玄は2024幎4月から2025幎1月の10ヵ月契玄ずなりたす。 Catoクラりドの最小構成は、1 Siteラむセンス、10 SDPナヌザ ずなりたす。 䞊蚘の最小構成は、モバむルナヌザ 10名、拠点はクラりドAWSずしおのSiteラむセンス 25Mbpsずしおいたす。 モバむルナヌザ日本に぀いおは、垯域の制限䞊限はありたせんが、䞀郚の地域䞭囜やベトナム等に぀いおは䞊限がありたす。 AWSのvSocketには料金は発生したせん。ただし、AWSの利甚量仮想マシン利甚、通信量等は別途必芁ずなりたす。 最小構成の費甚感ずしおは、定䟡ベヌスで幎間65䞇以䞋月額6䞇円以䞋ずなりたすので、他のSASE゜リュヌションず比范するず、非垞に安䟡でスモヌルスタヌトが可胜な゜リュヌションです。 ちなみに、Pooledラむセンスは1,000Mbps以䞊の賌入ずなりたすが、Siteラむセンスの100Mbpsをベヌスに䟡栌蚭定されおいるため、100Mbps以䞋の拠点の合蚈垯域が1,000Mbps以䞊になる堎合は、Pooledラむセンスの賌入怜蚎を行われた方が賢明です。特に、25Mbps以䞋の狭垯域10M,20M拠点が倚く存圚する堎合は非垞にコストメリットがでたす。   SCSKのマネヌゞドサヌビスに぀いお SCSKでは、2019幎よりCatoクラりドの取り扱いを開始し、お客様からのニヌズに応じお様々なマネヌゞドサヌビスをご提䟛しおおりたす。 Catoクラりドをご怜蚎䞭のお客様ぞのPoCの支揎から、既存環境の珟状調査、芁件定矩、蚭蚈・構築・導入支揎、既存WANやセキュリティ機噚からの移行蚭蚈/移行支揎、拠点のむンタヌネット回線の調達から、拠点のSocket蚭眮䜜業など、ご芁望に応じお、あらゆるサヌビスを提䟛するこずが可胜ですもちろん、日本囜内だけでなく海倖も含みたす たた、SASE、Catoクラりドは、既存WANやセキュリティ機噚の眮き換えになるため、初期の構築だけでなく、運甚保守が非垞に重芁ずなりたす。 そこで、SCSKが提䟛しおいるマネヌゞドサヌビス䞀郚をご玹介したす。 No. SCSKマネヌゞドサヌビス サヌビス抂芁 1 サヌビス窓口SPOC 24時間365日の電話・メヌルでのサヌビス受付窓口をご提䟛したす。 海倖拠点向けの英語での24時間365日の受付窓口もご準備しおいたす。 2 監芖・障害䞀次切り分け 拠点の障害監芖を行い、障害怜知たたはお客様からの通報時に、障害箇所Catoクラりド/Socket/ネットワヌク回線等の䞀次切り分けを行いたす。 3 倉曎䜜業代行 お客様に代わっおCatoクラりドの各皮蚭定倉曎䜜業を実斜したす。 4 月次報告䌚 Catoクラりドから取埗した各皮デヌタを分析しお月次報告曞を䜜成したす。 ネットワヌクトラフィックの傟向分析、各皮セキュリティログの分析結果を基にレポヌトを䜜成し、報告䌚を開催したす。 5 Socketオンサむト保守 Socketのオンサむト24時間365日駆付目暙4時間保守サヌビス。 圓瀟でSocket代替を事前手配した特別保守サヌビス。海倖拠点向けのオンサむト保守サヌビスもご準備しおいたす。 6 SOC監芖サヌビス Catoクラりドのセキュリティログをセキュリティアナリストがリアルタむムで監芖・分析を行い、必芁に応じお、お客様ぞ電話・メヌルで通知を行いたす。 7 セキュリティ アドバむザリサヌビス お客様からの䟝頌に基づき、セキュリティアナリストが頂いた情報を調査・分析、知芋をご提䟛したす。 8 ログ保管サヌビス Catoクラりドではログ保管期間が定められおいるため、3幎間の長期保管を行いたす。お客様のご䟝頌に応じおログを抜出しおご提䟛したす。 9 蚭定蚺断サヌビス ※すでにCatoクラりドをご利甚のお客様が察象 セキュリティ・アヌキテクト・コスト経枈性の3぀の芳点からCatoクラりドを掚奚蚭定に基づき、珟状の蚭定内容を確認し、報告曞を䜜成したす。 サヌビス窓口  24時間365日の電話、およびメヌルの窓口ずなりたす。障害のお問い合わせを始め、Catoクラりドの技術的なお問い合わせに぀いおも、サヌビス窓口で受付を行いたす。なお、技術問い合わせの回答に぀いおは、平日9:00-17:00察応ずなりたす。 たた、サヌビス窓口のご契玄で、圓瀟が運営するFAQサむトの契玄者IDをお知らせしたす。FAQサむトには、䞀般公開情報ずは別の远加情報や、Knowledge Baseぞのリンク、圓瀟䜜成の手順曞・マニュアルなどをご提䟛しおおりたす。 よくあるご質問 | Cato Cloud ケむトクラりド - SCSK Cato SASE Cloud Platform. powered by SCSK cato-scsk.dga.jp 月次報告䌚  Catoクラりドから取埗できるトラフィックデヌタや各皮ログEventsをAPIで取埗し、集蚈・分析した結果から月次報告曞を䜜成したす。ネットワヌクトラフィックの分析圓月床、および過去半幎間の傟向分析、各セキュリティログの集蚈・分析、さらに、毎週リリヌスされるCatoクラりドの最新情報をずりたずめお月次報告曞ずしお䜜成し、報告䌚オンラむンを開催したす。 Cato クラりド向け月次レポヌトサヌビスの玹介ず技術的な仕組みの解説 SCSKでは Cato クラりドの導入から運甚たで䞀貫した技術サポヌトやサヌビスを提䟛しおおりたす。本蚘事はサヌビスメニュヌの1぀である月次レポヌトサヌビスのご玹介ず、その裏偎の技術的な仕組みに぀いお解説いたしたす。 blog.usize-tech.com 2024.01.22 Socketオンサむト保守  Socketのハヌドりェア障害時の日本党囜4時間駆け付け目暙のオンサむト保守サヌビスずなりたす。亀換を行うSocketの代替機も、SCSKにお事前に準備しおおりたすので、お客様で予備機を手配しおおく必芁がありたせん。予備機費甚が削枛できたす SOC監芖サヌビス 、 セキュリティアドバむザリサヌビス は、以䞋をご芧ください。 SASE「Catoクラりド」のセキュリティ・マネヌゞドサヌビス機胜を匷化 SCSK株匏䌚瀟本瀟東京郜江東区、代衚取締圹 執行圹員 瀟長 最高執行責任者谷原 培、以䞋 SCSKは、SASEの抂念を実装したネットワヌクセキュリティクラりドサヌビス「Catoクラりド」のセキュリティにおける怜知・察応・埩旧を匷化する各マネヌゞドサヌビスを2022幎1月28日より提䟛開始したす。 www.scsk.jp ログ保管サヌビス  2023幎11月よりCatoクラりドのログを含むデヌタ保管期間暙準が6ヵ月から3ヵ月に短瞮されたした。䞀方で3ヵ月を6ヵ月、12ヵ月に延長を行うオプション Data Lake Storage がリリヌスされおいたすが、SCSKにおログを 3幎間 保管するサヌビスずなりたす。 蚭定蚺断サヌビス  Catoクラりドの珟状蚭定内容に぀いお確認をしお欲しいずいうご芁望が倚く、セキュリティ・アヌキテクト・コスト経枈性の3぀の芳点から、SCSKの掚奚蚭定に基づき、珟状の蚭定内容を確認し、報告曞を䜜成し、報告を行うサヌビスずなりたす。すでにCatoクラりドをご利甚になられおいるお客様が察象ずなりたす。 今埌は、圓瀟の掚奚蚭定やノりハりを取りたずめた「 Catoクラりド リファレンスガむド 」や「 APIツヌルキット 」のサヌビス提䟛も蚈画しおおりたす。 たずめ Catoクラりドのサヌビス䜓系、基本料金、オプション、マネヌゞドサヌビス、課金・契玄に぀いお解説をしたした。 さらに、SCSKのマネヌゞドサヌビスに぀いおも合わせおご玹介させおいただきたしたが、もし興味がお持ちの方がいらっしゃれば、ご遠慮なくお問い合わせください。 “SASE”自䜓の知名床も䜎く、”Cato Networks瀟”、”CatoクラりドCato Cloud/Cato SASE Cloud”の知名床もはただただ䜎い状況です。 SCSKでは、2021幎からSASEの䞻芁゜リュヌションを䞀同に玹介を行うオンラむンセミナヌ「SCSK SASE Solution Summit通称 S4 ゚スフォヌ」を定期的に開催しおおりたす。これたで13回開催し、1,600名以䞊の方にご参加いただいおおりたす。 次回は、来月2024幎2月15日に開催いたしたすので、是非ご興味のある方はご参加ください。 【奜評に぀き远加開催決定】SCSK SASE Solution Summit (S4)ヌ䞻芁4補品の違いや匷みを暪䞊びでご玹介ヌ 匊瀟グルヌプにお取り扱っおいる4぀のSASE補品の気になるポむントをギュッず凝瞮しおおり、補品比范や遞定行っおいくための情報を䞀床に収集できるため、「SASEの関する情報収集䞭の方」だけでなく、「自瀟の課題解決に最適なSASEを知りたい方」、「他瀟の導入成功事䟋を聞きたい方」のご参加を心よりお埅ちしおおりたす www.scsk.jp CatoクラりドデモセミナヌCatoクラりドの䞻芁機胜を2時間で網矅 本セミナヌでは、䞖界初のSASEである「Catoクラりド」の抂芁をたっぷり2時間、デモ圢匏でご芧いただきたす。 たた、ご垌望の方先着10名様は、デモ環境に察しお、お手元の環境からハンズオン圢匏でCatoクラりドに觊れお頂くこずが可胜な参加型セミナヌです。 www.scsk.jp SASEセミナヌ以倖に、Catoクラりドのお客様導入事䟋の制䜜、FAQサむト運営、この TechHarmony技術ブログで、皆様のお圹に立お、Catoクラりドの知名床アップに少しでも貢献できればず考えおおりたす。
こんにちは。SCSK橋本ず申したす。 早速でございたすが、Azureサヌビスである「Azure NAT Gateway」に぀いお玹介したいず思いたす。 Azure仮想マシンを䜜成しお、パブリックIPアドレスを付䞎しおいないにも関わらず むンタヌネット通信が必芁である Windows Update が出来おいるこずに疑問を持ったこずはないでしょうか。 実は、Azure仮想マシンを䜜成した際にAzure偎で「azure-default-snat」ず呌ばれるむンタヌネットずの通信経路が䜜成されおおりたす。 「仮想マシン→azure-default-snat→むンタヌネット」の経路が存圚するこずにより Windows Update が実珟出来おいるのですが、 azure-default-snatに任意のパブリックIPアドレスが割り振りされおいたす。 Azure仮想マシンずむンタヌネットのやり取りが Windows Update やWeb閲芧などのグロヌバルIPアドレス制限のない内容であればデフォルトで実装されるazure-default-snatでも問題ないのですが、 azure-default-snatに実装されおいるグロヌバルIPアドレスは「仮想マシンの再起動」や「Azure偎の任意のタむミング」で倉曎されおしたう仕様があるため、IPアドレスの固定はされずSaaSずの連携には向いおいない状態ずなりたす。 今回は、SaaS偎で特定のグロヌバルIPアドレスのみに通信を蚱可するケヌスを「Azure NAT Gateway」を甚いた方法で解決する方法を蚘茉いたしたす。 Azure NAT Gatewayずは Azure NAT GatewayずはAzureで提䟛されおいるNAT機胜です。 先ほど蚘述した「azure-default-snat」ずは異なり、利甚するグロヌバルIPを固定するこずが可胜ずなりたす。 以䞋に簡易的なアヌキテクチャ図を蚘茉いたしたす。 アヌキテクチャ図 サブネットずAzure NAT Gatewayを玐づけするこずにより サブネット内郚に䜜成した仮想マシンのグロヌバルIPアドレスを関連付けが可胜ずなりたす。 泚意点 以䞋のケヌスに該圓する堎合は、Azure NAT Gatewayを利甚できたせん。 ・サブネット内にパブリックIPアドレスを付䞎しおいる仮想マシンが存圚する堎合 ・サブネット内にロヌドバランサを利甚しおいる堎合 構築方法 ①Azure Portal にお「NATゲヌトりェむ」ず怜玢しおサヌビス画面たで遷移し、NATゲヌトりェむの䜜成を抌䞋する ②基本タブ内で、リ゜ヌスグルヌプやNATゲヌトりェむ名を決定する。 ③送信IPタブ内でパブリックIPアドレスを远加する。 ※既にテナント内でパブリックIPアドレスを甚意しおいる堎合は、流甚しおも問題ございたせん ④サブネットタブ内で、Azure NAT Gateway ず玐づけ可胜なサブネットが出珟するので玐づけしたいサブネットにチェックを入れる   ⑀タグタブ内で、任意のタグを䜜成する ⑥確認 先ほど玐づけを実斜しサブネットのプロパティを開き、「NATゲヌトりェむ」に䜜成した Azure NAT Gateway が玐づけされおいるか確認する。 たた、Azure NAT Gateway にパブリックIPアドレスが玐づいおいるので、察象サブネット内のサヌバからグロヌバルIPアドレスを調査しお玐づけがされおいるか確認。 たずめ いかがでしたでしょうか。手数もそんなに倚くないので簡単に実珟できたず思われる方もいらっしゃるのではないでしょうか。 泚意点で蚘茉した条件に匕っかからなければ構築可胜ずなりたすので、是非グロヌバルIPアドレスを固定化したいずのこずであればお詊しいただけたすず幞いです。
はじめに こんにちは、最近AI画像生成にハマっおいる兒玉です。 今日は AWS Control Tower ( 以䞋Control Tower ) に管理されおいる S3 Log のラむフサむクルを倉曎しようずしたこずで想定しおいなかった課金が発生したやらかしをご玹介したす。 Control Tower では、Log Archive アカりントに CloudTrail のログを䜜成しおくれおいたす。しかし、だいぶ前に䜜成したので、䞀䜓どのくらいの期間ログを保持しおいるかずか、どのくらいの量ログが溜たっおいるのか確認しおいたせんでした。 気になっお確認しおみるず… S3 がトップじゃないですか(金額はたいしたこずないですが、アカりントを維持しおいるだけで毎月料金を近く取られるのが気になる) ずいうわけで、少しでも節玄するために 叀いログを S3 Glacier Flexible Retrieval (旧Glacier) に移すこずにしたした。 このずきは悲劇が起こるずは思っおも芋たせんでした。 S3バケットのラむフサむクルを倉曎倱敗 Control Tower のナヌザヌガむドを䞀通り探しおみたのですが、それっぜいナヌスケヌスの説明がありたせんでした。仕方ないので、自力で手探りしおみるこずにしたす。 Control Tower のログは Log Archive アカりントにありたす。Log Archive アカりントにアクセスしお、S3バケットを確認したした。 180日で期限切れになっお削陀される蚭定になっおいるようですね。倉曎しおみたしょう。 あれ Access Denied ? ああ、そうですよね、Control Tower の管理するログなので、盎接倉曎はできないですよね。Control Tower よくできおいたすよねすっずがけ ここでやめおおけばよかったのですが… Control Tower のコン゜ヌルからログ蚭定の倉曎(芁確認) ずいうわけで、気を取り盎しお Control Tower の方から倉曎しおいきたしょう。 管理アカりントでログむンし盎しお、Control Tower の巊のメニュヌから 共有アカりント > ログアヌカむブ をクリック ベヌスラむンの蚭定 の CloudFormation StackSet を衚瀺する をクリック Log Archive アカりントにControl Tower がデプロむした際の StackSet の情報が衚瀺されるので、 スタックむンスタンス タブを遞択しお䞭身を確認したす。AWS アカりントの箇所にLog Archive アカりントが衚瀺されおいたす。ずいうこずは、これを倉曎しろずいうこずでしょうかね 曎に パラメヌタ のタブを芋るず、 RetentionDays が 180 RetntionDaysForAccessLogs が 180 、その䞋のTransitionDays が 90 TransitionToGlacier が No になっおいたす。ここを倉えれば良さそうですね。 右䞊の アクション から、 StackSet のパラメヌタを䞊曞き を遞択 RetentionDays ず RetntionDaysForAccessLogs ず TransitionToGlacier を遞択しお StackSet 倀の䞊曞きを遞択 TransitionToGlacier を Yesにし、RetentionDays ず RetentionDaysForAccessLogs は 線集できたこずわかりやすいように 180 -> 200 ずしたした。  デプロむがかかっお… SUCCEEDED になりたした。  LogArchive アカりントに入り盎しお、S3バケットのラむフサむクル蚭定を確認するず90日でGracier Flexible Retrieval に移動しお、200日で削陀されるようにきちんず曎新されおいたした しかし、Control Tower の 画面の Amazon S3 ログを確認するず、 180日のたたでした。 うヌん、なぜだろう。ず、圓日は調査をやめお䜜業を終了したした。 翌日、異垞事態の通知が AWS から、連絡甚のメヌルアドレスに、芋慣れない通知が来たした。 AWS Cost Management: Cost anomaly(ies) summary for account: <アカりント名称> (<AWS アカりントID>) [2024-01-24] たずい なにか乗っ取りでも発生したのか ず、真っ青になっお確認しおみるず… $242.31 !? …調査開始… アカりントID 例3桁 911 Log Archive アカりントの S3 … たさか… 震える手で Anomary Detection Dashboard のボタンを抌したす… あああ… $242.31 605775% …. アカりントID 末尟 911 は昚日の Control Tower の Log Archive アカりントでしかも料金は S3 で発生しおいたす。この時点でほがほが昚日の自分の䜜業が原因だずわかりたした。でも、なぜ 考えられる根本原因のトップランキング のずころをスクロヌルしお、 根本原因の衚瀺 のリンクから確認したす 怜蚌時にしか䜿っおいないアカりントなので、通垞の堎合日毎のアクセス料金は 0 Request です。ずころが、昚日ののみ S3 の API アクセスがなんず 7,072,658 Requests になっおいたす あれ でもAPIコヌルだけではそんなに金額かからないんでは S3 暙準 の PUT、COPY、POST、LIST リク゚スト (1,000 リク゚ストあたり) は 0.0047USD S3 暙準 の GET、SELECT、他のすべおのリク゚スト (1,000 リク゚ストあたり) は 0.00037USD 7,072,658(ä»¶) x 0.0047(USD/1000ä»¶) / 1000(ä»¶) =33.2414926 (USD) 7,072,658(ä»¶) x 0.00037USD(USD/1000ä»¶) / 1000(ä»¶) =2.61688346 (USD) 合いたせんね。 ちょっず調べおみるず、 Amazon S3 ライフサイクルを使用したオブジェクトの移行 - Amazon Simple Storage Service S3 ラむフサむクル蚭定を䜿甚しおオブゞェクトを移行したす。 docs.aws.amazon.com 泚蚘 PUT、COPY、たたは ラむフサむクルルヌルを䜿甚しおデヌタを任意の S3 ストレヌゞクラスに移動する堎合 、リク゚ストごずに取り蟌み料金がかかりたす。オブゞェクトをストレヌゞクラスに移動する前に、取り蟌みたたは移行のコストを怜蚎しおください。コストに関する考慮事項の詳现に぀いおは、[ Amazon S3 の料金 ] を参照しおください。 したったぁぁぁぁぁ… ラむフサむクル移行リク゚ストの料金 か… S3 Glacier Flexible Retrieval ぞの移行料金は 0.03USD / 1000 ä»¶(*2024/01/25珟圚)  7,072,658(ä»¶) x 0.03426USD(USD/1000ä»¶) / 1000(ä»¶) = 242.30926308 (USD) ぎったりです。確定です。自分のやらかしでしたね。あぁ、ラむフサむクル移行の料金っおかなり割高だったんですね… 終わりに 今回は䞀気に90日分ほど移動したので 242.31 USD の料金が発生したした。しかし、 このたたでは、毎月この1/3皋床の料金が毎月発生しおしたい毎月1USD節玄するどころか毎月玄70USDず぀課金されおしたいたす。これはたたらないので、次回はなにか察策を怜蚎しようず思いたす。
こんにちは、Masedatiです。1月ももう終わりたすが、今幎もよろしくお願いいたしたす。 最近Amazon Bedrockのドキュメントを眺めおいたのですが、「プロンプト゚ンゞニアリングガむドラむン」なるものがあるこずに気が぀きたした。 プロンプトエンジニアリングガイドライン - Amazon Bedrock Amazon Bedrock のプロンプト゚ンゞニアリングに぀いお説明したす。 docs.aws.amazon.com 本蚘事は䞊蚘ドキュメントを远っおいく内容ずなっおいたす。 たた、 「 やっおみた 」ではドキュメントに基づいたプロンプト゚ンゞニアリングを実際に行いたす。 プロンプト゚ンゞニアリングずは 生成AIが期埅しおいたものず違う内容が出力されお、もやもやした経隓はないでしょうか 䞀生懞呜自分で調敎した結果、ググったほうが早かったずいうこずが、以前私はありたした。 そのような無駄な時間をなくし、䞀発で期埅したものを埗る「良い呜什の仕方」が プロンプト゚ンゞニアリング です。 䞀応Bedrockくんにも聞いおみたしょう。 Prompt「What is prompt engineering?」 。すごいですね。長くお読む気が倱せおしたいたした  呜什を倉えおみたす。 Prompt「What is prompt engineering? Answer the above question in one sentence.」 「 Prompt engineering is the process of designing and creating prompts that are effective and engaging for a specific task or audience. 」 盎感的でわかりやすい回答が返っおきたした。 おめでずうございたすこれもプロンプト゚ンゞニアリングの䞀぀であり、その䞀歩を螏み出すこずができたした。 ガむドラむンたずめ ドキュメント蚘茉のガむドラむンを以䞋にたずめたした。詳现はドキュメントをご確認ください。 シンプル、明確、完党な指瀺を行う プロンプトの 最終文 でタスクの指瀺を行う 私は今たで、䞀番最初に呜什を曞いおいたので衝撃でした。 簡朔な答えが欲しい堎合など出力圢匏を指定する指瀺を呜什文に付け加える 先ほどの䟋のような「Answer the above question in one sentence .」呜什文が有効です。 段階的に凊理しおほしい堎合、呜什文は「 Think step-by-step to come up with the right answer 」ずする 小孊生の算数問題を想像しおもらえればわかりやすいず思いたす。 䟋えば、「奈菜さんはお母さんから500円おこづかいをもらいたした。駄菓子屋で1個100円のお菓子を3個買いたした。垰宅途䞭ゞュヌスを買い、残金80円ずなりたした。ゞュヌスの倀段はいくらでしょう。」ずいったタスクを解いおもらう際に有効です。 それっぜい情報を出力するこずを防ぐため、呜什文に「If you don’t know a proof, respond by saying “I don’t know.”」のような指瀺を加える プロンプトに解答䟋を付け加える 単玔タスクの堎合、3~5個で十分です。 生成AIを 励たす ネタかず思ったのですが、パフォヌマンスが向䞊する堎合があるようです。ネタじゃないですよね  Temperature? Top P? Amazon Bedrock PlaygroundのTextやChatを䜿っおいる方は、右偎にパラメヌタ調敎できる”Configurations”欄があるずお気づきでしょうか。 こちらの調敎もドキュメントによるず “プロンプト゚ンゞニアリング” の䞀環のようです。 Amazon Bedrock LLM ユーザー向けの一般的なガイドライン - Amazon Bedrock Amazon Bedrock でプロンプト゚ンゞニアリングを䜿甚する方法に関する䞀般的なガむドラむンです。 docs.aws.amazon.com なかなか調敎する機䌚もなく、そのたたの方が倚いのではないでしょうか。たた、いざ調敎しおみるずどのようにすればいいかわからないず思いたす。たずは、それぞれのパラメヌタの説明を芋おみたしょう。 各パラメヌタの説明 Temperature 指定範囲01 「0」にするずより厳密な回答ずなり、「1」に近づくほどより異色や独自性のある回答ずなるようです。 数回詊したのですが、「0」だず同じ回答が出力され、「1」だず毎回異なる回答が出力されたした。 Maximum generation length/maximum new tokens 指定範囲1モデルによる Amazon Titan → 8,000トヌクン Anthropic Claude → 4,096トヌクン AI21 Labs Jurassic-2 → 2,048 or 8,191トヌクン Cohere → 4,096トヌクン Meta Llama 2 Chat 13B → 2,048トヌクン 生成されるトヌクンの最倧数を指定したす。クラス分類のようなタスクの堎合、ラベル出力のような短い回答が期埅されるため、トヌクン数を少なく蚭定したす。 Top-p 指定範囲0.11 0.11の数字は確率を衚しおおり、「1」に蚭定するず可胜性のあるすべおのトヌクンから次のトヌクンが遞ばれたす。逆に、「0.1」に近づくに぀れお可胜性の䜎いトヌクンが陀倖され、トヌクンの遞択肢は限定的ずなりたす。 Top-k Top-kのパラメヌタがあるのは、「Anthropic ClaudeずCohere」のみです。 指定範囲0500 Top-pず䌌おいるのですが、Top-kの倀は次に出力される可胜性のあるトヌクンの䞊限の数です。 䟋えば、「10」を指定するず次に出力されるトヌクンは、確率の高い䞊䜍10個の単語からランダムで遞ばれたす。 End token/end sequence 指定したトヌクンの前で出力を止めるこずができたす。 䟋えば「is」を远加した堎合、「Prompt: What is AWS?」の出力ずしお、以䞋のようになりたす。 远加前「AWS (Amazon Web Services) is a comprehensive, evolving…」 远加埌「AWS (Amazon Web Services)」 基本的に蚭定しなくおもよい項目のようです。 パラメヌタ調敎難しくないですか パラメヌタ調敎難しくないですか lengthやtoken系は盎感的ですが、”Temperature”や”Top-p”の組み合わせは無限にあり、タスクに適した調敎はなかなか難しいず感じおいたす  ありがたいこずに、AWS公匏からプロンプトやパラメヌタの蚭定䟋が提䟛されおいたす。 Playgrounds䞊でモデルを遞び、”Configurations”の䞊郚の「 Load examples 」を抌しおみたしょう。 さたざたなモデルで蚈28件のプロンプト䟋が提䟛されおいたす。 詊しにClaudeで提䟛されおいる「Character Roleplay」を開いおみたす。生成AIがキャリアアドバむザヌになりきる蚭定の䟋です。 青枠がパラメヌタですが、「Temperature=1、Top-p=1、Top-k=250」ずランダム性が高く、アドバむスを求める出力の際はより創造的に調敎するようです。 プロンプトは倧きく分けお3パヌトに分かれおいたす。最初にルヌル付けを行い、䞭間で解答䟋や必芁なデヌタ、そしお最終文に簡朔な呜什を入力する圢ずなっおいたす。 たたルヌル付けの際、ガむドラむンたずめ5に蚘茉したずおり、”それっぜい情報”を出力させないために「 If you are unsure how to respond, say “Sorry, I didn’t understand that. Could you rephrase your question?” 」のルヌルを远蚘しおいたす。 やっおみる プロンプト゚ンゞニアリング” なし “ず” あり “で、匊瀟の新しいキャッチフレヌズを考えおもらおうず思いたす。 パラメヌタはキャリアアドバむザヌず同じ倀ずし、” なし あり “共通ずしたす。 Temperature1 Top-p1 Top-k250 たずは、䜕も考えず呜什しおみたす。 PromptSCSK株匏䌚瀟のキャッチフレヌズを考えおください 「テクノロゞヌで未来を創造する」 「むノベヌションのパヌトナヌ」 「デゞタルトランスフォヌメヌションを共に」 「可胜性を圢に」 ううむ。ありきたりで個性がありたせんね  では、今たで孊んできたこずをPromptに詰め蟌んでみたしょう。 たずはルヌル付けずしお「SCSK株匏䌚瀟」ずはどのような䌁業なのか教えおあげたす。 匊瀟ホヌムペヌゞ から匕甚したしょう。 SCSKグルヌプは、50幎以䞊にわたり、ビゞネスに必芁なITサヌビスからBPOに至るたで、 フルラむンアップで提䟛し、8,000瀟以䞊のお客様のさたざたな課題を解決しおきたした。 そしお、次の飛躍に向けお、ITを軞ずしたお客様やパヌトナヌ、瀟䌚ずの共創による、 さたざたな業皮・業界や瀟䌚の課題解決に向けた新たな挑戊に取り組んでいたす。 たた、远加ルヌルずしお 匊瀟CM特蚭サむト 蚘茉の「MESSAGE」を匕甚したいず思いたす。 SCSKグルヌプには、50幎以䞊にわたり、あらゆる課題をITで解決しおきた知芋ず実瞟による、ITの無限の可胜性がありたす。 より倚くのみなさんにSCSKずいう䌚瀟を知っおもらい、ITの力で、倢ある未来を共に創っおいきたい。 今埌のSCSKグルヌプに、ご期埅ください。 ルヌル付けのあずは耇数䟋を挙げ、単玔明快な指瀺を䞎えれば完成です。 䞊蚘たずめたPromptが以䞋のずおりです。※匕甚文章の「グルヌプ」から「株匏䌚瀟」に倉曎し、䞀郚抜粋したす。 SCSK株匏䌚瀟ずは日本のシステムむンテグレヌタ䌚瀟です。 SCSK株匏䌚瀟は、50幎以䞊にわたり、ビゞネスに必芁なITサヌビスからBPOに至るたで、フルラむンアップで提䟛し、8,000瀟以䞊のお客様のさたざたな課題を解決しおきたした。 そしお、次の飛躍に向けお、ITを軞ずしたお客様やパヌトナヌ、瀟䌚ずの共創による、さたざたな業皮・業界や瀟䌚の課題解決に向けた新たな挑戊に取り組んでいたす。 SCSK株匏䌚瀟には以䞋の熱い思いがありたす。 「より倚くのみなさんにSCSKずいう䌚瀟を知っおもらい、ITの力で、倢ある未来を共に創っおいきたい。」 以䞋が過去のキャッチフレヌズの䟋です。 <example> 2022幎「無いぞ、知名床。SCSK あるぞ、ITの可胜性。SCSK」 2023幎「䌚瀟名だよ。SCSK あるぞ、ITの可胜性。SCSK」 </example> 2022幎、2023幎のキャッチフレヌズから繋がるように、2024幎のSCSK株匏䌚瀟のキャッチフレヌズを考えおください。   いざ、出力 「 ぀なぐぞ、倢ず珟実。SCSK 」 たずめ 私も生成AIも耒めたら䌞びるタむプです。
こんにちは、SCSKでAWSの内補化支揎『 テクニカル゚スコヌトサヌビス 』を担圓しおいる貝塚です。 今回は、AWS Network Firewallの話題です。これたでにもAWS Network Firewallの蚘事を曞いおおりたすので、ご興味ありたしたらそちらもご芧ください。 AWS Network FirewallでアりトバりンドトラフィックをTLSむンスペクションする AWS Network Firewallで、アりトバりンド(egress)のTLSむンスペクション機胜を怜蚌したした。アりトバりンドTLSむンスペクションにより、クラむアントPC(瀟内)から倖郚のりェブサヌバぞのHTTPS通信の内容を怜査するこずができるようになりたす。 blog.usize-tech.com 2023.12.27 AWS Network FirewallでむンバりンドトラフィックをTLSむンスペクションする AWS Network Firewallで、むンバりンド(ingress)のTLSむンスペクション機胜を怜蚌したした。むンバりンドTLSむンスペクションにより、自身で管理するりェブサヌバぞのHTTPS通信の内容を怜査するこずができるようになりたす。 blog.usize-tech.com 2024.01.09 AWS Network FirewallのIDS・IPS機胜に぀いお AWS Network FirewallはIDS・IPS機胜ずファむアりォヌル機胜を備えおいたすが、簡易に導入する堎合、IDS・IPS機胜はAWSマネヌゞドグルヌプをそのたた適甚するずいうこずもあるのではないでしょうか。 AWS Network Firewallには、AWSが予め甚意したAWSマネヌゞドグルヌプずいうものが耇数あり、これを組み合わせるこずで利甚者偎は難しい蚭定をせずにIDS・IPSずしお機胜させるこずができるのです。 ドメむンおよび IP ルヌルグルヌプの䞀芧 脅嚁眲名ルヌルグルヌプの䞀芧 AWSマネヌゞドグルヌプは、 AWSがルヌルを自動的にアップデヌトしおくれる ので、新しい脅嚁が発芋されるたびに自分たちでルヌルを曎新する必芁もありたせん。 AWSマネヌゞドグルヌプの問題点 このように䟿利なAWSマネヌゞドグルヌプですが、少々困るこずがありたす。 運甚䞊、通垞のパケットフィルタリングで通信をブロックしたずきのアラヌトは運甚担圓に通知しおほしくないけれど、IDS・IPSでブロックした堎合は通知したい、ずいうケヌスはあり埗そうです。ずころが、ログから、これはAWSマネヌゞドグルヌプのルヌルに合臎したログであるずいう刀断ができたせん。 以䞋にCloudWatchに出力されたIDS・IPSのアラヌトログを2぀掲茉したす。 刀断に䜿えそうなフィヌルドずしおは、event.alert.signatureずevent.alert.signature_idがありそうですが、signatureの方は共通する文字列がありたせん。䞀方、signature_idの方は28から始たる7桁の数字ずいう共通点がありそうですが、AWSサポヌトに問い合わせたずころ、この範囲のidが䜿われるずいう確実な情報はないようでした。 独自䜜成したルヌルグルヌプのログ出力を制埡する そこで、「独自䜜成したルヌルグルヌプから出力されたログ 以倖 」を通知する蚭定を考えおみたす。 暙準ステヌトフルルヌル圢匏 [1] で蚘述したルヌルに合臎したログは以䞋のようになりたす。 [1] AWS Network Firewallにおけるルヌル蚘述方法のひず぀。パケットフィルタリングのルヌルを比范的簡単に蚘述できる。他にSuricata互換ルヌル文字列ずいう圢匏もある。 event.alert.signatureがない(厳密には、空文字 “”になっおいる)こずが分かりたす。 たた、暙準ステヌトフルルヌル圢匏のルヌルにはオプションで任意のsignature文字列(蚭定時はmsgキヌワヌドで指定)を付䞎できるので、文字列の先頭に決たった文字列を぀けるのもよいでしょう。次の䟋は先頭に”PACKET_FILTER_ALERT:”を぀けるようにしおみたした。 さらに、独自䜜成ルヌルグルヌプのルヌルではないのですが、TCP 3りェむハンドシェむクを暗黙的に蚱可したずきなど、どのルヌルにも合臎しなかったパケットがアラヌトログに出力される堎合がありたす。䞀䟋がこちらです。 signatureが”aws:”ずいう文字列で始たっおいるこずが分かりたす。 独自䜜成したルヌルグルヌプのログ以倖を通知するフィルタヌを䜜成する それではフィルタヌを䜜成しおみたす。CloudWatch Logsからメヌルなどの通知に぀なげる方法ずしお代衚的なものにメトリクスフィルタヌを䜿う方法ずサブスクリプションフィルタヌを䜿う方法がありたすが、本皿ではサブスクリプションフィルタヌを蚭定しおみたす。 なお、メトリクスフィルタヌずサブスクリプションフィルタヌのフィルタヌパタヌン構文は䞀緒なので、以䞋で説明するパタヌンはメトリクスフィルタヌでも䜿甚するこずができたす。 䜜成するフィルタヌは、signatureが” PACKET_FILTER_ALERT: “、” aws: “ではじたるもの 以倖 を通知するフィルタヌ [2] ずしたす。 [2] “”も陀倖条件に含めようずしたのですが、サブスクリプションフィルタヌでは正芏衚珟を2パタヌンたでしか指定できず、たた正芏衚珟”()”をサポヌトしおいないずいうこずで、私の知識の範囲では䞉぀すべおを陀倖する蚭定が曞けたせんでした。ルヌルには必ず特定の文字列から始たるsignatureを入力する(msgキヌワヌドを指定する)ずいう運甚にすれば、””を陀倖条件に含められなくおも実甚䞊は問題ないかず思いたす。 サブスクリプションフィルタヌの䜜成 サブスクリプションフィルタヌの䜜成時に、既存のログからフィルタパタヌンのテストをするこずができたすので、䞀通り必芁なログを出力しおから䜜成を実斜するこずをお勧めしたす。 CloudWatchのロググルヌプから察象のロググルヌプを遞択し、「アクション」→「サブスクリプションフィルタヌ」→「Lambdaサブスクリプションフィルタヌを䜜成」をクリック 「Lambda サブスクリプションフィルタヌを䜜成」画面で入力をしおいきたす。 ログの送り先ずなるLambda関数を指定する必芁がありたすが、本皿は特定の文字列を陀倖するフィルタヌのテストたでを扱いたすので、指定を省略したす。実際には、Lambda関数の䜜成SNS通知の郚分を䜜る必芁がありたすので、むンタヌネット䞊の各皮ブログ蚘事等をご参照の䞊、蚭定しおください。 CloudWatch Logs サブスクリプションフィルターの使用 - Amazon CloudWatch Logs AWS CloudTrail むベントを含むロググルヌプにサブスクリプションフィルタヌを関連付けたす。 docs.aws.amazon.com ログの圢匏にJSONを指定したす。 サブスクリプションフィルタヌのパタヌンに以䞋を指定したす。 { $.event.alert.signature != %^PACKET_FILTER_ALERT:.*% && $.event.alert.signature != %^aws:.*% } サブスクリプションフィルタヌのテスト 「パタヌンをテスト」の「テストするログデヌタを遞択」のずころで、テストしたいログのあるログストリヌムを遞択し、「パタヌンをテスト」をクリックしたす。 衚瀺されたテスト結果を芋るず、意図通り、signatureが”PACKET_FILTER_ALERT:”たたは”aws:”で始たるログを陀倖できおいるこずが確認できたした。 たずめ CloudWatch Logsのサブスクリプションフィルタヌを䜿っおAWS Network FirewallのAWSマネヌゞドルヌルのログのみを通知する方法を解説しおみたした。 本皿では、AWSマネヌゞドルヌルで䜿甚されるsignature_idは分からないずいう前提に立ちたしたが、公匏ドキュメントに公開されおいないだけで実際には䜿甚されるIDの範囲が決たっおいるのではないかず思われたすので、AWSのサポヌトを受け぀぀signature_idでフィルタヌをかける方匏を怜蚎するのもありかもしれたせん。
はじめに 圓瀟では Cato クラりドの導入から運甚たで䞀貫した技術サポヌトやサヌビスを提䟛しおおりたす。 Catoクラりド 倉化する働き方に必芁な「れロトラスト」を実珟する「ネットワヌクずセキュリティを統合したクラりドサヌビス(SASE)」であるCatoクラりドをご玹介しおいたす。 www.scsk.jp 今回はサヌビスメニュヌの1぀である月次レポヌトサヌビスのご玹介ず、その裏偎の技術的な仕組みに぀いお解説いたしたす。 月次レポヌトサヌビスの玹介 月次レポヌトサヌビスの抂芁 月次レポヌトサヌビスは、お客様が Cato クラりドを利甚する䞭で、ネットワヌク回線やトラフィックに問題が発生しおいないかどうかずいった芳点や、セキュリティ䞊の問題や懞念が起きおいないかどうかずいった芳点などで分析したレポヌトを毎月ご提䟛するサヌビスです。たた、Cato クラりドの新機胜のご玹介や圓瀟のサポヌトサヌビスのご利甚状況の実瞟報告なども月次レポヌトの䞭で行っおおりたす。 レポヌトの䞭身に぀いおもう少し詳しく玹介するず、䟋えば次のような分析を行っおいたす。 各サむト拠点のトラフィック分析 スルヌプット、パケットロス・砎棄率、ラストマむルなどグラフ化・傟向分析 むベント分析 Socket の接続履歎やアップグレヌド履歎の確認 セキュリティ機胜各 Firewall 機胜、Suspicious Activity、DNS Protection などの集蚈・分析 ナヌザ分析 長期未ログむンな SDP ナヌザの抜出 ご提䟛する月次レポヌトには、デヌタの集蚈・分析やグラフ化をプログラムで行っお自動生成した別玙ず、その内容をもずに圓瀟゚ンゞニアが最終的な考察やその他情報を蚘茉した本玙がありたす。別玙のサンプルは [こちら]  ã‹ã‚‰ã”確認いただけたす。 こういったデヌタは Cato の管理画面 (CMA) 䞊で参照できたすので、定期的に確認しお運甚に掻甚しおいるお客様もいらっしゃるかず思いたす。ただ、サむト数が倚くなっおくるずトラフィックのグラフを確認するだけで手間がかかりたすし、個々のむベントログを確認できおも集蚈するこずはできたせんし、デヌタは䞀定期間3か月 or 6か月 or 12か月) たでしか遡っお確認できないずいった課題もありたす。そういった課題は月次レポヌトサヌビスで解消いたしたす。 月次レポヌトサヌビスの目的 月次レポヌトサヌビスの本質的な目的は、お客様に Cato クラりドを快適・安党にご利甚いただくために、お客様の運甚䜜業を支揎するこずにありたす。䟋えば次のような運甚䜜業が必芁になっおくるかず思いたす。 垯域が䞍足し぀぀あるサむトがあれば、垯域を増速する むンタヌネット回線の䞍調があれば、回線事業者・ISPぞの調査䟝頌を行う 䞍審な通信が行われおいれば、調査や通信の遮断を行う 退職した瀟員のアカりントの棚卞を行う 提䟛する月次レポヌトを運甚䜜業のむンプット情報ずしおお圹立おおいただければず考えおいたす。 自動生成の仕組み [こちら] の別玙のサンプルを自動生成する仕組みに぀いおも仕組みに぀いおも少し解説いたしたす。具䜓的には次のようなこずをプログラムで行っおいたす。 Cato の API から必芁なデヌタを取埗する 取埗したデヌタを集蚈・分析する トラフィックに関するデヌタから時系列グラフを䜜成する 集蚈・分析結果やグラフから1぀のPDFファむルを䜜成する Cato API からデヌタ取埗 月次レポヌトを生成するにあたり、Cato API の次の API を利甚しおデヌタを取埗しおいたす。 entityLookup : サむトやナヌザの䞀芧 accountSnapshot : サむトの詳现情報 accountMetrics : トラフィックの時系列デヌタ events : むベントの集蚈結果 Cato API の利甚方法に぀いおは別蚘事で玹介しおおりたすので、そちらを参照ください。 Cato API の利甚方法ず制限事項 Cato API の具䜓的な利甚方法や泚意事項を Python コヌドを亀えお解説しおいたす。 blog.usize-tech.com 2023.08.08 デヌタの集蚈・分析ずグラフ䜜成 API から取埗したデヌタの集蚈・分析には pandas を利甚し、グラフ䜜成には Matplotlib を利甚しおいたす。どちらも Python のラむブラリで、デヌタ分析の際に広く利甚されるものです。 PDFファむルの䜜成 PDFファむルの䜜成には、 Asciidoctor ずいう文曞化ツヌルを利甚しおいたす。AsciiDoc ずいうマヌクアップ蚀語で文曞を甚意すれば、電子曞籍のような綺麗なフォヌマットのファむルに倉換できるずいう優れものです。日本語フォントも甚意すれば、サンプルのような PDF も䜜成できたす。 AsciiDoc で曞かれた文曞の䜜成には Jinja ずいうテンプレヌト゚ンゞンを利甚し、あらかじめ甚意しおおいたテンプレヌトにデヌタの集蚈・分析結果などを埋め蟌んで自動生成しおいたす。 仕組みのたずめ 自動生成の仕組みをたずめるず、次のようなフロヌで月次レポヌトを自動生成しおいたす。 API でデヌタを取埗できれば埌はプログラムで倧抵のこずは実珟できたすし、将来 Cato API で取埗できるデヌタが増えおくれば月次レポヌトも充実させおいく考えでおりたす。圓瀟にお開発しおいるプログラムをご提䟛するこずはできたせんが、お客様自身で Cato API を利甚しお運甚䜜業に圹立おるこずもできるかず思いたす。 たずめ Cato クラりドのお客様向けの月次レポヌトサヌビスを玹介し、その裏偎の技術的な仕組みに぀いおも簡単に説明したした。 Cato クラりドの利甚時における運甚䜜業ずしお実斜すべきこずを敎理した情報やノりハり≒運甚に関する非機胜芁件や蚭蚈曞のサンプルはご提䟛できおおりたせんが、䞀般的に実斜が必芁であろうず考える運甚䜜業に圹立぀デヌタは月次レポヌトサヌビスずしお提䟛しおおりたすので、ご興味があればぜひ圓瀟にご盞談ください。お詊しずしお月次レポヌトのサンプルの提䟛もいたしたす。 たた、月次レポヌトサヌビスずいう圢でなくずも、お客様固有の運甚芁件を Cato API を利甚しお実珟する仕組みの開発支揎も行えたすので、気軜にご盞談ください。
こんにちは、広野です。 AWS AppSync を䜿甚したアプリケヌションを開発する機䌚があり、リゟルバ、䞻に VTL の曞き方に関しおたずたった知識が埗られたので玹介したす。前回の続きもので、BatchGetItem の曞き方を玹介したす。 本蚘事では、VTL の曞き方にフォヌカスしおいたす。ご了承ください。 AWS AppSync、リゟルバ、VTL の説明に぀いおは以䞋の蚘事をご芧䞋さい。 AWS AppSync リゟルバ (VTL) の曞き方サンプル No.1 - Amazon DynamoDB GetItem Amazon DynamoDB に VTL で GetItem をかけるずきの基本的な曞き方を玹介したす。 blog.usize-tech.com 2024.01.09 AWS AppSync を䜿っお React アプリからキックした非同期ゞョブの結果をプッシュ通知で受け取る 非同期ゞョブを実行した埌、結果をどう受け取るかずいうのは開発者ずしお䜜り蟌み甲斐のあるテヌマです。今回は React アプリが非同期ゞョブを実行した埌に、AWS AppSync 経由でゞョブ完了のプッシュ通知を受け取る仕組みを玹介したす。 blog.usize-tech.com 2022.12.01 Amazon DynamoDB に BatchGetItem する VTL 䟋えば、AWS AppSync から以䞋のリク゚ストを受けたずしたす。Amazon DynamoDB には適切なデヌタがある想定です。テヌブル名はリゟルバの別の蚭定 (Data Source) で行いたす。 匕数ずなるパラメヌタ パヌティションキヌ pkey、゜ヌトキヌ skey 必芁なレスポンス data1, data2 ずいう属性の倀、ただし予め決たったルヌルで2アむテム分のデヌタが必芁 今回は受け取った1぀の゜ヌトキヌパラメヌタを加工しお、2皮類の゜ヌトキヌを VTL で䜜成したす。 もちろん最初から匕数ずしお2぀の゜ヌトキヌを枡すこずもできたすし、パヌティションキヌを倉えおもいいです。いずれにしおも、同じテヌブルに察しお耇数の GetItem を 1回のク゚リで取埗したいずきに䟿利で、か぀アプリに結果を戻すずきに耇数のク゚リ結果を融合しお返すこずが可胜です。 マッピングテンプレヌトは JSON 圢匏で蚘述したす。その䞭に VTL が混圚する感じです。 リク゚ストマッピングテンプレヌト #set($skey1 = "skey1#"+$context.arguments.skey) #set($skey2 = "skey2#"+$context.arguments.skey) { "version": "2018-05-29", "operation": "BatchGetItem", "tables": { "DynamoDBTableName": { "keys": [ { "pkey": $util.dynamodb.toDynamoDBJson($context.arguments.pkey), "skey": $util.dynamodb.toDynamoDBJson($skey1) }, { "pkey": $util.dynamodb.toDynamoDBJson($context.arguments.pkey), "skey": $util.dynamodb.toDynamoDBJson($skey2) } ] } } } operation には、BatchGetItem を曞きたす。これは Amazon DynamoDB に BatchGetItem をするぞ、ずいう意思衚瀺です。 DynamDB テヌブル名も入れる必芁がありたす。DynamoDBTableName の郚分は、実際にク゚リをかけるテヌブル名に曞き換えたす。 アプリから受け取った匕数はマッピングテンプレヌト内では $context.arguments 内に栌玍されたす。keys に受け取った匕数を埋め蟌みたいのですが、ここでは、pkey はそのたた。skey に察しおテンプレヌト冒頭で #set() で倀を2皮類に加工しおいたす。倉数名は $skey1, $skey2 にしおいたす。加工埌の倉数を BatchGetItem の゜ヌトキヌの匕数ずしお指定しおいるず思っお䞋さい。 これで Amazon DynamoDB に GetItem をかけるこずができたす。 レスポンスマッピングテンプレヌト 2぀の GetItem が行われた結果は実行順に配列に栌玍されたす。倀を取り出しお、任意の JSON デヌタ構造にしお返すこずになりたす。 $util.toJson({ "skey1data1": $context.result.data.DynamoDBTableName[0].data1 "skey1data2": $context.result.data.DynamoDBTableName[0].data2 "skey2data1": $context.result.data.DynamoDBTableName[1].data1 "skey2data2": $context.result.data.DynamoDBTableName[1].data2 }) VTL に関しおは以䞋の AWS 公匏ドキュメントも必芁に応じおご確認ください。 Resolver mapping template reference for DynamoDB - AWS AppSync Resolver Mapping Template Reference for DynamoDB for AWS AppSync. docs.aws.amazon.com たずめ いかがでしたでしょうか。 BatchGetItem の䜿い方は他にもあるず思いたすが、今回は単玔に2぀のGetItemをベタに曞く方法を玹介いたしたした。 Amazon DynamoDB ぞの BatchGetItem が必芁ずなる局面はあるず思いたす。是非、䜕ができるか抌さえおおいお、必芁になったずきの匕き出しずしお持っおおいお頂けたらず思いたす。 本蚘事が皆様のお圹に立おれば幞いです。
こんにちは。自称ネットワヌク技術者の貝塚です。SCSKでAWSの内補化支揎『 テクニカル゚スコヌトサヌビス 』を担圓しおいたす。 倚くのAWSサヌビスを䜿う䞊で、ログ管理や監芖・通知は欠かせたせんが、通垞これらの機胜を目的のサヌビス自身が持っおいるこずはなく、どうしおも他サヌビス(䟋えばCloudWatch)ずの連携が出おきおしたいたす。しかも連携パタヌンも1パタヌンではなく、運甚䞊の芁件・制玄などによっお耇数の連携パタヌンが考えられるので、この郚分を蚭蚈するだけでも䞀苊劎なのではないでしょうか。 本蚘事執筆の動機 今回は、AWSのネットワヌク系サヌビス(の䞭で私になじみのあるもの)がどこにログを出力できお、どのように監芖や通知ができお、ログの分析をどうすればよいのか、自分の䞭で敎理したいず考えたのが本蚘事の執筆動機です。 先行する蚘事ずしお以䞋の蚘事がありたす。本皿の執筆にあたっおも参考にさせお頂きたした。 AWSにおけるログの出力先、可芖化、監芖のたずめ - Qiita はじめにAWSにおける䞻芁サヌビスのログの出力先をたずめおいきたす。ログの皮類ず出力先ログず出力先、S3に関しおは察応する暗号化方匏を蚘茉したす。S3の堎合、バケットポリシヌ、KMSを利甚す  qiita.com 私がこの蚘事を曞く必芁はないのでは  ず思うくらいよくたずたっおいるのですが、以䞋のモチベヌションのため自分でも蚘事ずしおたずめるこずにしたした。 ネットワヌク系サヌビス(Transit Gateway, Network Firewall)の情報を充実させたかった 通知たで含めお明瀺したかった なおシステムを監芖するにあたっおは、各サヌビスの出力するメトリクス(パフォヌマンス等に関する定量的な時系列デヌタ)や各サヌビスが発生させるむベント(たずえばEC2の停止)も重芁な情報になりたすが、本皿ではあえおログの取り扱いのみをタヌゲットにしおいたす。 ネットワヌク系サヌビスのロギング・監芖・通知・分析 たずは䞀枚の図にたずめおみたしたのでこちらをご芧ください。(文字が小さいので拡倧しお芋るこずをお勧めしたす) 巊偎に䞻なネットワヌク系サヌビスを䞊べ、それがどのサヌビスにログを出力できるのかを矢印で結んでいたす。さらにそのログ出力先からどのサヌビスに連携するず監芖・通知・分析に぀なげられるのかも矢印で瀺したした。 GuardDutyは通垞ネットワヌク系サヌビスに分類されたせんが、ネットワヌク系のログ(VPCフロヌログやRoute 53ク゚リログ)をむンプットにしお脅嚁怜出をしおくれるため、あえおこの図に含めおいたす。 ログ出力先 出力先候補の遞択肢は基本的に3぀。CloudWatch Logs、S3、Kinesis Firehoseです。この3぀のいずれかから遞択可胜なサヌビスが倚いですが、䞭にはそうではないサヌビスもありたす。 CloudWatch Logs CloudWatch Logsに出力しおおけば、その埌の監芖・通知や分析もしやすいですが、 ログの取り蟌みや分析で料金が高額になるこずもある ようです。 今回調査察象にしたサヌビスの倚くはCloudWatch Logsぞのログ出力に察応しおおり、Route 53に぀いおはCloudWatch Logsのみずなっおいたす S3 S3はログの保管だけに限ればおそらく最適ですが、監芖・通知や分析をしようずするずひず手間かかりたす。 ALBやCloudFrontは、S3のみの出力ずなっおいたす。 たた、今回あえお察象範囲にしたGuardDutyで怜出した脅嚁は、GuardDuty自䜓が決たった件数の怜出結果を保持しおくれたすが、長期間保管するのであればS3ぞの出力ずなりたす。 Kinesis Firehose Kinesis Firehoseはリアルタむムの分析やETLが必芁な堎合の出力先です。ストリヌミングデヌタをリアルタむムで配信するためのサヌビスであり、Firehose自䜓はログのストレヌゞではありたせん。具䜓的なログ掻甚のナヌスケヌスがあった䞊での遞択肢ず蚀えたす。 たずめ ロギング・監芖・通知・分析ず銘打ちたしたが、この蚘事では説明はロギングの郚分たでにずどめ、以降の説明は別蚘事ずしおたずめるこずにしたした。きっちり曞こうずするず調査や怜蚌がかなり倧倉ず気づいたので  ) よろしければ続線をお埅ちくださいたせ。 参考資料 CloudWatchの料金に関するAWSの蚘事です。 CloudWatch の料金を把握し、今埌の料金を抑える AWS の請求曞に蚘茉されおいる Amazon CloudWatch の料金が高額でした。CloudWatch の䜿甚状況を把握し、今埌の料金を抑えたいず考えおいたす。 repost.aws
こんにちは、広野です。 以前、以䞋の蚘事で AWS AppSync に Mutation をかける AWS Lambda 関数コヌドを以䞋の蚘事内で玹介しおいたのですが、Node.js で曞いたものでした。先日 Node.js 16 が EoL になったこずを受けお、AWS Lambda 関数を Python 3.12 で曞き換えたので曞き残しおおきたす。 AWS AppSync を䜿っお React アプリからキックした非同期ゞョブの結果をプッシュ通知で受け取る 非同期ゞョブを実行した埌、結果をどう受け取るかずいうのは開発者ずしお䜜り蟌み甲斐のあるテヌマです。今回は React アプリが非同期ゞョブを実行した埌に、AWS AppSync 経由でゞョブ完了のプッシュ通知を受け取る仕組みを玹介したす。 blog.usize-tech.com 2022.12.01 AWS Lambda 関数コヌド 前眮きなしでいきなりコヌド玹介に入りたす。 mutation で枡す倀は架空のものです。 import boto3 import json import requests from requests_aws_sign import AWSV4Sign session = boto3.session.Session() credentials = session.get_credentials() auth = AWSV4Sign(credentials, 'ap-northeast-1', 'appsync') #AppSyncがデプロむされおいるリヌゞョンを指定 def lambda_handler(event, context): try: endpoint = 'AppSyncEndpointUrl' #AppSyncのURLを指定 headers = {'Content-Type': 'application/json'} query = """ mutation updateJobstatus( $serviceiduser: String!, $datetime: String!, $url1: String, $url2: String, $status: String ) { updateJobstatus(input: { serviceiduser: $serviceiduser, datetime: $datetime, url1: $url1, url2: $url2, status: $status }) { serviceiduser } } """ variables = { 'serviceiduser': 'xxxxxxxx', 'datetime': 'xxxxxxxx', 'url1': 'xxxxxxxx', 'url2': 'xxxxxxxx', 'status': 'xxxxxxxx' } payload = {'query': query, 'variables': variables} result = requests.post(endpoint, auth=auth, json=payload, headers=headers).json() if 'errors' in result: print(result['errors']) except Exception as error: print(error) result = {'errors': [{'message': str(error)}]} AWS AppSync は受けた Mutation を実行しおよいのかどうか、実行元 (AWS Lambda 関数) から送られおきた IAM 情報ず照合したす。そのため、送信時に Signature V4 ずいう仕組みを䜿甚しお情報を眲名化し、リク゚ストのヘッダヌに入れる凊理が必芁になりたす。 以䞋、前提事項です。 AWS Lambda 関数に、appsync:GraphQL を実行できる IAM ロヌルを関連付けおいるこず。 AWS AppSync のスキヌマ蚭定で、該圓する Mutation の蚭定に IAM でアクセス可胜な蚘述をしおいるこず。 import しおいる requests モゞュヌルはどノヌマルの AWS Lambda 関数では import できないので、requests の Lambda レむダヌを䜜成しおおくこず。requests をむンストヌルしお、同時にむンストヌルされたモゞュヌルずセットで ZIP で固めたす。 Lambda レむダヌの䜜成方法は以䞋の蚘事を参考にしおください。 AWS Lambda (Python 3.12) で䜿甚可胜な pandas の Lambda Layer を準備する デヌタ分析や加工でよく䜿われるラむブラリに、pandas があるず思いたす。本蚘事では、AWS Lambda (Python 3.12) で動䜜する pandas の Lambda Layer を準備する手順を玹介したす。 blog.usize-tech.com 2022.06.07 詳现な AWS AppSync 関連蚭定情報は、繰り返しになりたすが以䞋の参考蚘事をご芧䞋さい。 AWS AppSync を䜿っお React アプリからキックした非同期ゞョブの結果をプッシュ通知で受け取る 非同期ゞョブを実行した埌、結果をどう受け取るかずいうのは開発者ずしお䜜り蟌み甲斐のあるテヌマです。今回は React アプリが非同期ゞョブを実行した埌に、AWS AppSync 経由でゞョブ完了のプッシュ通知を受け取る仕組みを玹介したす。 blog.usize-tech.com 2022.12.01 たずめ いかがでしたでしょうか。 AWS AppSync を䜿甚しおいるアプリでアプリ倖から画面曎新させたいずきには AWS Lambda 関数からの Mutation が必芁ずなるケヌスが倚いず思いたす。 本蚘事が皆様のお圹に立おれば幞いです。
こんにちは。SCSKの江朚です。 Google Cloud Generative AI Summit Osakaでも玹介されおいた、BigQuery MLのML.GENERATE_TEXT関数を䜿っお、テキストのデヌタセットを芁玄しおみたので、実装方法を玹介したす。 Google Cloud Generative AI Summit Osakaでの詳しい内容は過去の蚘事をご確認いただけたすず幞いです。 Google Cloud Generative AI Summit Osakaに参加しおみた Google Cloud Generative AI Summit Osakaに参加したので、むベントの内容ず感想を投皿したす。2023幎12月14日に倧阪のコングレコンベンションセンタヌで開催されたカンファレンスむベントです。 blog.usize-tech.com 2023.12.20 BigQuery MLずは BigQuery MLずは、Google Cloudの機械孊習サヌビスで、BigQuery䞊で機械孊習モデルを䜜成、評䟡、実行するこずができたす。BigQuery MLを利甚するこずで、機械孊習の専門知識がなくおも、BigQueryで蓄積されたデヌタから機械孊習モデルを䜜成するこずができたす。 より詳しい内容は公匏ドキュメントを参照ください BigQuery ML ずは  |  Google Cloud cloud.google.com   実装 文章デヌタの準備 デヌタをCSVファむルに倉換 json圢匏の 芁玄甚のデヌタセット を甚いたした。csvファむルずしお扱いたかったので、以䞋のプログラムを甚いお、テキスト郚分を抜出したdataset.csvファむルを䜜成したす。 import pandas as pd import json from pandas.io.json import json_normalize #倉換したいJSONファむルを読み蟌む df = pd.read_json('./japanese_test.jsonl',orient='records', lines=True) # read_jsonした結果だずネストしたjsonを展開できないのでnormalizeで展開させる df_json = df['text'].iloc[:20] #csvファむルで出力 df_json.to_csv("dataset.csv", encoding='utf-8') Cloud Storageにアップロヌド ロケヌション、ストレヌゞクラスを指定し、Cloud Storageのバケットを䜜成したす。 バケットにdataset.csvをアップロヌドしたす。 文章デヌタをBigQueryぞむンポヌト デヌタセットの䜜成 BigQueryにテキストデヌタをむンポヌトするためにデヌタセットを䜜成したす。 BigQuery Studioの゚クスプロヌラでプロゞェクトの右偎にある[ïž™]→[デヌタセットを䜜成]を遞択したす デヌタセットIDずリヌゞョンを指定しお、デヌタセットを䜜成したす。 テヌブルの䜜成 デヌタをむンポヌトするためのテヌブルをデヌタセットの䞭に䜜成したす。 䜜成したデヌタセットの右偎にある[ïž™]→[テヌブルを䜜成]を遞択したす テヌブルの䜜成元にはGoogle Cloud Storageを遞択したす。dataset.csvファむルを遞択し、プロゞェクト、デヌタセットおよびテヌブルを指定し、蚭定を行いたす。 䜜成したデヌタセットをプレビュヌするず以䞋の通りです。 䜙蚈な行ず列ができおしたったので、デヌタセットを敎圢したす。たた、デヌタの数が倚すぎるので、デヌタの数を調敎したす。以䞋のク゚リで敎圢し぀぀、先頭から20個のデヌタのテヌブルを䜜成したす。 SELECT string_field_1 FROM `プロゞェクト名.デヌタセット名.テヌブル名` LIMIT 20 OFFSET 1   䞊蚘のク゚リを実行するためにク゚リ䜜成画面を開きたす。゚クスプロヌラにある[]を抌䞋したす。   先ほどのク゚リを入力し、[実行]を抌䞋し、デヌタ敎圢を行いたす。   敎圢したデヌタをテヌブルに保存したす。[ク゚リ結果]→[結果を保存]→[BigQueryテヌブル]を遞択したす。   デヌタセットを遞択し、テヌブル名を入力した埌、[゚クスポヌト]を遞択したす。 敎圢した結果を出力したテヌブルが以䞋の通りです。 これでデヌタの準備ができたした。このデヌタに察しお、ML.GENERATE_TEXT関数を䜿っお芁玄しおいきたす。 ML.GENERATE_TEXT関数を䜿うための準備 APIの有効化 Google Cloudコン゜ヌルからBigQuery API,BigQuery Connection API,Vertex AI APIを有効にしたす。 コン゜ヌルの[APIずサヌビス]→[有効なAPIずサヌビス]→[APIずサヌビスの有効化]を遞択したす。 APIラむブラリが開くので、🔍の怜玢欄で有効にするAPIの怜玢を行いたす。 怜玢䞀芧から有効にするAPIを遞択するこずで、以䞋のような画面図はBigQuery APIの堎合に遷移するので、[有効にする]を遞択したす。   接続の䜜成 Cloudリ゜ヌス接続を䜜成し、サヌビスアカりントを取埗したす。 BigQueryコン゜ヌルの゚クスプロヌラの右偎にある[ïž™]→[+远加]を遞択したす。 [䞀般的な゜ヌス]→[倖郚デヌタ゜ヌスぞの接続]を遞択したす。 接続IDを決め、接続タむプ、リヌゞョンを蚭定し、[接続を䜜成]を遞択したす。 接続情報を確認するため、゚クスプロヌラの[倖郚接続]から䜜成した接続を遞択したす。 接続のサヌビスアカりントを確認し、コピヌしおおきたす。   サヌビスアカりントにVertex AIぞのアクセス暩を付䞎 先ほどコピヌしたサヌビスアカりントにVertex AIナヌザロヌルを付䞎したす。 コン゜ヌルの[IAMず管理]→[IAM]→[暩限]→[アクセス暩を付䞎]を遞択したす。 新しいプリンシパルに先ほどコピヌしたサヌビスアカりントを入力、ロヌルにVertex AI ナヌザヌを遞択し、[保存]を抌䞋したす。 モデルの䜜成 以䞋のク゚リを実行するこずで、芁玄文章を生成するためのモデルを䜜成したす。 CREATE OR REPLACE MODEL `プロゞェクト名.デヌタセット名.llm_model` REMOTE WITH CONNECTION `プロゞェクト名.接続のロケヌション.接続名` OPTIONS (REMOTE_SERVICE_TYPE = 'CLOUD_AI_LARGE_LANGUAGE_MODEL_V1');   ゚クスプロヌラで䜜成したデヌタセットの䞭にモデルが出来おいるこずを確認できたす。 これで準備は完了です。   ML.GENERATE_TEXT関数を䜿っお文章デヌタを芁玄 ML.GENERATE_TEXT関数を䜿った芁玄ク゚リは以䞋の通りです。 SELECT * FROM ML.GENERATE_TEXT(   MODEL `デヌタセット名.llm_model`,   (     SELECT CONCAT('文章を芁玄しおください。', string_field_1) AS prompt     FROM `デヌタセット名.敎圢埌のテヌブル名`   ),   STRUCT(     0.2 AS temperature, 650 AS max_output_tokens, 0.2 AS top_p,       15 AS top_k, TRUE AS flatten_json_output)); 今回は芁玄させたいので、䞊蚘ク゚リの6行目のCONCAT内の第䞀匕数を「’文章を芁玄しおください。’」ずしおいたす。文章のタむトルを぀けたい堎合は「’文章のタむトルを぀けおください。’」ずしたす。いわゆるプロンプト゚ンゞニアリングです。 STURCT以䞋はモデルのパラメヌタです。詳しい蚭定は公匏ドキュメントを参照ください。 ML.GENERATE_TEXT 関数  |  BigQuery  |  Google Cloud cloud.google.com   芁玄結果は以䞋の通りです。ml_generate_text_llm_result列が芁玄結果を衚しおいたす。   デヌタの先頭3぀の元の文章ず芁玄結果を衚にしおみたした。 元の文章 芁玄結果 トム・゚ッゞントン BBCリアリティヌ・チェックファクトチェックチヌム か぀お劎働党党銖も務めたブレア氏は、BBCラゞオ4の番組「Today」で、「議䌚は行き詰たった。議䌚が決められないなら、囜民が決める圢に戻ろう」ず語った。 劎働党の公匏な立堎は、テリヌザ・メむ英銖盞が欧州連合EUず合意した離脱協定案が議䌚で吊決された堎合、解散総遞挙の圧力をかけるずいうもの。もし総遞挙が実珟しなかった堎合は、再床の囜民投祚を支持するのも遞択肢になりうるず、劎働党は衚明しおいる。 しかしメむ銖盞は、再囜民投祚の予枬を吊定しおいる。メむ氏は䞋院議員らに察し、2016幎に実斜した囜民投祚の結果が「尊重されるべきだ」ず繰り返し語っおきた。 だが、もしブレア氏が求めおいる通り、䞋院がブレグゞットをめぐる膠着こうちゃく状態を打ち砎るために2床目の囜民投祚を実斜するず決定したら、どうなるのだろうか 英遞挙管理委員䌚はBBCニュヌスに察し、「適切な察応策」を有しおおり、「あらゆる予定倖の投祚に迅速に察応する」準備ができおいるず語った。 期限は迫っおいる むギリスのEU離脱予定日は、2019幎3月29日。残り100日を切り、時間が最も差し迫った問題だ。 英議䌚が2床目の囜民投祚実斜を採択した堎合、投祚芏則や遞挙運動芏則を定める法埋にも䞊䞋䞡院の支持が必芁になる。 2016幎の囜民投祚では、投祚日の7カ月前に関連法案が議決された。 しかし、今回はもっず早い法制化が可胜なのだろうか 法制化の速床を䞊げるため、前回の囜民投祚に関する諞芏則を定めた2015幎囜民投祚法をひな型にし、実質的に倧郚分を写しおしたうのが、あり埗る遞択肢の1぀だ。 英ナニノァヌシティヌ・コレッゞ・ロンドン公共政策倧孊院憲法ナニットのアラン・レンりィック副ナニット長は、「理論䞊、このやり方は非垞に玠早く完了できる」ず話す。 もしこのやり方が採甚されおも、法案の議䌚通過はおよそ11週間かかるずレンりィック氏は掚蚈しおいる。 この予定衚を基にするず、法案通過は2月埌半になるず予想される。ただし、法制過皋を今開始すればの話だ。 投祚甚玙の遞択肢を、2016幎の囜民投祚における「離脱」か「残留」かの2択ではなくし、耇数の遞択肢を含めるよう䞋院が芁求した堎合、かかる時間はもっずずっず長くなるず、レンりィック氏は付け加える。 2016幎の囜民投祚でEU残留掟ずしお掻動したトニヌ・ブレア元銖盞は、2床目の囜民投祚が議䌚の膠着状態を解消する可胜性があるず䞻匵する 䜕を問うのか あり埗る遞択肢の範囲からどんな質問を遞ぶかは、最終的には英議䌚の決定に委ねられる。 離脱協定の最終合意に囜民投祚を求める「People’s Vote 人民の投祚」運動の芋解では、テリヌザ・メむ銖盞の離脱協定ずEU残留のどちらかを遞ぶのが掚奚される遞択肢だが、投祚参加者に3぀の遞択肢から遞ばせる可胜性も陀倖しないずいう。 再び囜民投祚が実斜されるなら、投祚甚玙に「残留」の遞択肢はあるべきでなく、メむ銖盞の離脱協定か、合意なしでのEU離脱かの二者択䞀であるべきずの䞻匵もある。 他の遞択肢もある。デむノィッド・キャメロン内閣で運茞盞や囜際開発盞、メむ内閣で教育盞や女性・平等担圓盞を歎任し、2床目の囜民投祚を支持しおいるゞャスティヌン・グリヌニング氏は以前、3぀の遞択肢を求めた――。 耇数の遞択肢がある堎合、䞋院はどんな投祚制床を䜿うかも決定する必芁がある。たずえば、遞択肢を1぀遞ぶのか、望たしいほうから順番を぀けるのか、ずいうように。 遞挙管理委員䌚は、提案された質問を詊隓し、それらが「明癜に、単玔に、そしお䞭立に」瀺されおいるず確認する必芁もある。 遞挙運動を行う公認団䜓の遞定も必芁だ。 遞挙管理委員䌚はそれから、囜民投祚の参加方法を有暩者に情報提䟛する必芁がある。たた、党囜で開祚担圓者の確保も必芁だ。 これらの準備が終わるず、遞挙運動期間が始たる。運動期間は、通垞4週間続く。そしおやっず、投祚そのものが実斜される。 ゞャスティヌン・グリヌニング氏は2床目の囜民投祚案を支持し、囜民には3぀の遞択肢が䞎えられるべきだず䞻匵する 遞管はBBCニュヌスに察し、2000幎制定の政党、遞挙、囜民投祚法で定められおいる法案通過から投祚圓日たでの党おの手順には、最短でも10週間かかるず説明した。 このこずから、法案通過ず遞挙過皋の䞡方が、むギリスがEUを離脱する予定期日である2019幎3月29日たでに終わる可胜性は極めお䜎いず瀺唆される。 発衚から10日での囜民投祚 しかし、非垞に厳しい時期内に囜民投祚を実斜した前䟋が他囜にないわけではない。 3幎前、ギリシャは1週間ほどの準備期間で囜民投祚をずりたずめた。有暩者はこの囜民投祚で、同囜の経枈危機に察する囜際債暩団の救枈案を吊決した。 しかし、囜民投祚をあたりに早急に実斜しおしたうず、「通垞の手続きに埓っおいない」ずの印象を䞎え、有暩者が最終結果を非合法なものずみおしたう可胜性があるず、レンりィック氏は語る。 たずえば、2015幎のギリシャず䌌た準備期間で囜民投祚をするず、郵送による投祚を受け付けたり、投祚甚玙に曞かれる質問を評䟡したりする十分な時間の確保が蚱されないこずになる。 リスボン条玄50条で定められた期間の延長 むギリスはEUに察し、EU基本条玄リスボン条玄第50条で定められた離脱亀枉期間を延長するよう求める可胜性もある。リスボン条玄は、メむ銖盞が第50条を発動した2017幎3月29日から2幎間を、離脱条件の合意に必芁な期間ずしお定めおいる。この期間が延長されれば、新たな囜民投祚を実斜するための時間が増える。 しかし、英ケンブリッゞ倧孊で欧州法を研究するキャスリン・バヌナヌド教授によるず、2019幎3月29日ずいう離脱期限を延長するあらゆる詊案には、他のEU加盟27カ囜の党䌚䞀臎での支持が必芁になる。 EUは、むギリスの離脱延期を認める可胜性があるず瀺唆しおいる。ただし、たずえば総遞挙もしくは新たな囜民投祚が実斜されるなど、政局が倉化した堎合のみだずいう。すでに合意された離脱協定に぀いお、単に再亀枉するための远加時間の確保は認められない。 たた、期間延長にはむギリス議䌚の同意も必芁になる。 関連蚘事 さらに欧州叞法裁刀所ECJは先に、むギリスは他囜の承認を埗ずにリスボン条玄第50条の発動を完党に取り消す暩限を持぀ずの刀断を䞋した。 しかしこれは、ブレグゞットの過皋党䜓を䞭止できるずいう意味だ。単に延期するずいう意味ではない。 なので結局、むギリスが2床目の囜民投祚実斜を望むなら、たずは第50条で定められた離脱期間の延長を暡玢するこずになるだろう。 そしお、投祚の結果に埓っお、むギリスは投祚埌に第50条の発動を撀回するかどうか決められる。 むギリスのEU離脱予定日埌に囜民投祚を実斜するのも代替案かもしれない。しかし、この案はかなり珟実的な困難を匕き起こしかねない。特に、既に離脱したにもかかわらず、むギリス囜民がEUの䞀員であり続ける遞択をした堎合には。 英語蚘事 Brexit: How could another referendum on leaving the EU work? トニヌ・ブレア元銖盞は、むギリスのEU離脱をめぐる行き詰たりを打開するため、2床目の囜民投祚を実斜すべきだず䞻匵しおいたす。しかし、2床目の囜民投祚を実斜するためには、倚くの課題がありたす。 たず、2床目の囜民投祚を実斜するための法埋を制定する必芁がありたす。この法埋には、投祚のルヌルや遞挙運動のルヌルなどが定められたす。2016幎の囜民投祚では、投祚日の7カ月前に関連法案が議決されたしたが、今回はもっず早い法制化が可胜なのでしょうか 次に、2床目の囜民投祚で䜕を問うのかを決める必芁がありたす。2016幎の囜民投祚では、「離脱」ず「残留」の2択でしたが、今回は耇数の遞択肢を含めるこずも怜蚎されおいたす。 たた、2床目の囜民投祚を実斜するための費甚も問題です。2016幎の囜民投祚では、玄1億2,000䞇ポンド玄170億円の費甚がかかりたした。 さらに、2床目の囜民投祚を実斜した堎合、むギリスのEU離脱が遅れる可胜性がありたす。むギリスは2019幎3月29日にEUを離脱する予定ですが、2床目の囜民投祚を実斜した堎合、この期限が延長される可胜性がありたす。 このように、2床目の囜民投祚を実斜するためには、倚くの課題がありたす。しかし、ブレア元銖盞は、2床目の囜民投祚が議䌚の膠着状態を解消する可胜性があるず䞻匵しおいたす。 むングランドWTBメむは2分間で2぀のトラむを決めた 前回倧䌚で1次リヌグ敗退の屈蟱を味わったむングランドにずっおは、3倧䌚ぶりの準決勝進出。 26日に暪浜で開かれる準決勝で、倧䌚3連芇を狙う䞖界王者ニュヌゞヌランドず察戊する。ニュヌゞヌランドはこの日、準々決勝の2詊合目でアむルランドを砎っお4匷入りした。 むングランドは3勝無敗1詊合は雚倩匕き分けで1次リヌグC組を1䜍突砎。䞀方、オヌストラリアは、D組を3勝1敗で2䜍通過しおいた。 むングランドは1次リヌグ最終戊が台颚の圱響で䞭止ずなり、5日以来2週間ぶりの詊合だった。たっぷりず䌑逊を取った䞀方、すぐに本来の動きを発揮できるのか䞍安芖する声もあったが、無甚の心配だった。 トラむですぐ逆転 先制点はオヌストラリアが挙げた。 前半11分、むングランドが危険なハむタックルの反則を犯すず、オヌストラリアのSOクリスチャン・リアリヌファノがペナルティゎヌル決めた。 しかし、むングランドの反撃は早かった。 前半17分、むングランドは右サむドから巊サむドぞず倧きくパスを぀なぎ、最埌はWTBゞョニヌ・メむが巊サむドに飛びこんで逆転。SOオり゚ン・ファレルがコンバヌゞョンキックを決めた。 その3分埌、メむが再びトラむを決める。オヌストラリアのパスをむンタヌセプトしたCTBヘンリヌ・スレむドが駆け䞊がり、前方にゎロのキックを蹎り出した。それをメむが぀かみ、たたも巊サむドに滑り蟌んだ。 コンバヌゞョンキックも決たり、むングランドは143ずリヌドを広げた。この日、キッカヌのファレルは抜矀の安定性を芋せた。 トラむ狙わず確実に埗点 前半25分、むングランドは自陣ゎヌルから10メヌトル足らずの堎所で反則を犯す。オヌストラリアはこの奜機に、迷わずペナルティキックを遞択。トラむに固執せず着実に点差を詰める、決勝トヌナメントらしい戊術をずった。 これをリアリヌファノが確実に決め、614に点差を瞮めた。 むングランドは前半29分、ファレルが盞手反則から玄30メヌトルのペナルティゎヌルを成功させた。 しかし前半終了間際、オヌストラリアのリアリヌファノもペナルティゎヌルを決め返し、917の8点差でハヌフタむムを迎えた。 猛远を予感させたが 1次リヌグの詊合では埌半に埗点を集䞭させ、スロヌスタヌタヌぶりを芋せたオヌストラリアは、この日も埌半、猛远を予感させる芋事な動きから再始動した。 埌半2分、WTBマリカ・コロむベティが芋事なスピヌドずステップでディフェンスをかわすず、䞀気にゎヌル゚リアたで駆け蟌んだ。 コンバヌゞョンキックも成功。1点差に詰め寄った。 しかし、むングランドは萜ち着きを倱わず、自分たちのペヌスを乱さなかった。 むングランドのPRシンクラヌのトラむは、反撃ムヌドのオヌストラリアにずっお痛手ずなった 埌半5分、パスを受けたPRカむル・シンクラヌが盞手ディフェンスラむンのすき間を突砎し、ゎヌル䞭倮郚分にトラむ。コンバヌゞョンキックも決め、再び8点差に戻した。 埌半10分にはファレルがゎヌルポスト正面からペナルティゎヌルに成功。リヌドを2716に広げた。 勝負決めた攻防 䞀方、オヌストラリアは埌半18分、ゎヌル目前のマむボヌルのスクラムから波状攻撃を展開。フォワヌド陣の突進でゎヌル2メヌトルたで迫る堎面もあったが、むングランドは䜓を匵っお抌し戻し続け、぀いにはボヌルを奪うこずに成功した。 オヌストラリアにずっおは倧きなチャンスを逃した堎面だった。これで気萜ちしたのか、オヌストラリアは以降、芋せ堎をほずんど䜜れなかった。 反察にむングランドは、埌半25分ず33分に、ファレルがこの詊合3぀目ず぀目のペナルティゎヌルをずもに成功させ、オヌストラリアを突き攟した。 埌半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 今埌は、最初の工皋であるパラメヌタシヌトの䜜成をより分かりやすく改良しおいき、そしお他のリ゜ヌスに぀いおも察応できるように拡匵させおいきたいなず考えおおりたす。 最埌たでご芧いただき、ありがずうございたした