本記事は、本記事の内容は、Cato Networks社の以下の記事を元に日本語へ意訳、再構成したものとなります。 Cato Global Private Backbone レガシーな専用線/閉域網をやめて、インターネット回線ベースとしたSASEへ移行する企業が増えています。 企業ネットワークは、長い間、信頼性が高く、かつ手頃な価格のグローバル接続手段を見つけるのに苦労してきました。 グローバルの専用線（MPLS）接続は、非常コストが高額なため帯域幅を制限しているのが現状だと思います。 一方で、インターネットを利用したネットワーク接続は、長距離グローバル接続の遅延（レイテンシー）により、満足に利用ができない状況かと思います。 Catoクラウドでは、このようなグローバル接続の課題も解決します。 Catoクラウドの グローバルプライベートバックボーン （ Global Private Backbone ）は、世界中の90以上の接続拠点（PoP）にまたがるプライベートネットワークになります。バックボーンは手頃な価格で利用することができ、管理はすべてCato Networks社が行います。 信頼性の高いグローバル接続を手頃な価格で Catoクラウドを利用し、通信帯域を大幅に増強し、高額なIP-VPNなどのWAN回線を排除することで、エンタープライズのグローバル接続コストを劇的に削減することができます。CatoクラウドのPoPは、可用性、遅延（レイテンシー）、パケットロス、ジッターに関するSLA保証された複数のティア1プロバイダー間で相互に接続さています。Catoクラウドのソフトウェアは、プロバイダーネットワークをリアルタイムにパフォーマンス監視し、アプリケーションを意識したルーティングアルゴリズムによって、Catoクラウドのバックボーンを経由する最適なパスを選択します。ルーティングを制御し、SLA保証されたネットワークキャパシティのみを使用することで、パブリックインターネットよりもはるかに凌ぐパフォーマンスを、グローバル専用線（MPLS）よりもはるかに低いコストで実現することが可能になります。 ピークスループットのWAN最適化 Catoクラウドは、グローバルネットワークのレイテンシーを最小化するだけでなく、アプリケーションのスループットを向上させます。内蔵されているWAN最適化機能により、TCP効率が劇的に改善され、サイト（拠点）やモバイルユーザーのデータスループットが最大40倍向上させます。CatoクラウドのPoPはTCPコネクションをプロキシし、TCPクライアントとサーバーがより多くのデータをより早く送信できるようにします。また、高度なTCP輻輳制御により、Catoエッジはより多くのデータを送受信し、利用可能な帯域幅をより有効活用することができます。これらの技術により、エラー修復に必要な時間を短縮し、パケットロスによるデータスループットへの影響を軽減します。 クラウドネイティブソフトウェアによるイノベーションの加速とコスト削減 CatoクラウドのPoPは、完全にマルチテナントでスケーラブルなネットワークスタックにより、経路計算、ポリシーの実施、セキュリティ検査など、ネットワーキングとセキュリティのすべてのコア機能をクラウドネイティブで実行しています。このソフトウェアプラットフォームは、従来のカスタムハードウェア（専用機）でしか実現できなかったようなパフォーマンスを、市販のサーバー上で動作させて実現することを可能にしました。 専用アプライアンスや専用機を一切排除することで、レガシー通信ネットワークの技術面・運用面でのコストが大幅に変わります。独自ハードウェアの調達・導入がないため、Catoクラウドでは、ネットワークのフットプリントを急速に拡大することができています。現在、Catoクラウドのネットワークはすべての主要なビジネス都市をカバーしており、Cato PoPは主にソフトウェアと標準サーバで構成されているため、新しいPoPの開設も迅速に行うことができます。自社でソフトウェアを所有することで、より迅速なイノベーションが可能になり、顧客の求める機能要求に迅速に対応し、サービスの問題を迅速に解決し、運用コストとサードパーティのライセンス料を削減することができます。 セルフヒーリング（自己修復）アーキテクトによる24時間365日運用 Catoクラウドは、完全なセルフヒーリング（自己修復）アーキテクチャにより、最大限の可用性を確保します。障害の検知、フェイルオーバー、フェイルバックのすべてが自動化されており、特別な計画や事前のオーケストレーションは一切必要ありません。各PoPには、Catoのソフトウェアの同一コピーを実行する複数のコンピュートノードがあり、どのコンピュートノードでも、そのPoPに接続されたエッジトンネルにサービスを提供できます。コンピュートノードが故障した場合は、トンネルは自動的に別のノードに切り替わります。PoPへの接続ができなくなると、そのPoPに接続されたエッジ（Socket、またはCato VPNクライアント）は自動的に次に近いPoPに再接続します。また、CatoクラウドのPoP間を接続しているティア1プロバイダーでの障害や劣化が発生すると、PoPは自動的に代替のティア1プロバイダーへ切り替わります。 組み込みのエンドツーエンドの暗号化とセキュリティ Catoクラウドのセキュリティを確保するために、広範な対策が講じられています。PoP間であれ、Cato SocketやCato VPNクライアントとの通信であれ、すべての通信はAES-256暗号化トンネルによって保護されています。攻撃対象領域を最小化するため、許可されたサイトとモバイルユーザーのみがバックボーンに接続し、トラフィックを送信することができます。PoPの外部IPアドレスは、特定のDDoS対策で保護されています。また、Catoクラウドは、ISO 27001認証を取得しています。 まとめ Catoクラウドのサービスの根幹となる グローバルプライベートバックボーン（Global Private Backbone） について解説しました。 Catoクラウドに少しでも興味をお持ちになられた方は、遠慮なくSCSKまで お問い合わせ ください。 SASE、Cato Networks、Catoクラウド（Cato Cloud/Cato SASE Cloud）自体の知名度がまだまだ低い状況です。 SCSKでは、2021年からSASEの主要ソリューションを一同に紹介を行うオンラインセミナー「SCSK SASE Solution Summit（通称S4 エスフォー）」を定期的に開催しております。これまで14回開催し、1,800名以上の方にご参加をいただいております。 S4については、次回2024年4月以降に開催する予定ですので、改めてご案内いたします。 SASEや、Catoクラウドセミナー以外に、Catoクラウドのお客様導入事例の制作、 FAQサイト 運営、この TechHarmony （技術ブログ）にて、皆様のお役に立て、Catoクラウドの知名度アップに少しでも貢献できればと考えております。

Cato クラウドでは、通信先の FQDN をベースとしたトラフィック制御やアクセス制御を行うことができます。一方で、FQDN の根幹を成す DNS はアプリケーションレイヤの技術であり、ネットワークやトランスポートのレイヤからは直接扱えない技術でもあります。 そうしたレイヤの違いから Cato クラウドが通信先の FQDN をどのように識別しているのか気になりましたので、深掘りして調査検証し、いくつか浮かび上がってきた課題をここで説明します。 通信における FQDN の利用 まず、実際の通信において FQDN がどう利用されるか整理します。 クライアントがIPアドレスではなく FQDN を指定して通信を開始しようとしたとき、その通信に先立ってクライアントは FQDN の名前解決を行います。名前解決には DNS や mDNS、あるいはマシン上の hosts ファイルなどを利用し、通信相手のIPアドレスを把握します。その後、そのIPアドレスに対してパケットを送信します。 IP ヘッダや TCP/UDP ヘッダには FQDN を格納する領域がないため、クライアントが送信するパケットには通常は FQDN に関する情報は含まれていません。ただし、上位レイヤのプロトコルによっては、各プロトコルにおける必要性からデータ部 (TCP/UDP ペイロード部) に FQDN を含むものがあります。 よく利用されるプロトコルの中では、HTTP や TLS (HTTPS を含む) では次の箇所に FQDN を含められるようになっています。 HTTP の場合：HTTP リクエストの Host ヘッダまたは :authority 疑似ヘッダ プロトコル仕様： https://www.rfc-editor.org/rfc/rfc9110.html#section-7.2 TLS (HTTPS を含む) の場合：ハンドシェイク開始時に送信される ClientHello メッセージの server_name 拡張 SNI (Server Name Indication) と呼ばれる仕組み プロトコル仕様： https://www.rfc-editor.org/rfc/rfc6066.html#section-3 他にも FQDN をデータとして含むプロトコルもあると思いますが、FQDN を含まないプロトコルのほうが多いです。また、HTTP や TLS であっても FQDN を必ず含むとは限りません。   Cato クラウドによる FQDN 識別の仕組み さて、Cato クラウドはどのようにして通信先の FQDN を把握し、トラフィック制御やアクセス制御を行っているのでしょうか。 この疑問に対する回答の一部は、Knowledge Base の以下のページに記載されています。 参考： Traffic Intermittently Fails to Match Firewall Rules 上記ページによると、PoP に存在する DNS サーバは通信に先立って行われる名前解決の結果（FQDN とIPアドレスの組）をキャッシュして覚えておき、その後に行われる通信のIPアドレスを見て FQDN を識別しているようです。Internet Firewall や WAN Firewall などで通信をイベントログに出力するようにしていれば、各イベントログの “Domain Name” フィールドに識別された FQDN が格納されています。 しかし実際に検証してみると、それだけではなく HTTP 通信や TLS 通信に含まれる FQDN も参照して識別していることがわかりました。複数のパターンで試した結果、次のようになっていました。 TLS (HTTPS 含む) 通信の場合で、ClientHello メッセージに server_name 拡張が含まれている場合、server_name 拡張の値 HTTP (非暗号化) 通信の場合で、HTTP リクエストに Host ヘッダが含まれている場合、Host ヘッダの値 上記以外の場合で、PoP の DNS サーバに名前解決結果のキャッシュがある場合、キャッシュされた FQDN の値 上記以外の場合、FQDN は識別されない (“Domain Name” フィールドが存在しない) FQDN が識別されなかった場合、FQDN を指定して行う各制御機能が正常に働かない (例：Cato PoP からインターネットに出る際のIPアドレスを固定にできない、ブロックさせたい通信がブロックされない）ということにも繋がります。そういったことを避けるためにも、DNS Settings の Primary DNS の設定値を Cato の推奨通り デフォルト値 (10.254.254.1) のままとし、Socket 配下に位置するマシンや Cato Client で接続したマシンに PoP の DNS サーバを参照させることで、FQDN の識別が必ず行われるようにしましょう。   FQDN ベースの制御の課題 Cato クラウドによる FQDN 識別の仕組みがわかると、FQDN ベースの制御における課題、あるいは技術的な制約も見えてきましたので、ここでは4点挙げてみます。 異なる FQDN が同じIPアドレスを共有する場合に誤識別が起きる インターネット上では、1つのIPアドレスで複数の異なる FQDN のサービスを提供するといったことが一般的に行われています。これはクラウドサービスや共有のレンタルサーバ・ホスティングサービスなど、様々な場所で行われています。そうしたとき、異なる FQDN が同じIPアドレスとして名前解決されると、PoP の DNS サーバの名前解決結果のキャッシュ状況によっては、FQDN を識別する際に誤識別が生じる可能性があります。 実際、インターネットで名前解決可能な2つの FQDN を用意し、そのAレコードを同一のIPアドレスとし、その FQDN に対して Cato クラウド経由でアクセスして試してみました。名前解決結果のキャッシュによって FQDN を識別させるために、TLS や HTTP 以外の通信を行うアプリケーションで試しました。 FQDN① にアクセスした際、手元のマシンは PoP の DNS サーバに対して名前解決の問い合わせを行い、アプリケーションの通信は期待通り FQDN① として識別されました。その後、FQDN② にアクセスした際も同様に名前解決が行われ、期待通り FQDN② として識別されました。 その後改めて FQDN① にアクセスすると、手元のマシンには FQDN① の名前解決結果のキャッシュがあるため、PoP の DNS サーバに対して問い合わせを行わず、アプリケーションの通信が行われました。PoP の DNS サーバではIPアドレスに対して FQDN② を紐づけるキャッシュが残っているようであり、アプリケーションの通信は FQDN② として識別されてしまいました。何度か試した結果、後から名前解決を行った FQDN がそのIPアドレスに紐づけられるようでした。 インターネットにおける通信の仕組み上、こういった誤判定を Cato クラウドが技術的に解消することは不可能だろうと思います。そのため、Cato クラウドの機能で通信を明確に制御したい場合は、FQDN ではなくIPアドレスやポート番号によって制御するしかありません。ただし、TLS や HTTP 通信を行うアプリケーションではこの誤判定は生じないため、実際に課題として顕在化してIPアドレスやポート番号による制御を行う必要があるケースは稀かもしれません。 Cato PoP 側の機能のみ FQDN ベースの制御を行える 通信の FQDN を識別するにはパケットの中身を解析したり、DNS サーバの名前解決キャッシュと突き合せたりする必要があるため、現状では Cato PoP で FQDN の識別が行われています。そのため、Cato Client で接続した SDP ユーザの Split Tunnel 機能や、Socket の Bypass 機能などでは、FQDN ベースの制御は行えません。 将来的に Cato Client や Socket で FQDN を識別することで制御を行えるようになる可能性はありますが、パケット処理の負荷が高い内容でもあるため、ユーザのマシンに求められるスペックが高まったり、高価で高スペックな Socket が必要になったりするはずです。 現状では Cato PoP 側で行われる機能のみ FQDN ベースの制御を行えるのだとご理解ください。 悪意あるユーザは各種制御を回避できる TLS の server_name 拡張や HTTP の Host ヘッダの値は、ある程度知識があれば書き換えたり削除したりできます。そのようなことが行われたパケットをインターネット上のサーバが受信したときに、書き換え・削除が行われていないパケットを受信したときと同様の動作を行うようになっていると、悪意あるユーザは Cato クラウド上で行った FQDN ベースの各種制御を回避できてしまいます。 また、TLS や HTTP 以外の通信を行う場合にも、手元のマシンから Cato PoP の DNS サーバに名前解決の問い合わせを行わないようにしておけば、同様に各種制御を回避できてしまいます。 実際、server_name 拡張や Host ヘッダを適当な値に書き換えて通信すると、FQDN がその適当な値に識別されることを確認しました。また、Cato PoP の DNS サーバで名前解決を行わないようにしたうえで、server_name 拡張や Host　ヘッダを削除して通信すると、FQDN が識別されないことも確認しました。 FQDN による制御を回避できてしまうこと自体は、やはりインターネットにおける通信の仕組み上、Cato クラウドとしてはどうすることもできないように思います。悪意がなければ各種制御が回避されることはないため気にしすぎる必要はないと思いますが、厳格に制御する必要がある場合はIPアドレスやポート番号によって制御すべきですね。 Encrypted Client Hello によって通信できなくなる 2018年頃より、 Encrypted Client Hello (ECH) という TLS に関する新しい技術仕様が IETF にて議論されています。TLS 通信開始時に送信される ClientHello メッセージは鍵交換前であるため暗号化されていませんが、この ECH という技術仕様では ClientHello メッセージの一部を暗号化し、とりわけ server_name を秘匿しようとされています。 ECH の詳細はここでは説明せず Cloudflare のブログ や APNIC のブログ にお任せするのですが、端的に言うと、ClientHello メッセージの server_name 拡張の部分にはユーザのアクセス先の FQDN とは異なる値が入り、本当の FQDN は暗号化されて ClientHello メッセージに格納されるようになります。Cato クラウドやその他セキュリティソリューションなどは暗号化された部分を復号できないため、本当の FQDN を知ることができなくなります。 ECH に対応した通信を行うにはクライアントとサーバの両者がそれに対応している必要がありますが、Google Chrome や Microsoft Edge といったブラウザでは既に ECH がデフォルトで有効となっており、Cloudflare のような CDN では ECH を有効にするオプションも用意されています。そのため、今後普及することが予想され、気付かないうちに広まっているかもしれません。 一方で、クライアントが ECH に対応した通信を開始した場合、Cato クラウド側で TLS Inspection を行うようになっていると正常に通信できなくなる可能性があります。実際、日本の通信事業者のセキュリティサービスにおいても ECH により通信が行えなくなったというアナウンス もありました。TLS Inspection をバイパスすれば通信できるはずですが、CASB の各種機能は働かなくなってしまいますし、Cato クラウドが server_name 拡張の値をもとに FQDN を識別するのであれば誤識別も発生してしまいます。 ただし、Cato Client をインストールした Windows マシンを用いて ECH のテストサイトで試したところ、Cato Client 非接続時は ECH が使われたものの、Cato Client 接続時は ECH を使わずに通信していました（HTTPS レコードの問い合わせが行われていませんでした）。ECH が使われなかった理由は不明ですが、そうなるように Cato Client が Windows のレジストリを操作している可能性があります。もしそうであれば、通信できなくなる問題は起きなくて済むので良いのですが、正確な仕様は把握できておりません。   所感 Cato クラウドが通信の FQDN を識別する仕組みについて調査検証し、技術的に行えることはきちんと行う仕組みになっていると感じました。ほとんどの場合は正常に機能しますので、FQDN ベースによる制御も正しく行えるものと思います。 一方で、インターネットにおける通信の仕組み上、誤識別や悪意者が回避できるといった課題が残ってしまっています。これ自体は避けることはできませんが、将来のトラブルシューティング時にもしかしたら役立つかもしれませんので、頭の片隅に残しておきたいと思います。 Encrypted Client Hello という技術仕様については、IETF で議論されている最中でありインターネット標準となっているわけではないため、将来どうなるかはまだわかりません。CASB の各種機能を活かすには ECH を無効にせざるを得ないですが、無効にする設定をマシンに1ずつ導入していかなければならない事態はどうにか避けたいので、Cato クラウド側で何らかの対応（Cato PoP の DNS サーバが HTTPS レコードの問い合わせに応答しないようにする対応）が欲しいですね。

こんにちは！最近元気な挨拶を心がけているMasedatiです。 2023年度のAWSのアップデートを見直していたらAmazon Lexに関する以下の記事を見つけました。 Amazon Lex が Amazon Lex V2 向けの Selective Conversation Log Capture を導入 aws.amazon.com Selective Conversation Log Capture は、セキュリティやプライバシー上の懸念から会話型ログをデフォルトで有効にできない場合に、お客様がトラブルシューティングや詳細な会話分析を行うために役立ちます。… …この機能により、ユーザーが提供した承認や法的同意など、最も関連性の高いデータのみがキャプチャされ、アーカイブされます。 いったいどのような機能なのでしょうか？詳しく見ていきたいと思います。 Amazon Lexとは？ Amazon Lexとは、Amazon Alexa と同じ会話型エンジンを搭載した、音声やテキストを使用して任意のアプリケーションに対話型インターフェイスを構築するサービスです。チャットボットと呼べばイメージしやすいでしょうか。 Amazon Lexではサンプルボットが公開されており、以下は花屋を想定したチャットボットです。 ユーザの注文に対して自動応答を行っています。 なお、Amazon LexにはV1とV2がありますが、今回Selective Conversation Log Captureが使用できるのはV2のみのため、以降はAmazon Lex V2とします。   Selective Conversation Log Captureとは？ Amazon Lex V2 は、会話のテキストログを Amazon CloudWatch Logs に保存することができます。また、会話のオーディオログを S3 バケットに保存することができます。 すべてのログを保存できるのはありがたいですが、これまでは「ログを保存しない or ログを すべて 保存する」の2択だったため、ログを保存する場合、会話の中の機密情報(クレジットカード番号、セキュリティコード)もログの中に含まれる可能性がありました。 今回導入された「Selective Conversation Log Capture」は、有効化することで ログを 一部 保存することができるように なります。 具体例 Selective Conversation Log Capture 有効化前 のログはこちらです。 そして、Selective Conversation Log Capture 有効化後 のログはこちらです。 明らかに少なくなってますね。   やってみた では、花屋のサンプルボットを利用して、「Selective Conversation Log Capture」を導入してみましょう。 ボットの作成 Amazon Lexのページから「ボットを作成」ボタンをクリックします。 「例から開始」を選択し、サンプルボットとして、「OrderFlowers」を選択します。 ボットの名前を入力し、IAMロールを作成します。 児童オンラインプライバシー保護法は「 いいえ 」を選択します。 児童オンラインプライバシー保護法 (COPPA) の対象となるボットでは、会話ログを使用することはできません。 会話ログの記録 - Amazon Lex Amazon Lex V2 ボットを使用してユーザーとの会話を記録する方法を説明します。 docs.aws.amazon.com その他の設定項目はデフォルトとし、「次へ」ボタンを押します。 言語を選択し、チャットボイスの声優さんを選択後、完了ボタンを押します。 声が素敵だと思ったので、私はTomokoさんを選びました。 サンプルで作られる会話の流れは以下のようになっています。 Selective Conversation Log Captureを有効化する 今回は、新たに会話内容(顧客注文の最終確認)を追加し、その会話内容(スロット)のみログを保存してみます。 既存会話内容のログにセンシティブ情報( クレジットカード番号等 )があり、「 顧客注文の最終確認のみ記録する 」必要があると仮定します。 事前準備としてスロットタイプを定義する必要があります。 スロットタイプとは、スロット内のデータの認識と処理方法を定義するものです。 今回最終確認に対して、「はい/いいえ」の答えが期待されるので、以下のように作成します。 事前準備ができたところで、「スロットを追加」ボタンを押し、新しい会話を追加しましょう。 事前準備で作成したスロットタイプを指定し、以下のようにスロットを設定・追加します。 名前：CustomerCheck スロットタイプ：CustomerCheck プロンプト：{FlowerType} を {PickupDate} の {PickupTime} に受け取りますか？ スロットが追加できたら「インテントを保存」後、インテントリストに戻ります。 デプロイ>エイリアスを選択後、デフォルトで作成されているエイリアスを選択します。 「会話ログを管理」を押します。 テキストログを有効化し、Selectively log utterancesに✓を入れます。ログを保存するCloudWatchロググループを選びます。 なお、オーディオログは無効としました。 インテントに戻り、初期応答→詳細オプションをクリックします。 Selective Conversation Log Captureを有効にするインテントとスロットに基づいて、Session attributesに以下の形式で記載します。 [x-amz-lex:enable-text-logging: intent : slot]  = "true" 今回ログを保存するインテント名が[OrderFlowers]、スロット名が[CustomerCheck]なので、以下のように記載しました。 [x-amz-lex:enable-text-logging: OrderFlowers : CustomerCheck]  = "true" 公式ドキュメント には x-amz-lex:enable-text-logging: intent : slot と記載されてましたが、エラーがでました。 [ x-amz-lex:enable-text-logging: intent : slot ] が正しいようです。 インテントを保存後、Buildし、Testしてみましょう。 新しい会話が追加されました。 ログを確認する（再掲） では、CloudWatchログを確認してみましょう。 Selective Conversation Log Capture 有効化前 のログはこちらです。 上記会話の すべて のやりとりが保存されています。 そして、Selective Conversation Log Capture 有効化後 のログはこちらです。 “content”に表示されている内容は、該当会話でのユーザへの返答ですので、今回Selective Conversation Log Captureを有効化した CustomerCheckスロットのログのみ 保存されています。 今回は該当箇所のテキストログのみを保存しましたが、すべての会話をテキストログとして保存し、該当箇所のみオーディオログとして保存することもできます。   感想 一昔前のアップデート内容でしたが、皆様のお役に立てれば幸いです。

こんにちは！SCSKの江木です。 以前、BigQuery MLのML.GENERATE_TEXT関数を使って要約を生成させるというブログを執筆している際に、要約精度が良いモデル・プロンプトは何だろうと疑問が湧きました。 今回はこの疑問について解決するべく、流行りのLangChainを使って、要約精度が良いGoogleのLLMとプロンプトを考えてみようと思います。 ※以前のBigQuery MLのML.GENERATE_TEXT関数のブログが見たい方はこちら。 BigQuery MLのML.GENERATE_TEXT関数を使ってテキストデータを要約してみた BigQuery MLのML.GENERATE_TEXT関数を使って、テキストのデータセットを要約してみたので、実装方法を紹介します。 blog.usize-tech.com 2024.01.19 LangChainとは？ LangChainは、大規模言語モデル（LLM）を活用してサービスを開発する際に役立つオープンソースフレームワークです。LLMは、大量のデータで事前にトレーニングされた大規模な深層学習モデルで、ユーザーのクエリに対する応答を生成できます。 LangChainは、LLMと外部リソース（データソース、言語処理系）を組み合わせて、より高度なアプリケーションやサービスの開発をサポートすることを目的としています。プログラミング言語はPythonとJavaScriptに対応しています。 今回はLangChainが複数のLLMを扱えるという長所を利用します。 LangChain LangChain’s suite of products supports developers along each step of their development journey. www.langchain.com   要約精度をどのように比較するのか？ 人による要約精度評価をすることがベストですが、個人差が出てしまうため、今回は自動評価指標を使いたいと思います。生成AIの要約精度の比較にはROUGE、METEOR、BLEUといった自動評価指標が用いられることが多いですが、今回は比較的新しい指標であるBertScoreを使います。BertScoreを用いて、人が要約した文章と生成AIによって作られた要約の文章の類似度を比較することで、要約精度を導出します。 そもそもBertScoreとは？ BertScoreは、 BERTと呼ばれるTransformerベースの言語モデル を利用して、2つの文章の類似性を測定します。BERTは、文章中の単語だけでなく、文脈も考慮して単語の意味を理解することができます。 BertScoreの具体的な計算方法は以下の通りです。 2つの文章をBERTに入力し、それぞれの文のベクトル表現を得ます。 2つのベクトル表現の距離を計算します。 距離を元に、類似度スコアを計算します。 BertScoreは0~1の値を取り、1に近ければ近いほど文章の類似度が高いといえます。   検証環境およびソースコード 検証環境 本記事で検証環境として使用したのは、Google Colaboratoryです。Google Colaboratoryは、ブラウザ上で動作するJupyter Notebook環境です。無料で利用でき、Pythonコードの実行やデータ分析、機械学習などを行うことができます。 検証に使用したデータセットは 前回のブログ と同様にjson形式の 要約用のデータセット を用いました。 また、比較に使用したモデルはGoogle AIのGemini-pro、Vertex AIのGemini-pro、text-bison、text-unicornです。 ソースコード 検証の際に使用したソースコードを紹介していきます。 最初にモジュールのインストールを行います。 !pip install --upgrade langchain-google-genai langchain-core langchain-google-vertexai langchain langchain_community !pip install google-cloud-aiplatform chromadb==0.3.26 pydantic==1.10.8 typing-inspect==0.8.0 typing_extensions==4.5.0 pandas datasets google-api-python-client pypdf faiss-cpu transformers config --upgrade --user !pip install bert_score 続いて、使用するデータセットを読み込みます。今回は20個の文章を要約して、検証してみます。 import pandas as pd import json #変換したいJSONファイルを読み込む df = pd.read_json('jsonファイルが置いてあるフォルダ/japanese_test.jsonl',orient='records', lines=True) #要約に使用するテキスト df_text = df['text'].iloc[:20] #要約の正解テキスト df_sum = df['summary'].iloc[:20] 続いて、langchainを使って要約を行い、BertScoreで要約結果を比較する関数を作っていきます。 また、要約を行うために、以下の3つのプロンプトを用意しました。 以下の文章を要約して 以下の文章を200文字で要約して 以下の文章を3文で要約して 検証の際にはプロンプトを入力する箇所を適宜変更します。 from langchain_google_genai import GoogleGenerativeAI from langchain.prompts import PromptTemplate from bert_score import score import torch from langchain_google_vertexai import VertexAI from tqdm import tqdm #APIキーの設定 api_key = "Google AIのAPIキーを入れてください" #プロンプトを入力 #プロンプト1:以下の文章を要約して #プロンプト2:以下の文章を200文字で要約して #プロンプト3:以下の文章を3文で要約して template1 = """以下の文章で要約して。 文章：{sentence}""" #関数の作成 def compare_summary_result(llm,text,sum): 　text_list = text.tolist() 　sum_list = sum.tolist() 　result_sum_list = [] #llmによる要約の結果を格納 　sum_list_final = [] #データセットの要約を格納。データによってllmがエラーを出す時があるので、エラーを出したものを飛ばす。 　text_list_final = [] #データセットの元のテキストを格納。データによってllmがエラーを出す時があるので、エラーを出したものを飛ばす。 　for i in tqdm(range(len(text_list))): 　try :   　sentence = text_list[i]   　prompt = PromptTemplate.from_template(template1)   　prompt = prompt.format(sentence=sentence)   　result = llm.predict(prompt)   　result_sum_list.append(result)   　　　text_list_final.append(text_list[i])   　sum_list_final.append(sum_list[i]) 　except IndexError :     print("IndexError") P, R, F1 = score(result_sum_list, sum_list_final, lang="ja") result_bertscore = float(torch.mean(P)) return result_bertscore,result_sum_list,sum_list_final,text_list_final それでは作成した関数を用いて、検証するプログラムを作成します。 以下、Google AIのGemini-proモデルを使用した検証プログラムになります。 llm = GoogleGenerativeAI(model="gemini-pro", google_api_key=api_key) #結果を整形 google_gemini_bertscore,google_gemini_result,google_gemini_sum,google_gemini_text = compare_summary_result(llm,df_text,df_sum) df_google_gemini_result1 = pd.DataFrame(list(zip(google_gemini_result,google_gemini_sum,google_gemini_text)), columns=["summary_result", "summary_label", "text"]) 続いて、Vertex AIのGemini-pro、text-bison、text-unicornを使用した検証プログラムになります。 import sys import IPython import vertexai from google.colab import auth #認証を行う app = IPython.Application.instance() app.kernel.do_shutdown(True) if "google.colab" in sys.modules: 　auth.authenticate_user() #初期化を必ず行う #Gemini-proモデル vertexai.init(project="プロジェクト名",location="us-central1") llm = VertexAI(model="gemini-pro") vertex_gemini_bertscore,vertex_gemini_result,vertex_gemini_sum,vertex_gemini_text = compare_summary_result(llm,df_text,df_sum) df_vertex_gemini_result1 = pd.DataFrame(list(zip(vertex_gemini_result,vertex_gemini_sum,vertex_gemini_text)), columns=["summary_result", "summary_label", "text"]) #text-bisonモデル vertexai.init(project="プロジェクト名",location="us-central1") llm = VertexAI(model="text-bison",project_id="プロジェクト名") vertex_bison_bertscore,vertex_bison_result,vertex_bison_sum,vertex_bison_text = compare_summary_result(llm,df_text,df_sum) df_vertex_bison_result1 = pd.DataFrame(list(zip(vertex_bison_result,vertex_bison_sum,vertex_bison_text)), columns=["summary_result", "summary_label", "text"]) #text-unicornモデル vertexai.init(project="プロジェクト名",location="us-central1") llm = VertexAI(model="text-unicorn",project_id="プロジェクト名") vertex_unicorn_bertscore,vertex_unicorn_result,vertex_unicorn_sum,vertex_unicorn_text = compare_summary_result(llm,df_text,df_sum) df_vertex_unicorn_result1 = pd.DataFrame(list(zip(vertex_unicorn_result,vertex_unicorn_sum,vertex_unicorn_text)), columns=["summary_result", "summary_label", "text"])   検証結果 先ほどのソースコードを実行し、それぞれのプロンプトにおいて、要約結果を言語モデル間で比較してみました。それでは、結果を見てみましょう。 プロンプト1：以下の文章を要約して プロンプト1をLLMに入力して、類似度を出した結果は以下の図の通りです。 縦軸がBertScore、横軸がモデルを表しており、左からGoogle AIのGemini-pro、Vertex AIのGemini-pro、text-bison、text-unicornのモデルの結果を示しています。   Google AI のGemini-proが一番よい要約精度を記録しました。 データセットの先頭のデータに対する要約結果を以下のようにまとめてみました。 元のテキスト このワクチンは複数の動物実験で、安全性や、効果的な免疫反応を引き起こすことが示されている。 今回の第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） 要約の正解データ 新型コロナウイルスの新しいワクチンの臨床試験がイギリスで始まった。インペリアル･コレッジ･ロンドンのロビン・シャトック教授らが率いる試験の一貫で、今後数週間で約300人を対象に実施される。 Google AI Gemini-proによる要約結果 インペリアル・カレッジ・ロンドンは、新しいRNAベースのコロナウイルスワクチンの第1段階臨床試験を開始しました。これまでの動物実験では安全性と免疫反応の有効性が示されており、10月に6000人を対象とした第2段階試験が予定されています。このワクチンは、弱体化したウイルスではなく、自己複製してスパイクタンパク質の複製を生成するRNAを使用しています。主任研究員は、免疫反応に期待を寄せていますが、ワクチンが効果的であるかどうかを評価するにはさらなる調査が必要です。 Vertex AI Gemini-proによる要約結果 インペリアル・カレッジ・ロンドンの新しいmRNAワクチンは、動物実験で安全かつ効果的であることが示され、現在第1段階の臨床試験が行われている。6000人を対象とした第2段階試験は今年10月に予定されており、早ければ2021年初頭にワクチンが配布される見込み。このワクチンは、体内にスパイクタンパク質のコピーを作成し、免疫システムを活性化してCOVID-19と戦う仕組み。 Vertex AI text-bisonによる要約結果  インペリアル・カレッジ・ロンドンは、新型コロナウイルスのワクチンの人間に対する臨床試験を開始した。このワクチンは、遺伝子のRNA（リボ核酸）を使用しており、筋肉に注射すると、自己増殖して新型ウイルスの表面にみられるスパイクタンパク質のコピーをつくるよう、体内の細胞に指示を出す。この方法で、COVID-19（新型ウイルスによる感染症）を発症することなく新型ウイルスを認識して戦うための免疫システムを訓練できるという。臨床試験には、300人のボランティアが参加し、初日には1人 Vertex AI text-unicornによる要約結果 インペリアル・カレッジ・ロンドンの研究チームは、新型コロナウイルス感染症（COVID-19）のワクチンの臨床試験を開始した。このワクチンは、従来のワクチンとは異なる新しいアプローチで開発されたもので、遺伝子のRNA（リボ核酸）を使う。筋肉に注射すると、RNAは自己増殖し、新型ウイルスの表面にみられるスパイクタンパク質のコピーをつくるよう、体内の細胞に指示を出す。この方法で、COVID-19を発症することなく新型ウイルスを BertScoreの結果の通り、Google AIのGemini-proモデルの要約が一番良いように思えます。 プロンプト2：以下の文章を200文字で要約して プロンプト2をLLMに入力して、類似度を出した結果は以下の図の通りです。 text-unicornが最も精度の高い要約を生成したという結果となりました。 以下の公式ドキュメントによると、text-unicornは「複雑な自然言語タスクに使用する PaLM モデル ファミリーの中で最も高度なテキストモデル。」とのことなので、高い精度となったと考えられます。 モデル情報  |  Vertex AI の生成 AI  |  Google Cloud cloud.google.com   また、データセットの先頭のデータに対する要約結果を以下のようにまとめてみました。 元のテキスト このワクチンは複数の動物実験で、安全性や、効果的な免疫反応を引き起こすことが示されている。 今回の第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） 要約の正解データ 新型コロナウイルスの新しいワクチンの臨床試験がイギリスで始まった。インペリアル･コレッジ･ロンドンのロビン・シャトック教授らが率いる試験の一貫で、今後数週間で約300人を対象に実施される。 Google AI Gemini-proによる要約結果 インペリアル・カレッジ・ロンドンは、RNAベースのCOVID-19ワクチンの人間による最初の臨床試験を開始した。このワクチンは動物実験で安全性と免疫反応が実証されており、今後6000人を対象とした第2段階の試験が予定されている。この新しいアプローチは、弱体化したウイルスを使用する従来のワクチンとは異なり、ウイルス表面のスパイクタンパク質をコードするRNAを使用し、免疫システムがウイルスを認識することを訓練する。主任研究員のポロック博士は、前臨床データに期待を寄せており、このワクチンがパンデミックへの対応に革命をもたらす可能性があると述べている。研究チームは、慎重に段階を踏んで試験を進め、ワクチンが安全かつ効果的であることを確認することを目指している。 Vertex AI Gemini proによる要約結果 インペリアルカレッジロンドンの新しいワクチンは、動物実験で安全かつ免疫反応を誘発することが示されました。6000人を対象とした第2段階の臨床試験が計画されており、2021年初頭には配布を目指しています。このワクチンはRNAを使用して、ウイルスの認識を訓練し、免疫システムを構築します。研究者らは、中和抗体応答が確認され、高い免疫反応を期待しています。金融業界のキャシーさんは、ボランティアに参加し、パンデミックの克服に貢献しています。この臨床試験では、慎重に被験者数を増やし、4週間の間隔で2回の接種を行います。安全性上の懸念ではなく、新しいアプローチを慎重に評価するためです。 Vertex AI text-bisonによる要約結果  インペリアル・カレッジ・ロンドンは、新型コロナウイルスに対する新しいワクチンの第1段階の臨床試験を開始しました。このワクチンは、遺伝子のRNA（リボ核酸）を使用しており、筋肉に注射すると、自己増殖して新型ウイルスの表面にみられるスパイクタンパク質のコピーをつくるよう、体内の細胞に指示を出します。この方法で、COVID-19（新型ウイルスによる感染症）を発症することなく新型ウイルスを認識して戦うための免疫システムを訓練できるという。この研究は英政府から4100万ポンド（約5 Vertex AI text-unicornによる要約結果 インペリアル・カレッジ・ロンドンの研究チームは、新型コロナウイルス感染症（COVID-19）のワクチンの臨床試験を開始した。このワクチンは、従来のワクチンとは異なる新しいアプローチで開発されたもので、RNA（リボ核酸）を使う。筋肉に注射すると、RNAは自己増殖し、新型ウイルスの表面にみられるスパイクタンパク質のコピーをつくるよう、体内の細胞に指示を出す。この方法で、COVID-19を発症することなく新型ウイルスを認識して戦 BertScoreが一番良かったtext-unicornモデルの要約が今一つのように思えます。個人的にはGoogle AIのGemini-proモデルの要約が一番良いように感じています。 プロンプト3：以下の文章を3文で要約して プロンプト3をLLMに入力して、類似度を出した結果は以下の図の通りです。 こちらもtext-unicornが最も精度の高い要約を生成したという結果となりました。 また、データセット中の1つのデータに対する要約結果を以下のようにまとめてみました。 元のテキスト このワクチンは複数の動物実験で、安全性や、効果的な免疫反応を引き起こすことが示されている。 今回の第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） 要約の正解データ 新型コロナウイルスの新しいワクチンの臨床試験がイギリスで始まった。インペリアル･コレッジ･ロンドンのロビン・シャトック教授らが率いる試験の一貫で、今後数週間で約300人を対象に実施される。 Google AI Gemini-proによる要約結果 インペリアル・カレッジ・ロンドンが開発したCOVID-19ワクチンは、動物実験で有効性が確認されており、現在第1段階の臨床試験が行われています。このワクチンは従来の方法とは異なり、RNAを使用してスパイクタンパク質の生成を誘導し、免疫システムを訓練します。研究者は、早ければ2021年初頭からワクチンを配布することを目指しています。 Vertex AI Gemini-proによる要約結果 インペリアル・カレッジ・ロンドンの新しい新型コロナウイルスワクチンは、動物実験で安全で効果的であることが示されています。2021年早々に配布可能となることを目指し、6,000人を対象とした臨床試験が予定されています。このワクチンは、遺伝子のRNAを使用して免疫システムを訓練し、将来的にアウトブレイクに対応する方法に革命をもたらす可能性があります。 Vertex AI text-bisonによる要約結果 インペリアル・カレッジ・ロンドンは、新型コロナウイルスのワクチンの人間に対する臨床試験を開始した。 このワクチンは、遺伝子のRNA（リボ核酸）を使用しており、筋肉に注射すると、自己増殖し、新型ウイルスの表面にみられるスパイクタンパク質のコピーをつくるよう、体内の細胞に指示を出す。 臨床試験には、300人のボランティアが参加し、4週間の間隔をあけて2回の接種を行う。 Vertex AI text-unicornによる要約結果 インペリアル・カレッジ・ロンドンで、新型コロナウイルスワクチンの臨床試験が開始された。このワクチンは、従来のワクチンとは異なる新しいアプローチで開発されたもので、RNA（リボ核酸）を使う。臨床試験は、安全性を確認するために慎重に進められている。 BertScoreの結果の通り、text-unicornモデルの要約が一番良いように思えます。 プロンプト間での比較 プロンプト間で比較してみるとプロンプト3「以下の文章を3文で要約して」が最もよい結果となりました。文字数で指定するよりも、文の数を指定したほうが少し精度が上がるのかもしれません。   まとめ 本記事では、GoogleのLLMを用いたテキスト要約タスクにおける性能比較検証を行いました。自動評価指標であるBertScoreを用いた評価において、Text-Unicornは高い精度を示しました。また、プロンプトに文の数を指定することで、どのモデルにおいても要約精度がわずかに向上することが確認されました。これは、文の数を指定することで、要約すべき内容をより明確に理解できるためと考えられます。 しかし、実際に生成された要約を見てみると、Text-Unicornの要約は必ずしも最適とは言えないことがわかりました。これは、BertScoreと人間の評価基準が必ずしも一致していないことを示唆しています。人間の評価基準に沿った要約生成においては、Google AIのGemini-proが優れているように思えます。 以上の結果から、AI評価と人間の評価の間には乖離が存在することが明らかになりました。これは、AIモデルの開発において、人間の評価を考慮することが重要であると思います。 今回の検証では、GoogleのLLMの性能比較という限定的な結果しか得られませんでした。今後は、AI評価と人間の評価の乖離についても考慮しつつ、より多くのモデルおよびプロンプトを比較検討することで、タスクごとに最適なモデルおよびプロンプトを決定できるようにしたいと考えています。 最後までご覧いただきありがとうございました。

こんにちは、SCSKのひるたんぬです。 もう4月になりますね…2024年度の幕開けです。 昨年の4月に新入社員としてSCSKに入社し社会人デビューをした身としては、あっという間の一年だったなぁ…と思うと同時に、「もう後輩が来るんですか！？」というのが正直なところです。少しでも先輩らしい(？)振る舞いができるようになりたいものです。 今回は、仕事上…というよりもプライベートで取り組んでみたことについてご紹介いたします。 背景 私は学生時代の友人と、「まれによく¹」Minecraftをして遊びます。 学生時代はサーバやインフラに関する知識などは全くと言っていいほどなかったため、 月額固定料金のサーバを契約 → Minecraftサーバとしての初期設定 → 一定期間遊ぶ → 飽きる → 解約する を繰り返していました。この「まれによく」という頻度がくせ者でして、 よく遊ぶ…固定料金を契約して好きなだけ遊ぶ まれに遊びたくなる…その気持ちをこらえて、忘却を待つ とできないのです。皆さんも今回の話に限らず、このようなことありませんか…？ ある日、私がクラウド関係の仕事をしていると友人に話したところ、 マイクラ(Minecraft)って、急に無性に遊びたくなるんだよねぇ… 今までみたいに いちいち契約して設定して使うっていうのは面倒くさい・時間かかる し、かと言って ずーーっと契約して遊ぶほどでもないんだよね。お金の無駄だし。 なんとかならない？？ ※若干脚色しております。 …なんとわがままなのでしょうか。 しかし、言っていることはごもっともであり、そういうことなら何か仕組みを作ってみよう！ということで、今回の取り組みが幕を開けました。 ¹ 「まれによく」という言葉は正しい日本語ではないですが、この頻度を適切に表す表現が他に見当たらないためこの表現を用いています。 こちらの図解 「1. よくある(頻発する)ことが稀に起こる状態」が私が表現したい頻度です。   取り組み概要 今回は「 友人と普段の通話やチャットで用いている Discord 」と「 私が業務で触れている AWS 」を組み合わせて、先程の友人のわがままを叶えようと考えました。調べたところ、既に同様のことに取り組まれている方々がおり、それらを参考に以下のようなアーキテクチャを構築しました。 ここでの特徴は 「Lambdaが多段構成」となっている 点です。このようにすることで、EC2に関する処理に時間がかかってもタイムアウトとなることを防いでいます。 もう少し詳しく説明いたします。 通常は下図に示すアーキテクチャが一般的だと思われます。 こちらの場合ですと、「App」のLambdaがServerとのやり取りをし、その結果をAPI Gateway経由でDiscordに返すという処理の流れになります。しかし、Discordのドキュメントを確認すると、 Interaction  tokens  are valid for  15 minutes  and can be used to send followup messages but you  must send an initial response within 3 seconds of receiving the event . If the 3 second deadline is exceeded, the token will be invalidated. 引用元：Discord Developper Potal 「 Interactions: Receiving and Responding 」 と記載があります。つまり、 Discordに対して3秒以内に一度応答を返さないとエラーになってしまう のです。そのため、通常の構成ですとEC2の起動や終了の命令を出すことはできても、EC2側においてそれらの処理が正常に完了したかを確認する時間がありません。 そこで、最初に示したようにLambdaを多段構成にすることで、「App」が対応するLambdaを非同期で呼び出し、仮の応答(ACK)をDiscordに返します。そして、対応するLambdaがそれぞれの処理を実行し、メッセージを更新するという形で仮の応答を更新します。これにより、タイムアウトのエラーを防ぎ、適切な応答を返すことができるようになります。 記事の構成上、参考サイト等は記事の末尾に記載しております。   構築手順 ここからはアーキテクチャの構築手順について、Discord Botの作成からAWSでのリソース構築までを画像での解説を交えながら順に説明いたします。 少々長い内容とはなりますが、最後までお付き合いいただけますと幸いです。 Discord Botの作成 Discord Developer Portal にアクセス 「New Application」を押下し、Botのアカウント名を入力し「Create」を押下する。 遷移先の画面（General Infomation）にて、 ・APPLICATION ID ・PUBLIC KEY を控えておく。 左ペインより「Bot」を選択し、「Reset Token」を押下してトークンを発行する。 発行されたトークンを控えておく。                        このタイミングで「USERNAME」を編集しても問題ありません。 ここで設定する名前が、Discordの表示名となります。 発行されたトークンは画面遷移などにより再表示できなくなる場合があるので、発行したタイミングで必ず控えておくようにしてください。 控え忘れてしまった場合は再度「Reset Token」を押下してトークンを発行してください。 スラッシュコマンドの登録 実際にDiscordからBotを呼ぶ際に、多くの方は「/XXXXX」という形式でコマンドを入力すると思います。 今回作成するBotもこのような形で利用するため、コマンドの登録を行います。 以下のコードの「認証情報」を自身の情報に置換した上、Python（実行環境は問いません）で実行してください。 “Registration Completed!!”と表示されれば正常に処理が行われています。                                       # register-slash-commands.py import requests import json # 認証情報 BOT_ACCESS_TOKEN = "トークンを記載" APPLICATION_ID = "APPLICATION IDを記載" commands = {   "name": "server",   "description": "EC2の起動状態を管理します",   "options": [       {           "name": "action",           "description": "開始(start)・停止(stop)・状態確認(status)",           "type": 3,           "required": True,           "choices": [               {"name": "start", "value": "start"},               {"name": "stop", "value": "stop"},               {"name": "status", "value": "status"},           ],       },   ], } def main():   url = f"https://discord.com/api/v10/applications/{APPLICATION_ID}/commands"   headers = {       "Authorization": f'Bot {BOT_ACCESS_TOKEN}',       "Content-Type": "application/json",   } try: res = requests.post(url, headers=headers, data=json.dumps(commands)) res.raise_for_status() print("Registration Completed!!") except Exception as e: print("Error occurred.", e) if __name__ == "__main__": main()   リソースの構築 事前準備 今回は前提条件として、サーバとなるEC2インスタンスは既に作成されているものとします。 そのため、この時点でEC2インスタンスを作成していない方は作成してください。 今回の要件においては、EC2インスタンスを作成するのみで問題ありません。 サーバとしての設定等は不要です。 また、下記に示す4つのPythonコードを指定名で保存し、一つのzipファイルに圧縮してください。zipファイル名は任意です。 そして、そのzipファイルを適当なS3バケットにアップロードしてください。 ※…コメントアウト等で処理内容を残すべきですが、コードの量が多いため削除しております。 # ファイル名 -> app.py import os import json import boto3 import logging from nacl.signing import VerifyKey logger = logging.getLogger() logger.setLevel("INFO") def lambda_handler(event: dict, context: dict):   try:       headers: dict = {k.lower(): v for k, v in event["headers"].items()}       rawBody: str = event.get("body", "")       signature: str = headers.get("x-signature-ed25519", "")       timestamp: str = headers.get("x-signature-timestamp", "")       if not verify(signature, timestamp, rawBody):           return {               "cookies": [],               "isBase64Encoded": False,               "statusCode": 401,               "headers": {},               "body": "",           }       req: dict = json.loads(rawBody)       if req["type"] == 1:           return {"type": 1}       elif req["type"] == 2:           action = req["data"]["options"][0]["value"]           if action == "start":               token = req.get("token", "")               parameter = {                   "token": token,                   "DISCORD_APP_ID": os.environ["APPLICATION_ID"],               }               payload = json.dumps(parameter)               boto3.client("lambda").invoke(                   FunctionName="DiscordSlashCommandController-Start",                   InvocationType="Event",                   Payload=payload,               )           elif action == "stop":               token = req.get("token", "")               parameter = {                   "token": token,                   "DISCORD_APP_ID": os.environ["APPLICATION_ID"],               }               payload = json.dumps(parameter)               boto3.client("lambda").invoke(                   FunctionName="DiscordSlashCommandController-Stop",                   InvocationType="Event",                   Payload=payload,               )           elif action == "status":               token = req.get("token", "")               parameter = {                   "token": token,                   "DISCORD_APP_ID": os.environ["APPLICATION_ID"],               }               payload = json.dumps(parameter)               boto3.client("lambda").invoke(                   FunctionName="DiscordSlashCommandController-Status",                   InvocationType="Event",                   Payload=payload,               )           else:               Exception("Unexpected Command")       return {           "type": 5,       }   except Exception as e:       logger.error(str(e))       return e def verify(signature: str, timestamp: str, body: str) -> bool:   PUBLIC_KEY = os.environ["PUBLIC_KEY"]   verify_key = VerifyKey(bytes.fromhex(PUBLIC_KEY))   try:       verify_key.verify(           f"{timestamp}{body}".encode(), bytes.fromhex(signature)       )   except Exception as e:       logger.warning(f"failed to verify request: {e}")       return False   return True # ファイル名 -> start.py import os import json import requests import boto3 import logging logger = logging.getLogger() logger.setLevel("INFO") def lambda_handler(event, context):   logger.info("Starting script")   instance_id = os.environ["INSTANCE_ID"]   result = start_ec2(instance_id)   application_id = event["DISCORD_APP_ID"]   interaction_token = event["token"]   message = {}   if result["status"] == 1:       message = {"content": "Server is already running\n```\n{}\n```".format(result["ip"])}   elif result["status"] == 0:       message = {"content": "Server becomes ready!\n```\n{}\n```".format(result["ip"])}   elif result["status"] == 2:       message = {"content": "Starting instance process failed"}   else:       message = {"content": "Unexpected error at starting process"}   payload = json.dumps(message)   r = requests.post(       url=f"https://discord.com/api/v10/webhooks/{application_id}/{interaction_token}",       data=payload,       headers={"Content-Type": "application/json"},   )   logger.debug(r.text)   logger.info("Finished starting script")   return r.status_code def start_ec2(instance_id: str) -> dict:   try:       logger.info("Starting instance: " + str(instance_id))       region = os.environ["AWS_REGION"]       ec2_client = boto3.client("ec2", region_name=region)       status_response = ec2_client.describe_instances(InstanceIds=[instance_id])       if (status_response["Reservations"][0]["Instances"][0]["State"]["Name"] == "running"):           logger.info("Instance is already running: " + str(instance_id))           return {"status": 1, "ip": get_public_ip(status_response)}       else:           logger.info("Start instance: " + str(instance_id))           response = ec2_client.start_instances(InstanceIds=[instance_id])           logger.debug(response)           logger.info("Waiting for Instance to be ready: " + str(instance_id))           try:               waiter_running = ec2_client.get_waiter("instance_running")               waiter_status = ec2_client.get_waiter("instance_status_ok")               waiter_running.wait(InstanceIds=[instance_id])               waiter_status.wait(InstanceIds=[instance_id])               logger.info("Starting instance: " + str(instance_id))               return {"status": 0, "ip": get_public_ip(ec2_client.describe_instances(InstanceIds=[instance_id]))}           except Exception as e:               logger.error("Starting instance process failed.")               logger.error(str(e))               return {"status": 2}   except Exception as e:       logger.error(str(e))       return {"status": 3} def get_public_ip(response: dict) -> str:   try:       ip_address = response["Reservations"][0]["Instances"][0]["PublicIpAddress"]   except KeyError as e:       logger.warning("Failed Extract ip address.")       ip_address = "XXX.XXX.XXX.XXX"   except Exception as e:       logger.error(str(e))       ip_address = "XXX.XXX.XXX.XXX"   return ip_address # ファイル名 -> stop.py import os import json import requests import boto3 import logging logger = logging.getLogger() logger.setLevel("INFO") def lambda_handler(event, context):   logger.info("Starting script")   instance_id = os.environ["INSTANCE_ID"]   result = stop_ec2(instance_id)   application_id = event["DISCORD_APP_ID"]   interaction_token = event["token"]   message = {}   if result["status"] == 1:       message = {"content": "Server is already stopped"}   elif result["status"] == 0:       message = {"content": "Server stopped!"}   else:       message = {"content": "Unexpected error at stopping process"}   payload = json.dumps(message)   r = requests.post(       url=f"https://discord.com/api/v10/webhooks/{application_id}/{interaction_token}",       data=payload,       headers={"Content-Type": "application/json"},   )   logger.debug(r.text)   logger.info("Finished stopping script")   return r.status_code def stop_ec2(instance_id: str) -> None:   try:       logger.info("Stopping instance: " + str(instance_id))       region = os.environ["AWS_REGION"]       ec2_client = boto3.client("ec2", region_name=region)       status_response = ec2_client.describe_instances(InstanceIds=[instance_id])       if (status_response["Reservations"][0]["Instances"][0]["State"]["Name"] == "stopped"):           logger.info("Instance is already stopped: " + str(instance_id))           return {"status": 1}       else:           logger.info("Stop instance: " + str(instance_id))           response = ec2_client.stop_instances(InstanceIds=[instance_id])           logger.debug(response)           logger.info("Waiting for Instance to be stopped: " + str(instance_id))           try:               waiter_stopped = ec2_client.get_waiter("instance_stopped")               waiter_stopped.wait(InstanceIds=[instance_id])               logger.info("Stopped instance: " + str(instance_id))               return {"status": 0}           except Exception as e:               logger.error("Stopping instance process failed.")               logger.error(str(e))               return {"status": 2}   except Exception as e:       logger.error(str(e))       return {"status": 3} # ファイル名 -> status.py import os import json import requests import boto3 import logging logger = logging.getLogger() logger.setLevel("INFO") def lambda_handler(event, context):   logger.info("Starting script")   instance_id = os.environ["INSTANCE_ID"]   result = status_ec2(instance_id)   application_id = event["DISCORD_APP_ID"]   interaction_token = event["token"]   message = {}   if result["status"] == 1:       message = {"content": "Server: Stopped"}   elif result["status"] == 0:       message = {"content": "Server: Running\n```\n{}\n```".format(result["ip"])}   elif result["status"] == 2:       message = {"content": "Server: Pending"}   elif result["status"] == 3:       message = {"content": "Unexpected instance status"}   else:       message = {"content": "Unexpected error at status check process"}   payload = json.dumps(message)   r = requests.post(       url=f"https://discord.com/api/v10/webhooks/{application_id}/{interaction_token}",       data=payload,       headers={"Content-Type": "application/json"},   )   logger.debug(r.text)   logger.info("Finished status checking script")   return r.status_code def status_ec2(instance_id: str) -> None:   result = {}   try:       region = os.environ["AWS_REGION"]       ec2_client = boto3.client("ec2", region_name=region)       status_response = ec2_client.describe_instances(InstanceIds=[instance_id])       status = status_response["Reservations"][0]["Instances"][0]["State"]["Name"]       if (status == "running"):           logger.info("Instance is running: " + str(instance_id))           result["status"] = 0           result["ip"] = status_response["Reservations"][0]["Instances"][0]["PublicIpAddress"]       elif (status == "stopping" or status == "stopped"):           logger.info("Instance is stoppping: " + str(instance_id))           result["status"] = 1       elif (status == "pending"):           logger.info("Instance is pending: " + str(instance_id))           result["status"] = 2       else:           logger.warning("Unexpected instance status")           result["status"] = 3       return result   except Exception as e:       logger.error(str(e))       result["status"] = 4       return result アップロード後、zipファイルのオブジェクトを開き、キーを控えておいてください。     Layerの作成 先ほどのLambda関数において、外部ライブラリを使用します。 それにあたり、必要なパッケージを用意します。 私はCloud9にてPython 3.12を使用し作成しました。 そのため、デプロイするLambdaのランタイムもPython 3.12にしてあります。 下記引用に記載があるように、Lambdaのレイヤー作成にはLinux環境が必要です。 Windowsやmac OSでレイヤーファイルを作成した場合、Lambdaが動作しないケースがあります。 ※…私はWindowsで作成してしまい、一度引っかかりました。 The first step to creating a layer is to bundle all of your layer content into a .zip file archive. Because Lambda functions run on  Amazon Linux , your layer content must be able to compile and build in a Linux environment. If you build packages on your local Windows or Mac machine, you’ll get output binaries for that operating system by default. These binaries may not work properly when you upload them to Lambda. 引用元：AWS Lambda Document「 Packaging your layer content 」※…日本語版は機械翻訳のため、英語版サイトから引用しています。 カレントディレクトリ上に「requirements.txt」を作成します。テキストファイル内には以下を入力してください。 PyNaCl==1.5.0 requests urllib3<2 以下のコマンドを実行します。 $ mkdir python $ pip install -r requirements.txt -t ./python $ zip -r9 layer.zip python カレントディレクトリに「layer.zip」ができていることを確認し、そのzipファイルを適当なS3バケットにアップロードしてください。アップロード後、コードと同様にzipファイルのオブジェクトを開き、キーを控えておいてください。 レイヤーファイルのアップロード場所は、先程コードをアップロードしたバケットと同一でも問題ありません。 CloudFormationによる構築 今回構築するAPI Gateway, Lambda, IAMのCloudFormationテンプレートを用意しました。 以下のYAMLファイルを使用し、リソースをデプロイしてください。 パラメータには ApplicationID…Discord Bot作成時の「APPLICATION ID」 CodeS3BucketName…事前準備で格納したコードの宛先S3バケット名 CodeS3Key…コードのキー EC2InstanceID…制御したいEC2インスタンスのID LayerS3BucketName…事前準備で格納したレイヤーの宛先S3バケット名 LayerS3Key…レイヤーのキー PublicKey…Discord Bot作成時の「PUBLIC KEY」 をそれぞれ入力してください。 AWSTemplateFormatVersion: 2010-09-09 Parameters: ApplicationID:   Type: String PublicKey:   Type: String EC2InstanceID:   Type: String CodeS3BucketName:   Type: String CodeS3Key:   Type: String LayerS3BucketName:   Type: String LayerS3Key:   Type: String Resources: # API Gateway ControlAPIGateway:   Type: AWS::ApiGatewayV2::Api   Properties:     Name: DiscordSlashCommandController-Api     ProtocolType: HTTP ControlAPIGatewayIntegration:   Type: AWS::ApiGatewayV2::Integration   Properties:     ApiId: !Ref ControlAPIGateway     IntegrationType: AWS_PROXY     IntegrationUri: !GetAtt AppFunction.Arn     PayloadFormatVersion: 2.0 ControlAPIGatewayRoute:   Type: AWS::ApiGatewayV2::Route   Properties:     ApiId: !Ref ControlAPIGateway     RouteKey: POST /     Target: !Sub integrations/${ControlAPIGatewayIntegration} ControlAPIGatewayStage:   Type: AWS::ApiGatewayV2::Stage   Properties:     ApiId: !Ref ControlAPIGateway     StageName: $default     AutoDeploy: true # Lambda layer LambdaLayer:   Type: "AWS::Lambda::LayerVersion"   Properties:     CompatibleRuntimes:       - python3.12     Content:       S3Bucket: !Ref LayerS3BucketName       S3Key: !Ref LayerS3Key     LayerName: DiscordSlashCommandController-Layer # Lambda function AppFunction:   Type: AWS::Lambda::Function   Properties:     Code:       S3Bucket: !Ref CodeS3BucketName       S3Key: !Ref CodeS3Key     Handler: app.lambda_handler     Runtime: python3.12     FunctionName: DiscordSlashCommandController-App     Layers:       - !Ref LambdaLayer     MemorySize: 1024     Timeout: 10     Environment:       Variables:         PUBLIC_KEY: !Ref PublicKey         APPLICATION_ID: !Ref ApplicationID     Role: !GetAtt LambdaExecutionRole.Arn StartFunction:   Type: AWS::Lambda::Function   Properties:     Code:       S3Bucket: !Ref CodeS3BucketName       S3Key: !Ref CodeS3Key     Handler: start.lambda_handler     Runtime: python3.12     FunctionName: DiscordSlashCommandController-Start     Layers:       - !Ref LambdaLayer     MemorySize: 1024     Timeout: 600     Environment:       Variables:         INSTANCE_ID: !Ref EC2InstanceID     Role: !GetAtt LambdaExecutionRole.Arn StopFunction:   Type: AWS::Lambda::Function   Properties:     Code:       S3Bucket: !Ref CodeS3BucketName       S3Key: !Ref CodeS3Key     Handler: stop.lambda_handler     Runtime: python3.12     FunctionName: DiscordSlashCommandController-Stop     Layers:       - !Ref LambdaLayer     MemorySize: 1024     Timeout: 60     Environment:       Variables:         INSTANCE_ID: !Ref EC2InstanceID     Role: !GetAtt LambdaExecutionRole.Arn StatusFunction:   Type: AWS::Lambda::Function   Properties:     Code:       S3Bucket: !Ref CodeS3BucketName       S3Key: !Ref CodeS3Key     Handler: status.lambda_handler     Runtime: python3.12     FunctionName: DiscordSlashCommandController-Status     Layers:       - !Ref LambdaLayer     MemorySize: 1024     Timeout: 10     Environment:       Variables:         INSTANCE_ID: !Ref EC2InstanceID     Role: !GetAtt LambdaExecutionRole.Arn # Lambda execution log groups AppFunctionLogGroup:   Type: AWS::Logs::LogGroup   Properties:     LogGroupName: !Sub /aws/lambda/${AppFunction}     RetentionInDays: 30 StartFunctionLogGroup:   Type: AWS::Logs::LogGroup   Properties:     LogGroupName: !Sub /aws/lambda/${StartFunction}     RetentionInDays: 30 StopFunctionLogGroup:   Type: AWS::Logs::LogGroup   Properties:     LogGroupName: !Sub /aws/lambda/${StopFunction}     RetentionInDays: 30 StatusFunctionLogGroup:   Type: AWS::Logs::LogGroup   Properties:     LogGroupName: !Sub /aws/lambda/${StatusFunction}     RetentionInDays: 30 # Lambda invoke permission ApiGWInvokeAppFunction:   Type: AWS::Lambda::Permission   Properties:     Action: lambda:InvokeFunction     FunctionName: !GetAtt AppFunction.Arn     Principal: apigateway.amazonaws.com     SourceArn: !Sub arn:aws:execute-api:${AWS::Region}:${AWS::AccountId}:${ControlAPIGateway}/*   # Lambda IAM Role LambdaExecutionRole:   Type: AWS::IAM::Role   Properties:     AssumeRolePolicyDocument:       Version: 2012-10-17       Statement:         - Action: sts:AssumeRole           Effect: Allow           Principal:             Service: lambda.amazonaws.com     Policies:       - PolicyDocument:           Version: 2012-10-17           Statement:             - Action:                 - lambda:InvokeFunction                 - ec2:DescribeInstances                 - ec2:DescribeInstanceStatus                 - ec2:StopInstances                 - ec2:StartInstances               Effect: Allow               Resource: "*"         PolicyName: IPL-DiscordSlashCommandController     ManagedPolicyArns:       - "arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole"     RoleName: IRL-DiscordSlashCommandController Outputs: EndpointURL:   Value: !Sub https://${ControlAPIGateway}.execute-api.${AWS::Region}.${AWS::URLSuffix}/ 構築が完了すると、出力にエンドポイントのURLがありますので、そちらを控えておきます。 Discord Botの利用 Discord Developer Portal に再びアクセスし、先程作成したApplicationをクリックします。 中段にある「INTERACTIONS ENDPOINT URL」に、先程控えたエンドポイントURLを貼り付けます。 「Save Changes」を押下すると、接続テストが行われ正常に疎通確認が取れるとエンドポイントURLが保存されます。 ここで何かしらのエラーが出る場合は、APIが正常に構築できていない・貼り付け先のBOTを間違えている可能性があります。 Botの招待 左ペインより「OAuth2」を選択し、下段「OAuth2 URL Generator – SCOPES」から「bot」と「applications.commands」にチェックを入れます。その後、その下に表示されている「GENERATED URL」をコピーします。 コピーしたURLにアクセスして、サーバーにBotを招待します。 Botをサーバへ招待するには、サーバの管理者など「サーバ管理権限」を持つアカウントでの操作が必要です。 動作確認 Botが招待されたサーバのテキストチャンネルにて、スラッシュコマンドを入力します。 下記画像では「/server」を入力したあとに、コマンドの候補や説明が適切に表示されていることが分かります。 それぞれのコマンド（start, stop, status）を入力し、所望の応答が得られることを確認します。 コマンド入力直後（共通） サーバ開始時（/server start） サーバ終了時（/server stop） サーバステータス確認時（/server status） IPアドレス欄のみコードブロックにて独立して配置することで、IPアドレスのコピーを容易にしています。   参考サイト 今回の実装にあたり、以下のサイトを参考にさせていただきました。 構成や実際のコードを参考にいたしました。 discord の slash commands からEC2を操作できるようにしてみた - Qiita はじめにはじめまして、@nahiro_tus です。突然ですが、皆さんはdiscordのslash commands機能をご存知ですか？… qiita.com 応答方法の処理について参考にいたしました。 Discord Interaction Endpoint を多段 Lambda 構成にしてタイムアウトを回避する | DevelopersIO 前回の記事の続きです。 Discord の Interaction Endpoint は仕様上、Interaction リクエストから応答までに制限時間が設けられています。 制限時間を超えてしまう場合は、一旦仮の応答を返 … dev.classmethod.jp Discord Developer Portal — API Docs for Bots and Developers Integrate your service with Discord — whether it's a bot or a game or whatever your wildest imagination can come up with... discord.com Layerを作成する際に参考にいたしました。 AWS Lambda (Python 3.12) で使用可能な pandas の Lambda Layer を準備する データ分析や加工でよく使われるライブラリに、pandas があると思います。本記事では、AWS Lambda (Python 3.12) で動作する pandas の Lambda Layer を準備する手順を紹介します。 blog.usize-tech.com 2022.06.07 Lambda+PythonでLayerを使うときにハマったこと | ドクセル ドクセルはスライドやPDFをかんたんに共有できるサイトです www.docswell.com CloudFormationテンプレートを作成する際に参考にいたしました。 Amazon API Gateway と AWS Lambda の連携でもうハマりたくない [AWS CloudFormation テンプレート付き] Amazon API Gateway と AWS Lambda の連携がうまくできず時間を浪費してしまう方は結構いらっしゃるのではないかと思います。Amazon API Gateway のタイプや AWS Lambda との統合の仕方によって AWS Lambda 関数のコードも変わるので厄介です。私はそこでハマるのが嫌で、Amazon API Gateway と AWS Lambda 関数の標準設定パターンを決めて使い回ししています。 blog.usize-tech.com 2022.04.11 この他にも、API GatewayやLambdaのCloudFormationに関するドキュメント、Discord Developer Potalの公式ドキュメントも参考にしております。   終わりに 今回は、インフラのことを知らない人でもDiscord上から簡単にEC2インスタンスの開始・停止を行うための仕組みをご紹介いたしました。インスタンスを使いたい人が自分の好きなタイミングで開始や停止ができるので、運用面や費用面でも大きなメリットがあるのではないかなと思っております。 個人的にも一からこのような仕組みを構築することができ、達成感や学ぶことが多くありました。 （アイデアやコードは多くのサイトを参考にさせていただきました。） とても長くなってしまいましたが、最後までご覧いただきありがとうございました！ 余談：私はDiscordやVS Codeをライトテーマで使うタイプです。

こんにちは、SCSKでAWSの内製化支援『 テクニカルエスコートサービス 』を担当している貝塚です。 以前、AWSのVPC上で双方向1対1NATを実現するという記事を書きました。 AWSで双方向1対1NATインスタンスを構築する AWS環境でNATが必要なとき、NAT Gatewayなどのマネージドサービスが用意されていますが、双方向のNATが行えないなどの制約があります。双方向(SNAT, DNAT)での1対1NATを実現したい場合には、EC2でNAT用のインスタンスを構築することがひとつのソリューションとなりえるでしょう。本記事では、iptablesを使用した双方向NAT用インスタンスの構築手順を説明します。 blog.usize-tech.com 2024.01.04 今回は、オンプレミスもからんだ、やや複雑な環境で2社間をNATして接続することを考えてみます。 接続要件 接続要件は下図の通りです。 Direct Connect接続構成 A社オンプレミス環境とB社オンプレミス環境を接続したいとします。A社はAWSのアカウントを持っており、既にDirect Connectで接続しています。Direct ConnectはVPCのひとつに、仮想プライベートゲートウェイ経由で関連付けされています。 一方、B社はAWSアカウントを持っていません。キャリアの閉域網を契約しており、そのサービスの一つに閉域網とAWSを接続するサービスがあるので、それを使ってAWSアカウントに接続することができます。B社はAWSアカウントを取得する予定がないため、A社の管理するAWSアカウントにPrivate VIFで接続することを希望しています。(※) ※Transit VIFが出せないので、Direct Connect – Direct Connect Gateway – Transit Gateway という構成は取れないということです。 通信要件 通信要件は大きくふたつ、以下の通りです。 １．A社オンプレミス上のクライアントからB社オンプレミス上のサーバへの通信(通信要件(1)) TCPを用いて、A社 → B社のコネクションが発生します。 ２．A社AWSアカウント上のクライアント兼サーバとB社オンプレミス上のクライアント兼サーバの通信(通信要件(2)) TCPを用いて、A社 → B社、B社 → A社の両方のコネクションが発生します。 NAT要件 B社は、A社のIPアドレスを隠蔽して、B社の指定するIPアドレス(10.129.0.0/16)にNATしてもらいたいという要件があります。 A社も、B社のIPアドレスがA社で既に使用しているレンジであれば当然NATをする必要がありますが、調査の結果、B社の使用するIPアドレスはA社では使用していないと判明したため、B社のIPアドレスは隠蔽しないことにしました。 ソリューション A社を支援する立場で構築した環境は下図の通りです。 既存VPCの仮想プライベートゲートウェイAにB社のDirect Connectを接続するのは問題があると考え、B社接続専用の新規VPCを構成し、仮想プライベートゲートウェイBとB社Direct Connectを関連付ける設計としています。 NAT要件は、EC2のLinuxインスタンスでiptablesを使用したNATインスタンスを構築することにより満たすことにしました。一見、NAT Gatewayでも要件を満たせるように思えますが、NAT GatewayではB社からA社へコネクションを開始する通信要件(通信要件(2))が満たせません。 既存VPCと新規VPCはTransit Gatewayで接続します。VPC間接続というとVPC Peeringが思い浮かびますが、VPC PeeringだとNAT構成がより複雑になってしまうという点と、Transit Gateway構成にしておくと将来的にInspection VPCを導入してセキュリティを強化するという選択肢が増えるため、Transit Gatewayを選択しました。 また、この構成ではA社オンプレからB社オンプレや新規VPCに直接通信することができないので、既存VPCにNetwork Load Balancerをはさむことでこの問題を解決しています。 以下、このような設計とした意図を解説します。 Direct Connectの接続ポイント 以下の図のような、仮想プライベートゲートウェイAにB社ダイレクトコネクトのVIFを関連付ける構成を考えてみます。 Network Load Balancerを経由してA社オンプレとB社オンプレを接続する理由は別項で解説することにして、まずはB社Direct Connectを仮想プライベートゲートウェイAに関連付けることの良し悪しについて検討します。 この構成の場合、B社側の設定ミス等により、例えばデフォルトルート(0.0.0.0/0)などをA社にアドバタイズできてしまいます。その場合、A社オンプレとA社AWS環境間の通信に問題が発生する可能性があります。 また、仮想プライベートゲートウェイAは既存VPCのCIDR全体をB社にアドバタイズしてしまいます。そのため、B社から、A社既存VPC上の、今回の通信要件と関係のないサーバに通信を試みることができます。ネットワークACLを使用することで上手く制御できるかもしれませんが、セキュリティ管理上の難易度が高くなってしまいます。 以上の理由から、B社Direct Connectを収容するための専用のVPCを構成する設計としました。(前項『ソリューション』の図参照) この構成であれば、B社側からデフォルトルートがアドバタイズされてきたとしても経路を持ってしまうのは仮想プライベートゲートウェイBだけですから、既存VPCとA社オンプレの通信に影響が出ることはありません。 NATインスタンス NAT要件を満たすために、A社新規VPCにNAT機能を有するデバイスを配置します。 A社 → B社 方向の通信を考えると、A社のアドレスさえ隠蔽できればよく(送信元NAT, SNAT)、A社側からはB社のIPアドレスに通信すればよいので、NAT Gatewayで通信要件を満たせるように見えます。 しかし、通信要件(2)はB社 → A社 方向のコネクションも発生します。NAT Gatewayの提供する機能はN対1 NAT(IPマスカレード)と呼ばれるものなので、B社からNAT GatewayのIPアドレスに通信を試みても、A社内のサーバと通信することはできません。 以上の理由から、EC2を用いて独自にNAT用のインスタンスを作成することにしました。(※) ※ここで言うNAT用のインスタンスは、 AWSが過去にNATインスタンスと呼んでいたもの のことではありません。AWSがNATインスタンスと呼んでいたものは既にAMIのサポートが終了しており、また、基本的にはNAT Gatewayと同様にN対1 NAT(IPマスカレード)の機能提供を前提にしているため、本件の用途に向きません。 LinuxのEC2インスタンスを使用して双方向のコネクションに対応したNATインスタンスを作成する方法については、以下の記事を参考にしてください。 AWSで双方向1対1NATインスタンスを構築する AWS環境でNATが必要なとき、NAT Gatewayなどのマネージドサービスが用意されていますが、双方向のNATが行えないなどの制約があります。双方向(SNAT, DNAT)での1対1NATを実現したい場合には、EC2でNAT用のインスタンスを構築することがひとつのソリューションとなりえるでしょう。本記事では、iptablesを使用した双方向NAT用インスタンスの構築手順を説明します。 blog.usize-tech.com 2024.01.04 VPC間接続(Transit Gateway) 既存VPCと新規VPCを接続する必要があります。まずはVPC Peeringで接続することを検討してみます。VPC Peeringは無料で使用できるので、要件に合うのであればVPC Peeringを採用したいところです。 VPC Peeringの特徴は、接続したVPC同士の経路情報しか持っていない点です。この図でいうと、既存VPCと新規VPCの通信はできますが、既存VPCとB社オンプレは直接通信できません。VPC PeeringがB社オンプレへの経路を持っていないからです。 これに対処する方法としては、NATインスタンスでB社オンプレのIPアドレスを隠蔽するようにNATを設定し、A社からは新規VPC上のIPアドレス(10.129.0.0/16)と通信しているように見せかけるというものがあります。 この構成を採用してもよいのですが、せっかく通信要件・NAT要件を整理した結果、B社オンプレのIPアドレスを隠蔽する必要はないという結論に至ったのに、結果としてB社オンプレのIPアドレスを隠蔽するNATを導入することになります。運用面・障害対応面から見た場合、構成はできるだけシンプルにしたいので、この構成は検討の余地があります。 また、VPC Peeringの制約事項としてよく言われることですが、二つのVPCを接続するごとに一つのVPC Peeringを設定する必要があります。この図では必要なVPC Peeringの数は1ですが、他のVPC(図に書いていないだけでいくつかあります)からB社に接続する要件が出てきたら？とか、B社以外にもC社、D社と今回の接続形態でつなぐことになったら……？と考えると、VPC Peeringの管理負荷が重くのしかかってきます。 管理のシンプル化という観点と、将来的にC社、D社……と同様の形態で接続することを考えたときに、必要に応じて Inspection VPC という形ですべてのVPC間通信をひとつのNetwork Firewallで集約して検査する機能を導入することで、相対的に低い運用負荷で高度なセキュリティを実装できるという点から、Transit GatewayでVPC間を接続する構成を選択しました。 Transit Gateway構成であれば、前述の直接接続したVPC同士でしか通信できないという制約も受けないので、A社既存VPCからB社オンプレに通信するのに、B社オンプレIPを隠蔽する必要もありません。 Network Load Balancer 最後に既存VPCに配置したNetwork Load Balancerについて解説します。 実は仮想プライベートゲートウェイは、Direct Connect側(オンプレ側)に対しては比較的自由に経路を設定できるのですが、仮想プライベートゲートウェイが関連付けられているVPCの”先”のネットワークへの経路を持つことができません。 この図を例にとると、仮想プライベートゲートウェイAは、新規VPCやB社オンプレへの経路を持っていません。同様に、仮想プライベートゲートウェイBは、既存VPCやA社オンプレへの経路を持ちません。 つまりどういうことかというと、A社オンプレは、既存VPC以外とは通信できません。ここからB社オンプレにたどり着くためには、NATを駆使することになります。この場面で活躍する優秀なデバイスがNetwork Load Balancerです。 A社オンプレから既存VPC上のNetwork Load BalancerのIPアドレスに通信すると、送信先をNetwork Load BalancerのターゲットであるB社オンプレミス上の通信要件(1)サーバのIPアドレスに変換します(実質、送信先NAT, DNAT)。この時、送信元IPアドレスはA社オンプレのIPアドレスから、Network Load BalancerのIPアドレスに変換されます(実質、送信元NAT, SNAT)。 Transit Gatewayには、隣接するVPCにしか到達できないという制限がありませんので、Network Load Balancerから発信されたB社オンプレミス向けの通信はTransit Gatewayを通過し、NATインスタンスを通過していくことができます。そして仮想プライベートゲートウェイBに到達しますが、仮想プライベートゲートウェイBはB社オンプレへの経路を持っているので、無事B社オンプレ上のサーバに到達することができます。 次に、戻りの通信を考えます。B社オンプレミスからA社オンプレミスへの通信となりますが、行きの通信の時にNATインスタンスでA社のIPを隠蔽しB社体系のIP(新規VPCのCIDR)にNATされているので、送信先IPアドレスは新規VPC上のIPアドレスとなり、仮想プライベートゲートウェイBで破棄されることなく通過することができます。 NATインスタンスはNATを行って、Network Load BalancerのIPアドレスを送信先とします。VPC間はTransit Gatewayで接続しているので問題なく通過することができます。 Network Load Balancerは送信先をA社オンプレ上の通信要件(1)用クライアントのIPアドレスに変換します。送信元はNetwork Load BalancerのIPアドレスに変換されます。仮想プライベートゲートウェイAはA社オンプレへの経路を持っているので、A社オンプレ上のクライアントに戻っていくことができます。 まとめ 以上、NATを必要とする2社間のオンプレ/VPC接続構成について検討してみました。 Network Load Balancerは、実質的に送信元NAT、送信先NATを同時に行ってくれるので、仮想プライベートゲートウェイやVPC Peeringをいくつも越えないといけないときに大変重宝することが分かりました。ただし、ターゲットに定期的にヘルスチェックを実施してしまうので、他社のサーバをターゲットにする場合にはお断りを入れておくのがよいでしょう。 また、今回、双方向の通信要件に対応するためにEC2で独自にNAT機能を実装しましたが、EC2を使用するとOS以上はユーザー管理になってしまうので監視・運用の負荷が大きくなってしまう点が設計上の悩みどころです。AWSマネージドで柔軟かつ大規模なNATを実現できるサービスが出てくれると嬉しいですね。

皆様、こんにちは。 SCSK入社１年目の佐藤海渡です。 もう今月で、「入社１年目」と言えなくなってしまうことに恐怖を覚えている今日この頃です。 そんな私ですが、確実にこの１年で成長した点があります。 それは…   VCP-DCV 2024に合格したことです！ 今回の記事では、クラウド初学者である私が、VCP-DCVを受験し、合格するまでの流れをまとめてみようと思います。 VCP-DCVとは？ まず、最初に”VCP-DCV”とはどんな資格なのかを説明します。 VCP-DCVとは、”VMware Certified Professional – Data Center Virtualization”の略で データセンタを仮想化する技術に関するVMware社の認定資格です。 クラウドサービスを提供する基盤側の技術に関する資格で、 SCSKのクラウドサービスである ” USiZE ” も、このVMwareをベースにして構築されています。 「 ” USiZE ” ってなに？」って思ったそこのあなたはぜひ、私の執筆した第一回ブログをご参照ください。 USiZEってなに？～新人目線でまとめてみた～ – TechHarmony (usize-tech.com) ちなみに、VMwareの資格は難易度によって名称が分かれており、簡単な順に VCTA（VMware Certified Technical Associate） ↓ VCP（VMware Certified Professional）　 ←今回受験したのはこれ ↓ VCAP（Vmware Certified Advanced Professional） ↓ VCDX（Vmware Certified Design Expert） となっています。 また、分野によっても分かれており Data Center Virtualization（DCV）　 ←今回受験したのはこれ Network Virtualization（NW） Cloud Management and Automation（CMA） Security（SEC） ・・・ などなどに分かれています。 では、VCP-DCVがどんな試験で、どの立ち位置の試験なのか分かったところで 続いては、実際の受験の流れを記載していきます。 受験までの流れ 受験までの大きな流れとしては ①トレーニングコースの受講 ②資格試験の申込 ③試験対策の勉強 となります。それぞれについて以下で簡単に説明します。 ①トレーニングコースの受講 VCP認定資格を保有していない場合、トレーニングコースの受講が必須となります。 トレーニングはvSphereのバージョンや受講用途に応じていくつか種類がありますが、私は VMware vSphere: Install, Configure, Manage [V8] を受講しました。 上記のコースでは5日間でVMware vSphereの導入から管理までをみっちりINPUTしました。 コースの中ではハンズオンによるトレーニングもあり、実際にvSphereを操作することでより具体的なINPUTをすることが出来ました。 ハンズオンの中では、vCenterのデプロイからネットワークやストレージの作成、仮想マシンの作成からその管理方法、ライフサイクルの管理など実際の運用でも重要な内容が盛りだくさんとなっていました。 もっと詳しく内容が知りたいという方は、 こちら のリンクからコース概要についてご確認ください。 ②資格試験の申込 こちらは、AWSなどの資格試験と同様に Pearson VUE からの申し込みが可能となっています。 私は、テストセンターで受験しましたが、オンラインによる自宅からの受験も可能となっています。 （オンライン受験は準備が大変という噂を聞き、私はテストセンター受験にしました…笑） ③試験対策の勉強 こちらは、大きく行ったことは以下3点です。 ①のトレーニングコースのテキスト復習 Web上の問題集で演習 VMwareの公式ドキュメントを読む テキストの復習でINPUTをしっかりと行う ↓ 問題集を解いてみて知識のOUTPUTを行う ↓ 問題集を解いて疑問が残った部分について、公式のKBなどを読んで理解を深める 上記の勉強方法を資格受験の1か月前くらいから継続して行っていました。 試験当日 私は、テストセンターでの受験でしたので実際に試験会場に出向いての受験となりました。 当日、問題を見て困ったのが日本語→英語の問題文翻訳がなかったことです。 英語の問題集で対策をしていた方は、注意が必要かもしれません。 受験が終了すると、その場で合否と点数が出る試験になっています（合格点は300/500）。 勉強を頑張った甲斐もあり、何とかギリギリ合格することが出来ました。 受験から合格を振り返ってみて まず合格直後に思ったことは「受かって良かった！」ということでした。 短い時間でとにかくたくさんのINPUTをしていたので、中々試験までにすべてを覚えきることが難しく、試験中に何度も 「見たことはあるけど、どっちが正解だっけ」となることがありました。 そのため、その場で合格が分かった際には、まずほっとした感じでした。 しかしながら間違いなく、このVCP-DCVの受験を通してVMware vSphereに関するスキルは格段に向上したと思います。 今回の学びを活かして、USiZEのサービスをよりよくしていこうと思いますので ここまで読んでくださった方はぜひUSiZEに関しても興味をもっていただければと思います！ USiZEに関する情報は以下をご参照ください。 USiZEってなに？～新人目線でまとめてみた～ – TechHarmony (usize-tech.com) 　 ←USiZEについて簡単にまとめたもの クラウド移行だけでは描けない、理想のDXを実現する (scsk.jp) 　 ←USiZEホームページ お問い合わせ｜クラウド移行だけでは描けない、理想のDXを実現する (scsk.jp) 　 ←USiZEお問い合わせ先   以上、SCSK佐藤海渡の新卒1年目最後の記事でした。

こんにちは。SCSKの和田です。 私は、SCSKのプライベートクラウド「 USiZEシェアードモデル 」（ユーサイズシェアードモデル）のサービス企画・開発を担当しています。「USiZEって何だろう？」と思われた方、または「ちょっと気になる！」という好奇心旺盛なあなた！USiZEの世界を覗いてみたくなったら、まずはこちらをクリック↓ SCSKのプライベートクラウド「USiZEシェアードモデル」とは？ SCSKのプライベートクラウド「USiZEシェアードモデル」（ユーサイズシェアードモデル）についてご紹介します。 blog.usize-tech.com 2023.12.19 さて今回は、ちょっとした工夫を施した自動電話通知の仕組みを作成したので、その紹介をさせていただきます。 そもそも なぜ作ったの？ 正直なところ、システムのトラブルとは無縁でいたいのが本音ですが、いざという時には迅速な対応が求められます。 特にシステム監視からの重要なアラームが鳴った際には、ただちに通知を受け取りたいもの。ですが、夜中に急に鳴る電話にぼんやりと応答するのは、あまり賢明な対応とは言えませんよね。。。 そこで、電話に出た際に「きちんとアラーム発生の電話だと認識して、自分が対応し始めるぞ！」というアクションが伴う自動通知の仕組みが必要だと考えました。まずは、大まかなアーキテクチャからご紹介します。   アーキテクチャ 処理の流れを説明します。 アラーム発生時に左上の「電話通知用Lambda」を起動します。連絡先電話番号テーブルから連絡先を取得し、Amazon Connectを利用して電話をかけます。電話をかけたタイミングで、電話結果格納用テーブルに通話が開始されたことを登録します。 相手が電話に出て「ダイヤル1を押す」という対応の意思表示をした場合、右上の「電話結果確認用Lambda」を呼び出し、１で登録した電話結果格納用テーブルに結果を更新して終了します。 相手が電話に出たけれどダイヤル１を押さなかった、または電話に出なかった場合、「電話通知用Lambda」を非同期で呼び出すことで、次の連絡先へ電話をかける処理を開始します。 つまり、電話に出た際にダイヤル１を押すという明確なアクションを誰かが実施するまでは、アラーム担当者たちに順番に電話がかかり続けるというものです。次は、実際にどうやって作ったのかをご説明します。   どうやって作ったの？ Step1.監視設定・DynamoDBテーブル作成 まず、Amazon CloudWatch等を使用して監視システムを整えます。詳細な設定方法は他の記事に譲るとして、要点はアラームが作動した際にLambda関数を自動で起動することです。これにより、アラームの発生をシステムが即座に検知し対応に移れるようにします。 そして、「連絡先電話番号テーブル」と「電話結果格納テーブル」の２つのDynamoDBのテーブルを作成します。 連絡先電話番号テーブル パーティションキーはcall_group（String）、ソートキーはpriority（Number）を指定し、下記のようなデータを登録します。 処理を動かすには最低限これだけあれば十分です。 ※call_group：電話を掛ける対象のグループ、priority：通知順序の数字、phone_number：電話を掛けたい相手の電話番号 電話結果格納テーブル パーティションキーはcontact_id（String）を指定しておきます。こちらは事前にデータ登録は不要です。 Step2.Lambdaの作成 続いて、「電話通知用」と「電話結果確認用」の２つのLambdaを作成します。どちらもランタイムはPython3.9です。 IAMロールについては今回の記事のメインではないので、説明を割愛します。適宜、必要となる権限を付けたロールを作成してください。 電話通知用Lambda まず連絡先電話番号テーブルに登録されている１人目に電話をかけ、ダイヤル１を押すという意思表示がされた場合には処理を終了します。意思表示の対応が確認できなかった場合には、自分自身を非同期で呼び出し、次の人へ電話がかかるようにして処理を終了します。 電話をかける相手が多数いる場合や何周も電話をかけたい場合に、Lambdaのタイムアウト上限に達しないように、１回の電話ごとにLambdaを終了させるようにしています。 説明用に様々な設定情報を環境変数に設定していますが、実際の運用では設定ファイルをS3バケットに配置し、そこから読み込むなど、状況に応じて適宜変更してください。 import json import boto3 import os import time from boto3.dynamodb.conditions import Key dynamodb = boto3.resource("dynamodb") clientLambda = boto3.client("lambda") connect = boto3.client("connect") def lambda_handler(event, context):   print(json.dumps(event))   # *****処理1*****   # 環境変数に適宜必要となる情報を設定しておき、取得する   connectInstanceId = os.environ["CONNECT_INSTANCE_ID"]  # Amazon ConnectのインスタンスID   connectContactFlowId = os.environ["CONNECT_CONTACTFLOW_ID"]  # Amazon ConnectのコンタクトフローID   callerPhoneNumber = os.environ["CALLER_PHONE_NUMBER"]  # 発信元の電話番号   callStartMessage = os.environ["callStartMessage"]  # 電話開始時の音声 例）<speak>アラームが発生しました。対応する場合は、ダイヤル1を押してください<speak>     callConnectMessage = os.environ["callConnectMessage"]  # ダイヤル1が押されたときの時の音声 例）<speak>対応を確認しました<speak>   callNotConnectMessage = os.environ["callNotConnectMessage"]  # 電話が繋がらなかったときの音声 例）<speak>次の人へお繋します<speak>   callGroup = os.environ["call_group"]  # 電話を掛ける対象のグループ   nextLambda = os.environ["lambda_name"]  # 次に実行するLambdaの名前。このLambdaを再帰的に呼び出すために使用   # DynamoDBのテーブル名を取得   phoneTable_name = os.environ["phoneTable_name"] # 連絡先電話番号テーブル   contactTable_name = os.environ["contactTable_name"] # 電話結果格納テーブル   phoneTable = dynamodb.Table(phoneTable_name)     contactTable = dynamodb.Table(contactTable_name)   # *****処理2*****   # 何周目の何番目に登録の人に電話通知したいのかを判定。初回実行の場合は初期値を設定し、2回目以降は前回の情報を引き継ぐ     # 2回目以降の実行の場合は、前回の情報を引き継ぐ   if "processId" in event.keys():       processId = event["processId"]       callLoop = int(event["call_loop"]) # 何周目か         lastPhoneOrder = int(event["phone_order"])  # 前回は何番目の人に電話をかけたのか   # 初回実行の場合（processIdが存在しない場合）は初期値を設定     else:       processId = context.aws_request_id # lambdaのRequestIdをプロセスIDに設定       callLoop = 1  # 初回なので1周目とする         lastPhoneOrder = 0  # 初回なので0番目(前回はいない)とする   # *****処理3*****   # 電話を掛ける対象のグループ（１周）が何人なのか、何周目かを判定し、周回上限を超えるまでは次にかける電話番号を取得する     try:       phoneTableQueryResponse = phoneTable.query(           KeyConditionExpression=Key("call_group").eq(callGroup)         )       # call_group内の電話番号の数         maxPhoneOrder = phoneTableQueryResponse["Count"]   except Exception as error:         print("[ERROR]連絡先電話番号テーブルから通知先電話番号数の取得に失敗")       print(error)       return {'statusCode': 400 }   nextPhoneOrder = lastPhoneOrder + 1 # 次にかける電話番号の順番     # 次にかける電話番号の順番がcall_group内の通知先電話番号の数を超えていた場合は１番目に戻し、周回数を＋１する   if nextPhoneOrder > maxPhoneOrder:       nextPhoneOrder = 1       callLoop += 1   # 周回数が３以上になったら終了させる（２周まで電話をかけるとします）   if callLoop >= 3:       print("[INFO]上限周回数まで電話をかけ続けましたので、処理を終了します")       return {'statusCode': 200 }   # 連絡先電話番号テーブルから次かける電話番号を取得   try:       phoneTableGetResponse = phoneTable.get_item(           Key={"call_group": callGroup, "priority": nextPhoneOrder}       )         phoneNumber = phoneTableGetResponse["Item"]["phone_number"] # 次にかける電話番号   except Exception as error:       print("[ERROR]電話番号テーブルから次の電話番号の取得に失敗")       print(error)         return {'statusCode': 400 }   # *****処理4*****   # Step3で作成するコンタクトフローを指定して電話を掛ける   try:       connectResponse = connect.start_outbound_voice_contact(           DestinationPhoneNumber=phoneNumber,  # 送信先の電話番号           ContactFlowId=connectContactFlowId,           InstanceId=connectInstanceId,           SourcePhoneNumber=callerPhoneNumber,           Attributes={               "callStartMessage": callStartMessage,               "callConnectMessage": callConnectMessage,               "callNotConnectMessage": callNotConnectMessage,           },         )   except Exception as error:       print("[ERROR]Amazon Connectへの連係に失敗")       print(error)         return {'statusCode': 400 }     contactId = connectResponse["ContactId"]  # 発信のContactID   # *****処理5****   # 電話結果格納テーブルに通話開始を登録し、結果が格納されるのを待つ   try:       contactTabelputResponse = contactTable.put_item(           Item={               "contact_id": contactId,  # 発信のContactID               "call_flag": 0,  # 電話繋がったかフラグ 繋がれば1になる           }         )   except Exception as error:       print("[ERROR]電話結果格納テーブルへのコールフラグの準備に失敗")       print(error)         return {'statusCode': 400 }     # 応答があり電話結果格納テーブルが更新されるまで待機   time.sleep(60)   # 電話結果格納テーブルからcall_flagの情報を取得   try:       contactTableGetResponse = contactTable.get_item(           Key={               "contact_id": contactId,           }       )         callFlag = contactTableGetResponse["Item"]["call_flag"]  # 電話繋がったかフラグ   except Exception as error:       print("[ERROR]電話結果格納テーブルからコール結果の取得に失敗")       print(error)         return {'statusCode': 400 }     # *****処理6*****   # 電話応答の結果から、つながっていれば処理を終了し、つながっていなければ次の人に電話をかける   if callFlag == 0:       try:           passEvent = {               "processId": processId,               "phone_order": nextPhoneOrder,               "call_loop": callLoop,             }           lambda_responce = clientLambda.invoke(               FunctionName=nextLambda,               InvocationType="Event",  # 非同期的に呼び出す               Payload=json.dumps(passEvent),             )           # 呼び出しタイプがEventの場合はステータスコードが202が正常           lambdaStatusCode = lambda_responce["StatusCode"]             if lambdaStatusCode == 202:               print(f"[INFO]{nextLambda}にステータスコード「{str(lambdaStatusCode)}」で正常に連携されました")           else:               print(f"[ERROR]{nextLambda}にステータスコード「{str(lambdaStatusCode)}」で正常に連携されませんでした。")       except Exception as error:           print("[ERROR]次のLambda呼び出しに失敗")           print(error)             return {'statusCode': 400 }     # 電話が繋がっていれば終了   elif callFlag == 1:         print("[INFO]受電を確認したため架電を終了")   print(f"[INFO]{context.function_name}を正常に終了")     return {"statusCode": 200}   電話結果確認用Lambda ダイヤル１が押された場合にのみ、Amazon Connectコンタクトフローから呼び出されるLambdaです。 説明用に割愛していますが、通知先や通知時刻等もテーブルに書き込むと、後からログとしても確認がしやすい状態になります。 import json import boto3 import os def lambda_handler(event, context):   print(json.dumps(event))     # 環境変数に電話結果格納用DynamoDBのテーブル名を設定しておき、取得する   table_name = os.environ["contactTable_name"]   dynamodb = boto3.resource("dynamodb")   table = dynamodb.Table(table_name)   try:       # contactidを取得して、電話結果格納用DynamoDBのcall_flagを更新       contactId = event["Details"]["ContactData"]["ContactId"]       response = table.update_item(           Key={               "contact_id": contactId,           },           UpdateExpression="set call_flag=:a",           ExpressionAttributeValues={":a": 1},         )   except Exception as error:       print("[ERROR]コールフラグの変更に失敗")       print(error)         return {"statusCode": 400}     return {"statusCode": 200} Step3.Amazon Connectコンタクトフロー作成 以下、Amazon Connectのインスタンス作成、電話番号の取得は終わっていることを前提とします。 Amazon Connectの初期設定はこちらの記事で解説していますので是非ご参照ください。 Amazon Connectのはじめ方 Amazon Connect を触ってみましたので、今回の記事ではインスタンスの作成方法と電話番号の取得方法、ユーザー作成についての手順をご紹介します。 Amazon Connectを始める皆さんの参考になればと思っています。 blog.usize-tech.com 2022.02.16 それでは適宜、Amazon Connect側の設定が完了している前提で、今回の肝となるAmazon Connectコンタクトフローについて説明します。ここでは以下の流れに沿って、電話をかけるプロセスを作成します。 電話接続（発信）・ログや音声の設定 自動音声にて「アラームが発生しました。対応する場合は、ダイヤル1を押してください」と案内し、相手がダイヤル1を押したかどうかを15秒間チェック ※下記コンタクトフローの赤枠の「顧客の入力を保存する」の部分で定義 ダイヤル1が押された場合は、Step2にて作成した電話結果確認用Lambda関数を呼び出して、「対応を確認しました。」と案内し、通話を終了 ダイヤル1が時間内に押されなかった場合は、「次の人にお繋ぎします。」と案内し、通話を終了 このシンプルな流れによって、確実に対応意思表示のアクションが取られるまでのプロセス自動化が可能となります。   最後に この自動通知の仕組みよって、ちょっとした改善が日々の業務にもたらされました。大幅な変化というわけではありませんが、これまでの手作業による連絡リストの確認や、数回の電話をかける手間が省けたのは大きな進歩です。 USiZE（ユーサイズ）が提供するサービスも、このような小さな工夫を積み重ねて、お客様にとってより使いやすく、信頼性の高いものになるよう日々努力しています。私たちが提供するサービスを通じて、皆様のビジネスもさらにスムーズに、そして快適に進んでいくことを願っています。もし、USiZE（ユーサイズ）についてもっと知りたいと思われたら、ぜひ以下サイトを訪れてみてください。 運用付きの国産クラウドサービス　USiZEシェアードモデル 運用付きの国産クラウドサービス│SCSK株式会社 VMwareベースで構築された、高可用性、高機密を備えた国産のプライベートクラウドです。ファシリティスタンダード最高レベルのティア4に適合する日本国内のデータセンター上で稼働し、お客様データの保護とデータ主権を確保します。 www.scsk.jp SCSKのプライベートクラウド「USiZEシェアードモデル」とは？ SCSKのプライベートクラウド「USiZEシェアードモデル」とは？ SCSKのプライベートクラウド「USiZEシェアードモデル」（ユーサイズシェアードモデル）についてご紹介します。 blog.usize-tech.com 2023.12.19 最後までお読みいただきありがとうございました。 今回の小さな工夫が、皆様の仕事に少しでも役立つことを願っています。それでは、快適なITライフをお過ごしください。

Prisma Cloudは、クラウド環境のセキュリティとコンプライアンスを一元管理するツールで、リアルタイムの脅威検出やリソースの監視が可能です。今回は、実際にAzure環境（サブスクリプション）をPrisma Cloudに接続してみました。 作業する前に まずは接続する前に接続方法や前提条件の確認から行います。 接続パターン Azure環境をPrisma Cloudに接続するには、以下の3つのパターンがあります。 1 Azureテナント サブスクリプションやActive Directoryを含む、すべてのAzureリソースをPrisma Cloudに接続します。 2 Azureサブスクリプション 単一のサブスクリプションのみを接続します。 3 Azure Active Directory IAMモジュールをルートテナントレベルで接続します。 上記の接続パターンは、商用、政府、中国の各Azureクラウドで利用可能です。 接続方法 Prisma CloudにAzure環境を接続するためには、Azure環境側で必要なリソースを作成する必要があります。 以下の方法が利用できます。 1 Terraform（推奨） 自動的にPrisma Cloudアプリケーションをセットアップし、Azureサブスクリプションへのアクセスを許可します。ただし、中国のAzureではTerraformテンプレートはサポートされていません。 2 カスタムロールJSON 手動でカスタムロールを作成し、Prisma Cloudアプリケーションに必要な権限を付与します。 3 手動での承認 Terraformを使用できない場合、必要なリソースを手動で作成してPrisma CloudがAzure APIを呼び出せるようにします。 サブスクリプションの状態と影響 サブスクリプションの状態によって、Prisma Cloudの機能に影響が出ることがあります。たとえば、サブスクリプションが有効な場合は問題なくデータの取り込みや自動修正が可能ですが、削除されたり無効になったりしたサブスクリプションではデータの取り込みができません。 前提条件 Key Vaultとストレージアカウント Prisma CloudがAzure Key Vaultリソースを取り込むためには、特定の権限を設定する必要があります。 Azureポータルでストレージアカウントの設定を行い、「ストレージアカウントキーを許可する」オプションを有効にしてください。 ネットワークセキュリティグループ（NSG）フローログ ・Prisma Cloudがネットワークトラフィックデータを取得するためには、NSGフローログを有効にする必要があります。 必要なロールと権限 Prisma Cloudを接続するためには、基本的なセキュリティ機能だけでなく、より高度なセキュリティ機能にも対応するための適切なロールと権限を持っている必要があります。これには、Reader、Reader and Data Access、Network Contributor、Storage Account Contributor などのロールが含まれます。   接続してみる 前提条件等の確認ができたのでここからは実際に接続してみます。 今回はTerraformを使ってAzureサブスクリプションをPrisma Cloudに接続します。 作業準備 Azure環境とPrisma Cloudの接続作業には、以下の準備が必要です。 サブスクリプションIDおよびテナントIDの情報を用意してください。 Prisma Cloudが作成するアプリケーションをAzure Active Directoryに追加する権限（アカウントオーナーまたはコントリビューター）を持っていることを確認してください。 Azure PortalでCloudShellが使えることを確認してください。 Terraformスクリプトの取得 Prisma Cloudにログインします。 「設定」から「プロバイダ」＞「クラウドアカウント」を選択し、「プロバイダーに接続する」＞「クラウドアカウント」をクリックします。 クラウドプロバイダーで「Azure」を選択します。 「始めましょう」の画面が表示されたら、範囲は「サブスクリプション」、デプロイメントタイプは「商用」を選択します。 今回はCSPM機能だけ利用できればよいので、エージェントレスワークロードスキャンやサーバレス機能スキャン、エージェントベースのワークロード保護はチェックを外して次に進みます 「アカウントの設定」画面が表示されたら、以下を入力します。 ・ディレクトリ（テナント）ID ・アカウント名　※自由に指定できます ・サブスクリプションID ・「修復」機能は利用しないためチェックを外したままにします 上記を入力するとTerraformスクリプトがダウンロードできるようになるので、「Terraformスクリプトのダウンロード」をクリックします。   これでTerraformスクリプトのダウンロードは完了です。 Terraformスクリプトの実行 Terraformスクリプトがダウンロードできたので、次はAzure環境上でTerraformスクリプトを実行します。 Azureポータルにアカウントオーナーまたはコントリビューター権限でログインします。 今回はアカウントオーナー権限でログインしました。 CloudShellのアイコンをクリックしてCLI画面を表示します。ここからはCloudShell上での作業になります。 任意のパスにディレクトリを作成して、先ほどダウンロードしたTerraformスクリプトををアップロードします。 作成したディレクトリに移動します。 以下のコマンドを実行します。 # terraform init 「Terraform has been successfully initialized!」と表示されればOK 以下のコマンドを実行します。 # terraform apply 実行するか確認されるので、「 yes 」と入力します。 「Apply complete!」と表示されたら実行完了です。 Prisma Cloudに接続 Terraformスクリプトを実行して必要なリソースをAzure環境に設定できたので、次はいよいよPrisma Cloudに接続します。 Prisma Cloudにログインします。 Terraformスクリプトの取得でサブスクリプションID等を入力したところまで同じ設定をして進みます。 「アカウントの設定」画面で、「Terraformスクリプトのダウンロード」の下にある項目に情報を入力していきます。 アプリケーション（クライアント）ID Terraformスクリプト実行結果の 「c__application_client_id」の値を入力 アプリケーションクライアントシークレット Terraformスクリプト実行結果の 「d__application_client_secret」の値を入力 エンタープライズアプリケーションオブジェクトID Terraformスクリプト実行結果の「e__enterprise_application_object_id」の値を入力 ネットワークセキュリティグループフローログの取り込みと監視 チェックを入れたまま アカウントグループ 任意のアカウントグループを指定。 今回は事前に作成しておいたAzure環境用のものを指定します 「Next」をクリックして次の画面に進むと接続が始まります。 レビューステータスがすべて成功（緑色）になれば接続OKです！ 「保存して閉じる」をクリックして完了します。 監視設定してみる AzureサブスクリプションをPrisma Cloudに接続できたので、監視設定をしていきます。 アラートルールの設定 セキュリティ的によくないクラウド設定等を検知するため、アラートルールを設定していきます。 Prisma Cloudコンソール画面上部にある「アラート」を選択します。 「アラートルールを表示」を選択し、「アラートルールの追加」をクリックします。 アラートルール名を入力します。 アラート通知を行いたいので、「自動化(オプション)」＞「アラート通知」の項目を有効化して次に進みます。 「ターゲットを割り当て」の画面に進んだら、監視対象のアカウントグループを指定します。 今回は先ほど接続したAzureサブスクリプションで指定したアカウントグループを選択して次に進みます。 「ポリシーを割り当て」の画面に進んだら、監視するポリシーを選択します。 今回は一旦すべてのポリシーで監視してみるので「すべてのポリシーを選択」を有効にして、次に進みます。 「通知を設定」に進んだら、アラートの通知先を選択できます。 今回はメール通知したいので、「電子メール」を選択してメールアドレスを入力し、有効化します。 「概要」画面に進んだら設定した内容を確認し、「保存」します。 これでアラートルールの設定ができました。 アラート通知 アラートルールを設定してしばらくすると、ポリシーに違反したリソースを検知してアラート通知メールが飛んできました。 メール本文には、アラート検知したポリシーおよびアラート数、アラート検知した主なリソース名等が記載されています。 メールに記載されているリンク（「Open」の数のところをクリック）から該当のアラート情報の画面（Prisma Cloudのコンソール画面）にとぶことができました。より詳細なアラートの情報はコンソール画面で確認できるようです。 ↓　リンクをクリックすると… アセット情報 アラートルールによる監視とは別で、Prisma Cloudに接続されたAzureサブスクリプションのアセット情報がPrisma Cloudコンソール上で確認できます。こちらは追加の設定等は不要で、Prisma Cloudと接続できれば表示されてきます。 Prisma Cloudコンソール画面上部にある「インベントリ」＞「アセット」を選択すると確認できます。 検証したPrisma Cloud環境は、Azure以外にもAWSやGCPも接続されています。 「AZURE」をクリックすると各サービスごとに表示されます。さらに選択していくと、Azure環境上に存在しているリソース情報の詳細を表示することができます。 まとめ 今回は、Prisma CloudにAzureサブスクリプション接続してアラート検知するところまで確認できました。 今後も、実用的な情報をお届けできればと思います。 また、当社では、複数クラウド環境の設定状況を自動でチェックし、設定ミスやコンプライアンス違反、異常行動などのリスクを診断するCSPMソリューションを販売しております。 マルチクラウド設定診断サービス with CSPM｜ SCSK株式会社 マルチクラウド環境のセキュリティ設定リスクを手軽に確認可能なスポット診断サービスです。独自の診断レポートが、運用上の設定ミスや設計不備、クラウド環境の仕様変更などで発生し得る問題を可視化し、セキュリティインシデントの早期発見に役立ちます。 www.scsk.jp ご興味のある方は是非、お気軽にお問い合わせください。

SCSKではDropbox管理業務負荷の軽減及びエンドユーザの利便性を向上させるためのDropbox統合管理ツールとして「Smartdbx」を開発いたしました。 こちらの記事では「Smartdbx」についてご紹介いたします。 Dropbox（Business版）の機能と管理者について Smartdbxのご紹介の前にDropboxの機能と管理者に関してです。 DropboxのBusiness（法人）版は個人版Dropboxとは違い、組織（＝チーム）単位で契約を行うため、「テナント」と呼ばれる組織の環境が出来上がります。Dropboxではこのテナントを「チーム」とも呼びます。 テナントは管理者が各種設定を行うことができるため個人向けのDropboxでは実現できない、組織の情報管理を行うことができます。 組織で情報を管理するには、「管理者」は必要です。 ただ、組織の規模が大きくなればなるほど、管理者の手で組織管理を行うことは難しくなる場合があります。社内ルールの策定だけでは、メンバーの方が順守できているとは限りません。 全ての確認と管理を管理者が行うには運用負荷がかかる場合があります。 チームフォルダの作成 「チームフォルダ」とはDropboxの共有用のフォルダの一つで、管理者が作成し、管理者がアクセス権をつけるフォルダです。 この「チームフォルダ」にコンテンツを保存すると、アクセス権のあるメンバー全員と自動的に同期されます。 個人版のDropboxには存在せず、Business版のみの機能で、これがあることでファイルサーバーの代わりとして使用できます。   種類 特徴 用途 個人フォルダ メンバーが作成した共有されていないフォルダ 所有者は、メンバー。 フォルダの所有者のみがアクセス可能。 ファイルサーバーのユーザーフォルダの代わりとなる。 共有フォルダ メンバーが作成し、メンバー間で共有状態のフォルダ 所有者はメンバー。 共有メンバーのみがアクセス可能。 編集可能/閲覧の二種類の権限を設定可能。 共有フォルダ内のサブフォルダでは、独自の共有設定は行えない。 プロジェクトフォルダなど期間限定で共有したい場合に利用。 チームフォルダ システム管理者が作成、管理する特別なフォルダ 所有者はシステム管理者。 編集可能/閲覧のみの二種類の権限を設定可能。 サブフォルダにユーザー、グループを指定して共有メンバーを追加したり、上位のチームフォルダから継承された共有メンバ(アクセス権)から特定のグループやユーザーを削除することが可能。 部署単位でアクセス権を管理した上で情報共有を実施したい場合に利用。 ファイルサーバーの共有フォルダの主な移行先になる。   チームフォルダの作成や管理を管理者が行うと、管理者の作業は増えてしまいます。 また、管理者にフォルダ作成を依頼した際、ユーザーは管理者の作業完了を待つ必要がありました。 アクセス権限設定 Ｄropboxではチーム管理者が行うか、編集権限のあるユーザーが行いますが、会社規模が大きくなると統制がとりづらくなる場合があります。 社外との共有 組織の重要な情報管理のためにユーザーに自由に許可はできないことは多いと思います。ただDropboxでは外部共有先管理は管理者のみが行うため、管理者がすべて監視することが難しいです。   Smartdbxとは？ さて本題ですが、Smartdbxとは何でしょうか？ 冒頭の記載と重なりますが、Smartdbxとは、Dropboxの管理者の業務負荷の軽減やエンドユーザの利便性を向上させるためのツールです。 フォルダ管理については自動化を行い、社外の共有については上長の承認を、アクセス権管理についてもツールを通し一括管理を実現できます。 「Smartdbx」には管理者業務を自動化する事で、管理者業務自体を極力なくし、管理者の運用負荷を軽減させる機能が用意されております。 SmartdbxとDropbox と組み合わせてお使いいただくことでもっと便利に、効率的にDropbox をご利用いただくことができます。 弊社がDropboxの管理ツール開発を始めたのは2017年からになります。 ——————————————————————– 2017年 　ONEUPの開発・運用 Dropboxを導入した時から社内の運用管理の負荷低減、効率アップを目的としたツール（社内呼称：ONEUP）を開発、運用しています。 2022年 　外部共有の管理機能をリリースして機能拡張 2023年 　Smartdbx開発 —————————————————————— ONEUPに更に多くのDropboxプロジェクトで培った知見を取り入れ、多くのお客様からご要望が多い有益な機能をSmartdbxとして実現しました。 ではどんな機能があるのかについてご紹介していきたいと思います。   機能 機能詳細 基本/オプション アカウント/グループ管理機能 •人事マスタ(組織と人)と自動連係 •Dropboxのアカウントおよびグループの連係 •アカウント情報の照会 •グループ情報の照会 基本機能① 共有フォルダ管理 •共有フォルダ管理機能 •共有フォルダ承認ワークフロー •共有フォルダ棚卸機能 サブフォルダ含みの棚卸しのみ、順次リリース(可視化機能として) •共有フォルダアーカイブ機能 (順次リリース) •フォルダテンプレート 基本機能② 社外共有フォルダ監視 個人フォルダや、共有フォルダ申請で申請されたチーム外共有以外の社外共有の監視・ブロック機能 基本機能③ 全社ナレッジ共有 1,000人以上となるような大規模環境での全社共有するフォルダ管理機能 オプション① カスタムドメイン（ファイル送受信） 社外の方とのファイルの受渡をDropboxドメインを使わずに実現する機能 オプション②   機能紹介 今回はSmartdbxの基本機能3つについてご紹介いたします。 基本機能①　アカウント/グループ管理機能 「Smartdbx」の利用アカウントを管理する機能です。 人事マスタから指定のcsvフォーマットで人、組織、役職などの情報を取り込んでDropboxアカウントと連携してDropboxグループの管理も行うことができます。 組織単位のDropboxグループを人事情報と連携することで、自動でグループ内メンバーを変更します。 メンバーも人事情報と連携して、アカウントの発行、削除を行うことができます。 また、組織や役職の情報はSmartdbx内の承認ワークフローにも活用しています。   基本機能②　共有フォルダ管理 社内外との共有フォルダ管理の一元化と効率化を行います。 フォルダ共有 Dropboxの標準機能として用意されている共有方法はいろいろありますがその中に「フォルダ共有」があります。 「フォルダ共有」とは、Dropboxのアカウントを持っているユーザ同士でファイルを共有・編集できる機能です。 業務を行う際に便利な機能で、社外との共同プロジェクトでもよくつかわれます。 共有フォルダ申請 共有するフォルダの種類の中に冒頭で記載した「チームフォルダ」があります。 組織のフォルダ管理においてチームフォルダは重要な役割を果たしますが チームフォルダの作成や管理は管理者が行うため、管理者の作業は増えてしまいます。 また、管理者にフォルダ作成を依頼した際、ユーザーは管理者の作業完了を待つ必要がありました。 そこで、この機能を通して申請を行うことで管理者が作業せずに 自動でチームフォルダの作成・設定・アクセス権管理が行えるようになります。 社外との共有については外部共有先を事前に登録したり、必要に応じて申請時にワークフローを追加することで上長の承認を得ることができるようになります。 また、共有する社外の方（お客様やビジネスパートナー）と共有ルールなどを確認して遵守して頂く為、社外の方を含めた署名を回付する事も可能です。 署名には、Dropbox Signを使用いたします。 社外の方を含めたワークフローを利用する場合は、別途Dropbox Sign APIのご契約（有償）が必要となります。   「社外共有フォルダ申請」ワークフロー 弊社で実際に使用している「社外共有フォルダ申請」のワークフローを一例としてご紹介いたします。 ※上司からの承認＋署名回付を有効に設定 ワークフローは以下切替が可能です。 承認自体の有無 承認者のレベル（承認は課長まで、部長まで、など） 社内社外での切替  署名回付   棚卸し機能 有効期限（申請時に設定した利用終了日）に近づくと申請者にアラートの通知が届き、期限が切れると自動で社外共有が解除される仕様となっています。 利用していないフォルダがずっと社外共有されているのはセキュリティ的に問題です。 ほったらかしを防ぐ機能も備わっています。 現状Smartdbxで設定したフォルダについて管理を行え、細かいアクセス権管理については今後開発予定となっております。 アーカイブ機能 上記棚卸し機能により、共有フォルダ申請で設定した有効期限が過ぎた時、または終了申請がされた際、共有が解除される仕組みになっております。 では利用期間が過ぎた場合、そのフォルダをどうするのか？という問題があります。 そこで、共有を解除したフォルダを即時削除するのではなくDropboxでアーカイブを行います。 アーカイブをした場合、アクセス権はなくなりますが、データとしてはDropboxに保持されていますので、どうしてもデータが再度必要になった際に復元可能になります。 （本機能は順次開発予定となっております。） 基本機能③　社外共有フォルダ監視 組織で情報を扱う中で、社外との共有について、不要な共有がされていないか、正しい相手に共有されているか、人手で監視が難しいという問題があります。 特に個人フォルダと社外との共有を自由に許可してしまうと、セキュリティ対策としては課題に上がることが多いです。 そこで本機能「社外共有フォルダ監視」を活用いただくことで社外との共有は申請されているところだけに限定します。 個人フォルダが社外共有された場合や、未承認の会社との社外共有は、自動で解除され警告メールが発信される仕組みです。 こちらの機能で、外部共有を申請したものに限定することで、安全性を高めています。 これらの機能によって、管理者の運用負荷を軽減させることができるため、より快適な業務をDropbox で実現できます。 「Smartdbx」について詳しくはこちらをご覧ください。 Dropbox： Dropbox ｜ SCSK株式会社 次回は「Smartdbx」のオプション機能についてご紹介します！

2024年1月15日に、DLPの機能強化がアップデート情報としてあがりました。 具体的にはOCR機能が利用できるというものです！ 今回はその新機能を詳しくご紹介します。 OCRとは まず、OCRについてですが、OCRとは「Optical Character Recognition」の略で日本語にすると「光学文字認識」です。 印刷されたテキストや手書きの文字をカメラやスキャナ等の光学的な手段でデータとして取り込み、それを解読（文字認識）することにより、パソコン等のコンピューターが識別できる文字（テキスト）データに変換する技術です。 今回のアップデートは、この技術を利用したもので、 画像ファイル内のテキストをスキャンして分析し、個人情報や機密情報が含まれている場合はそれを保護することができるようになるという機能強化となっています。   条件 2024年1月時点では以下のような条件があります。 ※OCR固有の条件に加え、DLP機能自体の条件も含みます。 ・文字タイプ：アルファベット文字のみ（現時点では日本語が未対応です) ・画像タイプ：png, jpeg, tiff, bmp, pnm, webp, jpeg2000 ・ファイルサイズ ・ テキストファイル：1 KB～20 MB ・ 画像：10 KB～20 MB TLS Inspectionがデフォルトで暗黙的にバイパスされているアプリケーションはサポートされていません。 上記条件を踏まえ、今回は”Confidential”という文字が1つ入ったJPGファイルをGmailに添付させないという動作検証を行ってみました。 実際に試してみた結果を次の項目でご説明します！   設定方法 CMAの設定は、こちらの記事に記載の通りに行っていきます。 CatoクラウドのDLPについて Catoクラウドの情報漏洩対策にあたる「DLP」について紹介していきます！ blog.usize-tech.com 2023.10.06 Step1 今回は、カスタム定義型で”Confidential”というKeywordを指定し定義型を作成しました。 Thresholdは閾値の設定で、Keyword/Phraseで指定した文字の数量を定義します。 例えば、今回の場合「 ”Confidential” という文字が 1つ 入ったJPGファイルを、Gmailに添付させない」なのでThresholdは【1】となります。 Name：OCR Test “Confidential”　※任意の名前を入力 Description：OCR Test “Confidential”　※任意の説明を入力 Threshold：1 Keyword/Phrase：Confidential Validate Keywordでは、対象のファイルをアップロードすることで、そのファイルが定義した定義型にマッチしているかを事前にテストすることが可能です。 “Confidential”のテキストが入ったJPGファイルをアップロードしてみると、 このように”File matched the data type”とメッセージが表示され、定義型にマッチしていることがわかりました。 試しに、”Confiden s ial”というスペルを一部誤ったテキストが入ったJPGファイルをアップロードしてみると、 ” File didn’t match the data type”とメッセージが表示され、定義型にマッチしないことがわかります。 今回はカスタム定義型で定義型を作成していますが、もちろん事前定義型を利用することも可能です。 事前定義型の場合、ThresholdはCato社で事前に定義付けされており、Data Type Catalogから確認が可能です。 例えば、Confidential document marker[Japan] という定義型にはThresholdが【2】と定義されています。 この場合、Descriptionに記載のインスタンスのうち最低でも2つ含まれていないと、この定義型にマッチしないものと見なされます。   右側の…からValidateに進むと、カスタム定義型と同様に事前にテストが可能ですので事前にテストすることをお勧めします！ Step2 次にProfile作成ですが、 ここで”OCR Scan Enabled”にチェックを入れるだけでOCR機能を有効にできます！ Step3 作成したProfileを使って次にルールを作成していきます。 今回は以下通りの設定を行いました。 Name：DLPテスト Gmail(OCR) User defined　※任意のルール名を入力 Source：Any Application：Gmail Activities：Add Attchment DLP Profiles：Test OCR User define OCR enable　※STEP2で作成したProfileを選択 Actions：Block Tracking：Event 以上でCMA設定が完了しましたので、動作確認を行っていきます。   動作確認 実際にGmailでテストファイルの添付をしてみると・・・ Cato ClientをOFF(Disconnected状態)の場合、テストファイルは添付可能でしたが、 その後、Cato ClientをON(Connected状態)にして再度添付を試してみると、想定通りBlockされました。 さらに、OCRをOFFにしたProfileを作成して同様に試してみると、このようにテストファイルは添付ができました。 よって、きちんとOCR機能が働いていることがわかります。 試しに、ZipファイルやPass付のZipファイル、手書きや写真（粗めに撮影したもの）にて添付を試してみた結果、残念ながら添付ができてしまいました…。 よって、CatoクラウドのOCR機能は、一般的な「OCR」であり、最先端技術である「AI-OCR」ではないようです。 今後の機能拡張により、精度向上を期待したいと思います。   まとめ 今回はDLPの新機能についてご紹介いたしました。 今後も様々な機能強化や新機能のリリースを予定しております！ リリースされたらどう使ったらよいのか…悩まれる方も少なくはないかと思いますので、使用方法や使用感をたくさん発信していきます！

はじめに Prisma Cloud のライセンスの仕様をまとめてみました。 ライセンスの仕様については変更の可能性がありますので、最新のドキュメントは以下を参考にしてください。 Enterprise Edition Compute Edition Prisma Cloud ではライセンスは 100クレジット単位 で販売され、監視および保護するリソース数に応じてクレジット数が算出されます。 Prisma Cloud のライセンス仕様(Enterprise Edition) ※Prisma Cloud 製品ごとに消費するクレジット数が異なります。 Prisma Cloud 製品 消費するクレジット数 可視性 ※1 、コンプライアンス、ガバナンス(脅威検出を含む) ・Amazon EC2 ・Azure VM ・Azure Virtual Machine Scale Sets ・Google Compute Engine ・Alibaba Cloud ECS ・Oracle Cloud Compute 1台 1 クレジット IAM Security 0.25 x 可視性 ※1 、コンプライアンス、ガバナンスのクレジット使用量 データ セキュリティ 消費するクレジット数 ・Amazon S3 ・Azure Blob Storage  露出スキャン ※2 : 200GBあたり1クレジット フルスキャン ※3 : 33GBあたり1クレジット サーバーレス セキュリティ 消費するクレジット数 ・AWS Lambda ・Azure Functions Defender サーバーレス関数 6つにつき 1クレジット Prisma Cloud製品 消費するクレジット数 クラウドディスカバリーとエクスポージャー管理 0.25 x 可視性 ※1 、コンプライアンス、ガバナンスのクレジット使用量 ホスト セキュリティ(Linux, Windows) デプロイされたホスト Defender あたり 0.5クレジット コンテナ セキュリティ(Linux, Windows) デプロイされた Container Defender ごとに 5 クレジット デプロイされたアプリ埋め込み Defender ごとに 1 クレジット Web Application and API Security (WAAS) インラインで展開された Defender ごとに 2 クレジット 帯域外モードで Defender ごとに 2 クレジット Infrastructure as Code (IaC) セキュリティ 開発者 ※4  ごとに 3クレジット ソフトウェア・コンポジション解析(SCA) 開発者 ※4  ごとに 4クレジット シークレット セキュリティ 開発者 ※4  ごとに 1クレジット CI/CD セキュリティ 開発者 ※4  ごとに 3クレジット   ※1 可視性とは：クラウド環境全体の設定ミス、権限、データ、脆弱性の保護 ※2 露出とは：以前に検出された脆弱性が、ネットワーク上の不正な行為者によって利用された場合のインシデント ※3 フルスキャン：エクスポージャースキャン、データ分類、マルウェア分析 ※4 開発者とは：Prisma Cloud で保護しているアクティブなリポジトリに対して、過去90日以内でGitでコントリビュートした人 Prisma Cloud のライセンス仕様(Compute Edition) ※Prisma Cloud の製品ごとに消費するクレジット数が異なります。 Prisma Cloud製品   消費するクレジット数 ホスト セキュリティ(Linux, Windows) デプロイされたホスト Defender ごと 1クレジット コンテナ セキュリティ(Linux, Windows) デプロイされた Container Defender ごとに 7クレジット デプロイされたアプリ埋め込み Defender ごとに 1クレジット Web Application and API Security (WAAS) インライン モードを使用してデプロイされたホスト、コンテナー、またはアプリ埋め込み Defender ごとに 30クレジット アウトオブバンド モードで Defender ごとに 2クレジット サーバーレス セキュリティ   消費するクレジット数 ・AWS Lambda ・Azure Functions Defender サーバーレス関数 6つあたり 1クレジット Prisma Cloud クレジットの購入と使用方法 Prisma Cloud クレジットは、パロアルトネットワークス、パロアルトネットワークスのチャネルパートナー、およびさまざまなマーケットプレイス(AWS Marketplaceなど)から購入できます。 購入した Prisma Cloud クレジットがアカウントに追加されると、Prisma Cloud コンソール内から Prisma Cloud 製品モジュールを有効にできます。 Prisma Cloud クレジット使用量の測定方法 クレジット使用量は 1時間 ごとに測定されます(データセキュリティを除く※ Enterprise Edition のみ)。 その後、日次、週次、月次、四半期ごとの平均値にまとめて報告されます。 これにより、短期間の利用増加による超過を防ぎます。 Prisma Cloud の全モジュールにわたって、購入したクレジットを超えて使用した場合、カスタマーサクセスチームが追加のクレジット購入をサポートします。 おわりに 当社では、複数クラウド環境の設定状況を自動でチェックし、設定ミスやコンプライアンス違反、異常行動などのリスクを診断するCSPMソリューションを販売しております。 マルチクラウド設定診断サービス with CSPM｜ SCSK株式会社 ご興味のある方は是非、お気軽にお問い合わせください。

みなさんこんにちは、鎌田です。 PrismaCloudを使ったサービス開発、運営を行っている中での気づきや、使いこなし方などを皆さんと共有することで、クラウドセキュリティの重要性の認知度や対策レベルをみんなで徐々に上げられればいい、そういうモチベーションのブログ記事です。 ただの情報発信ではなく、PrismaCloudの使いこなし方や、失敗から学んだ教訓など、少し具体的な実務よりの内容も共有していければと思います。 今回は、CSPMとCWPPの領域について、PrismaCloudでどういったことができるか概要を説明したいと思います。   PrismaCloudとは PrismaCloudは、クラウド環境のセキュリティを網羅的に管理できるプラットフォームです。クラウドサービスの利用が日々拡大する現在、セキュリティへの対策は会社としても避けて通れない課題となっていますが、それぞれのクラウドサービスのネイティブ機能を使ってセキュリティ対策を行うと、ガバナンスをどう効かせるかが問題となります。 PrismaCloudを活用することで、複数のクラウドサービスに対して横断的にセキュリティ管理を行い、統一したポリシーでガバナンスを効かせることが可能になります。 CSPM（クラウドセキュリティポスチャ管理）とは CSPMは、クラウド環境におけるセキュリティの姿勢を継続的にチェックし、改善を促す機能です。具体的には、設定ミスや不適切なリソース使用を発見し、セキュリティのベストプラクティスに基づいた推奨すべき対処方法を提供します。 これにより、うっかりや設計時の想定漏れ等の誤設定から生じるセキュリティリスクを未然に防ぐことが可能になります。 CWPP（クラウドワークロード保護プラットフォーム）とは CWPPは、クラウド上で稼働するワークロード（アプリケーションやデータ等）を保護するための機能を提供します。ランタイム保護、ネットワークセキュリティ、脆弱性の管理など、多角的にワークロードを保護します。これにより、実行中のアプリケーションがセキュリティ脅威にさらされるリスクを軽減します。 PrismaCloudのCSPM・CWPP機能 CSPMとCWPPは、それぞれ異なるセキュリティの側面に焦点を当てていますが、PrismaCloudではこれらを組み合わせることで、クラウドセキュリティの全体像を網羅的にカバーしています。ここでは、PrismaCloudが提供するCSPMとCWPPの具体的な機能と、それによって実現できるセキュリティの強化について詳しく見ていきましょう。   CSPMの機能とメリット 継続的な設定監査 クラウド環境の設定をリアルタイムで監視し、誤設定やポリシー違反を検出します。これにより、セキュリティ侵害のリスクを大幅に低減できます。 コンプライアンスの自動評価 様々なコンプライアンスフレームワーク（例えば、PCI DSS、HIPAAなど）に基づいたセキュリティポスチャの自動評価を行います。これにより、コンプライアンス違反のリスクを事前に検出し、対応策を講じることが可能になります。 セキュリティポリシーの一元管理 複数のクラウド環境にまたがるセキュリティポリシーを一元的に管理し、適用します。これにより、一貫性のあるセキュリティ管理を実現し、運用の複雑さを軽減します。 CWPPの機能とメリット ランタイム保護 実行中のワークロードを監視し、不正なアクティビティや脅威をリアルタイムで検出します。これにより、攻撃者による侵害を即座に阻止し、被害の拡大を防ぎます。 ネットワークセキュリティ強化 クラウドネットワークトラフィックを監視し、不審な動きや不正なデータ流出を検出します。これにより、内部からの脅威や外部からの攻撃を早期に発見し、対応することができます。 脆弱性スキャンと修正支援 定期的にワークロードの脆弱性をスキャンし、潜在的なセキュリティリスクを特定します。また、脆弱性の修正やセキュリティの強化に向けた具体的なガイドラインを提供します。このスキャンはエージェントレスで実装可能です。 コンテナとオーケストレーションへのセキュリティ対策 コンテナ環境に特化したセキュリティ機能を提供し、コンテナイメージの脆弱性分析やランタイム保護を実施します。また、コンテナオーケストレーションツールと統合し、セキュリティ対策の自動化や効率化も可能になります。 まとめ PrismaCloudのCSPM、CWPP機能は、クラウドセキュリティの複雑な課題に対して、包括的かつ効果的な解決策を提供してくれます。CSPM機能でクラウドのセキュリティ設定をチェックし、CWPP機能で実行中のワークロードを保護することで、セキュリティリスクを大幅に軽減し、クラウド環境の安全性を高めることができます。 DX推進やクラウド移行を組織横断的にガバナンスを効かせながら行いたい場合、PrismaCloudを使ったセキュリティ対策は選択肢の１つとなってきます。 CWPPとは何か? クラウドワークロード保護の必要性を解説 クラウド上のデータとアプリケーションの安全性を確保するソリューションとして、日本でも徐々にCWPPの認知度が高まってきています。 CWPPの概要と必要性について解説します。 blog.usize-tech.com 2023.05.23 サーバレスセキュリティについて考える ① サーバーレスアーキテクチャの理解とそのセキュリティ課題の詳細な洞察を提供します。サーバーレス環境でのセキュリティ対策の重要性とその理由も解説します。技術者、デベロッパー、ITマネージャー必見の内容です。 blog.usize-tech.com 2023.07.21 サーバレスセキュリティについて考える ② サーバレス環境でのセキュリティ対策として、何に対して何をしないといけないかを解説します。技術者、デベロッパー、ITマネージャー必見の内容です。 blog.usize-tech.com 2023.11.22

こんにちは。SCSKの池邉です。 今回は、2023/07~2023/10の期間でAWS主催のハッカソン 『ANGEL Dojo 2023』 に参加してきましたので、どんなことをしたかや、参加してみて感じたこと等を書いていきたいと思います。 ANGEL Dojoについて知らない方はもちろん、これからANGEL Dojoに参加したいと思っている方にも参考になればと思っています。 是非最後までご覧ください！ ANGEL Dojo の概要 『ANGEL Dojo』とは、 「AWSで日本を元気に！」 がテーマの4か月間のハッカソン型トレーニングです。 約4か月間でAWS様による研修を受けつつ、企業同士が4~6名のチームを組んで、AWSを使ってチームで1つのサービスの開発を行っていきます。 ↓↓以下ANGEL Dojo 2023の概要↓↓ [内製化支援推進] ANGEL Dojo 2023 活動報告と結果発表！ | Amazon Web Services 今年度の ANGEL Dojo について、2023 年 10 月 13 日に最終発表会、2023 年 10 月 aws.amazon.com 弊社は株式会社スカイアーチネットワークス様と合同チームを組みました。 最終的には各チームが開発したサービスについてそれぞれプレゼンを行い、優勝を決める。そんな内容のハッカソン型トレーニングです。 上述の通りAWS様より様々な研修を受けさせていただけるのですが、その中でも特に自身の学びとなった 「WorkingBackwards」 についてまずはご紹介させていただきます。   Working Backwards WorkingBackwardsとは、 「お客様を起点に考え、お客様体験を徹底的に固める」 という考えを元にした、AWSで新しいサービスを開発する際に実施されるプロセスです。 具体的には お客様を起点に考える プレスリリースを書く FAQを練る ビジュアルでお客様体験を詰める の順番でワークをし、徹底的にお客様の価値を考えていきます。 すなわち 「顧客体験が高まると顧客数が増える。すると売り手と品揃えも増え、低コスト化が実現する。結果、顧客体験もアップする。このサイクルを回すことでビジネスが循環する。」 という考え方であり、最も重要なのは顧客体験だというわけです。 私たちは常にこの考えを念頭に置きながらサービスを開発しきましたので、その点も踏まえながら実際に開発したサービスについてご紹介させていただきます。   開発したサービス 弊社チームが開発したサービスは、 「RECIPICIAN」 です。 このサービスは 食材の写真登録や管理、レシピ閲覧等、自炊で発生する諸々のタスクをアプリ一つで管理してくれるサービス です。 提供する顧客価値 このサービスが提供する顧客価値は大きく 3点 あります。   1.買い物体験の改善 顧客は買い物の際、 家に何の食材があるかを把握してなく、余分な買い物をしてしまいます。 また、買い物リストを作成してこのことを防ごうとしますが、 そもそも買い物リストを作成することについても面倒に感じています。 しかしRECIPICIANには家にある食材を写真撮影するだけで登録できる機能があるため、 まるで手元に冷蔵庫があるかのような体験が得られます。 こうすることで 余分なものを買ってしまうことや、買い物リストをわざわざ作成することがなくなります。   2.レシピのレコメンド 顧客は 毎日毎日レシピを決めることに対して面倒に感じています。 しかしRECIPICIANには登録した食材から簡単に作れるレシピを提案してくれる機能があるので、 レシピ決めにかかる工数を減らしてくれます。   3.消費期限通知 顧客は 常に食材の消費期限を意識しているわけでは無く、意図せず食材を腐らせ、廃棄してしまいます。 しかしRECIPICIANには登録した食材の消費期限を通知してくれる機能があるので、 食材を廃棄することなく効率よく使用することを可能にします。   その他トピック 実際の使用技術については弊社とチームを組んだスカイアーチ様がブログを公開しておりましたので、そちらをご覧ください。 ↓↓スカイアーチ様の活動報告は以下↓↓ 【成果報告】Angel Dojo 2023 (前編：概要とサービス紹介) - CloudBuilders はじめに はじめまして、スカイアーチHRソリューションズのyokoiです。 7月から10月までの期間… www.cloudbuilders.jp 【成果報告】Angel Dojo 2023(後編：バックエンドについて) - CloudBuilders こんにちは、スカイアーチHRソリューションズのktakedaです。 7月から10月の期間で、AWS主… www.cloudbuilders.jp 結果として優勝することはできませんでしたが、 「一番実現して欲しいアプリです！」 「日用品にもこの考えを応用できるかもしれませんね」 のような様々な感想やアドバイスをいただけたのでとても満足しています。   振り返り ここまで研修の内容や実際に開発したサービスについて触れてきましたが、最後にこの活動を通して経験して良かったと感じたことを 3点 まとめさせていただきます。   1.Amazon流のサービスの開発を経験 WorkingBackWardsを経験するまでは、自分たちが開発したいサービスを開発することばかりに気を取られており、顧客に対する価値を度外視してしまっていました。 ですがWorkingBackWardsを経験してからは、まずは顧客起点で考えることが定着し、最終的な成果物についても 「このサービスがあると顧客がどう嬉しいか」 という視点ではかなり練度の高いものが製作できたのではないかと思います。 これからも顧客起点でも物事を考える思考は持ち続けたいと思います。   2.混合チームでのコミュニケーションを経験 今回は混合チームということもあり、活動初期はやはりコミュニケ―ションの取り辛さが多少ありました。 しかし開発が進むにつれてメンバー全員がかなりラフな雑談もしてくれるような雰囲気を作ってくれて、サービス開発を苦なく終えることができました。 コミュニケーションハードルを下げることの重要性 をこの活動で身に染みて感じたので、今後のチームビルディングにおいても、まずはその点から注力していきたいと思います。   3.他企業との競争を経験 この取り組みで最も価値のあるポイントはこの点だと個人的に思っています。 実際に優勝という目標があったからこそ、最後まで緊張感を持ってサービス開発に向き合うことができました。 日々の業務においても 何か明確な目標を立て、自然と競争が生まれるよう仕組み化 していきたいと思います。   まとめ 今回は 『ANGEL Dojo 2023』 に参加してみて感じたこと等を書いてきました。 ANGEL Dojoには自身を成長させてくれるコンテンツが盛りだくさんなので、参加を検討されている方にはぜひとも参加をお勧めしたいです。 最後までご覧いただきありがとうございました！

どうも、SCSKの齋藤です。 2024年3月2日に東京・池袋サンシャインシティにて開催された、JAWS DAYS 2024に参加してきました！ 今回は、SCSKはこのイベントにランチサポーターという立場として協賛し、イベント内ではお昼の時間帯にLT登壇枠をいただき発表をしてきましたので、参加した内容や感想をレポートいたします！ 概要 JAWS DAYS 2024は、AWSのユーザーグループであるJAWS-UGが主催し、アマゾン ウェブ サービス ジャパン合同会社が後援で行われる、JAWS-UG最大のAWSのコミュニティイベントです。 リアルなイベントということで、「ビジネスとテクノロジー」「地方と都市」「学生と社会人」など、さまざまなバックグラウンドを持つ人が同じ空間を共有します。この空間の中で、異なる価値観の人たちが、自分たちのコミュニティを飛び越えて偶然に出会う場を提供することで、新しい可能性を探っていく、そんなイベントです。 コミュニティイベントということで、AWSに関わるあらゆる人（初心者からベテランまで、エンジニアや非エンジニアな人までも）が参加して、AWSに関して学び合い、刺激をしあうイベントだと参加して感じました！ 今回、SCSKはランチサポーターとしてこのイベントを支援しているため、お昼の時間に15分間LT枠をいただきました！ 登壇内容 今回SCSKが発表した内容は、 「エンジニアブログ「TechHarmony」注目記事のご紹介」 というタイトルで発表しました！ これは、本ブログである「TechHarmony」の中から選りすぐりの記事を紹介するという内容です。 本ブログでは、発表で紹介した記事を改めて紹介させていただきます！ TechHarmonyの記事の特徴 TechHarmonyには、４つの記事の特徴があると考え、それぞれの観点で記事紹介を行いました。 ①親しみやすい記事 ・・・単なる技術(Tech)だけではなく、それを調和し組み合わせて提供できることが当社の強み。説明にはSIerならではの「優しさ」があるべき。TechHarmony の名前に込めた想いです。 ②すぐに使える！ CFnテンプレ提供 ・・・筆者が考えた構成、アイディアを直ぐに試していただけるよう、Cloud Formationテンプレートの 提供を行っている記事が多いです。これも優しさかと考えています。 ③ ときにはガッツリ解説する記事も！ ・・・でも、時には技術をガッツリ語る記事も発信。こうした記事での発信、ノウハウ共有は社内での技術力の底上げにも貢献しています。 ④ AWS認定取得系記事 ・・・AWSエンジニア育成・認定資格取得に注力している当社だからこそ。資格取得に関わる勉強法、ノウハウに関しての記事が多数発信されています。   特徴 ① 親しみやすい記事 PartyRockに料理レシピを提案してもらった ノーコードで生成AIアプリを作成することのできるPartyRockを使って、料理レシピを提案するアプリを作ってみた！という記事です。 日本語でどのようなアプリを作りたいかを入力することで、簡単に生成AIのアプリが作成できるという優れものです！ 皆さんも生成AI入門としてぜひ一読し、料理レシピを提案してもらってはいかがでしょうか？？ PartyRockに料理レシピを提案してもらった Amazon Bedrock Playgroundの新サービスであるParty Rockを使って、生成AIアプリを作った体験をご紹介します。 blog.usize-tech.com 2023.12.01   画像生成AI Stable DiffusionをAmazon SageMakerで始める 生成AIオープンソースStable Diffusionを使って画像生成をする記事です。 昨今では、Amazon Bedrockが主流ですが、Amazon SageMakerを使った生成AIの活用という手段もあります。 生成AIの学習を深めるために、Amazon SageMakerを活用した手段も学習してみるのもよいのではないでしょうか。 本記事は、文字入力から画像を生成する体験を手軽に始められるのでおすすめです！ 画像生成AI Stable DiffusionをAmazon SageMakerで始める 画像生成AIとして評価の高いオープンソースのStable Diffusionを、Amazon SageMakerで簡単に実行し体験します。 blog.usize-tech.com 2022.09.21 特徴② CFnテンプレート提供でお手軽！ AWSコンソールサインインとIAM操作の通知を実装する方法 AWS Configなどを使わずにサインインの通知を実装する記事です。 主にスタンドアロン環境においてこのようなセキュリティ対策を施すことを必要としている方におすすめです！ CloudFormationテンプレート付なので、同様の環境をさくっと構築できます！ AWSコンソールサインインとIAM操作の通知を実装する方法 [AWS CloudFormation テンプレート付き] 皆様はAWSコンソールサインインやIAM操作の通知が欲しくなったことありますでしょうか。 今回は「AWSコンソールサインイン」と「IAM操作」の通知機能をさくっと実装する例を紹介します。すぐにプロビジョニングできるように 可能な限り、AWS CloudFormation テンプレートを付けさせていただきたいと思います。 blog.usize-tech.com 2022.04.05 AWS Configを利用したElastic IPの自動削除の仕組み ElasticIPの自動削除を実施する仕組みを紹介した記事です。 使っていないElasticIPをAWS Configが検知し、自動削除を実施するまでの流れを説明しております。 意図しないコスト上昇を抑える一つの手段として、すぐに実践できるためおすすめです！ こちらもCloudFormationテンプレート付なので、同様の環境をさくっと構築できます！ AWS Configを利用したElastic IPの自動削除の仕組み[AWS Config+AWS CloudFormation] 弊社環境でも稼働しているElastic IPの自動削除の仕組みについてご紹介します。 Elastic IPが利用中のEC2及びENIにアタッチされていない場合、解放されるようSSM-Automationを実行させます。 blog.usize-tech.com 2024.02.09   特徴③ ガッツリ系記事 VPC Lambdaを実現しているAWS内の裏側と設計の心得三箇条 プライベート環境下でLambdaを利用する際に用いる「VPC Lambda」について解説した記事です。 VPC Lambdaの裏側を解説し、それをもとに使う際の設計に必要な心得が記載されています。 CloudFormationテンプレートで、ネットワーク環境を構築するハンズオンができ、実際にVPC Lambdaを作りながら、その裏側を理解することが可能です。 そのため、大変勉強になる記事でおすすめです！ VPC Lambdaを実現しているAWS内の裏側と設計の心得三箇条 インターネットに接していないVPC Lambdaの設計ポイントとVPC Lambdaを実現しているAWS内の裏側を紹介します。 blog.usize-tech.com 2023.12.22   EC2における「管理用VPC」設置の是非について VPCにおける最近のアップデートである Multi-VPC ENI Attachmentを使い、オンプレミス時代に存在した「管理用ネットワーク」を設けることの是非について議論した記事です。 オンプレミスとクラウドでの設計思想の違いを説明しており、クラウド世代もオンプレミスの思想を理解することができます！ それを踏まえた上で、クラウドではどういった設計をしなければならないか？を、セキュリティ面や運用面から考え理解を深めることができます！ クラウドのベストプラクティスがなぜそうなのかを、改めて考えて理解を深めることができるので、勉強になります！ EC2における「管理用VPC」設置の是非について EC2から複数のVPCに対してENIを接続できるようになる、Multi-VPC ENI Attachmentの発表がありました。 このアップデートで管理用VPCが作れるようになりますが、安易に設置すべきではないと考えています。 その理由をまとめます。 blog.usize-tech.com 2023.11.08   特徴④ AWS認定取得 1) AWS12冠をノーミスでクリアできた学習法と感想 2) ノーミスでAWS12冠を1年で制覇した必勝法 AWS認定を全て制覇する方に向けた記事の紹介です。今回は２つの記事を紹介いたします。 上記2つは類似内容に見えますが、観点が異なります。 1) 各試験ごとにどのような対策を行ったかを記載。 2) 全試験共通でどのような教材を使って対策をすべきかを記載。 両方を読むことで、ミクロとマクロの視点両方から12冠取得の勉強をすることができますので、勉強法の整理を考えている方にはおすすめの記事となっております！ AWS12冠をノーミスでクリアできた学習法と感想 2023年1月にAWS PASに合格してAWS12冠となりました。全ての試験に一発合格できましたので学習法を記事にします。 これからAWS認定試験を受験される方、今年度に追い込みをかける方、来年度に全冠を目指す方の参考になれば幸いです。 blog.usize-tech.com 2023.01.27 ノーミスでAWS12冠を1年で制覇した必勝法 2023 Japan AWS All Certifications Engineersに選出していただきました。AWS認定試験を受験される方に向けて全資格に通ずる合格するための必勝法や感想をお話します。 blog.usize-tech.com 2024.02.13   1) AWS SAP on AWS Speciality 受験対策シリーズ 2) AWS Certified Data Engineer – Associateベータ試験に合格しました 特定の認定試験の対策についても記事がございます！ 1) はSAP on AWSの試験のためのSAPとは？というのを全8回にわたって紹介するシリーズです。 恐らくここまでSAP on AWSの情報が揃っているのは日本で唯一だと思われますので、SAP on AWSを受験予定の方は必ず目を通すと良いと思います！ 2) は新しくリリースされる認定試験のベータ版の合格体験記となります！新しい資格を取得したい方はぜひ一読してみることをお勧めします！ AWS SAP on AWS Speciality 受験対策その1「学習リソース」 AWS SAP on AWS Specialityのβ試験が始まりますが、SAPの用語中心に私の知識の整理も兼ねて記事を投稿してきたいと思います。 まずはSAP on AWSに関しての学習リソースをご紹介します。 blog.usize-tech.com 2021.11.09 AWS Certified Data Engineer - Associate ベータ版試験に合格しました AWS Certified Data Engineer - Associate (DEA) のベータ版試験の合格体験記です。 blog.usize-tech.com 2024.02.14   感想 今回スポンサー枠としてJAWS DAYS 2024に参加できて、とても楽しかったです！ AWSユーザーコミュニティがオンサイトで約1000人も集まった時の熱狂が凄まじく、コロナ入社世代としては大変圧倒された1日でした！ AWS Jr.Championsに拝命している私としては、他のAWS Jr.Championsの方の発表を聞いたり、逆に他のAWS Jr.Championsの方が私の発表を聞いてくださったりと、コミュニティを通じて得たつながりを実感した日でもあり、またこういったイベントに登壇し、参加したいと思えた1日でした！   Appendix：資料 当日投影した資料は下記となります。 エンジニアブログTechHarmony注目記事のご紹介 Download Now! 5 Downloads

こんにちは、SCSK 浦野です。 3月になり、年度末が近いと焦りを覚えている筆者です。 前回の記事でも書きましたが、ここ最近あまり生成AIに触れていなかったのですが、Xのポストを眺めていたところ、Claude 3 のリリースについてと、肯定的な意見があるのを目にしました。 少し気になったので、AWSとClaude 3 で検索をかけたところ「 Amazon Bedrock expands its model selection with Anthropic’s industry-leading Claude 3 family, with the first model available today. 」という記事を見つけました。 内容を読むと、1モデル(Claude 3 Sonnet) は既に使えるとの事ですので、簡単に試してみました。 前提など AWS Management Console 上で利用できる機能の範囲で実施します。 Amazon Bedrockで Claude 3 Sonnet を利用可能にする 東京リージョンではまだ利用できませんので、バージニア北部(又は オレゴン)に変更します。 Amazon Bedrock を開き、左ペインの「モデルアクセス」をクリック、右上の「モデルのアクセスを管理」をクリックします。 表示された画面でAnthropic の利用をまだしたことがない場合、「ユースケースの詳細を送信」のボタンがありますのでこちらをクリックします。 クリックすると、会社名や利用用途を確認する画面が出ますので、それらを埋めて送信します。 すると、「ユースケースの詳細が送信されました」と表示され、各モデルが「ユースケースの詳細は必須です」から「リクエスト可能」に変化し、モデルの先頭のチェックボックスがチェック可能になりますので、チェックを入れ、「変更を保存」ボタンを押し、リクエストを行います。 画面が変わると、アクセスのステータスが「進行中」となりますが、数分待つと、「アクセスが付与されました」に変化します。 コンソールのチャットを設定する コンソールから今回有効化したClaude 3 Sonnetを利用したチャットを行うための設定を行います。 左ペインの [プレイグラウンド] > [チャット]を選択すると、チャットのプレイグラウンドの画面が表示されますので「モデルの選択」ボタンをクリックします。  モデルの選択画面になりますので、カテゴリで[Anthropic]を、モデルで[ Claude 3 Sonnet    v1 ]を選択し、「適用」ボタンをクリックします。 以下のようなチャットの画面が表示されます。プロンプトに指示や質問を入れると、対応して生成が行われます。 質問を試してみる 別のモデルでは、「 SCSK について教えて。」と質問すると、かなり無理がある回答がされ、ハルシネーションの良い例だと感じていたので、今回も同じ質問をしてみましたが、このモデルでもハルシネーションを起こしておりました。 (合併前の会社名がデタラメだったり、関係ない他社のグループ会社として説明されたりで、載せずらいのでキャプチャは省略します。） 次に、画像を読み込んで回答が可能になっているとの事でしたので、富士山の写真を読み込ませて説明を依頼しました。 結果として、富士山であることを認識し、かなり良い感じで回答してくれたのですが、後半で急に英単語を生成しており、今後のモデルの進化に期待したい結果となりました。( 「富士山のholding印象」って・・・）  今回は、簡単にプレイグラウンドでの操作を試しました。数週後には上位のモデルも利用可能になる予定のようですので、実装後にはそちらも試してみたいと思います。

SCSKが、Cato Networks社の Cato Distinguished Support Providers （以下、 CDSP ）認定を取得しました。 “ Cato Networksの「Cato Distinguished Support Provider」認証を取得 ～迅速かつ質の高い課題解決を実現～ ” CDSPとは まず最初に、当社のCDSP認定取得における お客様にとってのメリット は、以下の3点です。 お問い合わせに対して、より質の高い回答を得ることができる お問い合わせの 解決時間（レスポンス）を、より短縮することができる 課題・ニーズに対して、将来リリースされる機能も含めた解決策を得ることができる   Cato Networks社のパートナープログラムである CDSP の説明は以下です。「The Cato Networks Partner Program 2022（一部抜粋）」 Cato enables its strategic partners to be recognized as Cato distinguished support providers (CDSPs). This accreditation will allow partners to differentiate themselves, enhance their profitability, and turn them in to subject matter experts when it comes to managing, analyzing, and troubleshooting Cato, the world’s first SASE platform. Partners will be required to meet the prerequisites, training requirements, and ongoing KPIs in order to enjoy the benefits of CDSP. Catoは、戦略的パートナーをCato distinguished support providers (CDSP)として認定します。 この認定により、パートナーは差別化を図り、収益性を向上させ、世界初のSASEプラットフォームであるCatoの管理、分析、トラブルシューティングの専門家になることができます。 パートナーは、CDSPのメリットを享受するために、前提条件、トレーニング要件、継続的なKPIを満たす必要があります。 Why CDSP? 　• Official accreditation by Cato 　• Differentiation – Less than 10% of our partners will be CDSP support engineers 　• Free, on-line, and, on-demand training courses 　• CCA – escalation to Cato’s Tier-2 support engineers 　• Product early availability (EA) access 　• API access and support from Cato CDSPとは何か？ • Catoの公式認定である • すべてのパートナーの10%未満がCDSPとして認定 • オンラインおよびオンデマンドのトレーニングコースを無料で提供 • CCA （※）が、CatoのTier-2（ティア2）サポートエンジニアへエスカレーション • 製品早期入手（EA）へのアクセス • CatoからのAPIアクセスとサポート （※）CCAとは、 Cato Certified Associate というCato Netwroks社の技術者認定資格となります。以下のSASE/SSE Expertのようなどなたでも受験できる資格ではなく、Cato パートナーのみが受験できる資格となります。 Cato Networks社認定のSASE資格について紹介します！ 無償で受講が可能なCato Networks社認定のSASE資格があることをご存じでしょうか？今回はSASE資格の概要から合格までの流れをご紹介いたします！ blog.usize-tech.com 2024.02.29 CDSPとそのメリットについて CDSPとは、当社のこれまでのサポート実績が認められ、お客様に対して一流のサポートを提供するための知識と専門知識を備えていることがCato Networks社に認定されたことになります。 「 CDSPパートナーは全パートナーの10%未満 」とありますが、現在、Cato Networks社 Catoクラウドの日本国内のパートナー数は公表されていません。 Catoクラウドは、他のクラウド（AWS、Azure、Googleなど）のように、パートナープログラムが現時点ではきちんと整備されておらず、パートナーランク（プレミア、アドバンス、または、Glod、Silverなど）も存在せず、そもそもパートナー企業自体も公開されていません。 ただし、昨年（2023年7月）に日本で初めて開催したパートナーサミット東京2023で、パートナー企業 約20社（ディストリビューターを含む）が参加されていたとのことでしたので、10%未満のパートナーのみであるCDSPは 、日本国内については 2社（多くても3社）ということになるかと思います。 （※）ディストリビューター・・・お客様に直接Catoクラウドの販売（導入/保守含む）を行なわない卸業者（一次代理店） CDSPにて、当社が Tier1 （ティア1）サポートを担うことになっています。つまり、Cato Networks社の Tier2 （ティア2）サポートエンジニアへ直接エスカレーションを行うことになりましたので、ティア1を省くことで、サポートの問い合わせ時間、お客様への回答時間を大幅に短縮することが可能になっております。 また、Catoクラウドの新たな機能についても、優先的に情報提供および早期提供されるため、当社にて事前に動作検証を行い、新機能の理解を行うことで、例えば、Catoクラウドで提供されている現状機能では、解決が難しいお客様のニーズや課題について、将来的にリリースされる機能を含めた課題解決のご提案が可能となります。 これまでの FAQサイト の運営や、 エンジニアブログ にて、お客様の自己解決による課題解決時間の短縮を目指しておりましたが、今回 CDSP認定を取得することで、当社へお問い合わせいただいた課題についても、より早く、より質の高い回答が行えるようになりました。 つまり、当社とのサポート契約を行うことにおける お客様にとってのメリット は、以下の3点となります。 お問い合わせに対して、より質の高い回答を得ることができる お問い合わせの 解決時間（レスポンス）を、より短縮することができる 課題・ニーズに対して、将来リリースされる機能も含めた解決策を得ることができる   まとめ SCSKでは、2019年より Catoクラウド（Cato Cloud/Cato SASE Cloud）の取り扱いを開始しており、すでに30社以上のお客様にご契約、ご利用をいただいております。 Catoクラウドをご検討中のお客様へは、セミナーを始め、サービスの説明会（管理ポータルのデモを含む）や、ハンズオンセミナー（1日）、PoC（30日）の支援を実施しております。 Catoクラウドを採用されるお客様には、既存ネットワーク/セキュリティ環境の現状調査から、要件定義、設計・構築・導入支援、既存ネットワーク/セキュリティ機器からの移行設計/移行支援、拠点のインターネット回線の調達、拠点のSocket設置作業など、ご要望に応じて、あらゆるサービスを提供することが可能です。 導入後の運用保守サポートについても、各種マネージドサービスをフルラインナップでご提供しておりますので、ご安心してご利用いただくことが可能です。24時間365日のサービス窓口および技術問い合わせ、拠点の監視・通報サービス、Socketの4時間駆け付けのオンサイト保守、日本語SOCなど。 もちろん、日本国内だけにとどまらず、海外についても当社海外現地法人との連携により対応が可能です。 Catoクラウド（Cato Cloud/Cato SASE Cloud）にご興味をお持ちの方、ご質問がある方、導入を検討されている方がいらっしゃれば、お気軽に当社まで お問い合わせ ください。

2019年にGartnerがSASEを提唱して依頼、” SASE ”という言葉を耳にする機会は多くなってきているかと思います。 さらに、COVID-19のパンデミックによりSASE化が急激に加速したと言われています。 ですが、未だこのような悩みを持たれている方もいらっしゃるのではないでしょうか？ ” SASE ”という言葉は聞いたことがあるけれど、よくわからない… ” SASE ”を 導入するメリットをより具体的に知りたい… ” SASE ”を導入したいが、導入方法がわからない… Cato Networks社認定のSASE資格 は、そんな様々なお悩みを 解決する第一歩 になります！ 2024年2月現在、全部で6つのコースが用意されており、 これらのコースを受講し資格取得を目指すことでSASEにおける知識を幅広く習得することができます。 本投稿では、SASE資格の概要から合格までの流れについてご紹介していきます！ SASE資格ってどんなもの？ SASE資格には、以下のようなものがあります。（2024年2月現在） No. 資格名 概要 １ SASE Expert Level1  SASEについての基本的な知識を習得します。 ２ SASE Expert Level2 SASEについて、さらに専門的な知識を習得します。 ３ Advanced Security SASEの高度なセキュリティ機能について深く掘り下げて習得します。 ４ SASE Deployment & Management SASEの導入方法について習得します。 ５ Business Impact & Strategy SASEビジネス戦略を習得します。 ６ SSE Expert SSEについての基本的な知識を習得します。 これらのコースには、トレーニング動画が用意されています。 トレーニング動画視聴後、クイズに回答し合格基準に達した場合に合格となります。 所要時間はすべて 3～5時間 で、動画の言語は残念ながら選択ができず 英語のみ でした（SASE Expert Level1を除く）。 また、No.2～No.5の取得には、No.1（SASE Expert Level1）の取得が条件となっております。 つまり、SASE資格の受験を検討されているすべての方はまずSASE Expert level1を取得し、それ以降は各々の職種に合わせて必要なコースを取得していく流れになります。 ちなみに、すべて受験料はかかりません！ 無償で受講が可能 です。 内容は？ それぞれのコースの内容についてご紹介します！ SASE Expert Level1  このコースでは、SASEとは何か、SASEではないものの特徴、SASEアーキテクチャおよびユースケースといったSASEの基本的な内容を理解します。 初心者のためのSASE SASEの概要 SASE – 新しいエンタープライズ境界アーキテクチャ ポイントソリューションを統合するか、SASEアプローチを選択するか SASEへの移行ガイド マルチベンダーSASEを嫌う理由 企業VPNのデメリット SASEの収束か統合か？ MPLSからSD-WAN、そしてSASEへ：企業ネットワークの進化 SASEではないものとは？ SASE Expert Level2  SASE Expert Level1に続く上級認定です。 このコースでは、SASEの専門知識を向上させ、業界の方向性に沿ったネットワークとセキュリティのスキルを習得します。 シングルパス処理 グローバルクラウドとクラウドネットワーク ネイティブSD-WANが必須の理由 クラウドでのセキュリティ処理 VS エッジでのセキュリティ処理 IPS-as-a-Service SSE Expert このコースでは、SSEとは何か、SSEではないものの特徴、コアアーキテクチャ、利点、ユースケース、およびSSEベンダーの選択方法といったSSEの概要を理解します。 ボンネットを潜る： SSEのアーキテクチャ要件、利点、使用例 シングルパス処理とSSEの関係は？ すべてのZTNAが同じように構築されるわけではない理由… CASBへのゴルディロックス・アプローチ：あなたの企業に「ちょうどいい」のはどれ？ IPS-as-a-Service： コンテキスト共有か、それとも破綻か FWaas対SWGの（衝撃的な）限界 Advanced Security このコースでは、SASEの高度なセキュリティ機能について深く掘り下げ理解します。 CASBによるクラウドアクセスの保護 脆弱性管理と脅威ハンティング vs 脅威アクター SASEとMitre攻撃カバレッジの基礎 SASEが攻撃のチョークポイントでランサムウェアを阻止する方法 SASEサービスのセキュリティと可視性のテスト SASE Deployment & Management このコースでは、SASE POCとSASE導入の計画について理解します。 SASEのPOC計画とはどのようなものか SASEによるネットワークSLA: オーバーレイとアンダーレイの分離 SASEと高可用性プランニングの裏と表 SASEを徐々に導入する方法 SASEと簡素化された単一管理のパワー SASEのイベントデータとダッシュボードで可視性とコントロールを実現する Business Impact & Strategy このコースでは、SASEビジネス戦略を作成し、社内のステークホルダー、経営陣、取締役会に伝える方法を理解します。 そしてSASEへの切り替えが単なる技術的な意思決定ではなく、ビジネス上の意思決定である理由を理解します。 取締役会にSASEを “話す “方法 プラットフォームとポートフォリオとTelco SASEの違い SASEでセキュリティコンプライアンスを達成し、維持する方法 SASEとビジネスゴールとの整合性を確保する簡単な方法 どんな人向け？ ここまでで各コースの内容についてお伝えしましたが、それでも、どのコースを選択すべきか迷われる方も少なくないのでは？と思います。 そんな方はCato Networks社推奨コースの一例をご参考にされると良いかと思います。 前述の通り、まずSASE Expert level1を取得し、それ以降は職種に合わせて必要なコースを取得していく流れになっています。   Step1 Step2 Step3 Step4 すべての人 SASE Expert level1 SASE Expert level2 – – ネットワーク専門家 SASE Expert level1 SASE Expert level2 SASE Deployment & Management – セキュリティ専門家 SASE Expert level1 SASE Expert level2 SSE Expert Advanced Security CxO SASE Expert level1 SASE Expert level2 Business Impact & Strategy – 受けるにはどうしたらよいの？ それでは！ここからは、合格までの流れについてご紹介します。 大まかな流れは以下の通りです。それぞれ詳しくご説明していきます。 STEP1：申し込み STEP2：受講 STEP2：証明書の入手 STEP1　申し込み 申し込みはCato Networks社のサイトから行います。 https://www.catonetworks.com/ja/sase/sase-certification/ まずは、受講希望のコースを選択します。 ※本投稿では、SASE Deployment & Manageを選択しておりますが、どのコースを選択しても申し込み手順は同様です。 すると、以下情報の入力が求められますので入力を行い、” APPLY NOW（今すぐ申し込み）”より申し込みを行っていきます。 必要情報は以下の通りです。 Email Address：メールアドレス First Name：氏名(名前) Last Name：氏名(苗字) Job Title：役職 Company Name：会社名 Country：国 申し込みはこれで完了です。 STEP2　受講 STEP1の申し込みが完了したら、数日以内にCato Networks社よりこのような案内メールが届きます。 メールが届いたら、案内に従って受講を開始します。 メール受信から10日以内に受講する必要があります。 ログイン情報はメール本文に記載されており、初回ログイン後にPWの変更が求められます。 ログインが完了したら、My Coursesから対象のコースを選択し、受講を開始していきます。 前述の通り、トレーニング動画視聴後、クイズに回答し合格基準に達した場合に合格となります。 SASE Deployment & Manageの場合は、7つのLesson（7つ目はアンケート）が用意されており、各Lessonでトレーニング動画の視聴とクイズ（10問）への回答が必要でした。また、スコアは 80％以上 で 合格 でした！ 私の場合は、4時間程度ですべてのLesson受講が完了し、無事合格することができました！ STEP3　証明書の入手 合格すると、このような画面が出力されます。 証明書のダウンロードも可能でした！ まとめ 今回はSASE資格についてご紹介させていただきました。 SASE資格は認知度があまり高くはないかもしれませんが、SASEが必須になりつつある今、本投稿が多くの方にご興味をもっていただくきっかけなればうれしいです！ SASE資格の詳細はこちらから SASE認定 www.catonetworks.com

こんにちは、普段AWSやSnowflakeを中心としたデータ活用に関するサービス開発・案件を担当しているSCSKの高本です。 早速ですが、皆さんAWS Configはお使いでしょうか。そして、AWS Configはお好きでしょうか。 今回はAWS Configの自動修復アクションに関するお話です。本ブログ執筆前に（私が）そのままググってヒットして欲しかったタイトルをつけてみました。 AWS Configって何でしたっけ？ 今回は少し内容が長くなりそうなので、AWS Configとは？の概要については割愛させていただきたいと思います。 超ざっくりで言うと、各種AWSリソースの「あるべき姿（設定、Config）」を定義し、各リソースが「あるべき姿」になっているかを都度「評価」し、必要に応じて通知や現行の設定に対する是正措置などの「アクション」を実行してくれるAWSのマネージドサービスとなっています。 よく用いられる例で言うと、セキュリティグループがある日突然フルオープンになっていた場合、AWS Configを利用することで、確実にその変更を検知し、セキュリティ管理者に対してアラート通知をしたり、事前に定めた定義に従ってセキュリティ上好ましくない現行の設定を自動的に修復したりすることができます。 AWS Config とは? - AWS Config AWS Config を使用してアカウント内の AWS リソースの設定に関する詳細を表示したり、リソース間の関係を分析したり、変更履歴を確認したりします。 docs.aws.amazon.com 背景とゴール AWS Configでは非準拠判定となったリソースに対する修復対応として、手動修復か自動修復の２パターンが選択できます。 手動修復 自動修復 このうち、自動修復に関して、AWSのドキュメントに以下のような記載があります。 自動修復後もリソースがまだ非準拠である場合は、自動修復を再試行するようにルールを設定できます。・・・ ・・・修復スクリプトを複数回実行するとコストがかかります。修復が失敗し、指定された期間内に処理が行われた場合にのみ再試行を実行します。例えば、300 秒に 5 回再試行します。 AWS Config ルールによる非準拠リソースの修復 - AWS Config ルールとリソースはコンソールで修復します。 docs.aws.amazon.com 自動修復アクション実行後も依然として対象のリソースが非準拠である場合、AWS Config側で修復アクションを再実行してくれます。また、再試行ポリシーとして回数と期間を指定できるので、対象のリソースが非準拠であり続けた場合に、半永久的に修復アクションが実行されることも未然に防いでくれます。 ・・・のはずだったのですが、実際に試したところ、なぜか修復アクションの無限ループが止まりませんでした。 結論だけ先に言うと、自動修復アクション設定時に指定するパラメータの解釈ミスが原因でした。 試行錯誤の過程やどう対処したか、についてはまとめて後述しようと思いますが、なぜ無限ループが起きたのか、また、意図しない無限ループを防ぐにはどうしたらいいのか、という点の整理をモチベーションに書いていきたいと思います。 検証シナリオ・前提 まず、再現環境を構築するために、以下のシナリオを立てたいと思います。 １．AWS Configで評価・修復対象とするサービス： AWS Lambda ２．非準拠とする条件： Lambda関数の関数URLがパブリック公開になっている場合、「非準拠」判定とする ３．非準拠だった場合に実行する自動修復アクション： Lambda関数の関数URLが依然パブリック公開状態のまま設定を上書きする １. ２. については、何となくとっつきやすそうなAWS Lambdaの関数URLをターゲットに選びました。 ３. については、自動修復アクションの再試行に関する挙動を確認するために、実行しても未来永劫、非準拠のままとなり続ける”BAD”アクションを定義します。つまり、再度パブリック公開を許す設定で上書きするアクションを自動修復アクションとして定義します。 しかし、そもそも、Lambda関数の関数URLが依然パブリック公開状態のまま設定を上書きした場合、AWS Configはそれを設定変更として認識・検知してくれるのでしょうか。 答えは「Yes」です。 もちろんサービスによって例外あるかと思いますが、AWS Lambdaの場合はソースコードやその他設定に実質何も変更点がなくてもマネジメントコンソールやAWS CLIから更新をかければ、しかるべきUpdateのAPIが観測され、それがAWS Config側にちゃんと伝わるようになっています。 ということで、このシナリオ前提に立って具体的な環境を用意していきます。 環境準備・動作確認 評価対象のLambda関数を作成 AWS Configが評価する対象のLambda関数「awsConfigTestLambdaFunction」を用意します。特にソースコードにはデフォルトのまま修正を加えず、関数URLだけ追加設定します。この時関数URLの認証タイプには「NONE」を指定します。 払い出された関数URLのエンドポイントにブラウザ（インターネット経由）からアクセスできることを確認します。関数URLの認証タイプは「NONE」を設定しているので、本エンドポイントを知り得るクライアントからは認証なしにアクセスができる状態であり、セキュリティ的に脆弱な状態です。 AWS Configマネージドルールを作成 AWS ConfigにはマネージドルールとしていくつかのAWS管理の評価ルールが予め用意されています。カスタムLambdaルールは作成せず、今回のユースケースに合うマネージドルール「Lambda-function-public-access-prohibited」を選択します。先ほど作成したLambda関数「awsConfigTestLambdaFunction」を本ルールを用いて評価していきます。 lambda-function-public-access禁止 - AWS Config Lambda 関数ポリシーがパブリックアクセスを禁止しているかどうかを確認します。 docs.aws.amazon.com 評価モードの設定では、トリガー条件を限定する＋AWS CloudTrailのAPIログのノイズ排除を目的に、変更範囲を先ほど作成したLambda関数のみに限定します。 以上の設定でマネージドルールを作成します。「lambda-function-pubilc-access-prohibited-001」というルール名で作成します。ルールが正常に機能していれば、さきほど作成したLambda関数に対して実際にConfigルールの評価が走り、「最後に成功した検出評価」に緑色のチェックマークと最新の評価日時が表示されます。対象のLambda関数はパブリック公開状態のため、「コンプライアンス」では当然「非準拠」の評価となっています。   自動修復アクションの設定 作成したConfigルール「lambda-function-pubilc-access-prohibited-001」に対して自動修復アクションを設定していきます。修復アクションを定義・設定することで、「非準拠」判定となったリソースに対してなんらかの是正措置を取ることができます。 AWS Configでは、この修復アクションを実行する際、裏側でAWS Systems Manager Automationを利用します。 検証シナリオのおさらいですが、今回は自動修復アクションの再試行に関する挙動を確認したいので、実行しても未来永劫、非準拠のままとなり続ける”BAD”アクションを自動修復アクションで定義します。具体的には、対象のLambda関数の関数URLを、依然パブリック公開状態のまま設定を上書きするような操作をAutomationのランブック(awsConfigTestRunbook001とします)で定義します。 schemaVersion: '0.3' description: AWS Configの自動修復アクションに使用するランブック parameters:   AutomationAssumeRole:     type: String     allowedValues:       - arn:aws:iam::XXXXXXX:role/testRoleForAWSConfigTest assumeRole: arn:aws:iam::XXXXXXX:role/testRoleForAWSConfigTest mainSteps:   - description: AWS Configの自動修復アクションに使用するランブック     name: InvokeLambdaFunction     action: aws:invokeLambdaFunction     maxAttempts: 10     timeoutSeconds: 60     isEnd: true     inputs:       InvocationType: RequestResponse       FunctionName: arn:aws:lambda:ap-northeast-1:XXXXXXX:function:modifyLambdaFunctionUrlPublicAccessSetting このランブックの中で別のLambda関数（）である「modifyLambdaFunctionUrlPublicAccessSetting」を呼び出します。上のランブック(.yml)は単なるwrapperであって、具体的な自動修復アクションの中身として、Lambda関数「modifyLambdaFunctionUrlPublicAccessSetting」を以下の通り定義します。 import boto3 from typing import Dict import time target_function_name: str = 'awsConfigTestLambdaFunction' lambda_client: object = boto3.client('lambda') def lambda_handler(event, context): 　　try: 　　　　if is_the_target_lambda_func_exist(): 　　　　　　lambda_remove_permission() 　　　　　　time.sleep(1) 　　　　　　lambda_add_permission() 　　　　　　return { 　　　　　　　　"message": f"Successfully updated the permission attached to this func: {target_function_name}." 　　　　　　} 　　　　else: 　　　　　　return { 　　　　　　　　"message": f"the target lambda func may not exist: {target_function_name}." 　　　　　　} 　　except Exception as e: 　　　　return e def lambda_remove_permission() -> None: 　　try: 　　　　lambda_client.remove_permission( 　　　　　　FunctionName=target_function_name, 　　　　　　StatementId='FunctionURLAllowPublicAccess' 　　　　　　) 　　except Exception as e: 　　　　print(e) def lambda_add_permission() -> None: 　　try: 　　　　lambda_client.add_permission( 　　　　　　FunctionName=target_function_name, 　　　　　　StatementId='FunctionURLAllowPublicAccess', 　　　　　　Action='lambda:InvokeFunctionUrl', 　　　　　　Principal='*', 　　　　　　FunctionUrlAuthType='NONE' 　　　　) 　　except Exception as e: 　　　　print(e) def is_the_target_lambda_func_exist() -> bool: 　　try: 　　　　funcs: Dict = lambda_client.list_functions() 　　　　if 'NextMarker' in funcs: 　　　　　　next_marker: str = funcs['NextMarker'] 　　　　　　print(f'list_functions API NextMarker: {next_marker}') 　　　　else: 　　　　　　next_marker = '' 　　　　　　print(f'list_functions API NextMarker: {next_marker}') 　　　　for func in funcs['Functions']: 　　　　　　if func['FunctionName'] == target_function_name: 　　　　　　　　return 1 　　　　　　else: 　　　　　　　　pass 　　　　 　　　　while len(next_marker) > 0: 　　　　　　funcs: Dict = lambda_client.list_functions(Marker=next_marker) 　　　　　　if 'NextMarker' in funcs: 　　　　　　　　next_marker: str = funcs['NextMarker'] 　　　　　　　　print(f'list_functions API NextMarker: {next_marker}') 　　　　　　else: 　　　　　　　　next_marker = '' 　　　　　　　　print(f'list_functions API NextMarker: {next_marker}') 　　　　　　for func in funcs['Functions']: 　　　　　　　　if func['FunctionName'] == target_function_name: 　　　　　　　　　　return 1 　　　　　　　　else: 　　　　　　　　　　pass 　　　　 　　　　return 0 　　except Exception as e: 　　　　print(e) このLambda関数「modifyLambdaFunctionUrlPublicAccessSetting」では、AWS Configの評価ターゲットとなる別のLambda関数「awsConfigTestLambdaFunction」に適用されている既存のリソースベースポリシーを一度引きはがして、関数URLの認証タイプ「NONE」のリソースベースポリシーを当該関数に再適用する”BAD”アクションを実行します。当然このLambda関数が実行されても、Lambda関数「awsConfigTestLambdaFunction」は「非準拠」の評価のままとなります。 以下の図は修復アクションを実行した際のConfigルールの画面になります。アクションは正常に実行されるものの、コンプライアンスは「非準拠」の評価のままです。 上の画面は修復アクション設定後の画面なのですが、実は、修復アクションの設定において説明を省いていたパラメータがあります。以下の通り、自動修復アクションでは再試行に関わる回数と期間（秒単位）を指定できます。 パラメータとして「再試行までに：10」「秒：600」で自動修復アクションを設定したところ、無限ループが発生しました。てっきり600秒間に10回自動修復アクションを再試行してくれるのかと勝手に思っていました。以下は、AWS Systems Manager Automationのランブック実行履歴ですが、2~3分ぐらいの間隔で修復アクションの再実行が繰り返されました。10回以上再試行され、かつ初回のランブック実行から600秒経過しても再試行が止まりません。 試しに以下の通り「再試行までに：1」「秒：60」で自動修復アクションを再設定しても同様に無限ループが発生しました。再試行回数１回に設定しているのになぜ複数回実行されてしまうのか、この時点ではわからず。。。 とりあえず、無限ループ発生の再現自体はここまでで完了となります。   結論：自動修復アクションの無限ループの止め方 記事の冒頭でちらっと述べましたが、結論、自動修復アクションで指定する本パラメータの解釈ミスが原因でした。切り分けの過程でAWS CLI Commad Referenceの本設定に関するAPI仕様を確認していたところ、より具体的なパラメータの解説が記載されていました。 put-remediation-configurations — AWS CLI 1.32.51 Command Reference docs.aws.amazon.com MaximumAutomaticAttempts -> (integer) The maximum number of failed attempts for auto-remediation. If you do not select a number, the default is 5. For example, if you specify MaximumAutomaticAttempts as 5 with RetryAttemptSeconds as 50 seconds, Config will put a RemediationException on your behalf for the failing resource after the 5th failed attempt within 50 seconds. RetryAttemptSeconds -> (long) Time window to determine whether or not to add a remediation exception to prevent infinite remediation attempts. If MaximumAutomaticAttempts remediation attempts have been made under RetryAttemptSeconds , a remediation exception will be added to the resource. If you do not select a number, the default is 60 seconds. For example, if you specify RetryAttemptSeconds as 50 seconds and MaximumAutomaticAttempts as 5, Config will run auto-remediations 5 times within 50 seconds before adding a remediation exception to the resource. この黄色マーカの記載でようやく腑に落ちました。つまり、マネージドルール上の「再試行までに：XX」で設定した回数分の自動修復アクションが、「秒：XX」で設定した秒数以内に完遂した場合、RemediationExceptionが投げられて自動修復アクション再試行が停止する、という解釈が正しかったようです。 言い換えれば、「再試行までに：XX」で設定した回数分の自動修復アクションが、「秒：XX」で設定した秒数以内に完遂しない場合、RemediationExceptionが投げられず、自動修復アクション再試行が停止しない、という解釈になります。 無限ループが発生したケースでは、①「再試行までに：10」「秒：600」と、②「再試行までに：1」「秒：60」の２パターンを検証しました。10秒間に1回ペースの頻度では指定時間内に指定回数の自動修復アクション実行が終わらず、結果無限ループが発生していた、ということが推察できます。 無限ループを止めてみる それではパラメータの使い方が正しく解釈できたところで、再度トライしてみます。 「再試行までに：1」「秒：600」というかなり緩めの設定をすることで、自動修復アクションの無限ループが止まることを期待します。 さきほどはAWS Systems Manager Automationのランブック実行履歴から確認しましたが、AWS CloudTrailで別角度からより詳細に確認してみます。 一番下の赤枠の「2月27, 2024, 16:57:24」「2月27, 2024, 16:57:25」の部分は、先ほど作成したLambda関数「modifyLambdaFunctionUrlPublicAccessSetting」をLambdaコンソール上から直接実行した際のAPIコールを示しています。 このAPIコールを契機に真ん中赤枠「2月27, 2024, 16:57:54」の部分で「PutEvaluations」が呼ばれています。このAPIコールは、AWS Configが今回の評価ターゲットであるLambda関数「awsConfigTestLambdaFunction」を実際に評価し、「非準拠」の判定を下している部分です。 そしてさらに、この「PutEvaluations」を契機に「StartAutomationExecution」が呼ばれていています。このAPIコールは、AWS Configが自動修復アクションを開始している部分です。自動修復アクションが開始されると、アクションに紐づくLambda関数「modifyLambdaFunctionUrlPublicAccessSetting」が再度呼ばれ、「AddPermission」と「RemovePermission」が再度観測されます。 無限ループが発生していた時は、一番上の赤枠の「PutEvaluations」確認後、 「PutEvaluations」→「StartAutomationExecution」→「RemovePermission」→「AddPermission」→「PutEvaluations」→「StartAutomationExecution」→「RemovePermission」→「AddPermission」→「PutEvaluations」→・・・ という感じでループが発生していました。 しかし、自動修復アクションにて「再試行までに：1」「秒：600」の設定をしたことで、一番上の赤枠の「PutEvaluations」以降、「StartAutomationExecution」が観測されることはありませんでした。（もちろん、AWS Systems Manager Automationのランブック実行履歴上も再実行が繰り返されていないことも確認済み） …ということで無事、無限ループ解消となります！   最後に いかがでしたでしょうか。 最初からドキュメントしっかり読みこめば済む話ではありましたが、おかげでAWS Configと少しだけ仲良くなれたような気がします。 本記事がいつかどこかで少しでも皆様のお役に立てれば幸いです。

こんにちは。SCSKのふくちーぬです。 前回、Amazon Data Firehose を利用して、Amazon CloudWatch Logs のログを Amazon S3 に転送する手法をご紹介しました。こちらの記事を読んでいない方は、是非ご一読ください。 Amazon CloudWatch Logs を Amazon Data Firehose のみ利用して、解凍処理して Amazon S3 に転送する [Amazon Data Firehose + AWS Lambda + Amazon CloudWatch + Amazon S3 + AWS CloudFormation] Amazon CloudWatch Logs のログを Amazon Data Firehose を利用して解凍済みのログとして Amazon S3 に転送する方法を紹介します。 blog.usize-tech.com 2024.02.15 今回は、Amazon Data Firehose で Amazon S3 へ転送する際にログに含まれるヘッダー部分の抽出がサポートされたので紹介します。 Amazon Data Firehose で S3 転送時にメッセージ抽出機能がサポートされました 以前までは、ログイベント本体に加えて転送処理に関する付加情報が付与されていました。 今回のアップデートで、ログイベント本体のみS3やSplunkに配信することが可能になりました。メッセージ抽出にかかる料金は無料です。 Amazon Data Firehose adds message extraction feature for decompressed CloudWatch Logs aws.amazon.com ログイベント本体のみ配信することで、メッセージ（データ量）の削減も期待できます。 例えば後続の分析処理にてヘッダー部分の処理をわざわざ実装していた方はすぐに導入することで、カスタム処理の排除とデータ保管料の削減効果を得ることができます。 Writing to Amazon Data Firehose Using CloudWatch Logs - Amazon Data Firehose Guide for writing to Amazon Data Firehose from CloudWatch Logs. docs.aws.amazon.com 検証 実際にやってみます。リソースは、前回デプロイしたものを利用します。 Amazon Data Firehoseのマネジメントコンソールを開きます。 “レコードを変換および転換”を確認すると、新たに「ログイベントからのみメッセージデータを抽出」の欄が追加されています。 “ログイベントからのみメッセージデータを抽出”をオンに設定します。 ログの確認 Lambdaにてテストイベントを作成して実行します。CloudWatch Logsへログが出力され、FirehoseでS3へのログ転送を実施します。 ログの中身を確認すると、ログイベントのメッセージのみ配信されていることを確認できました。 データ量の削減もできていることを確認できました メッセージ抽出機能をオフ メッセージ抽出機能をオン 最後に いかがだったでしょうか。 Data Firehose のメッセージ抽出機能について解説しました。 S3やSplunkに配信後、後続の分析処理で余分なヘッダー部分の除外処理を実装する必要がなくなりました。これに伴いメッセージ（データ量）も削減できるため、オブジェクトの保管料も削減できます。 本記事が皆様のお役にたてば幸いです。 ではサウナラ～🔥