TECH PLAY

SCSKクラウドソリューション

SCSKクラウドソリューション の技術ブログ

1141

どうも、Catoクラウドを担当している佐々木です。 今回は Catoクラウドの「Header Injection」   について紹介します。   最近、Microsoft365やGoogleアカウントについて、許可していないアカウントを利用させないようにしたい、といった いわゆる「 テナント制御 」に関する問い合わせを多くいただきます。 Catoクラウド経由でテナント制御する際に利用する機能の一つ、それが「Header Injection」です。   画⾯は2024年7⽉時点のものです。 機能アップデート等で変わる場合がありますので、あらかじめご了承ください。 「Header Injection」を利用するためには、セキュリティオプションのCASBが必須になります。   テナント制御とは テナント制限とは、会社や管理者が許可したアカウントのみWEBサービスを利用できるようにすることです。 ※MicrosoftやGoogleで、会社のアカウントによるアクセスはOKだけど、個人アカウントでのアクセスはNG、を実現する機能です。   どうやってやってるの? クライアントとインターネットの間にあるプロキシなどで、通信ヘッダーや認証プロセスを操作することで実現しています。 例: Microsoft365の場合 クライアント端末からAzure ADに対する認証の通信をプロキシ経由させます。 そのプロキシから送信されるパケットに許可対象の Azure AD テナントの情報を付与します(HTTPヘッダーとして付与)。 Microsoft365側での上記で挿入したヘッダーの値を参照することで、許可したテナントへのアクセスのみ許可され、 それ以外はブロックされるといった動作をします。      ※Catoクラウド利用者は、上記のプロキシ=Catoクラウドと置き換えてください。 ※Microsoftの仕様については、以下の公式サイトを参照ください。   テナント制限を使用して SaaS アプリへのアクセスを管理する - Microsoft Entra ID 自社の Microsoft Entra テナントに基づいて、テナント制限を使用しアプリにアクセスできるユーザーを管理する方法。 learn.microsoft.com   つまり、プロキシ(=Catoクラウド)で実施しているのは、ヘッダーを挿入することです。 ブロックする/しないなどの「アクセス制御」は、 Microsoft365など WEBサービスがやっています。 Catoクラウドがブロックしている、と誤解される方が多いのですが、 Header Injection機能では一切アクセス制御はしていません!!!   Catoクラウドでの実現方法 Catoクラウドを経由してテナント制御する場合、以下の機能を利用します。   Header Injection機能 設定した条件(アプリケーションやアカウント等)にマッチする通信が発生した際、パケットのヘッダーに任意の文字列を挿入します。 アクセス先のWEBサービス側で、任意の文字列がヘッダーに含まれるパケットのみ許可し、それ以外をブロックするなど、 といった制御をさせることで、テナント制御を実現します。   TLSインスペクション トラフィックを検査するためTLSインスペクションを有効にする必要があります。 TLSインスペクションが有効でも、Bypassしている通信に対して「Header Injection機能」は動作しません。   その他 過去のブログ記事「 Catoクラウドでアプリケーションを制御するには 」でも紹介があった通り、 Catoクラウドの「Application Control」機能でもテナント制御は可能です。 気になる方は上記記事をご確認ください。   動作イメージ 例えば、Microsoft365へのテナント制御を実施する場合、以下のような動作をします。 ① ユーザーがMicrosoft365にアクセスし、サインインを試みます。 ② トラフィックは「Catoクラウド」に送られ、CMAで設定したヘッダー( Microsoft 365が指定したもの) を挿入します ⇒これがHeader Injectionの機能です。 ③ Catoクラウド経由でトラフィックをMicrosoft365に転送します。 ④ Microsoft365で、ヘッダー値を検索します。 ⑤ 正しいヘッダー値を持っている場合、アクセスが許可され、正しくない場合、アクセスに失敗します。   Microsoft365へのテナント制御をやってみた 今回は、問い合わせが多い「Microsoft365へのテナント制御」をテストしてみました。   注意事項 ここから読み始めた方もいるかもしれないので再掲します。 Catoクラウドで実施しているのは、ヘッダーを挿入することです。 ブロックする/しないなどの「アクセス制御」は、 Microsoft365など WEBサービスがやっています。 Catoクラウドがブロックしている、と誤解される方が多いのですが、 Header Injection機能では一切アクセス制御はしていません!!!   テスト条件 テスト内容:Microsoft365について、アカウントAのアクセスはOKで、アカウントA以外はアクセスさせない 端末:Windows 11 Catoクライアント:5.10.34.2284   Catoの設定 CMAで「 Security 」>「 Application Control 」>「 Header Injection 」から以下のように設定します。 ▼「Header Injections」の有効化 左上のHeader Injections Enabledをクリックして、バーが緑色になるようにしてください。   ▼ルール1(Microsoft365_テナント制御1) ログインを許可したいアカウントを定義 しています アプリケーションは「 Azure Active Directory 」を選択してください 「Injected Headers」で以下の設定をしてください Header Name: Restrict-Access-To-Tenants  / Header Value: Microsoftアカウントのprimary domainを入力 Header Name: Restrict-Access-Context  / Header Value: Microsoftアカウントのテナント IDを入力   MicrosoftアカウントのテナントIDなどがわからない方は、以下を参考に調べてみてください。 ※管理者権限がないと確認できません。 Microsoft 365 テナント ID を見つける   ▼ルール2(Microsoft365_テナント制御2_コンシューマーアカウントをブロックする設定) コンシューマー向けのアカウントをブロックするための設定です。 アプリケーションは「 Microsoft Live 」を選択してください 「Injected Headers」で以下の設定をしてください Header Name: sec-Restrict-Tenant-Access-Policy  / Header Value: restrict-msa   最後に設定を保存して完了です。 ※TLSインスペクションを有効にしていない場合、有効化してください。   Catoのバージョンアップに伴い、アプリケーション名などが変わる可能性がございますのでご注意ください。 ヘッダー値や動作は、Microsoftの仕様に依存しますので、思うように動作しない場合、Microsoftの仕様をご確認ください。   テスト結果 許可しているアカウントでのアクセスは許可されましたが、許可していないアカウントでのアクセスは以下のようにブロックされました。   ▼許可していないアカウントでアクセスした結果   ▼コンシューマー向けアカウントでアクセスした結果  ※ちょっと画面が違ったので一応共有します。 まとめ 意外と簡単な設定でテナント制御ができました。 挿入するヘッダー値は変わりますが、GoogleやSlackなど他のアプリケーションでも同じように設定することで制御可能です。   ・Catoクラウドでもテナント制御が可能 ・Microsoft365、Gmail、Slcakなど多くのアプリケーションに対応 ・Catoクラウドではヘッダーを挿入しているだけで「実際の振る舞い」はWEBサービス側に依存 ・Header Injectionだけではなく、TLSインスペクションも有効しないとダメ   上記以外の情報についても弊社の 「Catoに関するFAQサイト」 に多数情報ございますのでご参考にください。 よくあるご質問 | Cato Cloud ケイトクラウド - SCSK Cato SASE Cloud Platform. powered by SCSK cato-scsk.dga.jp   最後に、SCSKではPoCから導入、運用まで幅広くCatoに関する支援を行っております。 本番構成への移行を見据えたPoC構成や、PoCでつまづきやすい点のサポートなど、豊富な導入実績を基にご支援いたします。 ぜひお声がけください!
アバター
AWS JAPAN APNブログ にて 2024 Japan AWS Ambassadors / 2024 Japan AWS Top Engineers / 2024 Japan AWS Jr. Champions の受賞者が発表されました。 今年度は、SCSKより過去最多の表彰者が選出されました!SCSKから選出された計10名の社員を今回はご紹介します! 2024 Japan AWS Ambassadors 「 2024 Japan AWS Ambassadors 」は、2024 Japan AWS Top Engineers のうち、卓越した技術力を持ち、社内外への情報発信やその深い専門知識を基に、アマゾン ウェブ サービス(AWS)のソリューションアーキテクトと協力してお客様のAWS導入・活用にあたり大きく貢献・支援したメンバーが選出されます。(各社最大2名まで) SCSKからは広野と木澤の2名が選出されました。 広野 祐司 ソリューション事業グループ クラウドサービス事業本部 クラウドサービス第二部 第二課 ソリューション事業グループ ソリューション事業グループ統括本部 統括部 タレントマネジメント第二課 Ambassador 3 年目となりました。 私は社内クラウド技術者育成や、社外のお客様または社内のエンジニア向けの AWS 技術支援を担当しております。AWS サーバーレスサービス、React によるモダン Web アプリケーション開発が得意領域です。 社員向けクラウド学習用 e-Learning サイトの開発、コンテンツ作成をしながら、その e-Learning サイトを学習教材に仕立て、DevOps、CI/CD、アジャイルソフトウェア開発を体験できる研修も提供しております。 当社 AWS 認定資格数はちょうど 2,500 を超えたところです。知識的な育成だけでなく、人材育成施策の過程で得た実戦経験を社内外への技術支援に活用するサイクルも徐々にできるようになってきたと感じています。 今年度当社 Top Engineer は増えましたが、今後継続的に Top Engineer や次期 Ambassador の育成サイクルを回していけるようになれたらと思っています。 引き続き、どうぞよろしくお願いいたします。 ★ 広野のTechHarmony記事一覧は こちら 木澤 朋隆 ソリューション事業グループ クラウドサービス事業本部 事業推進部 事業企画課 ソリューション事業グループ クラウドサービス事業本部 クラウドサービス第二部 第二課 2021年からJapan AWS Ambassadorsを拝命しております。 自身の活動方針として「クラウドに強いSCSKの実現」と「それをアピールすることによる当社のプレゼンス向上」を挙げ活動してまいりました。それに伴い立ちあげた本エンジニアブログTechHarmonyも記事数が500を超え、認知度が高まってきていることを嬉しく思います。 私は新卒で入社以来、お客様先での常駐やWebシステム開発のインフラ構築で幅広い経験を積んでまいりました。2013年にAWS上での大規模構築案件を担当したことでクラウドサービスの将来性を感じ、2016年よりクラウド提供部署に異動して現在に至ります。 現在の業務は、クラウドアーキテクトとしての案件支援やマーケティングのリーダーとして各種イベントの企画や運営・登壇、社内外向けの情報発信などを担当しております。 なお表彰制度は活かしてこそと思っておりコミュニティイベントにも参加や発表を行い積極的に交流するようにしておりますが、そこでの交流は人生の糧になっていると感じております。皆様ありがとうございます。 そうした活動を通じ、今後も「クラウドに強いSCSK」の実現に邁進していく所存です。 よろしくお願いします。 ★ 木澤のTechHarmony記事一覧は こちら   2024 Japan AWS Top Engineers 「 2024 Japan AWS Top Engineers 」は、AWSパートナーネットワーク(APN) 加入のAWSパートナー企業に所属し、AWSに関する高い技術力を発揮した活動を行ったメンバーが選出されます。 8つのカテゴリ(Services、Software、Networking、Security、Analytics、Database、Machine Learning、SAP on AWS)が用意されており、 SCSKからはServicesで広野/木澤/寺内の3名(※)、Databaseで丸山/潮の2名、Analyticsで安彦/三上の2名、Nerworkingで貝塚の1名が選出されました。 ※広野/木澤は前項で紹介済みのため本項では割愛 (2024 Japan AWS Top Engineers SCSKメンバー8名)   ★ 2024 Japan AWS Top Engineers (Services) 寺内 康之 ソリューション事業グループ クラウドサービス事業本部 クラウドサービス第二部 第二課 四半世紀以上前にネットワークエンジニアとして社会人になり、サーバエンジニアを経由して現在AWSを専業でやっております。 2007年、EC2が発表され、あまりに簡単にLinuxマシンが手に入ることに感動して以来、AWSのファンです! 現在は、お客様の内製を技術面、教育面で総合的に支援する「テクニカルエスコートサービス」を提供しています。こちらはアプリケーションから基盤およびネットワークなど幅広く、AWSの範疇にとどまらなず幅広く相談を受け付ける総合IT支援サービスとなっておりますので、是非お気軽にお問い合わせください。 今回、AWS Top Engineersとしてご評価いただいたことは、長年”AWS愛”を育んできた私としてとても嬉しく光栄に思います。チームのみなさまと協力し得られた成果ですので、引き続きチーム力で貢献したいきます。 さて、個人的にはSF小説やアニメが大好きで、わりと妄想したり夢見がちです。VUCAの時代、SFプロトタイピングなどもやってみたいと常々思っております。関係の方々、よろしくお願いします。 ★ 寺内 のTechHarmony記事一覧は こちら   ★ 2024 Japan AWS Top Engineers (Database) 丸山 祐佳 ソリューション事業グループ クラウドサービス事業本部 クラウドサービス第二部 第三課 SCSKに入社以来、MySQLを中心としたDB技術者として、設計・構築をはじめ、サポートやチューニングサービス、研修講師などを担当していました。 その後、当社ERPパッケージであるProActiveのデータベースをOracle DBからMySQLへ移行するプロジェクトをきっかけとし、AWS環境への異種DBマイグレーションサービスを立ち上げ、PostgreSQLやAmazon Auroraへの移行案件に携わり、現在に至ります。 この度、昨年に続き2024 Japan AWS Top Engineers (Database)にも選出いただき大変光栄です。異種DB移行は、技術難易度やその複雑性から決して一人でできるものではなく、チームとして協力しあってこそ成功するサービスです。今回の選出についても、これまで異種DB移行に携わってきた方々のおかげです。大変感謝申し上げます。 おかげさまでお客様からの相談も多く少しずつ実績も増え、また移行後も快適にDBを利用できるようチューニングなどのサービス拡大を行っております。 AWS環境におけるDB分野のサービスを継続的に進化・拡大することで、今後もよりAWSの普及に寄与できるよう努めて参りたいと思います。 ★ 丸山 のTechHarmony記事一覧は こちら 潮 雅人 ソリューション事業グループ クラウドサービス事業本部 クラウドサービス第二部 第三課 新卒でSCSKに入社して以来、5年ほどMySQL関連の設計構築や性能問題対策を担当していました。その後、ニューヨークに1年半、ジャカルタに8か月ほどの駐在を経て、現在はお客様の異種データベースマイグレーションプロジェクトをご支援し、Oracle DatabaseからAmazon Auroraへの移行案件等に携わってきました。 異種データベース移行は、移行する際の規模の予測が難しく、かつ移行前後のデータベース両方の知識が必要とされるため、ハードルが高いと考えられ、実際ハードルは高い傾向にあるのですが、運用費用節減やクラウド活用による柔軟性の確保等、得られるメリットも大きい活動です。 今回Top Engineersの選出に際しては、この異種データベース移行の活動によるお客様のビジネスへの貢献、また、海外でのAWS利用拡大に向けた活動がご評価頂けたものと考えております。 今回のTop Engineers選出をきっかけとして、より高いレベルでのAWS上DBの理解と利用普及に貢献して参ります。 ★ 潮 のTechHarmony記事一覧は こちら   ★ 2024 Japan AWS Top Engineers (Analytics) 安彦 洋樹 ソリューション事業グループ クラウドサービス事業本部 データ&AIソリューション部 第一課 SCSKに入社以来、アプリケーション開発する部署と基盤を構築する部署を渡り歩き、主にDA/DBAとして様々な大規模プロジェクトを経験してきました。 その中でオンプレ環境でDWHシステムを構築するプロジェクトも何度か経験しており、面白い領域だなぁと思っていたところ、2018年にAmazon Redshiftを中心とした顧客情報基盤構築プロジェクトでアーキテクトリーダを担当したことをきっかけに、AWSのAnalytics系のサービス(Amazon Redshift、Amazon QuickSight、AWS Glue等)を使ったデータ活用システム構築のプロジェクトを主に担当することになりました。 そこで培った経験を活かし、2023年には「クラウドデータ活用サービス」を開発し、そのサービスを使って現在はAWS様主催のセミナーに登壇させて頂いたり、データ活用システムの構築プロジェクトを数多く推進しております。 このような活動をAWS様に評価頂き、2024 Japan AWS Top Engineers (Analytics) に選出して頂きました。 これからも、AWSのAnalytics系のサービスを活用して、お客様のDX推進やデータドリブン経営の支援に努めていきたいと思います。 ★ 安彦 のTechHarmony記事一覧は こちら 三上 晶子 産業事業グループ 産業ソリューション第二事業本部 エンタープライズソリューション第二部 第二課 新卒でSCSKに入社し、今年で入社6年目になります。 入社当初はデータベース専門部隊としてOracleやMySQLのデータベース構築案件を担当しており、その後はデータ活用案件と並行して、SCSKクラウドデータ活用サービスの企画からプロモーションを担当しました。現在はInformaticaの主管部署として、引き続きデータ活用案件やサービス開発に従事しております。 この度、2024 Japan AWS Top Engineers (Analytics)に選出いただきました!これまでのYouTubeを利用したプロモーション活動やセミナーでの登壇が選出に繋がったと考えております。YouTubeやセミナーなど表に見えているのは私一人ですが、その裏には多くの優秀な技術者がおり皆様にたくさんの支援をいただいております。大変感謝申し上げます。 現在はInformatica部隊ではありますが、AWSとの親和性を活かしAWS部隊との懸け橋となりビジネス拡大に貢献してまいります。 ★2024/7/26に大阪でデータ活用に関するセミナーを実施します!ぜひ興味のある方はご参加ください★ トヨタ紡織様事例から学ぶ、社員を幸せにするDXの第一歩 現在、DX(デジタルトランスフォーメーション)やデータ活用という言葉をよく目にしますが、多くの企業が「どのようにDXに取り組めば良いか分からない」「データ活用を進めたいが、何をしたら良いか分からない」といったお悩みを抱えています。 こうした... www.scsk.jp ★ 三上 のTechHarmony記事一覧は こちら   ★ 2024 Japan AWS Top Engineers (Networking) 貝塚 広行 ソリューション事業グループ クラウドサービス事業本部 クラウドサービス第二部 第二課 新卒でSCSKに入社後、数年間は自社データセンターをはじめとする各種ネットワークの設計・構築・運用を担当していました。その後、Linuxやサーバ仮想化技術の調査・開発、自社クラウド基盤(IaaS)の設計・構築・運用を経て、AWS関連の開発にも携わるようになりました。 さらにその後の約4年間は他業務を経験し、1年ほど前からはAWSの内製化・技術支援を提供するテクニカルエスコートサービスに従事しています。 AWSに関わること自体に数年のブランクがあった上、ネットワークについてもさらに長いブランクがあったため、今回のJapan AWS Top Engineers (Networking)受賞には驚いています。 手探りの中で、AWSのアーキテクチャ関連ドキュメントを読み込み、明確には分からないことを細かい部分まで検証し試行錯誤したこと、それらを社内外に発信できたことが選出につながったのだと思います。 今後も経験と実績を積み重ね、社内外へのAWSの普及に努めてまいります。 ★ 貝塚 のTechHarmony記事一覧は こちら   2024 Japan AWS Jr. Champions 「 2024 Japan AWS Jr. Champions 」は、APN加入のAWSパートナー企業に所属する社会人歴 1~3 年目で、AWSについて突出した活動実績がある若手エンジニアを対象とした、今年度より新設された日本独自の表彰制度です。 AWSを積極的に学び、アクションを起こし、周囲に影響を与えている若手エンジニアが選出されます。 SCSKからは福地 と蛭田の2名が選出されました。 2024 Japan AWS Jr. Champions SCSKメンバー2名(左右) ※AWSでJr.Championsを主管するYukki(髙橋 敏行)さんと一緒に 福地 孝哉 ソリューション事業グループ クラウドサービス事業本部 クラウドサービス第二部 第一課 2021年にSCSKに入社しました。 業務経歴は、オンプレミスからAWSへのマイグレーション支援、データ利活用のためのデータ連携基盤の設計・構築業務をしています。 2024 Japan AWS Jr. Champions選出にあたり、3つのContributionカテゴリに対してAWSエンジニアとして水準を満たしているか評価されます。 私の場合は以下の活動を評価いただきました。 Challenge:サーバレス技術を組み合わせたシステム設計、案件リード Influence:Techharmonyでの発信活動 Output:社内エンジニア向けの研修プログラムの企画・運営・講師 また、2023-2024 Japan AWS All Certifications Engineersとして認定資格を継続的に取得し、積極的にインプットに取り組んできました。 今回の選出について、協力いただいた皆様には感謝申し上げます。 このブログを読んでいるあなた!SCSKで次世代のJr. Championsを目指しませんか?? SCSKの代表としてAWSビジネスの発展に貢献できるよう精一杯頑張りますのでどうぞよろしくお願いします! ★ 福地 のTechHarmony記事一覧は こちら 蛭田 悠介 ソリューション事業グループ クラウドサービス事業本部 クラウドサービス第二部 第一課 2023年に新卒で入社しました。 半年間の研修を経て昨年10月よりAWSの主管部署に配属されております。 業務内容としては、福地さんと同じチームにてAPI基盤構築プロジェクトに配属後から現在まで参画しています。 入社してからは一年余り、AWSに触れ始めてからはまだ一年が経過していないため、最初は周囲の方々の知識のすごさに圧倒されておりました。 そのため、少しでもそのような方々に追いつく・追い越すべく、業務以外の場面においても「これってAWSで構築できるかなぁ…」と思ったことは自分で調べながら構築してみて、その取り組みをTechHarmonyにて発信するという活動をしてまいりました。 この活動によって社内で声を掛けていただき、この度2024 Japan AWS Jr. Championsに選出いただきました。 今まで以上にインプット、そしてアウトプットをし、社内外の若手に刺激を与えられる存在になれるよう努めてまいります。 (ちなみに写真の手は「S3」の「3」です。) ★ 蛭田 のTechHarmony記事一覧は こちら   最後に 2024 Japan AWS Ambassadors / 2024 Japan AWS Top Engineers / 2024 Japan AWS Jr. Champions に選出されたSCSK社員10名をご紹介しました。今回ご紹介した10名以外にもSCSKにはAWS認定資格取得者が多数在籍しております。 AWS導入・DX推進をお考えの方は、 ぜひSCSKにお気軽に お問い合わせ ください。 弊社の SCSKクラウドサービス(AWS) では AWS の導入から運用改善まで、お客様のAWS活用をご支援するサービスをご提供しております。 今後もお客様のAWS案件を強力にご支援出来るよう、技術力の向上や情報発信などの活動に努めてまいります。
アバター
こんにちは、SCSK株式会社の小寺崇仁です。 先日、安藤さんから バージョンアップ方法の紹介 がありました。 補足情報として、バージョンアップの注意点をご紹介したいと思います。 関連モジュールの依存関係について OSについて ZabbixOSは公式HPのダウンロードメニューより対応しているか確認します。 Zabbix7.0で対応していますが、OSのサポート終了(EOL)にご注意ください ■Zabbix Download https://www.zabbix.com/download OS バージョン EOL(AI調べ) Red Hat Enterprise Linux 9 2032年5月(メンテナンスサポート終了) 8 2029年5月(メンテナンスサポート終了) 7 2024年6月(メンテナンスサポート終了) 6 2017年5月(メンテナンスサポート終了) Alma Linux 9 2032年5月 8 2029年5月 Rocky Linux 9 2032年5月 8 2029年5月 Ubuntu 24.04 (Noble) 情報未定 22.04 (Jammy) 2027年4月(標準サポート終了)、2032年4月(ESM終了) 20.04 (Focal) 2025年4月(標準サポート終了)、2030年4月(ESM終了) 18.04 (Bionic) 2023年4月(標準サポート終了)、2028年4月(ESM終了) 16.04 (Xenial) 2021年4月(標準サポート終了)、2026年4月(ESM終了) ミドルウェアについて Zabbix7.0のミドルウェア要件として公式マニュアルに以下の記載があります ■Zabbix7.0 Requirements https://www.zabbix.com/documentation/current/en/manual/installation/requirements Apache 2.4 or later Nginx 1.20 or later PHP 8.0.0 – 8.3.X MySQL 8.0.30-8.4.X MariaDB 10.5.00-11.4.X PostgreSQL 13.0-16.X OSのリポジトリに対応のミドルウェアがあるか? 各MWの導入にdnf,aptコマンドを使用してインストールすると思います。 OSの種類ごとに2024年7月7日時点の最新のバージョンをまとめました。   Zabbix7.0 (要件) RHEL 9.4 RHEL 8.10 Ubuntu 24.04 Ubuntu 22.04 Ubuntu 20.04 Apache 2.4 or later httpd-2.4.57 2.4.37-65 2.4.58 2.4.52 2.4.41 Nginx 1.20 or later 1.20 1.14 1.24.0 1.18.0 1.17.10 PHP 8.0.0 – 8.3.X 8.0.30 7.2.24 8.3 8.1 7.4 MySQL 8.0.30-8.4.X 8.0.36 8.0.36 8.0.36 8.0.28 8.0.19 MariaDB 10.5.00-11.4.X 10.5.22 10.3.39 10.11.7 10.6.7 10.3.22 PostgreSQL 13.0-16.X 13.14 10.23 16+257 14+238 12+214 まとめ RHEL系もUbuntu(Debian)系もOSも合わせてアップグレードが必要になりそうです   バージョンアップの時間について Zabbixのバージョンアップはdnfやaptコマンドを使用して、プログラム(パッケージ)の更新を行います。 Zabbix-serverのサービスを起動する際に、データベースの更新処理が行われます。 データ量の多い、ヒストリー、イベントテーブルに更新があると、更新に時間がかかり、監視の停止時間が長くなります。 バージョン5からバージョンアップした際に、テーブル構造の変更があるか調査しました。 history系テーブルのIndexからPRIMARY KEY への変更 Zabbix5.0 CREATE TABLE `history` ( `itemid` bigint(20) unsigned NOT NULL, `clock` int(11) NOT NULL DEFAULT 0, `value` double NOT NULL DEFAULT 0, `ns` int(11) NOT NULL DEFAULT 0, KEY `history_1` (`itemid`,`clock`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin Zabbix7.0 CREATE TABLE `history` ( `itemid` bigint(20) unsigned NOT NULL, `clock` int(11) NOT NULL DEFAULT 0, `value` double NOT NULL DEFAULT 0, `ns` int(11) NOT NULL DEFAULT 0, PRIMARY KEY (`itemid`,`clock`,`ns`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin まとめ history、history_uint、history_str、history_log、history_textでプライマリキーに変更されていました。 データ容量やディスクの速度によって、時間が変わりますが、感覚的に時間がかかりに思います。 ヒストリデータを破棄してから更新するのもアリかもしれないです。   ZabbixProxyを利用している場合について ZabbixProxyを使用している場合、Zabbix7.0では下位互換があります。バージョンアップの際に活用できるか、別途検証してブログ記事にしたいと思います。   仕様の変更について Zabbixの5.0からバージョンアップをすると機能が大きく変わっています。 大きな変更点をご紹介します。 ダッシュボードの変更 メニューが左側になりました。 バージョンが上がる度に改良されていきます。 トリガー条件式 条件式の記述方法が大きく変わっています。 バージョンアップの際に自動で更新されます。 監視プロセスの最適化 Pollerプロセスが分割されます。 別途チューニングが必要となります。 ユーザ役割 ユーザの役割にて、権限が詳細設定可能になります。 監視対象のサーバ管理者にユーザを払い出している場合、注意が必要です。 監査ログ バージョンアップ時に既存の監査ログのレコードは削除されます。 サポートされるDBバージョンの確認 起動前にデータベースのバージョンを確認し、サポート範囲外のバージョンの場合は起動しないようになりました。 参考 https://www.zabbix.com/documentation/6.0/jp/manual/introduction/whatsnew600 https://www.zabbix.com/documentation/current/en/manual/introduction/whatsnew700   最後に 弊社ではZabbix関連サービスを展開しています。以下ページもご参照ください。 SCSK Plus サポート for Zabbix SCSK Plus サポート for Zabbix 世界で最も人気のあるオープンソース統合監視ツール「Zabbix」の導入構築から運用保守までSCSKが強力にサポートします www.scsk.jp ★YouTubeに、SCSK Zabbixチャンネルを開設しました!★ SCSK Zabbixチャンネル 本チャンネルでは、SCSK株式会社でのZabbixに関するトレンド/事例紹介などを動画にまとめて取り上げております。 最新のトピックについては、以下の弊社HPもしくはツイッターアカウントをぜひ参照ください。 ツイッターアカウント: www.youtube.com ★X(旧Twitter)に、SCSK Zabbixアカウントを開設しました!★ 【公式】SCSK Zabbix (@SCSK_Zabbix) / Twitter SCSKが提供するZabbixサービスのオフィシャルアカウントです。 #Zabbix #SCSKPlusサポートforZabbix #監視 #SCSK twitter.com  
アバター
こんにちは、広野です。 Amazon GuardDuty の設定は機能ごとに有効/無効にできるのですが、それを AWS CloudFormation で設定しようと試みたときにハマりました。 もし同じエラーが出た方には役立つかもしれません。そもそも AWS CloudFormation で Amazon GuardDuty の設定をする人ってあまりいないかもですが・・・。 ハマったこと 始まりは、AWS CloudFormation IaC ジェネレーターを使用したこと IaC ジェネレーターは、既存のデプロイ済みリソースをスキャンして、CloudFormation テンプレートにしたいリソースを選択すると、そのテンプレートを出力してくれるというスゴイやつです。 IaC ジェネレーターを使用して既存のリソースのテンプレートを生成する - AWS CloudFormation Infrastructure as Code (IaC) テンプレートを、CloudFormation で管理されていないアカウントにデプロイされた AWS リソースタイプから生成します。 docs.aws.amazon.com 今回、Amazon GuardDuty を AWS マネジメントコンソールからボタンぽちっとな、で有効にしたものを IaC ジェネレーターでテンプレート化して、他のアカウントにデプロイしようとしました。 IaC ジェネレーターが出力したテンプレートはこちら。↓ ここに、ハマり要素が潜んでいました。 注意!動きません。 --- Metadata: TemplateId: "arn:aws:cloudformation:ap-northeast-2:xxxxxxxxxxxxx:generatedTemplate/a4c6ba10-b002-47b3-bee2-587defc7921a" Resources: GuardDutyDetector0082c84d2d1e796541ecd974b782ea181600qtDWT: UpdateReplacePolicy: "Delete" Type: "AWS::GuardDuty::Detector" DeletionPolicy: "Delete" Properties: FindingPublishingFrequency: "SIX_HOURS" Enable: true DataSources: MalwareProtection: ScanEc2InstanceWithFindings: EbsVolumes: true S3Logs: Enable: true Kubernetes: AuditLogs: Enable: true Features: - Status: "ENABLED" Name: "CLOUD_TRAIL" - Status: "ENABLED" Name: "DNS_LOGS" - Status: "ENABLED" Name: "FLOW_LOGS" - Status: "ENABLED" Name: "S3_DATA_EVENTS" - Status: "ENABLED" Name: "EKS_AUDIT_LOGS" - Status: "ENABLED" Name: "EBS_MALWARE_PROTECTION" - Status: "ENABLED" Name: "RDS_LOGIN_EVENTS" - Status: "DISABLED" AdditionalConfiguration: - Status: "DISABLED" Name: "EKS_ADDON_MANAGEMENT" Name: "EKS_RUNTIME_MONITORING" - Status: "ENABLED" Name: "LAMBDA_NETWORK_LOGS" - Status: "DISABLED" AdditionalConfiguration: - Status: "DISABLED" Name: "EKS_ADDON_MANAGEMENT" - Status: "DISABLED" Name: "ECS_FARGATE_AGENT_MANAGEMENT" - Status: "DISABLED" Name: "EC2_AGENT_MANAGEMENT" Name: "RUNTIME_MONITORING" Tags: [] IaC ジェネレーターの出力を参考にして作成したテンプレート ※注意!動きません Amazon GuardDuty は機能ごとに有効/無効を設定できるものがあるので、私が必要な機能だけ有効にするように設定したつもりでした。 AWSTemplateFormatVersion: 2010-09-09 Description: The CloudFormation template that enables GuardDuty per region. Parameters: # ------------------------------------------------------------# # Input Parameters # ------------------------------------------------------------# TagValue: Type: String Description: Tag value for Cost key. Default: GuardDuty MaxLength: 30 MinLength: 1 Resources: # ------------------------------------------------------------# # GuardDuty # ------------------------------------------------------------# GuardDutyDetector: Type: AWS::GuardDuty::Detector Properties: FindingPublishingFrequency: SIX_HOURS Enable: true DataSources: MalwareProtection: ScanEc2InstanceWithFindings: EbsVolumes: true S3Logs: Enable: true Kubernetes: AuditLogs: Enable: false Features: - Status: ENABLED Name: CLOUD_TRAIL - Status: ENABLED Name: DNS_LOGS - Status: ENABLED Name: FLOW_LOGS - Status: ENABLED Name: S3_DATA_EVENTS - Status: DISABLED Name: EKS_AUDIT_LOGS - Status: ENABLED Name: EBS_MALWARE_PROTECTION - Status: DISABLED Name: RDS_LOGIN_EVENTS - Status: DISABLED AdditionalConfiguration: - Status: DISABLED Name: EKS_ADDON_MANAGEMENT Name: EKS_RUNTIME_MONITORING - Status: ENABLED Name: LAMBDA_NETWORK_LOGS - Status: DISABLED AdditionalConfiguration: - Status: DISABLED Name: EKS_ADDON_MANAGEMENT - Status: DISABLED Name: ECS_FARGATE_AGENT_MANAGEMENT - Status: DISABLED Name: EC2_AGENT_MANAGEMENT Name: RUNTIME_MONITORING Tags: - Key: Cost Value: !Ref TagValue ハマり その1 DataSources と Features の設定を両方入れるとエラーになる IaC ジェネレーターが出力したテンプレートを全面的に信じてテンプレートを作成したわけですが、実際にテンプレートを流すと以下のエラーメッセージでスタック作成が失敗しました。 Resource handler returned message: “Invalid request provided: AWS::GuardDuty::Detector” まず最初に気付いたのは以下のドキュメントでした。 GuardDuty API changes in March 2023 - Amazon GuardDuty The GuardDuty APIs configure protection features that don't belong to the list of . A feature object contains feature de... docs.aws.amazon.com どうも、GuardDuty の機能ごとに有効/無効を設定するには DataSources ではなく Features の設定を使用することを推奨していました。そして、両方記述するとエラーになるようです。 解決: DataSources の設定は削除しました。 ハマリ その2 EKS_RUNTIME_MONITORING と RUNTIME_MONITORING の設定も その1 の修正をしただけでは状況が変わりませんでした。エラーメッセージも その1 と同じです。テンプレートのどこに問題があるかわからず、AWS CloudTrail の API ログを確認したところ、以下のメッセージを発見しました。 The request was rejected because EKS_RUNTIME_MONITORING and RUNTIME_MONITORING cannot be provided in the same request.  EKS_RUNTIME_MONITORING と RUNTIME_MONITORING の設定を両方記述するとエラーになる ようです。 これについては、以下のドキュメントの冒頭に書いてありました。後から気付きました。 DetectorFeatureConfiguration - Amazon GuardDuty Contains information about a GuardDuty feature. docs.aws.amazon.com 解決: EKS_RUNTIME_MONITORING の設定は RUNTIME_MONITORING に含まれるようなので、EKS_RUNTIME_MONITORING の方を削除しました。 ハマり その3 指定した機能の名前が正しくない その2 の修正をしても状況は変わりませんでした。エラーメッセージも その1 と同じです。テンプレートのどこに問題があるかわからず、AWS CloudTrail の API ログを確認したところ、以下のメッセージを発見しました。 The request failed because the provided feature names are invalid: [FLOW_LOGS, DNS_LOGS, CLOUD_TRAIL]. テンプレートの中に記述している、これら 3つの機能の名前が正しくないと言っています。 後から気が付いたのですが、 設定変更可能な機能としてこれらは含まれていませんでした。 その2 で紹介した公式ドキュメントにしっかり書いてありました。 DetectorFeatureConfiguration - Amazon GuardDuty Contains information about a GuardDuty feature. docs.aws.amazon.com 解決: これら 3つの機能の設定は削除しました。 完成した AWS CloudFormation テンプレート ※動きます いろいろとハマりましたが、動作したテンプレートはこれです。有効にしたい機能は ENABLED にする必要があります。 IaC ジェネレーターを使用せずに最初から公式リファレンス読んで作成した方が早かったかも・・・。 AWSTemplateFormatVersion: 2010-09-09 Description: The CloudFormation template that enables GuardDuty per region. Parameters: # ------------------------------------------------------------# # Input Parameters # ------------------------------------------------------------# TagValue: Type: String Description: Tag value for Cost key. Default: GuardDuty MaxLength: 30 MinLength: 1 Resources: # ------------------------------------------------------------# # GuardDuty # ------------------------------------------------------------# GuardDutyDetector: Type: AWS::GuardDuty::Detector Properties: FindingPublishingFrequency: SIX_HOURS Enable: true Features: - Status: ENABLED Name: S3_DATA_EVENTS - Status: DISABLED Name: EKS_AUDIT_LOGS - Status: ENABLED Name: EBS_MALWARE_PROTECTION - Status: DISABLED Name: RDS_LOGIN_EVENTS - Status: ENABLED Name: LAMBDA_NETWORK_LOGS - Status: DISABLED AdditionalConfiguration: - Status: DISABLED Name: EKS_ADDON_MANAGEMENT - Status: DISABLED Name: ECS_FARGATE_AGENT_MANAGEMENT - Status: DISABLED Name: EC2_AGENT_MANAGEMENT Name: RUNTIME_MONITORING Tags: - Key: Cost Value: !Ref TagValue AWS CloudTrail のログが有用だった AWS CloudFormation テンプレートのスタック作成時エラーはメッセージから原因がわかることが多いのですが、GuardDuty に関しては Resource handler returned message: “Invalid request provided: AWS::GuardDuty::Detector” このメッセージ一辺倒だったので困りました。以下のドキュメントにあるように、AWS CloudTrail のイベント履歴から AWS CloudFormation のエラーメッセージを探すことで、原因を突き止められました。 コンソールで最近の管理イベントを表示する - AWS CloudTrail CloudTrail コンソールを使用して、アカウントで過去 90 日間の管理イベントを表示、フィルタリング、ダウンロードします。管理イベントは、単一の属性と時間範囲でフィルタリングできます。 docs.aws.amazon.com まとめ いかがでしたでしょうか? AWS CloudFormation テンプレートを IaC ジェネレーターで作成し始めたことからハマってしまいましたが、これに懲りずに他のリソースのテンプレート作成も引き続き試してみたいと思います。きちんと検証することの重要さや、AWS CloudTrail の有用性にも改めて気づかされました。 本記事が皆様のお役に立てれば幸いです。
アバター
こんにちは、広野です。 以下の記事と同じ理由で、AWS Summit Japan 2024 のセッションを聞いてインスピーレーションを受けまして、Amazon API Gateway と Amazon DynamoDB を AWS Lambda 関数抜きで直接連携しました。似たような記事は世の中に多いのですが、本記事では AWS CloudFormation でデプロイしています。 Amazon API Gateway から Amazon SES API を直接叩いてメール送信する (AWS Lambda 不使用) AWS Summit Japan 2024 でとあるセッションを聞いてインスピレーションを受けまして、Amazon API Gateway と Amazon SES を直接連携させてみました。 blog.usize-tech.com 2024.07.04 やりたいこと 以下の Amazon DynamoDB テーブルから、GetItem API を使用して指定のデータを 1件取得します。パーティションキーは pkey、ソートキーは skey です。属性として attr があります。 Amazon API Gateway REST API を使用します。AWS Lambda 関数は使用しません。 AWS Lambda 関数で行っていた Amazon DynamoDB API の呼び出しは、Amazon API Gateway の統合リクエストマッピングテンプレートで代用します。Amazon API Gateway の統合タイプは、AWS になります。 Amazon API Gateway の認証はありません。CORS 設定はあります。本記事では簡略化のため “*” を使用して設定します。 テストでは、”pkey”: “test1”, “skey”: 1 のパラメータを指定してデータ取得してみます。 マッピングテンプレートをどう書くか AWS Lambda 関数でやっていたことを Amazon API Gateway のマッピングテンプレートに肩代わりさせるので、そこが肝になります。イメージしてもらいやすくするため、AWS Lambda 関数と対比して紹介します。 AWS Lambda 関数 書き方はいくつかありますが、以下のような AWS Lambda 関数 (Python) で Amazon DynamoDB GetItem API を呼び出すと思います。 import json import boto3 dynamodb = boto3.resource('dynamodb') table = dynamodb.Table('extable-xxxxxxxxxx-hirono') def lambda_handler(event, context): input = json.loads(event['body']) res = table.get_item( Key={ 'pkey': input['pkey'], 'skey': input['skey'] } ) return { "isBase64Encoded": False, "statusCode": 200, "body": json.dumps(res) } マッピングテンプレート マッピングテンプレートだと、以下のように VTL を使用して書きます。統合リクエストマッピングテンプレートに定義します。 ## API Gateway が受け取った引数を $inputRoot に格納する #set($inputRoot = $input.path('$')) { "TableName": "extable-xxxxxxxxxx-hirono", "Key": { "pkey":{ "S": "$inputRoot.pkey" }, "skey":{ "N": "$inputRoot.skey" } }, "ConsistentRead" : false } Amazon DynamoDB GetItem API に渡すフォーマットは同じだと思いました。 冒頭で、Amazon API Gateway が受け取ったパラメータを $inputRoot という変数に格納しています。面倒なのは項目ごとに “N” や “S” などデータ型を明示的に書かないといけないことです。 Amazon DynamoDB テーブルに渡すパラメータの仕様は以下の公式リファレンス通りだったので、Amazon DynamoDB の他の API でも同様に応用できるものと想像します。 GetItem - Amazon DynamoDB The GetItem operation returns a set of attributes for the item with the given primary key. If there is no matching item,... docs.aws.amazon.com 実際の動作 実際に API へのリクエストを AWS CloudShell からコマンドを打って試してみます。以下のコマンドを打ちます。 curl -X POST 'https://xxxxxxxxxx.execute-api.ap-northeast-1.amazonaws.com/prod/Dynamodb' -H 'Content-Type: application/json' -d '{"pkey": "test1", "skey": "1"}' 以下の結果が返ってきます。 {"Item":{"attr":{"S":"attr1"},"pkey":{"S":"test1"},"skey":{"N":"1"}}} ↓整形すると { "Item": { "attr": { "S":"attr1" }, "pkey": { "S":"test1" }, "skey": { "N":"1" } } } 今回、Amazon API Gateway REST API の統合レスポンスマッピングテンプレートをパススルーにしたので、Amazon DynamoDB から返ってきたデータがそのまま表示されました。 レスポンスから余計な “N” や “S” を消そうと思ったら、統合レスポンスマッピングテンプレートで戻りを加工する必要がありますが、属性が固定ではない場合は難しいかもしれません。 本記事の例ではソートキーのデータ型が Number になっています。このケースでは、API に数値を文字列として渡さないとエラーになります。Amazon DynamoDB API の仕様です。”skey”:{“N”:”1″} となっている部分のことです。また、戻ってくる値も数値は文字列として返されます。 他にも Amazon API Gateway の設定はあるのですが、メインはマッピングテンプレートでしたので、AWS CloudFormation テンプレートから読み取るか、それを実行してデプロイされた現物をご確認頂けたらと思います。 AWS CloudFormation テンプレート 本記事で紹介した Amazon DynamoDB テーブルと Amazon API Gateway REST API を一式デプロイする AWS CloudFormation を貼り付けます。執筆時点で動いたことは確認済みです。 AWSTemplateFormatVersion: 2010-09-09 Description: The CloudFormation template that creates a DynamoDB table and an API Gateway. # ------------------------------------------------------------# # Input Parameters # ------------------------------------------------------------# Parameters: SubName: Type: String Description: System sub name. (e.g. example) Default: example MaxLength: 10 MinLength: 1 Resources: # ------------------------------------------------------------# # DynamoDB # ------------------------------------------------------------# DynamodbExample: Type: AWS::DynamoDB::Table Properties: TableName: !Sub extable-${AWS::AccountId}-${SubName} AttributeDefinitions: - AttributeName: pkey AttributeType: S - AttributeName: skey AttributeType: N BillingMode: PAY_PER_REQUEST KeySchema: - AttributeName: pkey KeyType: HASH - AttributeName: skey KeyType: RANGE PointInTimeRecoverySpecification: PointInTimeRecoveryEnabled: false Tags: - Key: Cost Value: !Ref SubName # ------------------------------------------------------------# # API Gateway # ------------------------------------------------------------# RestApiDynamodb: Type: AWS::ApiGateway::RestApi Properties: Name: !Sub dynamodb-${SubName} Description: !Sub REST API to call DynamoDB GetItem API for ${SubName} EndpointConfiguration: Types: - REGIONAL Tags: - Key: Cost Value: !Ref SubName RestApiDeploymentDynamodb: Type: AWS::ApiGateway::Deployment Properties: RestApiId: !Ref RestApiDynamodb DependsOn: - RestApiMethodDynamodbPost - RestApiMethodDynamodbOptions RestApiStageDynamodb: Type: AWS::ApiGateway::Stage Properties: StageName: prod Description: production stage RestApiId: !Ref RestApiDynamodb DeploymentId: !Ref RestApiDeploymentDynamodb MethodSettings: - ResourcePath: "/*" HttpMethod: "*" LoggingLevel: INFO DataTraceEnabled : true TracingEnabled: false Tags: - Key: Cost Value: !Ref SubName RestApiResourceDynamodb: Type: AWS::ApiGateway::Resource Properties: RestApiId: !Ref RestApiDynamodb ParentId: !GetAtt RestApiDynamodb.RootResourceId PathPart: Dynamodb RestApiMethodDynamodbPost: Type: AWS::ApiGateway::Method Properties: RestApiId: !Ref RestApiDynamodb ResourceId: !Ref RestApiResourceDynamodb HttpMethod: POST AuthorizationType: NONE Integration: Type: AWS IntegrationHttpMethod: POST Credentials: !GetAtt ApigDynamodbInvocationRole.Arn Uri: !Sub "arn:aws:apigateway:${AWS::Region}:dynamodb:action/GetItem" PassthroughBehavior: WHEN_NO_TEMPLATES RequestTemplates: application/json: !Sub | #set($inputRoot = $input.path('$')) { "TableName": "${DynamodbExample}", "Key": { "pkey":{ "S": "$inputRoot.pkey" }, "skey":{ "N": "$inputRoot.skey" } }, "ConsistentRead" : false } IntegrationResponses: - StatusCode: 200 ResponseParameters: method.response.header.Access-Control-Allow-Headers: "'Content-Type,X-Amz-Date,Authorization,X-Api-Key,X-Amz-Security-Token,Cache-Control'" method.response.header.Access-Control-Allow-Methods: "'POST,OPTIONS'" method.response.header.Access-Control-Allow-Origin: "'*'" - StatusCode: 400 ResponseParameters: method.response.header.Access-Control-Allow-Headers: "'Content-Type,X-Amz-Date,Authorization,X-Api-Key,X-Amz-Security-Token,Cache-Control'" method.response.header.Access-Control-Allow-Methods: "'POST,OPTIONS'" method.response.header.Access-Control-Allow-Origin: "'*'" - StatusCode: 403 ResponseParameters: method.response.header.Access-Control-Allow-Headers: "'Content-Type,X-Amz-Date,Authorization,X-Api-Key,X-Amz-Security-Token,Cache-Control'" method.response.header.Access-Control-Allow-Methods: "'POST,OPTIONS'" method.response.header.Access-Control-Allow-Origin: "'*'" - StatusCode: 404 ResponseParameters: method.response.header.Access-Control-Allow-Headers: "'Content-Type,X-Amz-Date,Authorization,X-Api-Key,X-Amz-Security-Token,Cache-Control'" method.response.header.Access-Control-Allow-Methods: "'POST,OPTIONS'" method.response.header.Access-Control-Allow-Origin: "'*'" - StatusCode: 500 ResponseParameters: method.response.header.Access-Control-Allow-Headers: "'Content-Type,X-Amz-Date,Authorization,X-Api-Key,X-Amz-Security-Token,Cache-Control'" method.response.header.Access-Control-Allow-Methods: "'POST,OPTIONS'" method.response.header.Access-Control-Allow-Origin: "'*'" - StatusCode: 503 ResponseParameters: method.response.header.Access-Control-Allow-Headers: "'Content-Type,X-Amz-Date,Authorization,X-Api-Key,X-Amz-Security-Token,Cache-Control'" method.response.header.Access-Control-Allow-Methods: "'POST,OPTIONS'" method.response.header.Access-Control-Allow-Origin: "'*'" MethodResponses: - StatusCode: 200 ResponseModels: application/json: Empty ResponseParameters: method.response.header.Access-Control-Allow-Origin: true method.response.header.Access-Control-Allow-Headers: true method.response.header.Access-Control-Allow-Methods: true - StatusCode: 400 ResponseModels: application/json: Empty ResponseParameters: method.response.header.Access-Control-Allow-Origin: true method.response.header.Access-Control-Allow-Headers: true method.response.header.Access-Control-Allow-Methods: true - StatusCode: 403 ResponseModels: application/json: Empty ResponseParameters: method.response.header.Access-Control-Allow-Origin: true method.response.header.Access-Control-Allow-Headers: true method.response.header.Access-Control-Allow-Methods: true - StatusCode: 404 ResponseModels: application/json: Empty ResponseParameters: method.response.header.Access-Control-Allow-Origin: true method.response.header.Access-Control-Allow-Headers: true method.response.header.Access-Control-Allow-Methods: true - StatusCode: 500 ResponseModels: application/json: Empty ResponseParameters: method.response.header.Access-Control-Allow-Origin: true method.response.header.Access-Control-Allow-Headers: true method.response.header.Access-Control-Allow-Methods: true - StatusCode: 503 ResponseModels: application/json: Empty ResponseParameters: method.response.header.Access-Control-Allow-Origin: true method.response.header.Access-Control-Allow-Headers: true method.response.header.Access-Control-Allow-Methods: true DependsOn: - ApigDynamodbInvocationRole RestApiRequestModelDynamodb: Type: AWS::ApiGateway::Model Properties: ContentType: application/json RestApiId: !Ref RestApiDynamodb Schema: |- { "$schema": "http://json-schema.org/draft-04/schema#", "title": "Dynamodb", "type": "object", "properties": { "pkey": { "type": "string" }, "skey": { "type": "integer" } }, "required": ["pkey", "skey"] } RestApiMethodDynamodbOptions: Type: AWS::ApiGateway::Method Properties: RestApiId: !Ref RestApiDynamodb ResourceId: !Ref RestApiResourceDynamodb HttpMethod: OPTIONS AuthorizationType: NONE Integration: Type: MOCK Credentials: !GetAtt ApigDynamodbInvocationRole.Arn IntegrationResponses: - ResponseParameters: method.response.header.Access-Control-Allow-Headers: "'Content-Type,X-Amz-Date,Authorization,X-Api-Key,X-Amz-Security-Token,Cache-Control'" method.response.header.Access-Control-Allow-Methods: "'POST,OPTIONS'" method.response.header.Access-Control-Allow-Origin: "'*'" ResponseTemplates: application/json: '' StatusCode: 200 PassthroughBehavior: WHEN_NO_MATCH RequestTemplates: application/json: '{"statusCode": 200}' MethodResponses: - ResponseModels: application/json: Empty ResponseParameters: method.response.header.Access-Control-Allow-Headers: true method.response.header.Access-Control-Allow-Methods: true method.response.header.Access-Control-Allow-Origin: true StatusCode: 200 # ------------------------------------------------------------# # API Gateway DynamoDB Invocation Role (IAM) # ------------------------------------------------------------# ApigDynamodbInvocationRole: Type: AWS::IAM::Role Properties: RoleName: !Sub ApigDynamodbInvocationRole-${SubName} Description: This role allows API Gateways to invoke DynamoDB GetItem API. AssumeRolePolicyDocument: Version: 2012-10-17 Statement: - Effect: Allow Principal: Service: - apigateway.amazonaws.com Action: - sts:AssumeRole Path: / ManagedPolicyArns: - arn:aws:iam::aws:policy/AWSXRayDaemonWriteAccess Policies: - PolicyName: !Sub ApigDynamodbInvocationPolicy-${SubName} PolicyDocument: Version: 2012-10-17 Statement: - Effect: Allow Action: - "dynamodb:GetItem" Resource: - !GetAtt DynamodbExample.Arn DependsOn: - DynamodbExample # ------------------------------------------------------------# # Output Parameters # ------------------------------------------------------------# Outputs: APIGatewayEndpointDynamodb: Value: !Sub https://${RestApiDynamodb}.execute-api.${AWS::Region}.${AWS::URLSuffix}/${RestApiStageDynamodb}/Dynamodb 本テンプレートは、Amazon API Gateway のログを Amazon CloudWatch Logs に push するために必要な IAM ロールがアカウントに登録済みでないとエラーになります。それについては以下の記事をご確認ください。 Amazon API Gateway のログを Amazon CloudWatch Logs に書き込むための IAM ロールはアカウント単位の設定です Amazon API Gateway のログを Amazon CloudWatch Logs に書き込むための IAM ロール設定を紹介します。 blog.usize-tech.com 2024.07.01 まとめ いかがでしたでしょうか? Amazon DynamoDB の API をそのまま使うだけの要件であれば、十分実用的であると思いました。VTL では対応しきれない文字列加工やビジネスロジックが必要になる場合は、やはり AWS Lambda 関数を間に挟む必要があります。 AWS AppSync のマッピングテンプレートでは便利な独自関数が用意されているのですが、Amazon API Gateway では標準 VTL が用意しているものしか使えないようなので (公式ドキュメントを見た限りでは) 、AWS AppSync の方がやや融通は利きやすいという印象でした。 本記事が皆様のお役に立てれば幸いです。
アバター
こんにちは、SCSK 木澤です。 SCSKでは、生成AIがより高精度の回答を出力できるRAG環境を、お客様AWSアカウントに構築できるテンプレートを提供する S-Cred+ InfoWeaveオプションを5月より提供開始 しました。 生成AI RAGソリューション InfoWeave|SCSK株式会社 生成AI RAGソリューション(InfoWeave(インフォウィーヴ))は、S-Cred⁺ ※ の生成AIオプションサービスです。 www.scsk.jp 本記事では AWS Summit Japan 2024の当社ブース内で講演した内容をベースに、本サービスの特徴等などについて解説します。 なお本サービスについては7/23にウェビナーを開催しますので奮ってご参加下さい。 [AI活用紹介セミナー] AWSとRAG構築テンプレで社内チャットボットを始めよう 本セミナーでは、AWSとRAG構築テンプレート「InfoWeave」を活用して社内チャットボットを簡単に始められる方法をご紹介いたします。 さらに、今年6月に開催されるAWS Summit Japan 2024のアップデート情報とあわせてA... www.scsk.jp AWS Summit Japan 2024ミニシアター資料 ミニシアターにて講演した内容はこちらです。 私は 6/20に1回と、(急遽)6/21の午前中に2回、合計3回発表いたしました。聴講頂いた皆様、ありがとうございました。   InfoWeaveの概要 InfoWeaveは当社のAWS複合基盤サービス、S-Cred+のオプションとして提供されています。 S-Cred+についてはこちらをご覧下さい S-Cred+プラットフォーム S-Cred+プラットフォームとはアプリケーション開発やサービス提供を最適な形で実現する複合基盤サービスです www.scsk.jp S-Cred+では、単なる運用基盤(MSP)に留まらず、環境構築テンプレートや、SCSK自社開発のローコード開発ツール等を組み合わせることによって、AWS上でのシステム/サービス開発をより迅速に行えるよう構成されています。 今回提供を開始したInfoWeaveは、この「システム環境構築テンプレート」の一種として提供を始めたものとなります。 生成AIがより高精度の回答を出力できるRAG環境を構築できるテンプレートを提供しますので、お客様は速やかに(※)独自ナレッジを含んだチャットボットを利用できるようになります。 利用料金は以下の通りです。 初期料金:600,000円(AWSアカウント単位) 環境構築代行:60,000/回(当社側でテンプレート展開を代行する場合のみ) ※申込(契約)後、利用開始まで3営業日。テンプレートのデプロイは概ね1時間程度 RAGについて さて、ご存じの方も多いと思いますが、RAGについて簡単におさらいしたいと思います。 生成AIのチャットボットを利用したことがある方も多いと思いますが、思ったよりも回答精度が良くないと感じることがあるでしょう。 大規模言語モデル(LLM)は、過去のある時点の情報を基に学習しているため、最新の情報は回答できません。 また、より専門的な情報や組織内の情報を基にした回答をして欲しい場合もあるでしょう。 そうした場合に回答精度を高める手段の一つして利用できるのが、RAG(Retrieval-Augmented Generation)となります。 LLMへのインプットとして関連情報を付加することで、より高精度な回答を得ることができるようになります。 InfoWeaveの特徴 さて環境構築テンプレートを利用し速やかにRAG環境を立ちあげることができるInfoWeaveですが、特徴として以下が挙げられます。 既存ドキュメントの活用 環境構築後、学習用ドキュメント格納用のS3バケットが1つ用意されます。 お客様はここにドキュメントを放り込むだけ独自ナレッジを利用したチャットボットを立ちあげることができます。 (テキストやMS-Office系、PDFなど一般的なドキュメント形式に対応。画像等マルチモーダルは現時点で非対応) 速やかにRAG環境を立ちあげることができる 利用開始(契約)後、3営業日にて環境構築テンプレートが提供されます。 テンプレートをデプロイすることで概ね1時間程度でチャットボットのUIも含めて提供されますので、  ① テンプレートをデプロイ  ② ユーザーを追加  ③ 既存ドキュメントを放り込む この一連の流れだけですぐにRAG環境を利用することができます。 またチャットボットだけでなくAPI機能も提供されるので、既存システムとの連携も容易に行うことができます。 無制限に環境作成が可能 環境構築テンプレートはAWSアカウント単位で提供されます。 よって当該AWSアカウント内では追加料金なくRAG環境を立て放題となります(AWSリソース料金は発生します) これにより、業務ごと・部署毎に独自の専門的なRAG環境を立ちあげることができます。 要件に応じて選択可能 大規模言語モデル(LLM)は、Amazon Bedrock上のAnthropic Claude(各種)および、OpenAI GPT-4から選択可能です。 RAG用のベクトルデータベースについては、Amazon Kendraあるいは外部サービスのPineconeを選択可能です。 セキュリティ重視でAWS内に閉じたい場合やコスト重視の場合など、要件に応じて構成を選択できる特徴があります。 利用者の権限に応じて回答が変化 これがRAGを選択する最大の特徴かもしれません。 RAGでは関連情報を付加してLLMに問い合わせるといった仕組みであることから、利用者の権限によって回答内容を変えることができます。これによって以下のような仕組みが可能になります。      社内 からの問い合わせ:社外秘の資料を用いて詳細な回答を行う 社外 からの問い合わせ:社内ナレッジを利用しない回答を行う Knowledge bases for Amazon Bedrockとの違い AWSでは同様に簡単にRAG環境を構築できる Knowledge bases for Amazon Bedrockが提供されていますが、違いは以下となります。 ① 標準でWeb ChatbotのWeb UIが提供されすぐに利用できる ② 選択できるLLMや検索用DBの幅が広い ③ 権限による回答の制御ができる InfoWeaveのユースケース 先述の特徴を持つInfoWeaveですが、以下のようなユースケースに活用可能です。 ヘルプデスクの業務効率化 専門分野・業務向けのチャットボット 社内ロール(権限)に応じた回答   アーキテクチャ 少しだけで恐縮ですが、アーキテクチャの話に触れたいと思います。 InfoWeaveの構築テンプレートは当社側のサービス提供環境よりAWS Service Catalogを通じて提供されます。 デプロイされるサービスは主なものとして以下があります。 Amazon S3(ドキュメント格納用) Amazon ECS , AWS Fargate(APIサーバー、Chatbot UI コンテナ、管理機能 各コンテナ) Amazon Bedrock(※LLM) Amazon Kendra(※RAG用データベース) DynamoDB(データストア) Application Load Balancer ※利用を選択した場合 コンテナイメージも弊社側管理のECRリポジトリから提供され、適宜更新される予定です。   注意点 本サービスはSCSKの複合基盤サービス、S-Cred+のオプションとして提供されており、S-Cred+の契約が必須となります。 AWS Service Catalogによるテンプレートやコンテナイメージの展開にあたり、AWSアカウントを弊社の管理基盤の管理下にする必要があり、このような仕様としております。 このような制約は有るものの、InfoWeaveは独特の特徴があるサービスとなりますので   最後に:AWS Summit Japan 2024を終えて AWS Summit Japan 2024が終わりましたね。 私は当社出展のリードとしてここ数ヶ月注力してきました。 細かい反省点は多いのですが、今はとにかく大きなトラブル無く終了できてホッとしています。 当社の出展内容は、川原さんのレポートをご覧下さい。 AWS Summit Japan 2024に出展しました! 6月20日~21日の2日間にわたり、幕張メッセで開催されたAWS Summit Japan 2024に出展しました。SCSKはプラチナスポンサーとして、スポンサーセッションとブースを出展し、大変多くの方々にご来場いただきました! blog.usize-tech.com 2024.06.27 私は2日間、概ねブース周辺におりました。たくさんの方に来訪いただき本当に感謝しております。 また夜はHUB周辺に出没し、いろいろな方との交流を深めることができました。 こちらでお会いした方々にも感謝したいと思います。 なお、お陰様で今年の表彰も継続して頂戴することができました。 AWS Ambassadors Japan AWS Top Engineers Japan AWS All Certfications Engineers 今回のイベントを成功させるにあたっては、社内外の皆様の協力無くしてなし得ませんでした。 この点においても感謝ですし、一個人としてはこの経験を糧に、今後も邁進して行ければと思います。 全ての皆様に御礼まで。ありがとうございました。
アバター
こんにちは。SCSK株式会社の上田です。 2024年6月4日に最新バージョンであるZabbix 7.0 LTSがリリースされ、様々な新機能が追加されました。 今回は、追加された新機能の中から、便利な機能をピックアップしてご紹介します。 Zabbixとは まずはZabbixの説明を簡単にさせていただきます。 Zabbixは、エンタープライズ対応のオープンソース統合監視ツールです。 サービスやそれを支える ITシステム(サーバ、ネットワーク機器等)の状態を把握し、障害の予兆やサービスへ影響を及ぼす事象が発生した際に、システム管理者やオペレータに通知を行うオープンソースの統合監視ソリューションです。 数万デバイス規模のエンタープライズ環境でも多数の稼動実績を誇っています。 Zabbixの詳細情報については、下記リンクよりご確認ください。 Zabbix :: The Enterprise-Class Open Source Network Monitoring Solution ZabbixはITインフラストラクチャ・コンポーネントの可用性やパフォーマンスを監視するためのエンタープライス向けソフトウェアです。Zabbixはオープンソース・ソフトウェアとして開発されており、無料でダウンロードいただくことが可能です。 www.zabbix.com 新機能の紹介 ここからは、新機能をカテゴリごとに紹介していきます。 Zabbixプロキシの新機能 大規模な環境で使われているZabbixプロキシについて、2つの新機能がリリースされました。 プロキシの負荷分散と高可用性 Zabbix 6.0ではサーバのHAが可能でしたが、7.0では プロキシもHAと負荷分散に対応 しました。 プロキシグループ という新たな概念が登場し、監視対象ホストをグループ内で自動的に分散して監視できるようになりました。 一つのプロキシがダウンした場合でも、残りのプロキシに監視を振り分けることが可能です。 プロキシのメモリバッファ 従来は必須だったヒストリデータのDB書き込みが、 プロキシメモリ内から直接Zabbixサーバに送信できる ようになりました。 保持方式は以下の3種類から選択可能です。 方式 機能 hybrid 正常時はメモリから送信、バッファフル時やプロキシ停止時はDBに書き込み memory DBへの書き込みは一切行わず、停止時のデータ保証はなし disk メモリを使用せず、従来通りDBで管理 WEB機能の追加 ZabbixのWEBインターフェース関連で、いくつかの新機能がリリースされています。 新ウィジェットの追加 新しいウィジェット が利用可能になりました。その中からいくつかを実際の画面付きでご紹介します。 ウィジェット 機能 Gauge(ゲージ) 単一アイテムの値をスピードメータ形式で表示 Pie Chart(円グラフ) 単一/複数アイテムの値を円グラフで表示 ハニカム(ハチの巣) アイテムの値を色分け可能な六角形セルで表示 新機能①:ゲージ 新機能②:円グラフ   新機能③:ハニカム 定期レポート機能の拡張 6.0で試験的に導入されていた定期レポート機能が、7.0で正式リリースとなりました。 1ページだけでなく、 複数ページのPDF出力が可能 になっています。 ブラウザ監視の追加 新しいアイテムタイプ「 ブラウザ 」が追加されました。こちらは別記事で検証しておりますので、是非ご覧ください。 Zabbix 7.0 新機能検証 (ブラウザモニタリング編) Zabbix 7.0 の新機能について検証しています。今回はブラウザモニタリングでZabbixの「キュー概要」画面を監視しています。 blog.usize-tech.com 2024.06.28 多要素認証(MFA)機能の追加 Zabbixへのログインに MFA認証 が利用可能になりました。ワンタイムパスワードとDuo認証に対応しています。 こちらも別記事で検証しておりますので、是非ご覧ください。 Zabbix 7.0 LTS 新機能:多要素認証機能 (Duo認証) を利用してみた 2024年6月に最新バージョンであるZabbix 7.0 LTSがリリースされました。Zabbix 7.0の新機能である、多要素認証機能(Duo認証)の利用方法をご紹介いたします。 blog.usize-tech.com 2024.06.17 パフォーマンス改善 Zabbixのパフォーマンスを向上させる改善も行われています。 ポーリングの高速化 Pollerプロセスが並列実行できるようになり、 ポーリング処理が高速化 されました。 こちらも別記事で検証しておりますので、是非ご覧ください。 Zabbix 7.0 新機能検証 (ポーリングの高速化編) Zabbix 7.0 の新機能について検証しています。今回はデータ収集処理の改善について検証しています。 blog.usize-tech.com 2024.06.18 ネットワークディスカバリの動作改善 ネットワークディスカバリの処理も並列実行できるようになり、 ネットワークディスカバリが高速化 されました。 従来と比べておよそ10倍~100倍のパフォーマンスと謳われています。 その他の追加機能 Zabbix API 経由で Zabbix サーバにデータ送信可能 history.pushメソッドを使うことで、 API経由でZabbixサーバにデータ送信可能 です。 これにより、 Zabbix agentが入っていないホスト (例えばIoTデバイスなど) でも監視を行うことが可能 になりました。 アイテム名のユーザーマクロサポート機能復活 アイテム名、アイテム プロトタイプ名で、ユーザーマクロが使える ようになりました。 こちらは、Zabbix 6.0で廃止された機能でしたが、Zabbix 7.0になって復活しました。   その他にも、いくつかの新機能が搭載しています。 詳しくは以下の公式サイトをご参照ください。 What's new in Zabbix 7.0 LTS www.zabbix.com まとめ Zabbix 7.0の新機能を紹介しました。様々な機能が追加されていますので、是非Zabbix 7.0を試してみてください。 「 Zabbix 7.0を新規にインストールしてみたい 」「 既存のZabbixからバージョンアップしたい 」という方は、こちらの記事も参考にしてみてください。 Zabbix 7.0 LTSをインストールしてみた 最新バージョンであるZabbix 7.0 LTSがリリースされましたので、AWS上にインストールしてみたいと思います。 また、インストールするために必要な手順を本記事にて記載いたします。 blog.usize-tech.com 2024.06.12 Zabbix 5.0 LTS から 7.0 LTS へ簡単にバージョンアップしてみた Zabbix 5.0 LTS から 7.0 LTS へバージョンアップしてみました blog.usize-tech.com 2024.07.04 今回は概要だけでしたが、新機能を検証した記事を順次投稿していく予定です! 最後まで読んでいただき、ありがとうございました。   最後に・・・ 弊社ではZabbix関連サービスを展開しています。以下ページもご参照ください。 ★SCSK Plus サポート for Zabbix★ SCSK Plus サポート for Zabbix 世界で最も人気のあるオープンソース統合監視ツール「Zabbix」の導入構築から運用保守までSCSKが強力にサポートします www.scsk.jp ★YouTubeに、SCSK Zabbixチャンネルを開設しました!★ SCSK Zabbixチャンネル 本チャンネルでは、SCSK株式会社でのZabbixに関するトレンド/事例紹介などを動画にまとめて取り上げております。 最新のトピックについては、以下の弊社HPもしくはツイッターアカウントをぜひ参照ください。 ツイッターアカウント: www.youtube.com ★X(旧Twitter)に、SCSK Zabbixアカウントを開設しました!★ x.com X.com
アバター
こんにちは。SCSK株式会社の安藤です。 2024年6月4日にリリースされた最新バージョンであるZabbix 7.0 LTSへ、5.0 LTSから簡単にバージョンアップしてみたいと思います。 ※新規インストールの場合は、以下の記事を参照ください。 Zabbix 7.0 LTSをインストールしてみた 最新バージョンであるZabbix 7.0 LTSがリリースされましたので、AWS上にインストールしてみたいと思います。 また、インストールするために必要な手順を本記事にて記載いたします。 blog.usize-tech.com 2024.06.12 Zabbixとは まずはZabbixの説明を簡単にさせていただきます。 Zabbixは、エンタープライズ対応のオープンソース統合監視ツールです。 サービスやそれを支える ITシステム(サーバ、ネットワーク機器等)の状態を把握し、障害の予兆やサービスへ影響を及ぼす事象が発生した際に、システム管理者やオペレータに通知を行うオープンソースの統合監視ソリューションです。 数万デバイス規模のエンタープライズ環境でも多数の稼動実績を誇っています。 Zabbixの詳細情報については、以下をご確認ください。 Zabbix :: The Enterprise-Class Open Source Network Monitoring Solution ZabbixはITインフラストラクチャ・コンポーネントの可用性やパフォーマンスを監視するためのエンタープライス向けソフトウェアです。Zabbixはオープンソース・ソフトウェアとして開発されており、無料でダウンロードいただくことが可能です。 www.zabbix.com   バージョンアップ手順 早速、Zabbix5.0から7.0へバージョンアップしていきたいと思います。 今回の構成 今回の構成は以下のとおりです。 ZABBIX VERSION: 5.0.42 OS DISTRIBUTION: Red Hat Enterprise Linux OS VERSION: 8.2 DATABASE: MySQL 8.0.36 WEB/AP SERVER: Apache 2.4.37 / PHP-fpm 7.2.24 SELinux: 無効 Firewalld: 無効   関連ミドルウェアのバージョンアップ 各ミドルウェアの対応バージョンは以下の通りです。事前に、Zabbix 7.0の動作が可能なバージョンまで、バージョンアップしておく必要があります。   5.0 LTS 7.0 LTS Apache 1.3.12 or later 2.4 or later PHP 7.2.0 or later 8.0.0 – 8.3.X MySQL 5.7.X – 8.4.X 8.0.30 – 8.4.X Zabbix 7.0リポジトリの設定とZabbixのバージョンアップ Zabbix 7.0 のリポジトリを設定します。 # Zabbix 7.0 リポジトリの設定 rpm -Fvh https://repo.zabbix.com/zabbix/7.0/rhel/8/x86_64//zabbix-release-7.0-1.el8.noarch.rpm dnf clean all 次に、Zabbix関連のパッケージをバージョンアップします。 # Zabbix関連パッケージのバージョンアップ dnf update zabbix-agent zabbix-apache-conf zabbix-server-mysql zabbix-web zabbix-web-japanese zabbix-web-mysql インストールされているZabbixパッケージのバージョンを確認します。 # インストールされているZabbixパッケージのバージョンの確認 dnf list --installed |grep zabbix これだけで完了です。とっても簡単です! Zabbix Serverのサービス再起動とデータベースのアップグレード Zabbix Serverのバージョンアップ後、Zabbix Serverのサービスを再起動すると、自動的にZabbixのデータベースのアップグレードが開始されます。データベースのアップグレード時には、ログに以下のような出力があります。 2623:YYYYMMDD:194015.890 using configuration file: /etc/zabbix/zabbix_server.conf 2623:YYYYMMDD:194015.941 current database version (mandatory/optional): 05000000/05000007 2623:YYYYMMDD:194015.942 required mandatory version: 07000000 2623:YYYYMMDD:194015.942 mandatory patches were found 2623:YYYYMMDD:194015.943 starting automatic database upgrade 2623:YYYYMMDD:194016.159 completed 0% of database upgrade 2623:YYYYMMDD:194017.273 completed 1% of database upgrade 2623:YYYYMMDD:194019.414 completed 2% of database upgrade 2623:YYYYMMDD:194021.865 completed 3% of database upgrade ・・・ 5.0 LTSのデータベースバージョン「05000000」であるのに対し、7.0 LTSの「07000000」が必要であると、出力があります。 その後、自動的にデータベースのアップグレードが開始されていることがわかります。   バージョンアップ中の挙動 バージョンアップ中に、以下のような挙動をすることがあります。 データベースのアップグレード中にWeb管理画面を表示 データベースのアップグレード中にWeb管理画面にアクセスすると、Zabbixデータベースのバージョンが要件を満たしていない旨のエラーメッセージが表示されます。 データベースのアップグレードを中断 データベースのアップグレードが中断した場合は、Zabbix Serverのサービスを再起動することで、中断した箇所からアップグレード処理が再開されます。   まとめ Zabbix5.0から7.0へのバージョンアップは、5.0→6.0→7.0と段階を踏むことなく、5.0から7.0へ、一度で簡単にバージョンアップすることができました。 最後まで読んでいただき、ありがとうございました。   最後に 弊社ではZabbix関連サービスを展開しています。以下ページもご参照ください。 SCSK Plus サポート for Zabbix SCSK Plus サポート for Zabbix 世界で最も人気のあるオープンソース統合監視ツール「Zabbix」の導入構築から運用保守までSCSKが強力にサポートします www.scsk.jp   ★YouTubeに、SCSK Zabbixチャンネルを開設しました!★ SCSK Zabbixチャンネル 本チャンネルでは、SCSK株式会社でのZabbixに関するトレンド/事例紹介などを動画にまとめて取り上げております。 最新のトピックについては、以下の弊社HPもしくはツイッターアカウントをぜひ参照ください。 ツイッターアカウント: www.youtube.com   ★X(旧Twitter)に、SCSK Zabbixアカウントを開設しました!★ x.com x.com
アバター
こんにちは。SCSK 稲葉・川原・間世田です。 6月20日と21日に幕張メッセで開催された「 AWS Summit Japan 2024 」に参加してきました!本イベントは、日本最大のAWSに関する学びの場であり、2日間にわたってさまざまなセッションや展示が行われました。 私たち3名で各セッションやブースを回りましたので、その感想やレポートを共有したいと思います。 イベント概要 AWS Summit Japan 2024は、日本最大の“AWS を学ぶイベント”として、多彩なプログラムが用意されていました。 主に以下のような内容で構成されております。 基調講演 150を超えるセッション 250を超えるEXPOコンテンツ DeepRacerリーグや開発者向けワークショップ、さまざまな AWS の質問をすることができる「Ask an Expert/Ask an Speaker」   基調講演やセッションなどには、AWSを導入しているパートナー企業やユーザー企業なども参画しています。自社で導入してきたAWSの知見などを発表し、他のAWS利用者がそれを見て学ぶことができるイベントになっております。 基調講演 1日目:AWSと創る次の時代 1日目の基調講演では「AWSと創る次の時代」という題で、既に活用されているAIの活用事例について発表され、後半にはAWSの新サービスの発表も行われました。 AIの活用事例では、画像認識を使用して養殖している魚の病原体を検知したり、データの傾向から病気の予兆を検知するなどさまざまな活用事例が紹介されており、非常に興味深かったです。 また善のためのAIが強調されていて、持続可能な社会の実現に向けた人類の課題に対して、AIでどのように課題を解決するかといった内容が多かった印象です。 後半のAWSの新サービス発表では、AI系のサービスが多く発表されました。 特にClaude3の東京リージョン対応やAmazon Q Businessの日本語版対応が、会場を大きく盛りあげていました。 2日目:ビルダーとテクノロジーが加速する次のイノベーション 生成AI および AI/ML マーケット戦略担当のラフール パサック氏が登壇され、生成AIによる新しい時代を、それらの実現に向けての AWS の戦略や支援を、これまで日本のお客様と創出してきたイノベーション事例とともに紹介されました。 セッションでは、複数の業界におけるクラウドテクノロジーの革新が焦点となりました。金融業界では、SBIがインフラストラクチャをコード化し、効率化を図っています。自動車業界では、TIER 4が大量のテスト資料から開発シミュレーションを作成し、エッジコンピューティングへの展開を推進しています。通信業界では、docomoが5Gの商用展開でAWSを選定し、消費電力を大幅に削減する取り組みを行っています。 また、プロジェクトKuiperによる衛星群の運用や、ANAがAWSにデータ分析基盤を移行し、グループ全体のデータを集約・分析することで競争力を高めています。これらの事例は、データの活用が企業の競争力を飛躍的に向上させ、AIがビジネスの差別化に重要な役割を果たしていると感じました。 さらに、AWSのLLM開発支援プログラムや新しい推論コンポーネントの導入が、デジタル革命が多岐にわたる産業で進行していることが強調されました。これにより、企業は柔軟に業務を変革し、進化を続けることが可能になっています。 電通とJR東海の事例も取り上げられ、電通はAIを活用したマーケティング戦略の展開や、顧客のデータドリブンな分析を通じたサービスの最適化を進めています。一方、JR東海はリニア中央新幹線の運行管理において、地上設備からのリアルタイムデータを活用し、運行計画の最適化と運行監視の効率化を図っています。これらの取り組みは、AWSのテクノロジーを駆使してデータ中心の革新を実現し、それぞれの業界において革新的な成果をもたらしています。 セッションの締めくくりでは、ラフール氏から「あなたが作り上げるのはどんな魔法ですか?」と問いかけられました。これからもAWSを活用した革新がさらに進展し、ビジネスにおける魔法のような変革をもたらすことが期待される素晴らしいセッションでした。   セッション 1日目 Amazon Bedrockの活用によるデジタル教育サービスの生成AI機能拡張 パートナーセッション 【スピーカー】中村 寿志 氏 株式会社 学研メソッド 取締役 学研様の生成AI活用事例についてお話しされていました。 学研様では生徒が学習するためのWebシステムを運用しており、学習情報の取得や独自にチューニングした分析システムで学習情報を分析していました。 このWebシステムに対し、生成AIを活用するアイデアがお話しされていました。 学習情報を分析した結果を生成AIが生徒一人に合わせてフィードバックしたり、生徒の質問に生成AIアシスタントが対応し生徒一人ひとりに合わせたヒントを出したり、生徒に合わせた類題を提示したりとたくさんのアイデアがお話しされていました。 このセッションで機械と人間のインタフェースとして生成AIは特に有用だなと感じました。 自社データを用いた生成AIの活用事例 AWSセッション 【スピーカー】中島 佑樹氏 アマゾン ウェブ サービス ジャパン合同会社 技術統括本部 エンタープライズ技術本部 本セッションでは、生成AIの導入におけるデータの重要性と活用戦略について事例を用いて詳細に解説していました。 まず、生成AIを効果的に活用するためには、良質なデータが不可欠であり、データ適用方式として、検索拡張⽣成 (RAG)、Fine-turning、継続的事前学習の3つの方法が紹介され、それぞれのメリットや具体的な事例が示されました。 具体的な事例としては、RIZAPテクノロジーズ様が社内問い合わせ検索システムを生成AIで構築したケースが紹介されました。このシステム導入により、従業員の問い合わせ対応工数が大幅に削減され、業務効率が向上しました。また、カラクリ株式会社様がカスタマーサポート向けに誠実かつ自然な返答を提供する生成AIを3日で学習させた事例も取り上げられ、生成AIの実用性が強調されていました。 また、データ戦略の重要性について、生成AIを活用するための3つの観点が示されました。 独⾃のカスタムデータを使⽤して AI アプリケーションをする 独自データを活用して他社との差別化を図る。 既存のデータ基盤上で⽣成 AI を活⽤する 既存のデータ基盤を活用して生成AIワークロードに適用。 生成AIアプリケーションを監査する 生成AIアプリケーションの監査機能をONにして責任あるAIを実践。 特に、責任あるAIの実践には生成AIアプリケーションの監査機能をONにすることが第一歩として重要であると強調されました。AWSのリソースを活用し、透明性や公平性を確保するための具体的な方法も提供されています。 このセッションを通じて、生成AIの導入にはデータの質と戦略が非常に重要であることを再認識しました。特に、実際の事例を通じて、生成AIがどのように業務効率を向上させるかが具体的に理解できました。今後のビジネスにおいて、生成AIの活用がどのように進化し、どのように実用化されるのか非常に楽しみです。AWSの提供する多様なツールとサポートを活用することで、企業はより効率的に生成AIを導入し、競争力を高めることができるのだと思いました。 生成AIが変える、データアナリティクス AWSセッション 【スピーカー】西澤 祐介氏 アマゾン ウェブ サービス ジャパン合同会社 プロフェッショナルサービス本部 ビッグデータコンサルト 生成AIがデータアナリティクスと連携することで何ができるようになったのかお話しされていました。 生成AIとAmazonDataZoneの連携では、データの説明やデータの分析例などを出力でき、AWS Glueとの連携では、自然言語でETLジョブを作成できるとお話しされていました。 また、生成AIとAmazon Redshift クエリエディタが連携することで、自然言語からSQLを生成してデータ分析可能だとお話しされていました。 Quicksightは生成AIと連携することで多くの恩恵を受けられるとお話しされていました。 自然言語でダッシュボードや計算フィールドを作成できたり、ダッシュボードに対してQ&Aインタフェースを提供し質問できるようになると紹介されていました。他にはデータからストーリーテリングを生成できるようになると紹介されていました。 このセッションでは特にQuicksightと生成AIの連携のお話しが興味深く、今後グラフを使用して発表するときはQuicksightと生成AIをぜひとも使用したいと思いました。 AWS 環境におけるセキュリティ調査の高度化と生成 AI 活用 AWSセッション 【スピーカー】 勝原 達也氏 アマゾン ウェブ サービス ジャパン合同会社 セキュリティソリューションアーキテクト AWS環境でのセキュリティインシデント対応をどのように高度化するかについてのセッションでした。 セッションのポイントを以下にまとめました。 AWSの特性がセキュリティ分析を支える 高い可視性 :AWSのサービスは詳細なログを提供し、システムの状態を把握しやすくしています。 柔軟な自動化機能 :自動化により、迅速かつ効率的なインシデント対応が可能です。 Amazon GuardDuty :脅威検知に特化したサービスで、インシデントの初期検知を担います。 Amazon Detective :詳細なログ分析を行うサービスで、脅威の根本原因を特定します。 セッションでは、仮想的なセキュリティインシデントを通じて、どのように脅威が検知されるかを具体的に説明されていて、GuardDutyが検知する脅威の種類や、Amazon Detectiveを用いた詳細なログ分析の方法が紹介されました。具体的な脅威検知の流れとしては、次のようなプロセスが示されていました。 GuardDutyの検知 :偵察活動、インスタンス侵害、アカウント侵害などの脅威を検知。 Detectiveでの詳細なログ分析 :検知された脅威を基に、詳細なログ分析を実施。 生成AIの活用 :自然言語でのクエリ生成により、分析作業が効率化。 生成AIはセキュリティ専門家を即座に置き換えるものではないですが、その活用により専⾨家は優れた成果を得ることができると述べられました。AWSのナレッジと自社固有の構成情報を基に、生成AIが優れたインサイトを提供し、セキュリティチームを強力にサポートしてくれます。 AWSのセキュリティサービスと生成AIの組み合わせにより、セキュリティ分析がより効率的かつ効果的に行える未来が見えてきたと思います。今後もAWSのセキュリティサービスの進化に注目していきたいです。 2日目 なぜ、AWS 活用のメリットを実感できないのか? ~内製化・運用改善の考え方~ パートナーセッション 【スピーカー】浅野 佑貴氏 株式会社BeeX 事業開発室 AWS Partnerから見た内製化支援の活用方法のナレッジを共有するセッションでした。 まず、内製化支援の活用方法を考える前に、AWSのメリットを実感できない理由として以下が挙げられていました。 継続的な変更・改善を行うためのコスト・プロセスを確保していない 「どの様な課題を解決することに使えるアップデートか?」を考えていない 前提として、AWSを活用して実現したいことは「ビジネス環境の変化に追随し、最新IT技術を取り込む」ことです。 しかし現状は、AWSサービスのアップデートが想像以上に速く・多く、自分たちに必要なアップデートが何か見極められなかったり、継続的な構成変更を計画せず、移行初期からのメリット享受を優先してしまったりすることが多いようです。 そこから考えると、内製化を進めるためのポイントは以下となります。 改善のための専任リソース(Teams)を確保する 通常業務を行ったまま改善業務を行うことは負担が大きいです。そのため専任Teamが必要とのことですが、会社の”理解”を得ることが個人的には一番難関だと感じました。セッションでも、Teamが機能するために必要なカルチャー/会社の仕組みの整備には時間がかかるため、3つめのポイントの実践が推奨されていました。 不足する役割・スキルをサポートするパートナーとの協業 必ずしもAWSサービス固有の深い知識が必要な訳では無いです。より重要なのは、担当システムの課題がどの様な技術課題なのかを把握し、どの様な課題を解決することに使えるかを考えることです。CCoEによるナレッジ収集・共有は組織的なソリューションの一つですが、ここは専門家(AWSパートナー)のナレッジを活用することで補うことができます。 取り組みレベルは段階的に成熟させる 内製化とは自社リソースですべて実施するものではなく、どこまでを自社で行うかを見極めることが必要です。例として3段階のアプローチが挙げられており、自社で行う範囲として、Lv1:企画の一部⇒Lv2:企画+開発の一部⇒Lv3:企画から運用まで また、どのレベルが正解といったわけではなく、内製化を行うシステム・領域によってレベルを使い分けることが重要とのことでした。 弊社も内製化支援を行っており、私も支援を行った経験があったため、非常に参考となるセッションでした。 AWS技術支援 テクニカルエスコートサービス|SCSK株式会社 テクニカルエスコートサービスはAWSの導入に関して課題に直面されているお客様にAWS認定資格保有者が参画いたします。 www.scsk.jp NTT の生成AI「tsuzumi」とともに挑む新たなチャレンジ(AWS LLM 開発支援プログラムを 用いた技術検証等) パートナーセッション 【スピーカー】爪長 美菜子氏 日本電信電話株式会社 研究開発マーケティング本部 執行役員 マーケティング部門長 NTT版LLM「tsuzumi」の紹介と活用領域、案件対応から浮き出たLLM利活用時の主な課題が伝えられたセッションでした。 「tsuzumi」の特徴として、軽量・高い言語性能・高カスタマイズ性・マルチモーダル性を挙げていました。特にパラメタサイズは、GPT-3の1/25である7Bサイズと非常に軽量のようです。驚くべきことに、「図表・イラストの読解(infoVQA)」と「複数画像の複合読解(SlideVQA)」ではGPT-3.5、GPT-4を凌ぐ精度となっていました。 LLM利活用時の主な課題として「精度」・「精度のゴール設定」・「データ整備」の三本を挙げていました。 精度 精度40%〜70%から出発すること チャンキング、検索手法の精査、pre-retrieval等で精度向上が必要であること 精度のゴール設定 PJ開始時に精度の定義合わせが重要であること データ整備 フォーマットの違い等でのデータ整備にコストがかかる PoCを行っている方も多いですが、データ整備に課題を感じている方も多いのではないでしょうか。 私もデータ整備を行ってくれる生成AIないかなぁ〜と日々感じています… 余談ですが、セッション冒頭で名前の由来も話されており、「雅楽で用いられる鼓が演奏の流れを統率する役割を担っていることになぞらえ、これからの自然言語処理技術の発展をリードしていく存在をめざす」とのことでした。日本らしく、素敵な名前です。 AIアプリ開発プロジェクトの始め方 AWSセッション 【スピーカー】⼤渕 ⿇莉氏 アマゾン ウェブ サービス ジャパン合同会社 サービス&テクノロジー事業統括本部 セッションの冒頭では、AIの基本的な概念とそれらの違いについてお話されていて、特に生成AIについては、テラバイト規模のデータで学習し、追加学習なしに人間と同等のコンテンツ生成能力を持つことが強調されました。AIの最大の特徴として「AIは間違えることがある(精度100%にはならない)」という点が挙げられ、入力が決まれば出力の「予測値」が決まるため、単純なロジックでは計算できない現象を予測する際に使われることが多く、必ず誤差が生じることが説明されました。 また、生成AIは、プロンプトエンジニアリングを通じて多様な表現形式や応答の微調整が可能です。しかし、プロンプトが肥大化する場合にはファインチューニングの検討が必要となります。 AIを自社アプリに組み込む具体的なステップは以下になります。 課題のフレーミング データ処理 モデル開発 モデルのデプロイ モデル性能監視 ビジネスゴールがないと、評価指標や評価データを作れず、AIが正しく機能しているかを評価できないため、ビジネスゴールの設定が非常に重要になります。 安全で信頼性の高い生成AIソリューションの実現には、生成AIを利用する際の入出力データの適切性を確保するためのガードレールやモデレーション機能が重要です。Amazon Bedrock や Amazon Rekognition などのAWSサービスを活用することで、より安全で信頼性の高い生成AIソリューションを構築することが可能となります。 このセッションを通じて、AIアプリ開発プロジェクトの始め方と、従来のAIと生成AIの違い、AWSが提供する豊富なAIサービスについて深く理解することができました。特に、ビジネスゴールの設定の重要性や、適切なAIサービスの選択が成功の鍵であると感じました。AWSのAIサービスを活用することで、AIアプリ開発がより身近で現実的なものになると感じました。 チームのつながりをInfrastructure as Codeでデザインする AWSセッション 【スピーカー】高野 賢司氏 アマゾン ウェブ サービス ジャパン合同会社 技術統括本部 ストラテジック製造グループ チームがDevOpsできるようになるにはどのような障壁を乗り越えないといけないのかというお話でした。 従来の分断されたチームでは、それぞれのチームがタスクの完了だけに注目し、フィードバック受け取って改善しなくなるという問題点がありました。 目標とするDevOpsできるチームは、コードをコミュニケーションの中心に置くことでフィードバックに基づいた継続的な改善を行うことができるチームとお話しされていました。 目標達成するためにはインフラストラクチャをコードで管理すること、バージョン管理ツールでコードを管理すること、チーム全員がコードを理解できることなどが挙げられていました。 DevOpsをできるようになるまでの手順を段階的に紹介されていたので非常に勉強になりました。 Amazon CodeCatalyst と Amazon Q で開発者の生産性を向上! – AI アシスタントの活用方法 – AWSセッション 【スピーカー】柳久保 友貴氏 アマゾン ウェブ サービス ジャパン合同会社 デジタルサービス技術本部 ISV/SaaSソリューション部 昨年11月のアップデートにて、Amazon CodeCatlyst での Amazon Q によるソフトウェア開発タスク支援が発表されており、本セッションではそのデモンストレーションが行われました。 Amazon CodeCatalyst、Amazon Q の機能開発 (プレビュー版) を発表 aws.amazon.com 具体的にはAmazon Q によって、単体テストの作成やPull Requestのコメント作成・レビューコメントの要約等です。驚くべきこと「Title」欄に一文記入するだけで、前述の処理の作成を行ってくれていました。エンジニア初心者でも簡単にアプリケーション作成を行えるでしょう。(生成AIのコードの正確性の理解は必要ですが。) また、「レビューコメント」の作成によって、大規模変更の際に大きくエンジニアの負担を減らすことができます。今までは大きな変更の際、差分が多くなってしまい、そのすべてを確認し、理解する必要がありました。この機能により、エンジニアの負担を大幅に削減することができます。 データセンターのラックぜんぶ抜く!SCSKだからできる脱オンプレの秘策とは? パートナーセッション 【スピーカー】岸岡 学氏 SCSK株式会社 クラウドサービス事業本部 事業推進部 クラウド営業課長 髙島 豊徳氏 沖電気工業株式会社 常務理事 情報責任者 本セッションでは、沖電気工業株式会社(OKI)のCIOである高島様と共に、実際のクラウド移行プロジェクトの具体的な取り組みと成功の秘訣について語られました。クラウドのメリットを理解し活用を進めようとする企業は多いものの、さまざまな理由で踏みとどまっている企業が多く存在するのが現実です。2日目の最後のセッションにもかかわらず、多くの方々が来場していて、クラウド移行に関する関心の高さを感じました。 沖電気工業株式会社様は広範な事業領域と高いセキュリティ要件を持つため、膨大な業務システムのクラウド移行には多くの課題がありました。特に、事業ごとに異なるシステム要件や古いシステムのモダナイズ、クラウド移行が難しいシステムが存在していました。さらに、2026年までに約800台のサーバ(100ラック相当)を含む現行データセンターの移転・移行が必要で、クラウド利用促進とシステム刷新を同時に進める必要がありました。 この課題に対し、ハード面、ソフト面、マネジメント面の三位一体のアプローチが成功の鍵となりました。 ハード面(設備/体制) 最新データセンター、自社プライベートクラウドとAWSへの直接コネクティビティを提供し、営業・技術一体となったデリバリ体制を整備したこと ソフト面(技術/サービス) オンプレミスも把握しているAWSスペシャリストによる全体計画、プロジェクト推進、最新技術への追随とAWS社と共同で立ち上げた移行アセスメント、移行仕分け、移行作業パッケージを利用した迅速で安心安全な移行 マネジメント面 当初の目的を定期的に経営レベルで見直し、共通ゴールをぶらさずに、現場メンバーがプロジェクトに専念できることを最優先したこと 今後は、クラウドシフト/サーバレス化、そしてアプリケーションのモダナイゼーションを目指しています。 今回のセッションを通じて、SCSKとOKI様がどのようにしてデータセンターの完全移行を実現したか、その具体的な施策と成功の秘訣を深く理解することができました。特に、SCSKのAWSに対する深い理解と高い技術力が、脱オンプレミスを実現する上で不可欠な要素であると強く感じました。 SCSKは、AWS戦略協業パートナーとして、トータルサポートを提供していて、豊富なサービスメニューと延べ2000を超えるAWS認定技術者が、お客様のクラウドジャーニーを最適なルートで案内しています。Lift & Shiftフェーズでの課題に対して、これまで培ったノウハウを活かし、ビジネスに必要なITサービスをフルラインナップで提供することができます。 クラウド移行を考えている企業にとって、今回のセッションは非常に参考になる内容でした。SCSKの技術力とサポート体制により、多くの企業が安心してクラウドへの移行を進めることができると確信しました。   EXPO AWS DeepRacer 白熱の戦いが繰り広げられていました。私が観戦したときは8秒台が決勝ラインでしたが、最終結果はどうなったのでしょう…?   AWS Village 生成AI・Developer・Industry・セキュリティのテーマごとに4つのエリアに分かれて、様々なソリューションの個々の基本的な機能から選定や組み合わせまで、実際に動くデモを見ながら学ぶことができました。 個人的に一番テンションがあがったのが、「 AWS Snowball Edge 」の展示でした。 他の方のレポートを見ると、触ったり持つこともできたようです。(持ち上げたかった!!!) 認定者ラウンジ AWS 認定ごとにシールがもらえました。品切れのため1枚しか貰えなかったので、来年は早めにラウンジへ行こうと思います。 その他の思い出 基調講演前に、田中知之(FPM)氏がウエルカムDJパフォーマンスを披露されており、厳かでありながら魅惑的かつ高揚感高まるステージでした。 (氏のRemix作品である、三日月サンセット -FPM EVERLUST Mix- を聞きながらこのレポートを書いていますが、最高です。) 先着でお弁当とクッションがもらえました。AWS Summitを通じて、クッションにはお世話になりました。 感想 疲れを忘れるぐらい、刺激的で素晴らしい体験でした。生成AIという技術革新の時代に生まれたことに改めて高揚感が高まっています。また、多くの企業がAWSを活用して次々と革新的なソリューションを生み出している様子を目の当たりにし、そのエネルギーを肌で感じることができました。 AWS Summit Japanは、素晴らしい学びを提供し、多くの人々にインスピレーションと知見を与える有意義な場でした。これからもAWSへの学びを深めていきたいです! 来年のAWS Summit開催を楽しみに待ちたいと思います!
アバター
こんにちは、広野です。 本題だけ挨拶抜きで冒頭に話します。本記事では、Amazon API Gateway と Amazon SES を Lambda 抜きで 連携する方法を紹介します。 はじめに 先月、AWS Summit Japan 2024 が開催されました。その中で、印象に残った AWS さんのセッションがありました。 「サーバーレス開発のベストプラクティス~より効果的に、より賢く使いこなすために~」 このセッションでは、サーバーレス開発のアーキテクチャ事例を数多く紹介してくれて非常に有用だったのですが、特に印象に残ったのは 「 AWS サービス間をプロキシするだけの Lambda 使用はやめましょう 」 というようなメッセージでした。 常々、私はサーバーレス開発において、コードやランタイムのメンテが必要になる AWS Lambda 関数が乱立することを負担に感じていました。また、昨今のアーキテクチャ時流では AWS Step Functions が AWS サービスの API を直接叩けるようになったり、Amazon EventBridge を活用したサービス間連携アーキテクチャの台頭があったりして、「とりあえず Lambda」から「脱 Lambda」に変わってきています。 そういう意味で、このメッセージには非常に共感を持つことができました。セッションでは Amazon API Gateway から 他の AWS サービスの連携も Lambda 関数抜きで行うアーキテクチャを紹介しており、やってみたくなりました。 私が題材に選んだのは、 Amazon API Gateway と Amazon SES の直接連携 です。現在主流のアーキテクチャでは、メールを送信する AWS Lambda 関数がメールのコンテンツを加工し、Amazon SES の API を叩く役割を持っています。しかしながら、加工と言っても文字列をちょこっといじるだけのようなもので、何らビジネスロジックがないケースが多いのではないかと思います。であれば、AWS Lambda 関数はいらんだろう!ということでチャレンジしたくなりました。 やりたいこと 本記事で紹介するアーキテクチャは、以前 jQuery でメール送信 API を叩くアーキテクチャを紹介した記事をベースにしています。その記事ではメール送信 API を Amazon API Gateway + AWS Lambda + Amazon SES で作成していたので、そこから Lambda を抜く!部分にフォーカスして執筆いたします。 ベースとなるアーキテクチャ、技術情報は以下リンクをご覧下さい。 フリーの HTML テンプレートと AWS を使って問い合わせフォーム付きサーバーレス WEB サイトをつくってみよう 本記事では、静的WEBサイトに jQuery で動的な機能を付加する例を紹介します。 blog.usize-tech.com 2022.07.14 前回記事の構成から Amazon API Gateway REST API は Amazon SES との直接連携をサポートしている。統合タイプの設定は AWS を選択する。 公開 WEB サイトの問い合わせフォームで使用するため、ユーザ認証はない。CORS はある。 CORS でハマるのが嫌なので、AWS CloudFormation でデプロイする。 WEB サイトから送信するデータは以下の JSON フォーマットとなっている。 { "subj": "件名", "name": "名前", "email": "xxx@xxxxxxx.com", "body": "問い合わせメッセージ本文" } 従来、このデータを AWS Lambda 関数にパススルーして、文字列加工したデータを Amazon SES に渡していた。AWS Lambda 関数がやっていたことは Amazon API Gateway REST API の「統合リクエスト」内、「マッピングテンプレート」で肩代わりさせる。 マッピングテンプレートは VTL (Velocity Template Language) で定義する。(AWS AppSync では多用するので AppSync 信者にはお馴染み) Amazon SES の API は SendEmail を使用する。 マッピングテンプレートをどう書くか AWS Lambda 関数でやっていたことを Amazon API Gateway のマッピングテンプレートに肩代わりさせるので、そこが肝になります。イメージしてもらいやすくするため、AWS Lambda 関数と対比して紹介します。 AWS Lambda 関数 細かい違いはあれど、だいたい以下のような AWS Lambda 関数 (Python) で Amazon SES を呼び出すと思います。 import json import datetime import boto3 def datetimeconverter(o): if isinstance(o, datetime.datetime): return str(o) def lambda_handler(event, context): try: # Define Variables ses = boto3.client('ses',region_name='ap-northeast-1') d = json.loads(event['body']) print({"ReceivedData": d}) RECEIVERS = [] RECEIVERS.append('xxxxx@xxxxxxx.xxxx') SENDER = 'xxxxxx@xxxxx.xxxxxx' # Send Email res = ses.send_email( Destination={ 'ToAddresses': RECEIVERS }, Message={ 'Body': { 'Text': { 'Charset': 'UTF-8', 'Data': 'NAME: ' + d['name'] + '\nMAILADDRESS: ' + d['email'] + '\n\nMESSAGE:\n' + d['body'] } }, 'Subject': { 'Charset': 'UTF-8', 'Data': d['subj'] } }, Source=SENDER, ReplyToAddresses=[d['email']] ) except Exception as e: print(e) return { 'isBase64Encoded': False, 'statusCode': 200, 'body': str(e) } else: return { 'isBase64Encoded': False, 'statusCode': 200, 'body': json.dumps(res, indent=4, default=datetimeconverter) } マッピングテンプレート マッピングテンプレートだと、以下のようになります。 ## API Gateway が受け取った引数を $inputRoot に格納する #set($inputRoot = $input.path('$')) ## メール本文の文字列加工 改行を入れたければここでリアルに改行すればよい(かなり違和感を感じるw) #set($tempbodya = "NAME: $inputRoot.name MAILADDRESS: $inputRoot.email MESSAGE: $inputRoot.body") ## Windows 環境からだと改行コードが CRLF で来ることがあるので、LF に置換しておく #set($tempbodyb = $tempbodya.replaceAll("\r\n", "\n")) ## メール本文は URL エンコードすること #set($body = $util.urlEncode($tempbodyb)) ## メールアドレスは URL エンコードすること #set($destination = $util.urlEncode("xxxxx@xxxxx.xxx")) #set($replyto = $util.urlEncode($inputRoot.email)) #set($source = $util.urlEncode("xxxxx@xxxxxx.xxxx")) ## 件名はエンコードしなくてよい、なぜか。エンコードするとエラーになる。改行が入っても通った。謎。 #set($subject = $inputRoot.subj) ## SES API 呼出はこのフォーマットで書く URL の続きに?付きでパラメータ指定するのと同じ形式 Action=SendEmail&Destination.ToAddresses.member.1=$destination&Message.Body.Text.Data=$body&Message.Subject.Data=$subject&ReplyToAddresses.member.1=$replyto&Source=$source AWS Lambda 関数では、URL エンコードなんて一切意識していなかったと思います。AWS が提供してくれる SDK がいい感じにデータを加工してくれていたものと思います。VTL は低級言語?なのか SDK をロードできないですし、組み込み関数も少ないです。ただ URL エンコードする関数 ($util.urlEncode) は用意してくれているので助かりました。 URL エンコードが必要な理由は、マッピングテンプレートから Amazon SES SendEmail API を呼び出すときに API の URL に続けてパラメータを書いて渡すためです。(想像) URL には使用してはいけない文字列、記号があり、UTF-8 の文字コードの文字列を URL で使用できる文字列、記号の範囲内におさまるようにエンコードする必要があります。それが URL エンコードです。 例えば、メールアドレスの @ は使えませんし、改行、日本語なんてもってのほかです。@ は %40 に、改行(\n) は %3A に置き換えられます。 メールの To だけでなく、Cc、Bcc ももちろん設定可能です。これらは複数指定できますが、仕様でそれぞれ 50 個までしか指定できません。To を複数指定するときは、Destination.ToAddress.member.1= のような記述を1始まりで50まで羅列させます。配列が使用できないので、このような書き方になります。AWS Lambda 関数では配列で SDK に渡していたので意識しなかった部分です。 VTL ではダブルクォーテーションとシングルクォーテーションで動きが異なるので、このサンプルコードにあるクォーテーションのまま使用することをお勧めします。 ここまで動く状態に到達するのに、情報が少なくて結構苦労しました。 他にも Amazon API Gateway の設定はあるのですが、メインはマッピングテンプレートでしたので、AWS CloudFormation テンプレートのところで補足いたします。 実際の動作 WEB サイトの問い合わせフォームから、問い合わせを送信します。 こんなメールが予め設定しておいた送信先メールアドレスに届きます。 AWS CloudFormation テンプレート 前回記事で紹介した AWS CloudFormation を修正したものを貼り付けます。一式、Amazon CloudFront や Amazon S3 なども含まれています。一応執筆時点で動いたことは確認済みです。 AWSTemplateFormatVersion: 2010-09-09 Description: The CloudFormation template that creates a static website hosting environment with a backend API for receiving emails from feedback form. # ------------------------------------------------------------# # Input Parameters # ------------------------------------------------------------# Parameters: SiteName: Type: String Description: Your Site name. (Not any upper case characters) Default: xxxxx MaxLength: 40 MinLength: 1 DomainName: Type: String Description: Domain name for URL. Default: example.com MaxLength: 100 MinLength: 5 AllowedPattern: "([a-zA-Z0-9][a-zA-Z0-9-]*[a-zA-Z0-9]*\\.)+[a-zA-Z]{2,}" SubDomainName: Type: String Description: Sub domain name for URL. Default: xxxxx MaxLength: 20 MinLength: 1 FeedbackSenderEmail: Type: String Description: E-mail address that sends feedback emails. Default: sender@example.com MaxLength: 100 MinLength: 5 AllowedPattern: "[a-zA-Z0-9_+-]+(.[a-zA-Z0-9_+-]+)*@([a-zA-Z0-9][a-zA-Z0-9-]*[a-zA-Z0-9]*\\.)+[a-zA-Z]{2,}" FeedbackReceiverEmail: Type: String Description: E-mail address that receives feedback emails. Default: receiver@example.com MaxLength: 100 MinLength: 5 AllowedPattern: "[a-zA-Z0-9_+-]+(.[a-zA-Z0-9_+-]+)*@([a-zA-Z0-9][a-zA-Z0-9-]*[a-zA-Z0-9]*\\.)+[a-zA-Z]{2,}" CertificateId: Type: String Description: ACM certificate ID. CloudFront only supports ACM certificates in us-east-1 region. Default: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx MaxLength: 36 MinLength: 36 Resources: # ------------------------------------------------------------# # S3 # ------------------------------------------------------------# S3Bucket: Type: AWS::S3::Bucket Properties: BucketName: !Sub website-${SiteName} PublicAccessBlockConfiguration: BlockPublicAcls: true BlockPublicPolicy: true IgnorePublicAcls: true RestrictPublicBuckets: true Tags: - Key: Cost Value: !Sub website-${SiteName} S3BucketPolicy: Type: AWS::S3::BucketPolicy Properties: Bucket: !Ref S3Bucket PolicyDocument: Version: "2012-10-17" Statement: - Action: - "s3:GetObject" Effect: Allow Resource: !Sub "arn:aws:s3:::${S3Bucket}/*" Principal: Service: cloudfront.amazonaws.com Condition: StringEquals: AWS:SourceArn: !Sub arn:aws:cloudfront::${AWS::AccountId}:distribution/${CloudFrontDistribution} DependsOn: - S3Bucket - CloudFrontDistribution # ------------------------------------------------------------# # CloudFront # ------------------------------------------------------------# CloudFrontDistribution: Type: AWS::CloudFront::Distribution Properties: DistributionConfig: Enabled: true Comment: !Sub CloudFront distribution for website-${SiteName} Aliases: - !Sub ${SubDomainName}.${DomainName} HttpVersion: http2 IPV6Enabled: true PriceClass: PriceClass_200 DefaultCacheBehavior: TargetOriginId: !Sub S3Origin-website-${SiteName} ViewerProtocolPolicy: redirect-to-https AllowedMethods: - GET - HEAD - OPTIONS CachedMethods: - GET - HEAD CachePolicyId: !Ref CloudFrontCachePolicy OriginRequestPolicyId: !Ref CloudFrontOriginRequestPolicy ResponseHeadersPolicyId: !Ref CloudFrontResponseHeadersPolicy Compress: true SmoothStreaming: false DefaultRootObject: index.html CustomErrorResponses: - ErrorCachingMinTTL: 10 ErrorCode: 403 ResponseCode: 404 ResponsePagePath: /404.html Origins: - Id: !Sub S3Origin-website-${SiteName} DomainName: !Sub ${S3Bucket}.s3.${AWS::Region}.amazonaws.com OriginAccessControlId: !GetAtt CloudFrontOriginAccessControl.Id S3OriginConfig: OriginAccessIdentity: "" ConnectionAttempts: 3 ConnectionTimeout: 10 ViewerCertificate: AcmCertificateArn: !Sub "arn:aws:acm:us-east-1:${AWS::AccountId}:certificate/${CertificateId}" MinimumProtocolVersion: TLSv1.2_2021 SslSupportMethod: sni-only Tags: - Key: Cost Value: !Sub website-${SiteName} DependsOn: - CloudFrontCachePolicy - CloudFrontOriginRequestPolicy - CloudFrontResponseHeadersPolicy - CloudFrontOriginAccessControl - S3Bucket CloudFrontOriginAccessControl: Type: AWS::CloudFront::OriginAccessControl Properties: OriginAccessControlConfig: Description: !Sub CloudFront OAC for website-${SiteName} Name: !Sub OriginAccessControl-website-${SiteName} OriginAccessControlOriginType: s3 SigningBehavior: always SigningProtocol: sigv4 CloudFrontCachePolicy: Type: AWS::CloudFront::CachePolicy Properties: CachePolicyConfig: Name: !Sub CachePolicy-website-${SiteName} Comment: !Sub CloudFront Cache Policy for website-${SiteName} DefaultTTL: 3600 MaxTTL: 86400 MinTTL: 60 ParametersInCacheKeyAndForwardedToOrigin: CookiesConfig: CookieBehavior: none EnableAcceptEncodingBrotli: true EnableAcceptEncodingGzip: true HeadersConfig: HeaderBehavior: whitelist Headers: - Access-Control-Request-Headers - Access-Control-Request-Method - Origin QueryStringsConfig: QueryStringBehavior: none CloudFrontOriginRequestPolicy: Type: AWS::CloudFront::OriginRequestPolicy Properties: OriginRequestPolicyConfig: Name: !Sub OriginRequestPolicy-website-${SiteName} Comment: !Sub CloudFront Origin Request Policy for website-${SiteName} CookiesConfig: CookieBehavior: none HeadersConfig: HeaderBehavior: whitelist Headers: - Access-Control-Request-Headers - Access-Control-Request-Method - Origin QueryStringsConfig: QueryStringBehavior: none CloudFrontResponseHeadersPolicy: Type: AWS::CloudFront::ResponseHeadersPolicy Properties: ResponseHeadersPolicyConfig: Name: !Sub ResponseHeadersPolicy-website-${SiteName} Comment: !Sub CloudFront Response Headers Policy for website-${SiteName} SecurityHeadersConfig: ContentSecurityPolicy: ContentSecurityPolicy: !Sub >- default-src 'self' *.${DomainName}; img-src 'self' *.${DomainName} data: blob:; style-src 'self' *.${DomainName} fonts.googleapis.com; font-src 'self' *.${DomainName} fonts.gstatic.com; script-src 'self' *.${DomainName} 'unsafe-inline'; script-src-elem 'self' *.${DomainName}; connect-src 'self' *.${DomainName} *.amazonaws.com; Override: true ContentTypeOptions: Override: true FrameOptions: FrameOption: DENY Override: true ReferrerPolicy: Override: true ReferrerPolicy: strict-origin-when-cross-origin StrictTransportSecurity: AccessControlMaxAgeSec: 31536000 IncludeSubdomains: true Override: true Preload: true XSSProtection: ModeBlock: true Override: true Protection: true CustomHeadersConfig: Items: - Header: Cache-Control Value: no-store Override: true # ------------------------------------------------------------# # Route 53 # ------------------------------------------------------------# Route53RecordIpv4: Type: AWS::Route53::RecordSet Properties: HostedZoneName: !Sub ${DomainName}. Name: !Sub ${SubDomainName}.${DomainName}. Type: A AliasTarget: HostedZoneId: Z2FDTNDATAQYW2 DNSName: !GetAtt CloudFrontDistribution.DomainName DependsOn: - CloudFrontDistribution Route53RecordIpv6: Type: AWS::Route53::RecordSet Properties: HostedZoneName: !Sub ${DomainName}. Name: !Sub ${SubDomainName}.${DomainName}. Type: AAAA AliasTarget: HostedZoneId: Z2FDTNDATAQYW2 DNSName: !GetAtt CloudFrontDistribution.DomainName DependsOn: - CloudFrontDistribution # ------------------------------------------------------------# # API Gateway # ------------------------------------------------------------# RestApiSendEmail: Type: AWS::ApiGateway::RestApi Properties: Name: !Sub SendEmail-website-${SiteName} Description: !Sub REST API to send user's feedback email for website-${SiteName} EndpointConfiguration: Types: - REGIONAL Tags: - Key: Cost Value: !Sub website-${SiteName} RestApiDeploymentSendEmail: Type: AWS::ApiGateway::Deployment Properties: RestApiId: !Ref RestApiSendEmail DependsOn: - RestApiMethodSendEmailPost - RestApiMethodSendEmailOptions RestApiStageSendEmail: Type: AWS::ApiGateway::Stage Properties: StageName: prod Description: production stage RestApiId: !Ref RestApiSendEmail DeploymentId: !Ref RestApiDeploymentSendEmail MethodSettings: - ResourcePath: "/*" HttpMethod: "*" LoggingLevel: INFO DataTraceEnabled : true TracingEnabled: false Tags: - Key: Cost Value: !Sub website-${SiteName} RestApiResourceSendEmail: Type: AWS::ApiGateway::Resource Properties: RestApiId: !Ref RestApiSendEmail ParentId: !GetAtt RestApiSendEmail.RootResourceId PathPart: sendemail RestApiMethodSendEmailPost: Type: AWS::ApiGateway::Method Properties: RestApiId: !Ref RestApiSendEmail ResourceId: !Ref RestApiResourceSendEmail HttpMethod: POST AuthorizationType: NONE Integration: Type: AWS IntegrationHttpMethod: POST Credentials: !GetAtt ApigSesInvocationRole.Arn Uri: !Sub arn:aws:apigateway:${AWS::Region}:email:action/SendEmail PassthroughBehavior: WHEN_NO_TEMPLATES RequestParameters: integration.request.header.Content-Type: "'application/x-www-form-urlencoded'" RequestTemplates: application/json: !Sub - |- #set($inputRoot = $input.path('$')) #set($tempbodya = "NAME: $inputRoot.name MAILADDRESS: $inputRoot.email MESSAGE: $inputRoot.body") #set($tempbodyb = $tempbodya.replaceAll("\r\n", "\n")) #set($body = $util.urlEncode($tempbodyb)) #set($destination = $util.urlEncode("${FeedbackReceiverEmail}")) #set($replyto = $util.urlEncode($inputRoot.email)) #set($subject = $inputRoot.subj+"(${SubDomainName}.${DomainName})") #set($source = $util.urlEncode("${FeedbackSenderEmail}")) Action=SendEmail&Destination.ToAddresses.member.1=$destination&Message.Body.Text.Data=$body&Message.Subject.Data=$subject&ReplyToAddresses.member.1=$replyto&Source=$source - {} IntegrationResponses: - StatusCode: 200 ResponseParameters: method.response.header.Access-Control-Allow-Headers: "'Content-Type,X-Amz-Date,Authorization,X-Api-Key,X-Amz-Security-Token,Cache-Control'" method.response.header.Access-Control-Allow-Methods: "'POST,OPTIONS'" method.response.header.Access-Control-Allow-Origin: !Sub "'https://${SubDomainName}.${DomainName}'" - StatusCode: 400 ResponseParameters: method.response.header.Access-Control-Allow-Headers: "'Content-Type,X-Amz-Date,Authorization,X-Api-Key,X-Amz-Security-Token,Cache-Control'" method.response.header.Access-Control-Allow-Methods: "'POST,OPTIONS'" method.response.header.Access-Control-Allow-Origin: !Sub "'https://${SubDomainName}.${DomainName}'" - StatusCode: 403 ResponseParameters: method.response.header.Access-Control-Allow-Headers: "'Content-Type,X-Amz-Date,Authorization,X-Api-Key,X-Amz-Security-Token,Cache-Control'" method.response.header.Access-Control-Allow-Methods: "'POST,OPTIONS'" method.response.header.Access-Control-Allow-Origin: !Sub "'https://${SubDomainName}.${DomainName}'" - StatusCode: 404 ResponseParameters: method.response.header.Access-Control-Allow-Headers: "'Content-Type,X-Amz-Date,Authorization,X-Api-Key,X-Amz-Security-Token,Cache-Control'" method.response.header.Access-Control-Allow-Methods: "'POST,OPTIONS'" method.response.header.Access-Control-Allow-Origin: !Sub "'https://${SubDomainName}.${DomainName}'" - StatusCode: 500 ResponseParameters: method.response.header.Access-Control-Allow-Headers: "'Content-Type,X-Amz-Date,Authorization,X-Api-Key,X-Amz-Security-Token,Cache-Control'" method.response.header.Access-Control-Allow-Methods: "'POST,OPTIONS'" method.response.header.Access-Control-Allow-Origin: !Sub "'https://${SubDomainName}.${DomainName}'" - StatusCode: 503 ResponseParameters: method.response.header.Access-Control-Allow-Headers: "'Content-Type,X-Amz-Date,Authorization,X-Api-Key,X-Amz-Security-Token,Cache-Control'" method.response.header.Access-Control-Allow-Methods: "'POST,OPTIONS'" method.response.header.Access-Control-Allow-Origin: !Sub "'https://${SubDomainName}.${DomainName}'" MethodResponses: - StatusCode: 200 ResponseModels: application/json: Empty ResponseParameters: method.response.header.Access-Control-Allow-Origin: true method.response.header.Access-Control-Allow-Headers: true method.response.header.Access-Control-Allow-Methods: true - StatusCode: 400 ResponseModels: application/json: Empty ResponseParameters: method.response.header.Access-Control-Allow-Origin: true method.response.header.Access-Control-Allow-Headers: true method.response.header.Access-Control-Allow-Methods: true - StatusCode: 403 ResponseModels: application/json: Empty ResponseParameters: method.response.header.Access-Control-Allow-Origin: true method.response.header.Access-Control-Allow-Headers: true method.response.header.Access-Control-Allow-Methods: true - StatusCode: 404 ResponseModels: application/json: Empty ResponseParameters: method.response.header.Access-Control-Allow-Origin: true method.response.header.Access-Control-Allow-Headers: true method.response.header.Access-Control-Allow-Methods: true - StatusCode: 500 ResponseModels: application/json: Empty ResponseParameters: method.response.header.Access-Control-Allow-Origin: true method.response.header.Access-Control-Allow-Headers: true method.response.header.Access-Control-Allow-Methods: true - StatusCode: 503 ResponseModels: application/json: Empty ResponseParameters: method.response.header.Access-Control-Allow-Origin: true method.response.header.Access-Control-Allow-Headers: true method.response.header.Access-Control-Allow-Methods: true RestApiRequestModelSendEmail: Type: AWS::ApiGateway::Model Properties: ContentType: application/json RestApiId: !Ref RestApiSendEmail Schema: |- { "$schema": "http://json-schema.org/draft-04/schema#", "title": "SendEmail", "type": "object", "properties": { "subj": { "type": "string" }, "name": { "type": "string" }, "email": { "type": "string" }, "body": { "type": "string" } }, "required": ["subj", "name", "email", "body"] } RestApiMethodSendEmailOptions: Type: AWS::ApiGateway::Method Properties: RestApiId: !Ref RestApiSendEmail ResourceId: !Ref RestApiResourceSendEmail HttpMethod: OPTIONS AuthorizationType: NONE Integration: Type: MOCK Credentials: !GetAtt ApigSesInvocationRole.Arn IntegrationResponses: - ResponseParameters: method.response.header.Access-Control-Allow-Headers: "'Content-Type,X-Amz-Date,Authorization,X-Api-Key,X-Amz-Security-Token,Cache-Control'" method.response.header.Access-Control-Allow-Methods: "'POST,OPTIONS'" method.response.header.Access-Control-Allow-Origin: !Sub "'https://${SubDomainName}.${DomainName}'" ResponseTemplates: application/json: '' StatusCode: 200 PassthroughBehavior: WHEN_NO_MATCH RequestTemplates: application/json: '{"statusCode": 200}' MethodResponses: - ResponseModels: application/json: Empty ResponseParameters: method.response.header.Access-Control-Allow-Headers: true method.response.header.Access-Control-Allow-Methods: true method.response.header.Access-Control-Allow-Origin: true StatusCode: 200 # ------------------------------------------------------------# # API Gateway SES Invocation Role (IAM) # ------------------------------------------------------------# ApigSesInvocationRole: Type: AWS::IAM::Role Properties: RoleName: !Sub ApigSesInvocationRole-website-${SiteName} Description: This role allows API Gateways to invoke SES. AssumeRolePolicyDocument: Version: 2012-10-17 Statement: - Effect: Allow Principal: Service: - apigateway.amazonaws.com Action: - sts:AssumeRole Path: / ManagedPolicyArns: - arn:aws:iam::aws:policy/AWSXRayDaemonWriteAccess Policies: - PolicyName: !Sub ApigSesInvocationPolicy-website-${SiteName} PolicyDocument: Version: 2012-10-17 Statement: - Effect: Allow Action: - "ses:SendEmail" Resource: - "*" # ------------------------------------------------------------# # Output Parameters # ------------------------------------------------------------# Outputs: APIGatewayEndpointSendEmail: Value: !Sub https://${RestApiSendEmail}.execute-api.${AWS::Region}.${AWS::URLSuffix}/${RestApiStageSendEmail}/sendemail SiteURL: Value: !Sub https://${SubDomainName}.${DomainName} Amazon API Gateway を CORS 対応にしているので、レスポンスのところで CORS 関連の設定が多くなっています。ヘッダー関連の設定はあまりいじらない方がよいと思います。 統合リクエストの設定で、HTTP ヘッダーに Content-Type: ‘application/x-www-form-urlencoded’ を設定しています。こうしないと動きませんでした。 このテンプレートが動作する前提はいろいろあるのですが (すいません) 前回記事から追加していることだけ。Amazon API Gateway のログを Amazon CloudWatch Logs に push するために必要な IAM ロールがアカウントに登録済みでないとエラーになります。それについては以下の記事をご確認ください。 Amazon API Gateway のログを Amazon CloudWatch Logs に書き込むための IAM ロールはアカウント単位の設定です Amazon API Gateway のログを Amazon CloudWatch Logs に書き込むための IAM ロール設定を紹介します。 blog.usize-tech.com 2024.07.01 まとめ いかがでしたでしょうか? 正直に申しますと、意気込んでやってはみたものの、 AWS Lambda 関数抜きの Amazon SES SendEmail API 呼出は絶対に流行らない と確信しました。VTL の使い勝手が Python に比べて悪すぎるのと、SendEmail 呼出だと文字列のエンコードというデリケートな部分があるためです。気を遣わなくて済む AWS Lambda の方が楽です。でも、せっかく作ったので私はこの方法を使おうと思います。他人にはお勧めしませんが。w ですがこの例は、Amazon API Gateway から Amazon SES でない、他の AWS サービスへの直接連携の参考になるかもしれません。 本記事が皆様のお役に立てれば幸いです。 最後に補足です。Amazon SES からメール送信するときは、Gmail と Yahoo Mail が実装した送信者要件を満たさないとそれらにはメールが届かない恐れがあります。Amazon SES 側で必要な設定があるので、要注意です。私も実装しました。 Yahoo/Gmail におけるメールの一括送信者に求められる要件の変更について | Amazon Web Services Gmail と Yahoo Mail は、ユーザーの受信トレイを保護するための取り組みとして、2024 年 2 月から送信者に関する新たな要件を発表しました。これらの要件を満たすために Amazon Simple Email Service... aws.amazon.com
アバター
こんにちは。SCSK渡辺(大)です。 AWS初心者なので、AWS Summit Japan 2024 は異世界に転生したような気持ちで楽しむことが出来ました。 今回は、 Amazon EC2 のコスト効率化に関する推奨事項を提供するサービス   を整理してみました。 そろそろ夏なので、熱中症にならないように暑苦しいコストは削っていきましょう。 ※当記事では、Amazon EC2 インスタンス = EC2 としています。 EC2のコストを削減する方法 まずはじめに、EC2のコストを削減する方法を考えてみます。 無駄な待機課金をなくすために、稼働スケジュールを見直す。 コストを抑えて利用するために、Reserved Instances/Savings Plans(RI/SP)を購入する。 最適な使用率にするために、インスタンスサイズを小さくする。   推奨事項を確認できるサービスとコスト削減方法の関係性 推奨事項を確認できるサービスとコスト削減方法の関係性は次の通りです。 推奨事項を確認できるサービス 関連するコスト削減方法 Trusted adviser a,b Compute Optimizer c Billing and Cost Management サイズ適正化に関する推奨事項 c Cost Optimization Hub a,b,c Reserved Instances b Savings Plans b   注意点 すべての推奨事項を実施したとしても、すべての恩恵を受けることが出来るわけではありません。 勘違いしたままだと「思ってた効果が得られなかった!」と悲しい思いをします。 なぜそのようなことになるのか? 理由は2つあります。 各サービスの推奨事項は競合します。 理由は言葉にすると難しいので、イメージ図を参照ください。 なお、Cost Optimization Hubは敢えて図に入れていません。   確認する日によって推奨事項の内容は変わります。 理由は単純で、ルックバック期間がズレるためです。 ルックバック期間とは”過去のデータを何日前まで遡って推奨事項を出すかを決める期間”です。 イメージ図はルックバック期間が60日間の場合です。   おすすめのロードマップ では、どうしたら良いか? 次のように段階を踏んでいくことで効率良くコスト削減できるかと思います。 (あくまで自論です。コスト削減に答えはありません!) RI/SP購入 まずは推定削減額の大きいものから実施します。 ただし、RI/SPの購入しすぎは効果が不明瞭になったり、 アカウントを解約したいのに有効期限前のRI/SPが大量に残ったりするリスクがありますので、 1年後や3年後の利用状況を見据えて計画することが重要です。 Trusted adviseやCompute Optimizerの設定見直し ルックバック期間などの設定を見直し、推奨事項の精度を向上させます。 推奨事項の再確認 見直した設定が反映され、競合が収まる頃(RI/SP購入から3か月ほど経過した後)に再確認します。 その中から簡単に実施出来る推奨事項を実施します。 継続的なコスト削減の運用化 1と3を繰り返し継続的なコスト削減を図ります。 また、必要に応じて、2の設定見直しも実施します。   EC2のコスト効率化に関する推奨事項を提供するサービス 続いて、EC2のコスト効率化に関する推奨事項を提供するサービスを見てみましょう。 なお、当記事ではサービスの概要と確認画面にフォーカスし、推奨事項の細かい説明は煩雑になるため割愛します。 Trusted adviser 各種リソースのベストプラクティスを支援してくれるサービスです。 AWS自体の知見と利用状況を組み合わせて分析してコスト最適化の推奨事項を提案してくれます。 コスト最適化の他にも、パフォーマンスやセキュリティなどの最適化の観点で推奨事項を提案してくれます。 推奨事項は次の画面から確認することができます。 Trusted adviser > コスト最適化 > 「即時の対応が推奨されるアクション」または「調査が推奨されます」を選択 Compute Optimizer 各種リソースの最適化に関する推奨事項を提案してくれるサービスです。 CPU使用率などのメトリクスを分析してコスト最適化の推奨事項を提案してくれます。 推奨事項は次の画面から確認することができます。 Compute Optimizer > ダッシュボード 下にスクロールします。 EC2 インスタンス > 過剰なプロビジョニング Billing and Cost Management Billing and Cost Management は請求とコストの最適化に役立つ機能を提供するサービスです。 利用状況を分析してコスト最適化の推奨事項を提案してくれます。 サイズ適正化に関する推奨事項 こちらはレガシーページのためAWS推奨ではありませんが、2024年7月時点でまだ確認できるためご紹介します。 推奨事項は次の画面から確認することができます。 Billing and Cost Management > レガシーページ > 規模の適正化 > サイズの適正化に関する推奨事項   Cost Optimization Hub Cost Optimization HubはAWS推奨です。 Compute Optimizerなどの推奨事項を一元化してくれます。 つまり、「各サービスの推奨事項は競合します。」という注意点は、このサービスが解消してくれます。 「じゃあ、これだけ見れば良くないか?」と思うかもしれませんが、全てのリソースをサポートしているわけではありません。 ですので、他のサービスと併せて確認するのが良いかと思います。 なお、”サポートされているリソース”については、 ユーザーガイド をご確認ください。 推奨事項は次の画面から確認することができます。 Billing and Cost Management > コスト最適化ハブ Reserved Instances 推奨事項は次の画面から確認することができます。 Billing and Cost Management > 予約 > 推奨事項 Savings Plans 推奨事項は次の画面から確認することができます。 Billing and Cost Management > Savings Plans > 推奨事項 まとめ お手軽にコスト削減の推奨事項を確認したい場合は、Cost Optimization Hubだけを確認することをオススメします。 全ての無駄コストを根絶やしにしたい場合は、その他のサービスの推奨事項も確認する必要があります。 当記事では推奨事項の細かい説明は割愛してしまったので、物足りない方は「AWS EC2 コスト最適化」で検索してみてください! AWS EC2 コスト最適化 検索
アバター
こんにちは。SCSKの田中です。 本記事では、ランサムウェア対策の最後の砦ともいえるバックアップの重要性やポイントについてご紹介します。 なお本投稿の前段にあたる投稿は以下のリンクよりご覧いただけます。 「ランサムウェアに気をつけろ!基礎知識と安全対策のポイント」 また、USiZEでは新たにオプションサービス:ランサムウェア対応サービスをリリースいたしました。 USiZE、ランサムウェア対応サービスにご興味を持っていただけた方は、以下ページをご参照ください。 USiZEについて ランサムウェア対応サービスに関するプレスリリース ランサムウェアの脅威 最近、人気動画サイトが被害を受けたことで話題となったように、ランサムウェアによる脅威が企業を脅かしています。 VPN機器の脆弱性やRDP通信の認証情報を悪用して、システム全体に攻撃が広がり、甚大な被害を及ぼしています。 以下はシステム全体に被害が拡大した事例です。 どちらもシステムが停止し、事業継続に大きな影響を与えました。 事例1:名古屋港のコンテナターミナルシステムの事例   ・ 感染経路     VPN 機器からの侵入が行われたと考えられている ​  ・被害    ・ 物理サーバ8台、および全仮想サーバ45台が暗号化されました。    ・ システムが停止し、約3日間コンテナ搬出・搬入業務が停止しました。 事例2: ​ 大阪急性期・総合医療センター  ・ 感染経路    給食事業者が設置するシステムにVPN機器から侵入が行われ、窃取された認証情報によりRDP通信を用いて、    病院給食サーバに侵入しました。そして病院給食サーバを踏み台に、他サーバへも被害が拡大  ・ 被害    ・ 基幹システムサーバの大部分が暗号化、電子カルテシステムが暗号化された影響で長期間診療制限​    ・ 基幹システムが再稼働するまで43日間、部門システムを含めた全体の診療システム復旧は73日間 また「Ransomeware as a Service(RaaS)」というランサムウェアの機能を提供するサービスが 名古屋港へのサイバー攻撃者として報道が多く出回っている「LockBit」も、その一例です。 LockBitが攻撃者から支持を受けている理由は「ユーザーフレンドリーなインターフェイス」により、 簡単に攻撃プログラムを組み立てることができる点にあると言われています。 これにより、高度な知識や専門的な技術を持たない人間でもランサムウェア攻撃が可能となっています。 このような背景から、ランサムウェアによる被害は今後ますます増加すると考えられます。                  バックアップデータが最後の砦に!! ランサムウェアからの攻撃を100%防御することは非常に困難です。 境界型防御やセキュリティ対策ソフトをすり抜ける事例も報告されています。​ 万が一攻撃を受けた際も、バックアップデータが無事であればデータを復旧することが可能です。 そのため、バックアップは最後の砦といえる対策となっています。                       バックアップが攻撃の対象に! ただバックアップを取っておくだけでは安全とはいえません。​ 攻撃者も容易に復旧されないようにバックアップデータを標的とします。 例えば、以下のような手法で攻撃が行われることがあります。 ・ バックアップデータ自体が暗号化される。 ・ バックアップデータが削除される。 ・バックアップソフトウェアがアンインストールされる そのため、バックアップデータを保護するための仕組みが必要となります。 仕組み①:侵入されにくいOS バックアップ製品に対してOSレイヤーで侵入される危険性があります。 WindowsやLinuxといったシェア率の高いOSは、情報が広く流布しているため、 攻撃者にとっても攻撃のための情報が集めやすいです。 それに比べ、独自OSは攻撃のための情報が限られているため、攻撃の難易度が高くなっています 仕組み②:書き換え不可なバックアップデータ バックアップデータ自体が上書きされることを防止するために、バックアップデータを書き換え不可にする機能が必要です。 イミュータブルバックアップ機能やWORM機能と呼ばれています。 他にもアクセス不可な領域に保管するエアギャップ、管理ツールの多要素認証などがあげられます。 またバックアップ製品の機能だけでなく、自社で気を付ける方法として「3-2-1ルール」に則るなどの対策も有効です。 3-2-1ルール ルール① : データは少なくとも「3つ」のバックアップコピーを持つ ルール② : バックアップデータを「2種類」以上の異なる媒体に保存する ルール③ : データ保管先のうち「1つ」は物理的所在地が遠隔地にあるものを選定   復旧時にバックアップデータを利用可能か? データのバックアップを取っているだけでは、破壊されたデータやマルウェアが潜むデータは復旧に利用できません。 そのため、復旧する際にはランサムウェアによる攻撃を受けていない安全なバックアップデータを特定する必要があります。 しかし、保持しているバックアップの世代数が多いほど、安全なバックアップデータを特定するのに時間がかかることがあります。 以下の図では8日分のバックアップしか保持していないため、5世代分のバックアップデータを調査することで 安全なバックアップデータの特定が可能ですが、場合によっては数か月前のデータにさかのぼっての確認が必要となります。                     そのため、バックアップデータが安全であることを確認するための機能が重要です。 最近のバックアップ製品にはAIなどを活用し、異常を検知する機能が搭載されています。 検知機能を利用することで調査対象を絞り込むことができ、特定までにかかる時間を短縮することが可能です。 USiZE バックアップ・ランサムウェア対応サービスのご紹介 最後にUSiZE バックアップ・ランサムウェア対応サービスのご紹介です。 USiZEではランサムウェア攻撃に備えたバックアップ・オプションサービスのランサムウェア対応サービスがございます。 バックアップデータ保護の仕組み USiZE 標準バックアップは独自OSや上書きや削除が不可能なイミュータブルファイルシステムという仕組みがあります。 他にも管理ツールは多要素認証によるなりすまし防止やSMB/NFSといった汎用的なアクセス方式の 制限など様々な仕組みによりバックアップデータを保護しています。 事業復旧対応を支援するランサムウェア対応サービス ランサムウェア対応サービスでは、ランサムウェアにより攻撃された疑いを機械学習により検知します。 「バックアップ侵害検知」では、ランサムウェアによる攻撃された疑いを検知すると自動で電話およびメールにて通知します。 「バックアップ保持・仮想マシン隔離」では、ランサムウェアによる攻撃された疑いを検知した際に自動で以下の2つの対応をいたします。 バックアップ保持:  以降のバックアップジョブが実行されないように自動で一時停止を行い、破壊されたデータのバックアップ取得や 世代管理のため、バックアップデータが削除されることを防止します。 仮想マシン隔離:  仮想マシンの仮想NICを自動で遮断し、感染拡大を防止します。 バックアップ侵害検知は5月にリリースしています。 バックアップ保持・仮想マシン隔離は近日中にリリースいたします。 USiZEやランサムウェア対応サービスについてご興味をお持ちになりましたら、気軽にお問合せください。  宛先: SCSK 株式会社 USiZE サービス部 ​  メールアドレス: usize-info@scsk.jp バックアップシステムの導入等にお困りの方はぜひ以下の記事についてもご参照ください。 バックアップ導入の勘所 参考資料 国土交通省 「コンテナターミナルにおける情報セキュリティ対策等検討委員会中間取りまとめ①名古屋港のコンテナターミナルにおけるシステム障害を踏まえ緊急に実施すべき対応策について(案) 」 大阪急性期・総合医療センター 「大阪急性期・総合医療センター 情報セキュリティインシデント調査報告書 概要」 トレンドマイクロ株式会社 RaaS (Ransomware as a Service)とは
アバター
本記事はBackhaulingの 「 Internet Breakout 」についてのご紹介です。 Local gateway IPについては、前編をご参照ください。 【前編】CatoクラウドのBackhaulingについて~Local gateway IP~ Catoクラウドの「Backhauling」をご紹介します!Backhaulingには2種類ありますが、今回は「Local gateway IP」のご紹介です。 blog.usize-tech.com 2024.06.26 「Internet Breakout」の ユースケース ※本記事では「Internet Breakout」のユースケースの一例をご紹介します。 Backhaulingの「Internet Breakout」は主に「一部トラフィックのみ、CatoのPoPのアドレスでアクセスさせたくない」場合に利用します。 具体的にユースケースを2つ挙げてご説明していきます。 SaaSサービス側で固定されている送信元アドレスを CatoのPoPのアドレスに 変更できない場合 SaaSサービスを各社専用のグローバルアドレスでアクセス制限をかけて利用している場合を考えてみます。 この場合、 Catoクラウド経由でアクセスさせるためには SaaSサービス側で送信元アドレスをCatoクラウドのPoPのアドレスに変更する必要がありますが、何らかの理由で変更ができないケースもあるかと思います。 そんな時、Backhaulingを使えば Catoクラウドを経由しながら現行 の グローバルアドレスを使ってアクセスさせることができます。 =  特定のWebサイトに、 CatoのPoPのアドレス でアクセスできない場合 Cato PoPのIPアドレスは、JPNICでなく上位のAPNICからIPアドレスを取得しています。 そのためアクセス先のWebサイトが日本からのアクセスのみに制限をかけている場合、Catoクラウド経由でアクセスできないケースがあります。 こんな時も、Backhaulingを使えば Catoクラウドを経由しながらISPの グローバルアドレスを使ってアクセスさせることができます。 “Catoクラウドを経由しながら”とはどういうことか構成図を使って補足します。 (前編を見たので説明不要という方は飛ばしてください) 例えば下図の構成の場合、 支店のユーザやモバイルユーザから宛先へのトラフィックは赤線経路で一度Catoクラウドを経由します。 その後、 トラフィックは 本社 内のSocketに転送され本社のインターネット回線経由でアクセスさせるといった通信経路です。 ここで注目いただきたいのは、 宛先が ドメイン・アプリケーションに加え、 IPアドレス・FQDN等の様々な形で指定することができる という点です。 Catoクラウドのその他機能には宛先をアプリケーションでしか指定できないものもあります。 それらの機能と比較すると設定方法においては便利であると言えるんです!(例えば、Split TunnelやBypass等の場合、宛先はアプリケーション指定のみです。※2024年6月現在) 「Internet Breakout」の設定例 前編でもお伝えした通り、 Backhaulさせたトラフィックは一度、Catoクラウドを経由 します 。 そのため、Catoクラウドのセキュリティチェックが適用され、ログにも記録されます。 ということで、以下3点を確認するためテストを行ってみました。 Backhaulさせる前後でのグローバルアドレスの変化 ログの残り方 Backhaulさせた場合、セキュリティ機能はどうなるか 構成例 構成は下図の通りです。 支店のユーザから、アドレス確認サイト(www.cman.jp)へのトラフィックのみをBackhaulさせ、検証環境のSocketから検証環境のインターネット回線経由でアクセスさせるというシナリオです。 まず、Backhaulingの設定を入れる前の状態で、アドレス確認サイト(www.cman.jp)へアクセスをしてみます。 この状態で自身のアドレスの確認を行うと、この通り150.195.219.0/24のアドレスが払い出されていることがわかりました。 このアドレスはCatoクラウドの東京PoPのアドレスとなっており、CatoクラウドのPoPから宛先のアドレス確認サイト(www.cman.jp)に接続していることがわかります。 ちなみに、CatoクラウドのPoPのアドレスはこちらから確認可能です。 Production PoP Guide – Cato Learning Center (catonetworks.com) 設定手順 次に、Backhaulingの設定を行っていきます。 Backhaulingは下記の順番で設定をします。 Step1: Gatewayサイトの定義 →出口として設定したい拠点をGatewayサイトと定義します。 → 今回は、”検証環境”というサイトをGatewayサイトとして定義します。 Step2:Network Ruleの作成 →対象トラフィックをGatewayサイトに向けるためのルーティングの設定を行います。 → 今回は、支店のユーザからアドレス確認サイト(www.cman.jp)へのトラフィックのみを”検証環境”にルーティングさせます。 Gatewayサイトの定義 設定箇所:Network>Site>Site Configuration>Backhauling 「Use this site as a backhauling gateway」のチェックボックスにチェックを入れます。 「Select the destination for the traffic」の設定項目が出力されます。 ここで 「Internet breakout」か「Local gateway IP」のどちらかを選択しますが、今回は「Internet breakout」を選択します。 上の手順で「Internet breakout」を選択すると「Preferred Socket Port」の設定項目が出力されます。 ここではSocketのどのポートから出力させるかを指定することができます。 今回はWAN1ポートから出力させたいので、「WAN1」を選択しました。 SocketのWANポートを冗長している場合は、「Automatic」を選択することで、自動で出力ポートを選択させることも可能です。 ここまででStep1のGatewayサイトの定義は完了です。 次にStep2のNetwork Ruleの作成に進みます。 Network Ruleの作成 中国のユーザからの接続の場合や、中国の拠点をGatewayサイトとする場合は、中国のインターネット規制に違反していないことを事前に確認し、設定を行う必要があります。 設定箇所:Network>Network Rules 「New」からルールを作成していきます。 本記事ではNetwork Rulesの詳細な説明は省略いたしますが、今回は以下の通り設定をしています。   ・Name:Backhauling test ・Rule Type:Internet ・Source:Site(支店) ・App/Category:Domain( www.cman.jp ) ・Configuration    – Bandwidth priority:P255    – Priority Transport:CATO(Automatic)    – Secondary Transport:None ConfigurationのRouting Methodでは「Backhaul via」を選択します。 「Backhauling Gateway Site」の設定項目が出力されるので、+ボタンからStep1で設定したGatewayサイトを選択します。 最後に「Save」ボタンで設定保存をします。 以上で設定は完了です。 結果 それでは、確認項目を1つずつ確認していきます。 Backhaulさせる前後でのグローバルアドレスの変化  まず確認項目1つ目のグローバルアドレスを確認してみます。 Backhaulingの設定を入れる前の状態では、Catoクラウドの東京PoPのアドレスでした。  Backhaulingの設定が完了した後に接続をしてみると… グローバルアドレスは以下の通りISPから付与されたアドレスへと変更され、CatoクラウドのPoPからではなく検証環境のインターネット回線経由で接続されていることがわかります。 ログの残り方 この時のログを確認してみると残念ながら最終的にどのグローバルアドレスでアクセスされているかまでは確認ができませんでした。 ですが、このログから設定手順のStep2で設定したNetwork Ruleにヒットして”検証環境”というサイトから接続していることがわかります。 また、「Sub-type」と「Rule」からCatoクラウドのInternet Firewall(ルール名:Any Allow)を突破していることもわかります。 Backhaulさせた場合、Catoクラウドのセキュリティ機能はどうなるか 2つ目の確認から、Internet Firewallが機能していることが確認できましたが、念のためInternet Firewallで アドレス確認サイト(www.cman.jp)へのトラフィックをBlockするルールを作成してみました。 この状態で同じようにアドレス確認サイト(www.cman.jp)へアクセスをしてみると、下図の通りBlockされました。 よって、Backhaulされた通信もCatoクラウドを経由するため、Catoクラウドのセキュリティ機能が機能するということがわかります。 さいごに 今回はBackhaulingについて解説しました。 このBackhaulingですが、実はトラブルシューティングで利用されるケースもございます。 詳細はこちらの記事をご参照ください。 Cato経由でのWebサイト接続のトラブル例とその対処法 Cato経由でのWebサイトの接続トラブルについて、事例とその対処法についてご紹介します。 blog.usize-tech.com 2024.04.19
アバター
皆さん、こんにちは!SCSK株式会社の川原です。 今年も、Google Cloudが主催するグローバルカンファレンスイベント「 Google Cloud Next Tokyo ’24 」が開催されます!このイベントは、クラウドテクノロジーの最新情報を学び、業界リーダーや専門家とのネットワーキングを行うための絶好の機会です。 ### Google Cloud Next Tokyo ’24 概要 開催日:  2024年8月1日(木)〜2日(金) 会場 : パシフィコ横浜ノース この度当社は、Platinumスポンサーとして出展いたします! ブレイクアウトセッション &Ask the Speaker に登壇し、 Expo 会場へのブースを出展予定 です。 IT 業界のみならず様々な業界のリーダー、意思決定者、エンジニア、そして開発者の皆様にご満足頂けるセッションコンテンツが準備されていますので、この機会をぜひ​ご活用ください。皆様のご参加を心よりお待ちしております 。 ご登録がお済でない方は、まずはこちらからご登録ください↓↓ 【招待コード  : FY24nx_pt030】 申し込み時にご入力ください !!   イベントの見どころ Google Cloud Next Tokyo ’24では、生成AIやセキュリティをはじめ、ビジネスに欠かせないテーマを元に、基調講演、ライブセッションやハンズオンなどのプログラムが用意されています。 ☁︎  基調講演 話題の生成  AI  を筆頭に多様なプロダクト アップデートや最新のソリューションを紹介します。 また、 Google Cloud  を導入しビジネスに革新をもたらす企業のリーダーから、そのビジョンと取り組みについてお聞きします。 ☁︎  ブレイクアウト セッション & Ask the Speaker 9 つのテーマで、米  Next  で発表された最新情報やお客様によるクラウド活用事例をお届けします。 具体的な活用事例やスピーカーへの質問コーナーを活用することで、自社に役立つヒントを見つけましょう。 ☁︎  ハンズオン セッション Google Cloud  の魅力を、実際のハンズオンを通して探求しましょう。 AI 、データ分析、インフラ構築、アプリ開発、セキュリティまで、 全てを学べるチャンスです!皆さまの参加をお待ちしております。 ☁︎ Expo Google Cloud  の最新製品やソリューション、パートナー、お客様の事例やデモを、エキスパートと交流しながら体験できるエリアです。 ☁︎ Innovators Hive デベロッパーやエンジニアのためのエリアです。 Google Cloud  のデモを体験し、学習プログラムや認定資格の最新情報を入手できます。 ぜひ会場で  Google Cloud  を共に学び、デベロッパー コミュニティと繋がりましょう。   ☁︎  体験  TAP for Gen AI 生成  AI  を活用した革新的なアイデアの創出を狙った  90  分間のアイディエーションを実施します。ソリューションや手段からではなく、 課題に焦点を当てて、生成  AI  で解決すべき問題を見つけましょう。   SCSKのセッションとブースのご紹介 SCSK セッションのご紹介 開始日時:8/1(木)14:00~14:30 タイトル: 明日からできる!業務で使える!多彩なAIを組み合わせたアーキテクチャとは? 【概要】 生成AIは、様々な業界で革新をもたらしています。そして、AIにとってデータは燃料であり、その活用がAIの性能を大きく左右します。SCSKはGoogle Cloudを通じてデータ・生成AI活用に取り組み、経験とノウハウを蓄積してきました。本セッションでは、データから従来AI・生成AIを組み合わせたアーキテクチャをご紹介し、失敗談や成功談についてお話させていただきます。   取り上げる主な Google Cloud 製品 / サービス  BigQuery Dialogflow Vertex AI Search ※セッション レベル:初級 【SCSK登壇者のご紹介】 SCSK株式会社 ソリューション事業グループ クラウドサービス事業本部 データ&AIソリューション部 第二課 AIリードエンジニア                青 木 琢人 SCSK のクラウド専門部隊に所属する、AI / ML サービスのリードエンジニア。Google Cloud の画像認識系AI、コンタクトセンターAI、生成AIを活用し、 製造業・金融業・食品業界など幅広いお客様のシステム設計・構築を担当。 生成AIを業務活用したい方、ぜひセッションへお越しください! SCSKブース SCSKのブースでは、 ソーシャルインパクト パートナー オブ ザ イヤーを受賞したSCSKが提供する「 総合SIer × AI ・ 生成AI の可能性 」 をテーマに、SCSKが提供するAI技術とそのビジネス活用についてご紹介いたします。SCSKは、 AIだけではなく良いシステムイングレーションやデータ整備など、業務課題の解決に必要な全体検討と組み合わせで、最適な業務実装まで支援することができる点が強みです 。当日の展示では、技術知見に留まらない、実績に基づいた具体的なシステムイメージをお伝えします。 ぜひご来場いただき、最新のAI技術とSCSKだからできるビジネスへの活用方法についてご確認ください! では皆様、 GoogleCloudNextTokyo’24を楽しみにお待ちください。 当日はSCSKセッションならびに Ask the Speaker、 展示ブースへの来場をお待ちしております! 【招待コード  : FY24nx_pt030】 申し込み時にご入力ください !
アバター
坂木です。 2024年6月12日-6月14日にかけて、幕張メッセで Interop24 Tokyo が開催されました。 SCSKはZabbix Japanと共同で出展いたしましたので、出展内容や出展感想等をご紹介いたします。   イベント概要 Interop Tokyoは、日本最大級のインターネットテクノロジーイベントであり、最新の技術や最新製品を紹介しています。 イベント内容としては、各企業ブースにてパネルディスカッションやワークショップ、ショートセミナーなどが実施されています。 Zabbixブースでは、Zabbix関連ソリューションのパネルディスカッションやショートセミナーを実施しました。   SCSKのZabbixブース出展内容 SCSKの展示では 監視ツールの移行 と Zabbix自動チューニング を紹介しました。 監視ツールの移行 Zabbixは、オープンソースソフトウェア(OSS)のためライセンス料がかからず、有償監視ツールから移行するとコストメリットが大きいことをご紹介しました。 また、監視ツール移行の手間という観点から見ても、Zabbixへの移行は自動化できる部分が多く、オペレーターの負担が少ないことも併せてご説明しました。 Zabbix自動チューニング 生成系AIを活用して、エラー内容の分析・原因調査・解決策提示を自動化する取り組みを紹介しました。 また、AIからの回答を元に、設定ファイルのエラー原因となっている箇所を自動で修正する手法も提案し、エラー発生から解決まで一切人を介在させず実現できることを示しました。   ちなみに、私は上記2項目を題材としてショートセミナーにて講演いたしました。 AI分野に興味を持つ方が多いのか、Zabbix自動チューニングの話をしているときは特に食いつきがよかった気がします。   感想 まず第一に、人が多いです。 Interopは規模が大きいITイベントということもあり、出店企業や参加者が非常に多かったです。   Interopでは各企業が最新のサービス・製品紹介を行っています。私はいくつかの企業ブースで話を伺いましたが、どれも聞いてて飽きることのない魅力的な内容で、多くの知見を得ることができました。 また、各企業ブースに話を聞きに行くとノベリティがもらえます。知見とノベリティが得られて一石二鳥です。 ちなみに、私は今治タオルとハイチュウをもらいました。   最後に 私は入社2年目で、IT業界での経験は浅く高い専門性を有してはいませんが、インタロップは楽しめました。そのため、ITに精通しているとまで言わなくても、多少ITを知っている方であれば楽しめるイベントだと思います。
アバター
こんにちは、広野です。 Amazon API Gateway REST API のロギングにはいくつか種類と方法がありますが、Amazon CloudWatch Logs は他の AWS サービスのログを見るときにも日々アクセスするため、なんだかんだ言うものの慣れているというのと、設定が簡単なので使いやすいです。 ですが、Amazon API Gateway に Amazon CloudWatch Logs に書き込みを許可する IAM ロールはその AWS アカウント共通の設定 なので、そのアカウントで最初に設定すると以後気にしなくなりますし、そもそも最初から設定されていたアカウントで作業する場合は何もすることがありません。そのため、私は新しい AWS アカウントで作業するときに必ずこの設定を忘れます。思い出すタイミングは、Amazon API Gateway のログ設定を有効にしようとしてエラーになるときです。 以下、備忘のため設定方法を書き落としておきます。 設定方法 まずは公式ドキュメントから。 API Gateway での CloudWatch による REST API のログの設定 - Amazon API Gateway Amazon API Gateway で CloudWatch によるログを設定する方法について説明します。 docs.aws.amazon.com   IAM ロールを作った後は、AWS マネジメントコンソールの以下の画面で IAM ロールを登録するだけです。   一応、AWS CloudFormation テンプレートにも落とし込んでおいたので、これを一発流すだけでも一通り設定できます。 AWSTemplateFormatVersion: 2010-09-09 Description: The CloudFormation template that creates an IAM Role and an account setting to push CloudWatch Logs from API Gateway. This setting is shared in your AWS account. Resources: # ------------------------------------------------------------# # API Gateway CloudWatchLogs Invocation Role (IAM) # ------------------------------------------------------------# ApigCloudWatchLogsInvocationRole: Type: AWS::IAM::Role Properties: RoleName: !Sub ApigCloudWatchLogsInvocationRole-${AWS::AccountId} Description: This role allows all API Gateways to invoke CloudWatch Logs. AssumeRolePolicyDocument: Version: 2012-10-17 Statement: - Effect: Allow Principal: Service: - apigateway.amazonaws.com Action: - sts:AssumeRole Path: / ManagedPolicyArns: - arn:aws:iam::aws:policy/service-role/AmazonAPIGatewayPushToCloudWatchLogs ApigAccountSettingCloudWatchLogs: Type: AWS::ApiGateway::Account Properties: CloudWatchRoleArn: !GetAtt ApigCloudWatchLogsInvocationRole.Arn DependsOn: - ApigCloudWatchLogsInvocationRole   まとめ いかがでしたでしょうか? このように AWS にはアカウント単位の共通設定がたまにあるので、管理方法も含めて気を付けていきましょう。 本記事が皆様のお役に立てれば幸いです。
アバター
こんにちは、SCSK株式会社の小寺崇仁です。 今回は「データベースモニタ」について設定方法を紹介します。 データベースモニタとは Zabbixのアイテムタイプに「データベースモニタ」があります。 データベースモニタでは、ZabbixサーバにインストールしたODBCドライバを使用して、監視対象のデータベースに接続し、任意のSQLを発行することができます。 このブログでは、ODBCドライバのインストール方法、アイテムの作成方法をご紹介します。 検証環境 AWS EC2 OS Red Hat Enterprise Linux release 9.4 (Plow) Zabbix 7.0.0 MySQL/MariaDB 10.5.22-MariaDB PostgreSQL PostgreSQL 13.14 on x86_64-redhat-linux-gnu SQLサーバ(MSSQL) Microsoft SQL Server 2019 (RTM-CU26) (KB5035123) – 15.0.4365.2 (X64) Oracle Oracle Database 19c Standard Edition 2 Release 19.0.0.0.0 – Production MySQL/MariaDB ODBCドライバのインストール(MySQL/MariaDB) # dnf install mariadb-connector-odbc インストールされたドライバのパスを確認(MySQL/MariaDB) cat /etc/odbcinst.ini ~~~~~~~~~~ [MariaDB] Description=ODBC for MariaDB Driver=/usr/lib/libmaodbc.so Driver64=/usr/lib64/libmaodbc.so FileUsage=1 ~~~~~~~~~~ アイテム作成(MySQL/MariaDB) アイテム名 任意   タイプ データベースモニタ   キー ※1行です。 db.odbc.select[ mysql_example, , Driver=/usr/lib64/libmaodbc.so; Database=zabbix; Server=127.0.0.1; Port=3306] Select用のキー 任意文字(第1引数) 不使用(第2引数) 上記で確認したパス 接続先のDB名 接続先のサーバ 接続先のポート データ型 任意   ユーザ DB接続ユーザー   パスワード DB接続パスワード   SQLクエリ 実行SQL 例:select version();   PostgreSQL ODBCドライバのインストール(PostgreSQL) # dnf install postgresql-odbc インストールされたドライバのパスを確認(PostgreSQL) cat /etc/odbcinst.ini ~~~~~~~~~~ [PostgreSQL] Description=ODBC for PostgreSQL Driver=/usr/lib/psqlodbcw.so Setup=/usr/lib/libodbcpsqlS.so Driver64=/usr/lib64/psqlodbcw.so Setup64=/usr/lib64/libodbcpsqlS.so FileUsage=1 ~~~~~~~~~~ アイテム作成(PostgreSQL) アイテム名 任意   タイプ データベースモニタ   キー ※1行です。 db.odbc.select[ pgsql_example, , Driver=/usr/lib64/psqlodbcw.so; Database=zabbix; Server=127.0.0.1; Port=5432] Select用のキー 任意文字(第1引数) 不使用(第2引数) 上記で確認したパス 接続先のDB名 接続先のサーバ 接続先のポート データ型 任意   ユーザ DB接続ユーザー   パスワード DB接続パスワード   SQLクエリ 実行SQL 例:select version();   SQLServer(MSSQL) ODBCドライバのインストール(MSSQL) # curl https://packages.microsoft.com/config/rhel/9/prod.repo | sudo tee /etc/yum.repos.d/mssql-release.repo # dnf install -y msodbcsql18 参考: https://learn.microsoft.com/ja-jp/sql/connect/odbc/linux-mac/installing-the-microsoft-odbc-driver-for-sql-server?view=sql-server-ver16&tabs=redhat18-install%2Calpine17-install%2Cdebian8-install%2Credhat7-13-install%2Crhel7-offline インストールされたドライバのパスを確認(MSSQL) cat /etc/odbcinst.ini ~~~~~~~~~~ [ODBC Driver 18 for SQL Server] Description=Microsoft ODBC Driver 18 for SQL Server Driver=/opt/microsoft/msodbcsql18/lib64/libmsodbcsql-18.3.so.3.1 UsageCount=1 ~~~~~~~~~~ アイテム作成(MSSQL) アイテム名 任意   タイプ データベースモニタ   キー ※1行です。 db.odbc.select[ mssql_example, , Driver=/opt/microsoft/msodbcsql18/lib64/libmsodbcsql-18.3.so.3.1; Database=master; Server=10.0.0.1; Port=1433; TrustServerCertificate=yes;] Select用のキー 任意文字(第1引数) 不使用(第2引数) 上記で確認したパス 接続先のDB名 接続先のサーバ 接続先のポート 接続エラー対策 データ型 任意   ユーザ DB接続ユーザー   パスワード DB接続パスワード   SQLクエリ 実行SQL 例:SELECT @@VERSION AS ‘SQL Server Version’;   Oracle ODBCドライバのインストール(Oracle) # mkdir /opt/oracle # cd /opt/oracle # wget https://download.oracle.com/otn_software/linux/instantclient/2111000/instantclient-basic-linux.x64-21.11.0.0.0dbru.zip # wget https://download.oracle.com/otn_software/linux/instantclient/2111000/instantclient-odbc-linux.x64-21.11.0.0.0dbru.zip # unzip instantclient-basic-linux.x64-21.11.0.0.0dbru.zip # unzip instantclient-odbc-linux.x64-21.11.0.0.0dbru.zip # echo /opt/oracle/instantclient_21_11 > /etc/ld.so.conf.d/oracle-instantclient.conf # ldconfig 参考: https://www.oracle.com/jp/database/technologies/instant-client/linux-x86-64-downloads.html アイテム作成(Oracle) アイテム名 任意   タイプ データベースモニタ   キー ※1行です。 db.odbc.select[ oracle_example, , Driver=/opt/oracle/instantclient_21_11/libsqora.so.21.1; Server_Name=10.0.0.2/ORCL; Port=1521] Select用のキー 任意文字(第1引数) 不使用(第2引数) 上記で確認しパス 接続先のサーバ/SID 接続先のポート データ型 任意   ユーザ DB接続ユーザー   パスワード DB接続パスワード   SQLクエリ 実行SQL 例:select * from v$version;   動作状況 このような形でデータ取得ができます。 最後に 弊社ではZabbix関連サービスを展開しています。以下ページもご参照ください。 SCSK Plus サポート for Zabbix SCSK Plus サポート for Zabbix 世界で最も人気のあるオープンソース統合監視ツール「Zabbix」の導入構築から運用保守までSCSKが強力にサポートします www.scsk.jp ★YouTubeに、SCSK Zabbixチャンネルを開設しました!★ SCSK Zabbixチャンネル 本チャンネルでは、SCSK株式会社でのZabbixに関するトレンド/事例紹介などを動画にまとめて取り上げております。 最新のトピックについては、以下の弊社HPもしくはツイッターアカウントをぜひ参照ください。 ツイッターアカウント: www.youtube.com ★X(旧Twitter)に、SCSK Zabbixアカウントを開設しました!★ 【公式】SCSK Zabbix (@SCSK_Zabbix) / Twitter SCSKが提供するZabbixサービスのオフィシャルアカウントです。 #Zabbix #SCSKPlusサポートforZabbix #監視 #SCSK twitter.com
アバター
こんにちは、SCSK株式会社の小寺崇仁です。 今回は「Java(JMX)監視」について設定方法を紹介します。 Java(JMX)監視とは Javaのプロセス内部は複雑で、独自のメモリ管理や、様々な処理が行われています。ZabbixではJavaのプロセスを監視することができ、テンプレートも準備されています。 しかし、設定が難しくあまり使われていないように思います。今回は、Zabbixサーバ側の設定とプロセス側の設定についてご紹介します。 Zabbixサーバーの設定 Javaを監視するには、「zabbix-java-gateway」といパッケージをインストールする必要があります。 「zabbix-java-gateway」サービスを起動して、「zabbix-server」から接続する設定をします。 インストール # dnf install zabbix-java-gateway # systemctl start zabbix-java-gateway # systemctl enable zabbix-java-gateway 設定 # vi /etc/zabbix/zabbix_server.conf JavaGateway=127.0.0.1 StartJavaPollers=1 # systemctl restart zabbix-server Javaプロセス側の設定 Javaのプロセス側ではJMXでリモート接続できるようにする必要があります。 設定を有効にするには起動時に以下のオプションを設定します。 -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=12345 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false 次に設定方法の例をご紹介します。 単純なJavaプロセス 起動時の引数に設定します。先日の Seleniumサーバ の場合、次のように設定します。 java -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=12345 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false -jar selenium-server-4.21.0.jar standalone --selenium-manager true Tomcatの場合  次の手順で確認しました。Tomcatではsetenv.shを作成すればオプションを読み込みます。 # mkdir /opt/tomcat # cd /opt/tomcat/ # wget https://dlcdn.apache.org/tomcat/tomcat-10/v10.1.25/bin/apache-tomcat-10.1.25.tar.gz # tar zxvf apache-tomcat-10.1.25.tar.gz # vi /opt/tomcat/apache-tomcat-10.1.25/bin/setenv.sh #!/bin/sh CATALINA_OPTS="-Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=12345 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false" export CATALINA_OPTS # /opt/tomcat/apache-tomcat-10.1.25/bin/startup.sh Zabbixのホスト作成 ホスト 任意   テンプレート Generic Java JMX Apache Tomcat by JMX 単純なプロセス用 Tomcat用 ホストグループ 任意   インターフェース JMX    IPアドレス プロセスが起動しているサーバのIP    ポート 引数で指定したポート   値の取得 このような形で値の取得ができます。 最後に 弊社ではZabbix関連サービスを展開しています。以下ページもご参照ください。 SCSK Plus サポート for Zabbix SCSK Plus サポート for Zabbix 世界で最も人気のあるオープンソース統合監視ツール「Zabbix」の導入構築から運用保守までSCSKが強力にサポートします www.scsk.jp ★YouTubeに、SCSK Zabbixチャンネルを開設しました!★ SCSK Zabbixチャンネル 本チャンネルでは、SCSK株式会社でのZabbixに関するトレンド/事例紹介などを動画にまとめて取り上げております。 最新のトピックについては、以下の弊社HPもしくはツイッターアカウントをぜひ参照ください。 ツイッターアカウント: www.youtube.com ★X(旧Twitter)に、SCSK Zabbixアカウントを開設しました!★ 【公式】SCSK Zabbix (@SCSK_Zabbix) / Twitter SCSKが提供するZabbixサービスのオフィシャルアカウントです。 #Zabbix #SCSKPlusサポートforZabbix #監視 #SCSK twitter.com
アバター
こんにちは、SCSK株式会社の小寺崇仁です。 先日Zabbixの7.0がリリースされました。 今回は「ブラウザモニタリング」について検証していきます。 ブラウザモニタリングとは ブラウザモニタリングとは、アイテムのタイプ「ブラウザ」というZabbix7.0の新機能になります。ブラウザを使用したWebサイトの操作をZabbixで再現して監視を行う機能になります。 Webシナリオ監視と類似した機能になりますが、違いは以下となります。 監視タイプ 概要 設定難易度 ブラウザモニタリング Seleniumを使用したスクレイピング 優しい Webシナリオ HTTPリクエスト、レスポンスを自作したスクレイピング 激ムズ 環境準備 ブラウザモニタリングを使用するには、Zabbix7.0とは別に、「WebDriverサーバ」を構築する必要があります。 「WebDriverサーバ」を構築する方法としては以下の2パターンあります。 SeleniumのDockerイメージを使用する SeleniumのStandaloneサーバを起動する ZabbixサーバにDockerを入れたくなかったので、私は2で検証をしました。 Dockerを使用する 検証はしておりませんが、次のURLに構築手順が記載してあります。 https://assets.zabbix.com/files/events/2024/conference_benelux_2024/KasparsM_browser_monitoring.pdf Standaloneを使用する 次の流れで、Selenium Standalone サーバを構築します。 Javaをインストールします。 Seleniumの公式HPから「Selenium Server (Grid)」をダウンロードします。 Selenium Standalone サーバを起動します。 Zabbixサーバのconfを編集します。 私が構築した際のコマンドは以下となります。 1.Java インストール # dnf install java-21-openjdk 2.Seleniumダウンロード # wget https://github.com/SeleniumHQ/selenium/releases/download/selenium-4.21.0/selenium-server-4.21.0.jar 3.Selenium起動 ※「--selenium-manager true」をオプションを付けることで各ブラウザのドライバーを自動ダウンロードできます。 # java -jar selenium-server-4.21.0.jar standalone --selenium-manager true 4.Zabbixサーバのconf編集 # vi /etc/zabbix/zabbix_server.conf WebDriverURL=http://localhost:4444 StartBrowserPollers=1 ※以下のバージョンで検証した際にエラーとなりました。そのため、Firefoxのドライバーを使用して回避しました。 Selenium-server:4.21.0、ChromeDriver:126.0.6478.126 アイテムの作成 サンプルでZabbixの管理画面にログインをして、キューの画面を監視したいと思います。 標準テンプレートで全体のキューの数しかわからないので、個別で監視を入れたいと思います。 項目 設定値 備考 アイテム名 キュー監視   タイプ ブラウザ   キー 任意   データ型 テキスト   スクリプト 次に記載   var browser = new Browser(Browser.firefoxOptions()); browser.navigate("http://localhost/zabbix/"); browser.findElement('css selector','#name').sendKeys("Admin"); browser.findElement('css selector','#password').sendKeys("zabbix"); browser.findElement('css selector','#enter').click(); browser.navigate("http://localhost/zabbix/zabbix.php?action=queue.overview"); return browser.findElement('xpath','/html/body/div/main').getText(); ※Chromドライバーを使用するとエラーになったため、Firefoxを使用しています。 ※最後に「getText」で文字列を取得していますが、「getScreenshot」で画像(バイナリデータ)の保存もできます。画像データの表示については別途検証する予定です。 ※スクリプトを作成する際に以下のマニュアルが参考になります。 https://www.zabbix.com/documentation/current/en/manual/config/items/itemtypes/browser https://www.zabbix.com/documentation/current/en/manual/config/items/preprocessing/javascript/browser_item_javascript_objects 監視データ(取得値) このような形でキューの画面の内容をテキスト保存できます。 総括 ブラウザモニタリングでSeleniumが使用できるようになり、監視設定がとても簡単になったと思います。 (Webシナリオ監視では、リクエストを自作する必要があったため、hiddenにトークンが仕込まれていたり、jQueryでお洒落なつくりをしていた場合、発狂していました。) 今後はブラウザモニタリングが主流になっていくと思いますので、ぜひご活用ください。 最後に 弊社ではZabbix関連サービスを展開しています。以下ページもご参照ください。 SCSK Plus サポート for Zabbix SCSK Plus サポート for Zabbix 世界で最も人気のあるオープンソース統合監視ツール「Zabbix」の導入構築から運用保守までSCSKが強力にサポートします www.scsk.jp ★YouTubeに、SCSK Zabbixチャンネルを開設しました!★ SCSK Zabbixチャンネル 本チャンネルでは、SCSK株式会社でのZabbixに関するトレンド/事例紹介などを動画にまとめて取り上げております。 最新のトピックについては、以下の弊社HPもしくはツイッターアカウントをぜひ参照ください。 ツイッターアカウント: www.youtube.com ★X(旧Twitter)に、SCSK Zabbixアカウントを開設しました!★ 【公式】SCSK Zabbix (@SCSK_Zabbix) / Twitter SCSKが提供するZabbixサービスのオフィシャルアカウントです。 #Zabbix #SCSKPlusサポートforZabbix #監視 #SCSK twitter.com
アバター
こんにちは!SCSK の中山です。   先日、Cato×SCSKで開催された「Catoクラウド 1Dayハンズオンセミナー@東京」に参加してきました! 私は4月に異動でCatoを担当することになり、今回は勉強のために参加させていただきましたが、”Catoとは何か”を理解するにはとても良いハンズオンでした。 少しセミナーから時間が経ってしまいましたが、今回はその内容をあくまで感想ベースで記事にしてみたいと思います。 この記事を見てCatoやセミナーの内容が気になった方は、大阪、名古屋で開催されるセミナーにページ下部のリンクよりお申し込みが可能です。   ハンズオン概要 Cato×SCSKで開催しているハンズオンセミナーは、私が参加した東京を含めた5都市で行われています。 このセミナーでは、Catoの導入にあたって使用するソケットを実際に触りながら、各機能をハンズオン形式で試すことができます。 参加人数も少ないため、ハンズオンで困った点や気になった点があれば、直接対応していただけます。 また、講師はCato社のエンジニアの方なので、その場でQ&Aに応じていただけるほか、Catoの導入を検討しているユーザー様であれば、弊社営業を含めた相談もできる体制になっています。   ●会場の様子 少人数のため、ハンズオンで詰まった時のフォローが手厚かったです。   当日のアジェンダ セクション   内容 時間 1 オープニング ・ご挨拶 ・ Cato×SCSK の取り組み紹介 ・ Cato Networks 紹介 /Cato クラウド概要 10:00–10:45 2 ハンズオン( AM ) ・ Cato 管理ポータル( Cato Management Application )概要 ・ Cato Socket ・ SD-WAN 10:45–12: 1 5 3 休憩 各自お昼休憩( 60 分) 12: 1 5–13:15 4 ハンズオン( PM ) ・ ZTNA ・ Internet Firewall/WAN Firewall ・ TLS インスペクション / アンチマルウェア /IPS ・ RBI/CASB/DLP 、等 13:15–15:45 5 クロージング ・ Q & A ・ご検討にあたって ・ Tips 、等 15:45–16:30   以降は当日の各アジェンダの概要を記載していきます。 オープニング Cato Networks社のチャネルセールスエンジニアの大森様より、Cato社、Catoクラウドの概要の説明をいただきました。 個人的に聞いていて以下の点が面白いなーと思いました。 Catoクラウドは”SASE”という言葉が生まれる前からサービス稼働している。 Catoクラウドをご存じの方はCatoクラウド=1SASE製品という認識されている方が多いのかなと思ってます。 実は”SASE”という言葉が生まれる前から、Catoクラウドは”SASE”の概念を持って設計されたサービスになっており、”SASE”という概念・言葉が生まれることにも携わっているというのが驚きでした! Catoはシングルエンジンで稼働している。 Catoクラウドには様々なサービスがありますが、基本的なサービスはすべてPoP上で処理をしており、同じ構成を使って処理をしているとのことです。 これによりユーザとしてはログが同じ形式で出てくるため、まとめて確認・検索ができるようになります。 当たり前のようにコンソールから確認してましたが、セキュリティとネットワークのログをまとめて見れるって従来のセキュリティ・ネットワーク製品では意外とできなかったなと思いました。 ハンズオン環境 今回ハンズオンで使用する環境は以下の通りです。 会場にはユーザ2名ごとにソケットが用意されており、2名ごとにこちらの環境を参加者ごとに作成しました。   ハンズオン(AM) 午前中はソケットをインターネットに接続し、Cato管理ポータル(以下、CMA)から作成したサイト(各拠点)とソケットを紐づけ、ソケットからCatoを経由して通信することを確認しました。 その後、固定IPを指定することで、固定IPからNetflixのサイトにアクセスし、日本向けではなくドイツ向けのページにアクセスできることを確認しました。 ◆サイトの作成 会場からSite接続するために、ハンズオンの会場を1つの拠点と見立ててサイトを作成。   ◆PoP指定(frankfurt) Netflixへの接続時に、フランクフルト(ドイツ)のPoPが出口となるように、Network Ruleを追加。   ◆接続確認 フランクフルトからのアクセスとみなされ、ドイツのNetflixサイトが表示されることを確認。   ハンズオン(PM) 午後は、午前に行ったソケット経由のアクセスに続いて、各PCからのクライアント接続から始まり、アジェンダに記載された各種機能(CASB、RBIなど)の説明とハンズオンを実施しました。 以下にハンズオンで実際に試した内容を紹介します。   ◆ZTNA(Zero-Trust Network Access) 今回は、コンソールからモバイルアクセス用のユーザーを新規で作成し、アクセスを行いました。 午前の内容ではサイト接続からのルールを追加していたため、モバイル接続からのアクセスではルールが適用されず、日本のNetflixのページが表示されました。   ◆CASB(Cloud Access Security Broker) CASBとはCloud Access Security Brokerの略でSaaSサービスへの処理を制限することができる機能になります。 実際に使用する場面としては、ファイルの受け渡しでクラウドストレージからファイルのダウンロードはしたいけれど、ファイルのアップロードはさせたくないという場合に使える機能です。 ハンズオンでは、YouTubeの動画再生のみを制限し、YouTubeにアクセスはできるけれど動画を見ることはできないという形でCASBを実際に試しました。 ・Application Controlより、YouTubeの「watch stream」をブロックするルールを追加。 ・YouTubeの動画が見れないことを確認。 ◆RBI(Remote Browser Isolation) RBIとは、手元のクライアントのブラウザから直接Webページにアクセスするのではなく、クラウドの仮想環境上のブラウザからWebページにアクセスし、その映像をクライアントのブラウザに表示する機能です。 これにより、クライアントから直接Webページにアクセスすることがないので、Webページに含まれる脅威からクライアントを守ることができます。 Catoでは、危険なページへのアクセスはそもそもブロックすべきとのことで、グレーなサイトへのアクセス時に使用することが推奨されています。 今回のハンズオンでは、グレーゾーンのサイトへのアクセスではなく、RBIのテスト用のページにアクセスしました。   ・RBIが有効化されていることの確認。 ・Internet FirewallにCategoryが「Uncategorized」「Undefined」のページに対して、Actionが「RBI」でアクセスするようなルールを追加する。 ・「rbicheck.com」というRBIのテストサイトにアクセスし、ファイルのダウンロードが防がれていることを確認する。 最後に 私が参加したハンズオンセミナーの内容の一部を記事にしてみました。 今回のハンズオンや説明を受けた内容は、Cato導入時に必要な作業や知識であり、私のようにCatoを扱い始めた人や、今Catoの導入を検討しているけれど何ができるか、何をすればいいのか分からないという人にピッタリの内容だと思います。 東京開催は終わってしまいましたが、まだ4か所で開催予定ですので、 Catoクラウドを触ってみたい! Catoって何ができるのか、イマイチ分からん、、 という方々は、場所や時間の都合もあるかと思いますが、ぜひ参加してみてください!   ●大阪(日程:7/18(木)) 世界初のSASEプラットフォーム Catoクラウド ハンズオンセミナー《午後開催》~全国5都市開催(東京/大阪/名古屋/博多/札幌)~ クラウドサービスの利用が拡大しワークスタイルが大きく変化する中、ランサムウェアを始めとするサイバー攻撃はより複雑・巧妙化し、被害は拡大の一途をたどっています。そこで、従来のネットワーク/セキュリティのレガシーアーキテクチャが抱える様々な課題... www.scsk.jp   ●名古屋(日程:7/25(木)) 世界初のSASEプラットフォーム Catoクラウド ハンズオンセミナー《午後開催》~全国5都市開催(東京/大阪/名古屋/博多/札幌)~ クラウドサービスの利用が拡大しワークスタイルが大きく変化する中、ランサムウェアを始めとするサイバー攻撃はより複雑・巧妙化し、被害は拡大の一途をたどっています。そこで、従来のネットワーク/セキュリティのレガシーアーキテクチャが抱える様々な課題... www.scsk.jp
アバター