SCSKクラウドソリューション の技術ブログ
全1141件
こんにちは、SCSKの前田です。 HAクラスターソフトウェアである LifeKeeper を利用するにあたり、一般的の用語や専門的の用語が出てきます。 今回は、皆さんがクラスターソフトを少しでも身近に感じられるよう、各用語について説明していきたいと思います。 HAクラスターとは？ LifeKeeper が HAクラスターソフトウェアと言うことで、HAクラスターから説明したいと思います。 この「 HA 」とは、「 High Availability 」、日本語に訳すと高可用性となります。 また「クラスター」とは、複数のサーバーをまとめて1台のサーバーとして見せるシステムの事を指します。 よって、HAクラスターとは、サーバーを複数台使用して、冗長化することで障害が発生したとしてもシステムの停止時間を最小限に抑え、業務の可用性(Availability)を向上させるクラスターシステムとなります。 もし、業務が稼働しているサーバーで継続が不可能な障害が発生した場合、他の正常なサーバーに業務の切り替えが行われ、システム全体として業務が継続されるようになっています。 業務用のアプリケーションが起動しているサーバーで障害が発生しても、違うサーバーで同じ業務用のアプリケーションが起動させるので、業務が続けられるんだね。 ノードとは？ 続いて、LifeKeeperでも良く登場する、ノードについて説明したいと思います。 「ノード」（node）とは、「結び目」「集合点」「節」といった意味になるようです。 Wikipediaによると、下記の通り項目によってさまざまな内容が出てきます。 ノード (ネットワーク) – ネットワークの節点。 ノード (グリーンランド) – グリーンランド北東部にある基地。 頂点 (グラフ理論) – グラフ理論における頂点や節点。ノードとも呼ばれる。 節点 (言語学) – 統語論において、範疇表示のある点。 Nord – クラビアのシンセサイザー製品。 Node.js – V8 JavaScriptエンジン上に構築されたJavaScript実行環境 そこで、LifeKeeperとしてのノードに関しては、ずばりクラスターを構成するサーバーの事を意味します。 例えば、1台のサーバーでご利用いただく Single Server Protection であれば1ノードでの構成になり、LifeKeeperを使って2台のサーバーでクラスターをご利用いただく場合、2ノードでの構成となります。 それ以上に可用性を高めるため3台のサーバーでクラスターをご利用いただく場合、3ノードでの構成になります。 LifeKeeperのライセンス購入も、ノード単位となっています。 リソースとは？ 「リソース」（resource）とは「供給源」「資源」「財源」など資源を意味する英語です。物質的なものに限らず、様々な分野における抽象化された資源を表す用語として広く使われいます。 LifeKeeperでは、保護する アプリケーション やファイルシステム(共有領域)や仮想IPアドレス等、「リソース」として管理しています。アプリケーションやファイルシステム毎を個別にリソースが作成され、作成されたリソースに対し、停止や開始が行えるとともに自動で監視が行われ、異常と判断された場合は自ノード上で再起動が行われます。（設定によってリソースの再起動を無効にすることが可能です。）それでも異常が解消しない場合は他ノードへの切り替えが自動的に行われます。 稼働系と待機系とは？ 「稼働系と待機系」とは、どの様な事なのでしょうか？ LifeKeeper等のHAクラスターソフトウェアとしては、複数台のノードを冗長化し、まとめて1つのノードとして見せるシステムになっています。 具体的には、複数台のノードでリソースが開始されているノードもあれば、リソースが開始されていない(停止されている)ノードも存在することになります。 このリソースが開始されているノードの事を稼働系ノードと言います。逆にリソースが停止されているノードの事を待機系ノードと言います。 フェイルオーバーとは？ LifeKeeperをはじめとしてHAクラスターソフトウェアで良く耳にする用語として、フェイルオーバーがあります。 この「フェイルオーバー」について説明したいと思います。 「フェイルオーバー」とは、稼働系ノードでサーバーやリソース等の問題が発生し、業務が続行できないような状態になった際、稼働系ノードから待機系ノードへリソースの状態を 自動的 に切り替えることを言います。 LifeKeeperでは、人の手を介入することなくソフトの観点から、ノードの異常やリソース（アプリケーション等）の異常を自動で検知し、障害と判断された場合は、自動的に稼働系ノードから待機系ノードに切り替えることで、業務を停止してしまう時間を極力減らすことが出来るソフトウェアになっています。 スイッチオーバーとは？ HAクラスターソフトウェアとして「フェイルオーバー」に似ている言葉として「スイッチオーバー」があります。 最後に「スイッチオーバー」について説明したいと思います。 稼働系ノードにてメンテナンスやバックアップ等、何らかの理由によりOSを停止する必要があるが、業務はそのまま停止したくない場合があります。そのため、稼働系ノードでの業務を待機系ノードに切り替える必要があります。 このように、稼働系ノードで開始しているリソースを 手動 で待機系ノードに切り替えることを「スイッチオーバー」と言います。 「スイッチオーバー」を実施することで、一旦稼働系ノードのリソースが停止され、待機系ノードでリソースが開始される処理が実行されるため、一時的に業務が途切れる事象が発生します。 そのため、「スイッチオーバー」を実施する際は業務が一時的に途切れても問題のない時間帯に実施する必要があります。 まとめ 今回はHAクラスターソフトウェアであるLifeKeeperで良く使われている用語について説明して来ましたが、いかがでしたでしょうか？少しでもLifeKeeperを身近に感じて頂けたら幸いです。 次回はLifeKeeperの内部で使われている機能の用語について説明したいと思いますので、お楽しみに！ 公式ホームページ： 「LifeKeeper」で安定稼働を実現 ｜ SCSK株式会社
こんにちは。SCSKの山口です。 今回は、BigQueryのテーブルにCSVデータを取り込む際、何度も遭遇したエラーたちと、その解消方法をご紹介します。 データを取り込む方法としては、下記「bq load」コマンドでGCS→BQに取り込むことにします。 実行コマンド bq load –skip_leading_rows=1 [データセット].[テーブル] gs://[バケット/フォルダ]/[ファイル名] コマンドのオプション等、詳細情報は下記ドキュメントをご参照ください。 bq コマンドライン リファレンス 使用するテーブル情報です。 データが入ると祝福されます。 エラー①：データ内に「”」がある 原因データ こんなデータの時に発生します。 clm1（STRING）がご丁寧に「”」で囲まれているのと、濁点が「”」になってますね。（誰だこんなことしたのは。） 発生するエラー こんなエラーが発生します。 Data between close quote character (“) and field separator. エラー内容的には、「 引用符（”）と区切り文字（,）の間になんか変なヤツが居るよ 」みたいな感じですね。 構造化すると、最初の「””」のセットで囲まれている、 “おめで” 部分が「データ」として認識され、 とう” 部分が「変なヤツ」と認識されています。 実はこれ、 データの先頭に「”」がある場合 に発生し、「おめて”とう”」や「おめて”とう」のような場合は発生しません。 解消方法 入れたいデータに合わせて二パターン紹介します。 データ両端の「”」が不要な場合 BigQueryに「おめて”とう」の形で入れたい場合の解消方法です。 この場合は、データ内の「”」をエスケープしてあげることで解消できます。 わかりづらいですが、データ内の「”」は前に「”」をもう一つつけることでエスケープ可能です。 実行コマンド bq load –skip_leading_rows=1 yamaguchi_blog.bqinsert_error gs://yamaguchi_blog_bqerror/double_quote.csv おめて”とうございます。データが入りました。 データ両端の「”」が必要な場合 BigQueryに「”おめて”とう”」の形で入れたい場合の解消方法です。 この場合は、 引用符として別の文字を設定する のが一番簡単です。 bq loadのコマンドを使う場合、 デフォルトの引用符は「”」で設定 されています。この引用符を変更することで解消可能です。 下記コマンドを実行します。 実行コマンド bq load –skip_leading_rows=1 –quote=# yamaguchi_blog.bqinsert_error gs://yamaguchi_blog_bqerror/double_quote.csv 今回は「#」を引用符として設定しましたが、 データに含まれてなさそうな文字 を選ぶのがポイントです。 コマンドを実行すると、 “おめて”とう”ございます。データが入りました。 エラー②：データ内に「,」がある 原因データ CSVのデータ内に「,」があることで区切り位置がおかしくなり、「テーブルのスキーマ数とレコードのデータ数が合わないよ。」と怒られるエラーです。 こんなデータの時に発生します。 スキーマ数が2つなのに対し、データが３つになっていますね。 発生するエラー こんなエラーが発生します。 Too many values in line. Found X column(s) when expecting Y 「行内のデータが多すぎるわ、Y個だと思ってたらX個あったわ。」といった感じですね。 解消方法 本来ならばCSV形式のデータ内の「,」はご法度ですが、今回は特別に「,」がデータ内にある状態で取り込む方法をご紹介します。 データ全体を引用符で囲む 先ほども登場した、引用符が活躍します。 実行コマンド bq load –skip_leading_rows=1 yamaguchi_blog.bqinsert_error gs://yamaguchi_blog_bqerror/comma.csv おめ,でとうございます。データが入りました。 区切り文字をタブ文字に変更する 区切り文字の変更で回避することも可能です。 この方法は、大規模なデータの際に有効です。 データのエクスポート時に区切り文字を「タブ文字」に変更しておくことで、全データに対する置換処理を省くことができます。 わかりづらいですが、色付部分がタブ文字になってます。 実行コマンド bq load –skip_leading_rows=1 –field_delimiter=’\t’ yamaguchi_blog.bqinsert_error gs://yamaguchi_blog_bqerror/comma.csv 区切り文字（field_delimiter）をタブ文字に変更しています。 おめ,でとうございます。データが入りました。 エラー③：データ内に「改行」がある 原因データ データ内に改行が含まれる際に発生します。 発生するエラー こんなエラーが発生します。 CSV table references column position X, but line contains only Y columns. テーブルのX番目にあたるデータを見ようとしたけど、データがY個しかないよ。といった感じです。 データがまだ続くと思いきや改行があり、（実際には次の行にデータが続くが）その先データが無いように見えているのであれ？となっているんですね。 解消方法 改行許可オプションを使う 改行許可オプション「 — allow_quoted_newlines 」という便利なものが用意されています。これを使って解消します。 このオプションを使うには、データを引用符（デフォルトでは「”」）で囲む必要があります。 実行コマンド bq load –skip_leading_rows=1 — allow_quoted_newlines = true yamaguchi_blog.bqinsert_error gs://yamaguchi_blog_bqerror/newline.csv 改行許可オプションを有効にしています。 おめ でとうございます。データが入りました。 まとめ BigQueryにCSVデータを取り込む際にあたったエラーを備忘録を兼ねてまとめました。 大規模データの際は、これらのエラーが複合的に出てくることがあります。 その際も、今回ご紹介した解消方法を組み合わせることで（だいたいは）解消可能です。 また新たなエラーに遭遇した際は共有します。
本記事は 新人ブログマラソン2024 の記事です 。 お疲れ様です。USiZEサービス部第三課の織田です。 今回はvCLSについてまとめてみました。 vCLSとは、私が仕事でよく利用するVMwareの製品の一つである、vSphereの機能の一つです。 vCLSが有効であるとどんないいことがあるのか、無効にするとどのような影響があるのか、を中心に調べてまとめました。 vCLSとは 初めにvSphere関連の用語を簡単に説明します。 用語 説明 仮想マシン ESXiホスト上で動作する仮想のコンピュータです。VM（Virtual Machine）と表記されることもあります。 ESXiホスト ESXiがOSとしてインストールされた物理的なコンピュータです。 仮想マシンはESXiホストのリソースを使用して稼働します。 クラスタ 複数のESXiホストの管理単位です。各ESXiホストのリソースを管理します。 vCenter vSphere環境全体を管理する中央管理ツールです。 ※以下はイメージ図です。わかりやすくするため、かなり簡略化しています。 vSphereのvCLS (vSphere Cluster Services) とは？ 今回紹介する vCLS (vSphere Cluster Services) は、vSphere 7.0 Update 1以降で導入されたクラスタの機能です。 ※参考サイト１，参考サイト２ vCLS機能を有効にすると、小さな仮想マシンが作成され、クラスタのリソース管理などを補助します。 以下はイメージ図です。 図のように、通常の仮想マシン（VM）よりも、小さな仮想マシンが作成されます。 参考サイト１： https://techdocs.broadcom.com/jp/ja/vmware-cis/vsphere/vsphere/8-0/vsphere-resource-management-8-0/vsphere-cluster-services-vcls.html （vSphereクラスタサービス） 参考サイト２： https://knowledge.broadcom.com/external/article?legacyId=80472 （vSphere Cluster Services (vCLS) in vSphere 7.0 Update 1 and newer versions） vCLSの主な役割 クラスタの健全性維持 vCLSはクラスタ内のホストが適切に機能しているかを監視し、クラスタ管理機能を維持します。 つまり、vSphere環境全体を管理するvCenterが一時的に利用できない場合でも、クラスタの一部機能が継続されます。 vCLSはvCenterが一時的に停止した際に、クラスタの健全性を代わりに維持する機能。 具体的な機能については、以下で説明します。 DRS (Distributed Resource Scheduler) の継続運用 DRSとは、「クラスタ内の仮想マシンのリソース配分を最適化する機能」です。 以下はイメージ図です。 図の説明をします。 はじめは左のESXiホストにVM（仮想マシン）が集中しており、各VMのリソース使用量が同じであるとした場合、各ESXiホストで使用されるリソースに不均衡が生じます。 DRSによって、各ESXiホストのリソース消費が均等になるようにVMの再配置が行われます。（この時VMはvMotionという機能によって無停止でホストを移動させられます。 ※vMotionはVMwareの用語です。一般的には、仮想マシンを無停止で別ホストに移動することをライブマイグレーションといいます。 なお、DRSはvCLSの登場と同時に、DRSの動作のためにはvCLSが有効であることが必須となっています。 ※参考サイト３ DRSによってクラスタのリソースを適切に配分することが可能となる。 DRSの動作にはvCLSが必須。（vSphere 7.0 Update 1以降） ※参考サイト３ 参考サイト３： https://techdocs.broadcom.com/jp/ja/vmware-cis/vsphere/vsphere/8-0/vsphere-resource-management-8-0/creating-a-drs-cluster.html#GUID-CAF3CDC4-469F-4FA4-ACFD-24F5F36847EA-en （DRS クラスタの要件） その他参考サイト： https://techdocs.broadcom.com/jp/ja/vmware-cis/vsphere/vsphere/8-0/vsphere-resource-management-8-0/creating-a-drs-cluster.html （vSphere DRSクラスタの作成） HA (High Availability) とは独立 HAとは、「クラスタ内のESXiホスト停止時に、停止したESXiホストで稼働していた仮想マシンを別ホストで自動的に再起動する機能」です。 以下はイメージ図です。 図の説明をします。 はじめに3台のESXiホストそれぞれで3台づつVM（仮想マシン）が稼働している状況で、一番右のESXiホストが突発的に何らかの障害で停止したとします。 この時、HAの機能によってホストの停止を検知し、停止したESXiホストで稼働していた3台のVMを残り2台のESXiホスト上で再起動します。 HAはDRSとは異なり、動作のためにvCLSは必須というわけではありません。 ただ、VMを再起動する際に、どのESXiホストで起動するかを適切に選択するためには、DRSの動作が必要になっています。 ※参考サイト４ HAによってESXiホストの障害発生時にVMが自動で再起動される。 HAの最適な動作のためにはDRSが必須であり、DRSの動作のためにはvCLSが必須。 ※参考サイト４ 参考サイト４： https://techdocs.broadcom.com/jp/ja/vmware-cis/vsphere/vsphere/8-0/vsphere-resource-management-8-0/vsphere-cluster-services-vcls.html#GUID-F98C3C93-875D-4570-852B-37A38878CE0F-en （クラスタの退避モードへの切り替え） その他参考サイト： https://techdocs.broadcom.com/jp/ja/vmware-cis/vsphere/vsphere/8-0/vsphere-availability/creating-and-using-vsphere-ha-clusters/vsphere-ha-interoperability/using-vmware-ha-and-drs-together.html （vSphere HA と DRS の併用） vCLSの構成 ここではvCLSの実態について説明します。 最初に述べたようにvCLSは仮想マシンとして稼働しています。 vCLS仮想マシンの数 以下はイメージ図です。 図を説明します。 Cluster①、②：3台以上のESXiホストによって構成されるクラスタでは、vCLS VM（vCLS仮想マシン）は3台以上存在し、それぞれ別々のホストに配置されます。 Cluster③、④：クラスタのESXiホストの台数が3台より少ない場合は、ホストと同じ台数のvCLS VMが存在し、同じくそれぞれが別のホストに配置されます。 ※vCLS仮想マシンは、手動の移動や、HAによって一部のESXiホストに偏ることがあります。 その対策として、3分ごとにチェックが行われ、自動的に複数のESXiホストに分散配置される仕組み（非アフィニティポリシー）があります。 ※参考サイト１ vCLS仮想マシンの数はクラスタのESXiホストの台数によって異なる。 vCLS仮想マシンのスペック vCLS仮想マシンは管理のためのVM（仮想マシン）であるため、ESXiホストのリソースを必要以上に使用しないために非常に軽量です。 具体的なスペックは以下の表のとおりです。 ※参考サイト５ プロパティ サイズ CPU 1 vCPU メモリ 128 MB ハードディスク 2 GB VMDKサイズ 245 MB（シンディスク） データストア上のストレージ 480 MB（シンディスク） 参考サイト５： https://techdocs.broadcom.com/jp/ja/vmware-cis/vsphere/vsphere/8-0/vsphere-resource-management-8-0/vsphere-cluster-services-vcls.html#GUID-E39875F2-2DA6-4592-A220-6014F54858D3-en （vSphere クラスタ サービスの監視） vCLSの今後 ここでは新しいvCLSである、「組み込みvCLS」について説明いたします。 vCLSには現在、「外部vCLS」と「組み込みvCLS」の2種類があります。 外部vCLSとは、これまでに説明してきたvSphere 7.0 Update 1以降で導入された従来のvCLSのことです。 組み込みvCLSとは、vSphere 8.0 Update 3以降で導入された新しいvCLSのことです。 どちらを使用するかはvCenterのバージョンによって決定されます。 組み込みvCLSは従来の仮想化による管理ではなく、コンテナとして管理されるようになり、以前にもましてリソースの消費量が抑えられています。 ※参考サイト６ リソース消費の低下には、以下の2つの組み込みvCLSの特徴が関わってきます。 ESXiホストのメモリ内で直接実行される メモリ内で実行されるため、ストレージの占有量がゼロ その他の「外部vCLS」と「組み込みvCLS」の変更点としては、 クラスタ当たりのvCLS仮想マシンの数が2つ。単一のESXiホストによって構成されるクラスタの場合のみ、vCLS仮想マシンの数が1つ。 などがあります。 vSphere 8.0 Update 3からは「組み込みvCLS」という新しいvCLSが導入されている。 参考サイト６： https://blogs.vmware.com/vmware-japan/2024/12/vmware-vsphere-8-update-3-newfeatures.html （VMware vSphere 8 Update 3 の新機能 – VMware Japan Blog） まとめ 今回の内容をまとめると以下の通りです。 vCLSはvCenterが一時的に停止した際に、クラスタの健全性を代わりに維持する機能。 DRSによってクラスタのリソースを適切に配分することが可能となる。DRSの動作にはvCLSが必須。 HAによってESXiホストの障害発生時にVMが自動で再起動される。 HAの最適な動作のためにはDRSが必須であり、DRSの動作のためにはvCLSが必須。 vCLS仮想マシンの数はクラスタのESXiホストの台数によって異なる。 vSphere 8.0 Update 3からは「組み込みvCLS」という新しいvCLSが導入されている。 今回の記事の執筆にあたりvCLSについて初めて知ったことも多数あるので、仕事に生かしていきたいと思います！
先日、Palo Alto Netwoks社より Cortex Cloudが発表 されました。 Cortex Cloudとはどのようなものか簡単に解説してみたいと思います。 Cortex Cloudとは？ Cortex Cloudは、「Prisma Cloudの次期バージョンとCortexプラットフォームのCDRを組み合わせたもの」と記載されています。 ここで少しPrisma CloudとCortexについても触れておきます。 簡単に説明するとPrisma Cloudはクラウドのセキュリティ保護プラットフォーム、Cortexは運用を強化する包括的なプラットフォームとなります。 Prisma Cloud：包括的なクラウドネイティブアプリケーション保護プラットフォーム（CNAPP）であり、コードからクラウドまでのセキュリティを提供。マルチクラウド環境にも対応。アプリケーションのライフサイクル全体を通じてリスクを排除し、リアルタイムでの脅威検出と防御を実現。 Cortex：サイバーセキュリティ運用を強化するための包括的なプラットフォーム。AIと自動化を活用して、脅威の検出、対応、予防を統合し、セキュリティオペレーションセンター（SOC）の効率を向上させる。 主要な製品として、Cortex XDR（脅威検出）、Cortex XSOAR（セキュリティオーケストレーション、自動化）、およびCortex Xpanse（攻撃対象領域管理）が含まれる。 つまり Cortex Cloud はクラウドセキュリティに対してAIと機械学習を活用して、リアルタイムで脅威を検出し、迅速に対応するセキュリティプラットフォームと考えることができます。 なぜCortex Cloudが必要なのか 現在、クラウドのインフラを攻撃から防御するのは非常に困難になってきています。 その背景にあるのがAIです。例えばフィッシングメールもAIにより、より高速に、よりパーソナライズされた仕掛けを作ることができるようになっています。その結果、侵入を防ぐことが困難になってきています。 また、攻撃者はクラウドを深く熟知し、攻撃のステップを高速に実行します。検知してから対策を実施するまでの猶予時間はどんどん短くなってきています。 かといって、すべてのアラートに対してリアルタイムに対応するのは現実的には不可能です。 そのため、Cortex Cloudのように リアルタイム脅威検出 ：AIと機械学習を活用して、リアルタイムで脅威を検出 自動化されたレスポンス ：脅威を検出すると自動的に適切な対策を講じ、セキュリティインシデントの影響を最小限に抑える 統合管理 ：ネットワーク、クラウド、エンドポイントのセキュリティを一元管理し、包括的なセキュリティ対策を提供 といった機能を提供し、セキュリティ負担の軽減、迅速な対応、コスト削減といったメリットを提供するツールが重要になってくるのではないかと思います。 まとめ クラウド環境がますます複雑化し、攻撃者の手法が高度化する中で、Cortex Cloudのようなツールは、セキュリティチームの負担を軽減し、迅速かつ効果的な対応を可能にします。これにより、企業は安心してクラウドの利便性を享受しつつ、セキュリティリスクを最小限に抑えることができるではないでしょうか。 また、クラウドセキュリティを行う上で重要なポイントして現状のクラウドセキュリティの可視化があります。まずは自身のクラウド環境がどのような状況にあるか確認することが非常に重要です。 当社ではクラウド診断のサービスを提供していますので、ご興味のある方は是非、お気軽にお問い合わせください。 マルチクラウド設定診断サービス with CSPM｜ SCSK株式会社 マルチクラウド環境のセキュリティ設定リスクを手軽に確認可能なスポット診断サービスです。独自の診断レポートが、運用上の設定ミスや設計不備、クラウド環境の仕様変更などで発生し得る問題を可視化し、セキュリティインシデントの早期発見に役立ちます。 www.scsk.jp
企業ネットワークにおける情報の持ち出し対策として、 Data Loss Prevention(DLP) が広まりつつあります。 情報の持ち出しは、正規のアクセス権限を持った人によって行われることが多く、それ自体は異常な通信ではないためにEDRやIPSでは検知できません。これをカバーする機能がDLPで、機密情報等を含むファイルの動きを検知して、通知したりブロックすることができます。 しかしながら、実際にDLPを導入しようとすると「具体的にどう制御したらいいのか?」を決めるのが難しく、当社でもご相談を受けることが多いです。 そこでこの記事では、 実際に設定されることの多いDLPルールの例をご紹介します。 設定はSASEソリューションである「Catoクラウド」のDLP機能に沿ってご紹介しますが、他のDLP製品においてもルール検討の参考にしていただけましたら幸いです。 なお、CatoクラウドのDLP機能の概要や設定方法については、当ブログ内にいくつかの記事がありますので、あわせてご参照ください。 CatoクラウドのCASBとDLPについて CatoクラウドのセキュリティオプションであるCloud Access Security Broker （CASB）とData Loss Prevention （DLP）について解説しています。 blog.usize-tech.com 2024.02.19 CatoクラウドのDLPについて Catoクラウドの情報漏洩対策にあたる「DLP」について紹介していきます！ blog.usize-tech.com 2023.10.06 DLPではどんな制御ができる? DLPでは、 あらかじめキーワードやデータ形式を指定しておき 、それを含むデータのやり取りを検知して、 通信を止めたり、管理者へ通知する ことができます。これにより、例えば 「社外秘」という文言が入った資料をクラウドサービスにアップロードしようとしたら通信を止める 、といったルールの設定が可能です。 どのようなデータを止めたい(または監視したい)のかの条件は、自社の業務やポリシーに沿って検討する必要がありますが、この条件決めがなかなか難しいため、参考になりそうな例をご紹介します。 DLPのよくある設定例 対象ファイルの条件 まずは、どのようなファイルを制御の対象にしたいのかを指定します。 「社外秘」「関係者外秘」「Confidential」といったキーワードが入っているファイル 👉️機密情報を含むファイルに対し、上記のようなキーワードの記載ルールが徹底されている場合、それを条件としてデータの持ち出しを検知できます。 クレジットカード番号やマイナンバーを含むファイル 👉️個人情報の持ち出し対策として有効です。 Microsoft製品の「秘密度ラベル」がつけられたExcel、Word等のファイル 👉️Microsoftが提供する「秘密度ラベル」機能を運用されている場合、これをDLP製品でも活用できる場合が多いです。 Pass付zip等、暗号化されたファイル 👉️条件に一致する機密ファイルでも、パスワード付きのZipファイルなどの暗号化ファイルにしてしまえば、DLP製品が中をチェックできないために、持ち出せてしまいます。これを防ぐために、暗号化ファイル自体の持ち出しを禁止することができます。 以上が一般的な例ですが、自社のルールや業務内容から「どんな情報を社外に持ち出されると困るか」を考えてみると、使えるキーワードや条件が見つかるかもしれません。 制御ルール 次に、条件に一致したファイルをどうするかを決めます。以下のような例が考えられます。 アップロード・ダウンロードをすべてログに残す 👉️有事の際に後から確認できるようにしておく目的です。 インターネット上のクラウドサービスへアップロードしようとしたらブロックする 👉️持ち出しと疑われる通信は止めてしまうという設定です。 なお、最初から通信ブロックを設定すると、想定しなかった業務影響が発生する場合があるため、初めはログを残すのみとし、実際の通信状況を確認した上でブロックへの移行を検討されるようおすすめしています。 DLP設定の例 以下に、 条件とルールを組み合わせた設定例 をご紹介します。 「社外秘」「関係者外秘」「Confidential」 のいずれかのキーワードを含むファイルについて 自社テナントのOneDriveに対しては、制限なし その他すべてのクラウドサービスへは、対象ファイルの アップロードをブロック する その他すべてのクラウドサービスへは、対象ファイルのダウンロードはログに残す 👉️実際によくある設定です。社外秘情報の持ち出しを防ぐ意図です。 Eメールアドレスを30個以上含む ファイルについて すべてのクラウドサービスへのアップロード・ダウンロードをログに残し、 管理者へ通知 する 👉️Eメールアドレスを多く含むファイルは、個人情報リストの可能性があるため監視するという設定例です。 100MB以上のファイル について 自社テナントのboxに対しては、制限なし その他すべてのクラウドサービスへの アップロードをログに残す 👉️大きなサイズのファイルのアップロードは、データの持ち出しの可能性があるため、記録しておくという設定例です。 いかがでしょうか。このように実際のルールを見てみると、DLPでできることがイメージしやすいかと思います。 DLPは本当に有効なのか? ところで、DLPの設定をしっかりと行えば、情報の持ち出しは防げるのでしょうか? 答えは残念ながらNoです。 持ち出し方法は他にも無数にあります。例えば機密情報を表示した画面をスマートフォンで撮影したり、単純に手帳に書き写したり、やりようはいくらでもあり、全てを防ぐことはできません。 しかしながら、 DLPの導入には以下の効果があります 。 DLPで監視することで、持ち出しの一部に素早く気づける。早々に対処を行うことで、情報の拡散を防ぐことができる。 DLPのログを取っておくと、万が一情報流出が起こった場合にログから流出元を特定できる可能性がある。 DLPが導入されている旨を周知することが、持ち出しに対する抑止力となる。 DLPはそれ単独で完璧なソリューションではなく、 不正の”機会”を減らすための対策の一つ であるということに留意する必要があります。 CatoクラウドのDLP機能 最後に、CatoクラウドのDLP機能についてご紹介します。 CatoクラウドのDLPはオプションでのご提供となっており、ご利用にはCASBオプション+DLPオプションのご契約が必要です。また、TLS Inspection機能が有効になっている必要があります。 DLP条件 様々な方法での条件指定に対応しています。 プリセットのデータカタログ Catoにあらかじめ設定されていて、すぐに条件として使えるものです。 日本のマイナンバーや、世界共通のクレジット番号、世界各国のID形式などが収録されており、指定するだけで条件として利用することができます。 キーワード登録・辞書登録 自社専用のキーワードや、キーワード辞書を作成して利用できます。もちろん日本語にも対応しています。 正規表現 正規表現による文字列指定も可能です。 Microsoftの機密度ラベル M365と連携することで、ユーザ定義のラベルにも対応できます。 機械学習による条件作成 識別させたいデータを複数与え、学習させて条件を作成でききます。 Exact Data Matching 実際のデータを読み込ませて、それに完全一致するデータを見つける機能です。 例えば、従業員管理台帳をDLPエンジンに読み込ませて、実際の従業員番号と氏名の組み合わせを記録することができます。※データはハッシュ化されて安全にアップロード・保存されます DLPルール 条件に合致するファイルについて、各種クラウドサービスへのアップロード・ダウンロードを、許可・ブロック・ログに残すなど、柔軟なルール作成が可能です。 ユーザ単位やグループ単位でのルールや、接続元の国、端末の条件などに基づくルールも作成できます。 また、本記事で設定例としてご紹介したルールは、すべてCatoクラウドのDLP機能で実現可能な内容です。先程の例の1つめですと、以下の設定となります。 「社外秘」「関係者外秘」「Confidential」のいずれかのキーワードを含むファイルについて Security > Data Types & Profiles > Data Types > User Defined で Dictionaryを作成する Security > Data Types & Profiles > DLP Profiles で、上記のDictionaryを指定しプロファイルを作成する 自社テナントのOneDriveに対しては、制限なし Security >App & Data Inline にて、CASB機能で自社テナントのみ Microsoft Loginを許可する設定をする (参考) CASBの制御って何をしたらいいの? ～ルールの設定例 上記のルールよりも下に、OneDriveへのDownload/UploadをAllowするルールを設定する その他すべてのクラウドサービスへは、対象ファイルのアップロードをブロックする 上記のルールよりも下に、Any Cloud Applicationに対し、指定のDLP Profilesに合致するUploadをBlockするルールを設定する その他すべてのクラウドサービスへは、対象ファイルのダウンロードはログに残す 上記のルールよりも下に、Any Cloud Applicationに対し、指定のDLP Profilesに合致するDownloadをMonitorするルールを設定する Cato管理画面での実際の操作方法等につきましては、 Catoクラウドのナレッジベース をご参照ください。 CatoクラウドのDLPの制約 Catoクラウドではこの制御をPoP上で行うため、以下のような 端末ローカルでの操作を制御することはできません 。 ❌️ 端末からUSBメモリへのコピーを禁止 ❌️ プリンタでの印刷を禁止 ❌️ スクリーンショットを禁止 また、ファイルサイズやファイルタイプ等によりDLPの動作に制約があります。こちらも詳しくは Catoクラウドのナレッジベース をご確認ください。 最後に 本記事を通して、DLPの活用イメージを持っていただけましたら幸いです。 また、CatoクラウドのDLP機能は、現在も鋭意機能拡充中です。こういった制御はできる?など導入・運用のお悩みがありましたら、ぜひSCSKへご相談ください。
こんにちは ＳＣＳＫ 池田です。 ３月に入り、桜の開花が待ち遠しい季節になりましたが、すでにお花見の予定を立て始めている人もいるとか。なかなか気が早いですね 笑 さて今回は、ちょっと解りづらいLifeKeeperのプロダクトライフサイクル（サポート）について解説したいと思います。 サポートレベルのフェーズは大きく３つに分けられる LifeKeeperのサポートフェーズは、大きく以下の３つに分けられ、「技術的な支援」や「不具合などの問題への支援」の内容が異なります。 ※細かく分けると「ライフサイクル年長プラス」というフェーズもありますが、説明を簡単にする為、本ブログでは３つについて解説します。 サポートフェーズ サポート内容 1 フルサポート 未知の 製品不具合に対するパッチを作成し提供する 2 メンテナンスサポート 既知の 不具合に対するパッチを提供する。 本フェーズ以降に発見された未知の不具合については最新バージョンへのアップデートを案内する。 3 ライフサイクル延長 標準のサポート契約に加えて、 「ライフサイクル延長サポート」もご契約いただいた際 に、メンテナンスサポートと同レベルのサポートを提供する ※ユーザーポータルからのお問い合わせに対しての回答となります。 それぞれのフェーズ毎の「技術支援」「不具合などの問題への支援」に関してサポートされる内容の違いは上記の通りですが、このほかにも以下のサービスが提供されます。 ・ライセンスアカウントの再発行 ※ライセンスシステムのログインID再発行、バージョンアップ手順の案内を含む ・バージョンアップ版の無償利用 これらを整理すると以下のマトリクスで表現できます。 サポートフェーズ ライセンスアカウント再発行 バージョンアップ版の無償利用 技術支援/問題対応支援 不具合パッチの利用 1 フルサポート 〇 〇 〇 〇 2 メンテナンスサポート 〇 〇 〇 ー 3 ライフサイクル延長 〇 〇 〇(※1) ー (※1)標準のサポート契約に加えて、「ライフサイクル延長サポート」もご契約いただいた際に、メンテナンスサポートと同レベルのサポートを提供する サポートフェーズ期間はOSによって期間が異なります ご存じの通り、LifeKeeperにはLinux版とWindows版とありますが、 OSごとにサポートフェーズの期間とその考え方が異なります。 Linux版のサポートフェーズ期間 以下の表をご覧ください。 こちらはサイオステクノロジー社の公式サイト「プロダクトライフサイクル」の画面となりますが、Lifekeeper for Linuxの最新バージョンであるv9.9.0は、フルサポート終了日以降が決定していないことが判ります。 この理由は、Linuxのサポート期間の考え方が 次のアップデートリリース時が起点となる ためです。 一つ前のバージョンであるv9.8.1を例にすると判りやすいと思います。 以下のようにv9.8.1は2024年3月にリリースされていますが、この時点ではフルサポートの終了日が決まっていません。 そして2024年9月に次のアップデートリリースであるv9.9.0がリリースされました。 この時点で、v9.8.1のフルサポート終了日が2027年8月末（v9.9.0のリリースから3年後）と定まるのです。 ■LifeKeeper for Linux v9.8.1のサポート期間 次のアップデートリリースが起点になるなんてユニークな考え方ね Windows版のサポートフェーズ期間 では、Windows版のLifeKeeperのサポートフェーズ期間はどうなるのでしょうか？ Linux版と異なり、最新バージョンのLifeKeeper for Windows v8.10.2のフルサポート終了日が既に決まっています。 従いまして、以下のように 当該バージョンのリリース時点で、フルサポート期間、メンテナンスサポート期間、ライフサイクル延長期間の終了日が確定 しています。 Windows版は「ライフサイクル延長期間」が短い Windows版の場合、もう一点注意が必要なのが「ライフサイクル延長期間」が2年と短い という点 です。Linux版とWIndows版のライフサイクルを並べてみました。Linux版の場合は5年のライフサイクル延長期間が設けられています。 特に Linux版 と Windows版の混在 するシステム では、ライフサイクル延長期間の違いを十分に理解した上で、 「Windows版のライフサイクル延長期間の費用を見込んでなかった」 ということがないように気を付けましょう。 LifeKeeperの次期バージョンに期待！ ここまでご説明したとおり、LifeKeeperはLinux版とWindows版で、サポートフェーズの考え方も期間も異なります。 これは製品開発の歴史などの背景によるものと思われますが、これにより少なからず誤解や混乱を招いている部分もある為、LifeKeeperの次期バージョンv10では、「LifeKeeper」という統一的な考え方にもとづいた製品開発に期待したいものです。 まとめ 今回は、LifeKeeperのサポートフェーズについて解説しましたが、いかがでしたでしょうか？ まとめると、、、 ・サポートフェーズは主に3つ（フルサポート、メンテナンスサポート、ライフサイクル延長） ・OSによりサポート終了の考え方が異なる ・Windows版の、ライフサイクル延長は2年と短い ・次期バージョンにおける製品サポートに関する考え方の統一に期待
こんにちは。SCSKの山口です。 今回は、Google Cloud認定資格の受験レポート その①です。 はじめに 先日、Google CloudのAssociateレベルの認定資格として、下記二つの認定資格が追加されました。 ・ Associate Data Practitioner ・ Associate Google Workspace Administrator 全冠維持継続中の私にとっては見逃せないニュースでしたが、 Associate Google Workspace Administrator に関しては、前身となるProfessional Workspace Administrator を取得済みであれば有効期限が切れるまでは何とかなるようです。 問題は「 Associate Data Practitioner 」です。 情報収集として、社内で受験済みの人がいないか探し回っていますが、本ブログ執筆時点で見つけ切れず、なんとか自力で対策するしかなさそうです。。。というわけで、今日から対策を始めようと思ったのですが、「せっかくだから受験前後でブログ書いてみよう」と思いつき、今日から執筆を始めました。 受験前後のブログではそれぞれ下記を書こうと思っています。 [受験前] ・対策内容 ・抑えておく要点 [受験後] ・合否 ・出題内容（受験前の想定とのギャップ） ・抑えておいた方が良い要点 本ブログ執筆時点の筆者はこんな感じです。 Google Cloud歴 3年目 BigQuery一番よく触っている Professional Data Engineer取得済み 最新のTOEICスコア：645（※試験が英語版しかないので書きました。） 対策内容 ここでは、受験前に実際に取り組んだ対策の内容を書きます。 とりあえず試験ガイドを見てみる 試験ガイドは、認定資格ページにリンクが貼ってあります。 https://services.google.com/fh/files/misc/v1.0_associate_data_practitioner_exam_guide_english.pdf?hl=ja 英語があまり堪能ではないので、PDFでダウンロードして「 NotebookLM 」にアップして日本語で読みました。 ドキュメントをほとんど翻訳しただけの内容を書きますが、あまり深読みせず、「こんな感じのが問われるんだな。」と大まかな内容を把握するために使いました。 ①データ準備と取り込み（～30％） このセクションでは、その名の通り「データの取り込み～利用可能な状態にするまでのプロセス」に焦点が当てられています。 データ処理方法（ETL,ELT,ETLT）の理解と適切な選択 データ転送ツールの適切な選択 データの品質評価とクレンジング データ形式の識別とストレージ選択 この辺りが問われるそうです。 ②データ分析とプレゼンテーション（～27％） このセクションでは、データの分析、可視化、機械学習モデルの活用に関する知識とスキルに焦点が当てられます。 BigQueryとJupyter Notebookを用いたデータ分析 Lookerを用いたデータ可視化とダッシュボード作成 機械学習モデルの定義、トレーニング、評価、利用 この辺りが問われるそうです。 ③データパイプラインのオーケストレーション (~18%) このセクションでは、データパイプラインの設計、実装、自動化、監視に関する知識に焦点が当てられます。 適切なデータ変換ツールの選択 ELTとETLの使い分け データ処理タスクのスケジュール、自動化、監視 イベントドリブンデータ取り込みの活用 この辺りが問われるそうです。 「ELTとETLの使い分け」に関しては、①のデータ処理方法と重複しているように見えますが、ここでは ETLとELTのユースケースを評価した上での適切な選択 が求められるようです。 ④データ管理（～25％） このセクションでは、アクセス制御、ライフサイクル管理、高可用性と障害復旧、セキュリティ対策とコンプライアンスなど、データ管理の重要な側面に焦点が当てられます。 アクセス制御とガバナンス ライフサイクル管理 高可用性と障害復旧 セキュリティ対策とデータプライ バシー規制への準拠 この辺りが問われるそうです。 とりあえず模擬試験を受けてみる 模擬試験は、認定資格ページにリンクが貼ってあります。 Associate Data Practitioner Sample Questions The Data Practitioner sample questions will familiarize you with the format of exam questions and example content that m... docs.google.com 試験の詳細な内容はここには載せませんが、正解率は12/20でした。（まずい、、、） 英語なのもあり、ちょっと難しく感じます。 ここまでの内容をふまえ、受験前に抑えておいた方が良いと思われる（実際に学習した）内容を書きます。 抑えておく要点 試験ガイドと模擬試験の内容を加味し、試験前にこれだけは押さえておこうと思っている内容を書きます。 ETL/ELT で登場するサービス 本試験には、ETL/ELTを実現するために使用する多くのサービスが登場しそうです。 登場しそうなサービスと特徴、ユースケースを私がわかる範囲でまとめます。 サービス名（元名称） 機能概要 特徴・ユースケース Dataflow（Apache Beam） 大規模なデータ処理パイプラインを構築・実行するための フルマネージドサービス データの検証とクリーニング リアルタイム処理とバッチ処理を どちらも処理可能 低レイテンシ オンプレミス、Google Cloud内どちらのソースデータにも対応可能 スケーラビリティ 処理頻度にバラツキがある際にも有効 データ品質 の問題を解消 Dataflowテンプレート： ユーザ定義関数（UDF） で機能拡張が可能 Dataproc（Apache Hadoop、Apache Spark） Apache Hadoop および関連エコシステムをクラウド上で実行するための マネージドサービス 他サービスとの連携が容易 大規模な並列処理 が可能 Dataprocサーバレス：インフラ管理が不要 Dataprocワークフローテンプレート：ジョブ管理とスケジュール管理に特化。メール通知機能もあり Data Fusion コード不要でデータ統合・変換処理を構築するためのクラウドネイティブETLサービス 他サービスでは対応が難しい 複雑な処理 （入力ファイルの解析等）が必要な際に最適 多様なデータソースに対応 GUIで直感的に パイプライン構築 コーディング不要 Cloud Composer（Apache Airflow） 複雑なワークフローを定義・管理するフルマネージドワークフローオーケストレーションサービス DAG （有効非巡回グラフ）をPythonで記述 複雑なワークフロー をカバー スケジュール 機能 再試行ポリシー で失敗したタスクを監視＋再実行 各フローの 依存関係の管理 が可能 試験で特に重要になりそうなのが、 「元名称」 と 「特徴・ユースケース」 です。 元名称は、例えば、「 Apache Hadoopの処理を移行したい 」など、移行元のワークフローが特定されているような問題の際に使えます。この場合は「 Dataproc 」を使用している選択肢に絞り込むことができます。 元名称で特定できない場合に、「特徴・ユースケース」の知識を使います。問題文中の要件に合わせてサービスを選択できます。 ETL/ELTの使い分け 模擬試験の内容を見る限、割と明確に処理の順序が記載されている（Loadする前にTransformしたい。とか）ので、軽く表にまとめます。 方式 処理順序 メリット デメリット ETL 抽出 → 変換 → ロード データ品質確保 DWH負荷軽減 柔軟性欠如 変換処理に時間かかる ELT 抽出 → ロード → 変換 柔軟性高い リアルタイム分析 DWH負荷増大 データ品質管理が必要 Data Fusionを使うかどうか 試験問題を解く際、数を熟していくと 「これはData Fusion使う必要あるのか、、、？（スケジュールクエリとかで事足りるのか、、、？）」 という分かれ道に立つことが多くなると思います。 その際に使える判断基準の例を書いておきます。 ・複雑なデータ変換処理が必要か？ ・データソースはどこか？（BigQuery or その他） ・問題に登場するユーザのスキルは？（SQLに精通、開発経験がない、GUIで開発したい、など） 「複雑なデータ変換」かどうかは抽象的過ぎてこれ以上明確な切り分けが難しいですが、複雑な変換の場合、複雑さが問題文の表現からプンプン匂ってくるような表現がされている場合が多いです。 具体的な処理で言うと、 ・NULL値の排除 ・ 重複排除 ・データフォーマット統一 くらいであれば、BigQuery上でクエリ実行したほうが手っ取り早いです。 BigQuery BigQueryは他試験でもかなり多く目にするGoogle Cloudの目玉サービスの一つですが。本試験でもかなり多くの問題に登場しそうです。 模擬試験の出題内容から、抑えておいた方が良いと思われる項目を書きます。 アクセス制御 BigQueryのアクセス制御は、ユーザに行わせる（許可する）アクションに合わせて下記ロールを付与する必要があります。 許可する処理 必要なロール データ閲覧（読み取り） BigQueryジョブユーザ BigQuery閲覧者 データ編集（読み取り＋書き込み） BigQueryジョブユーザ BigQuery編集者 SELECTのようなデータの閲覧しか行わないユーザには「閲覧者」 UPDATEのようなデータの編集を行うユーザには「編集者」を付与する必要があります。 また、上記どちらのユーザも 「クエリの実行」 は行うので、 「ジョブユーザ」 を付与する必要があります。 暗号化 Google Cloud内のデータは、基本的に Googleが管理する暗合鍵（GMEK） で デフォルトの暗号化 がされています。 一方で、暗号化に 顧客管理の暗号鍵（CMEK） を使用することもできます。CMEKを使用することで、複雑な暗号化要件に対応することもできます。詳細は 公式ドキュメント をご参照ください。 似た用語で、 顧客提供の暗号鍵（CSEK） があります。CSEKは顧客がGoogleのインフラストラクチャ外で暗号鍵を管理できるため、 Googleから暗号鍵にアクセスされたくない ような厳格な規制要件がある際に使用されます。 本試験では、GMEK、CMEK、CSEKに加えて「 認証付き暗号化（AEAD） 」も取り扱われるようです。 AEAD 暗号化関数を使用すると、暗号化と復号に使用する鍵からなる鍵セットを作成し、これらの鍵を使用して テーブル内の個々の値を暗号化および復号 できます。 たとえば、BigQueryテーブルの列レベル、行レベルで暗号化を適用する。みたいな使い方が可能です。 パーティショニング BigQueryには、日時のカラムでデータを論理的に分割するパーティショニング機能があります。詳細は過去ブログをご覧ください。 【GCP】BigQuery -パーティショニングによるコスト削減- BigQueryでの「テーブルの論理パーティション分割の有効性」についてご紹介します。 blog.usize-tech.com 2023.04.04 本試験では、パーティショニング機能を活用したGoogle Cloud内でのデータの整理が出題されるようです。たとえば、下記のような要件、実現方式があります。 [要件] ・BigQueryに分析用のデータをため込んでいる ・最初の一年間は分析に利用される（頻繁にクエリされる） ・一年経過後は、長期保管に切り替える [実現方式] ・BigQueryをパーティション分割する（月単位） ・一年経過後にCloud Storageへエクスポートする このようにしてデータを順次移動させていくことで、コストを抑えたデータ管理を実現することができます。 また、長期保管用のCloud Storageのストレージクラスを要件に合わせて選択することでよりコストパフォーマンスを高めることができます。（詳細は後ほど書きます。） 公開データセット BigQuery には 一般公開データセット と呼ばれる一般提供のデータセットが用意されています。 世界の気象データ 国勢調査データ（アメリカ） 小売店の販売実績データ など、様々な種類のデータが大量に用意されており、なんと Googleがこれらの保存費用を負担 してくれています。 我々ユーザは、これらのデータへアクセスし、様々な用途に使用することができますが、もちろん「クエリ料金」は発生します。 むやみにエクスポートやコピーをしてしまうと膨大な料金が発生してしまう恐れがあるので、必要に応じて 「参照」だけ を行うことが推奨されます。 Cloud Storage これまた他試験でも馴染みのあるサービスですが、知識が必要になりそうなところがあるので説明します。 冗長化と高可用性 GCSのデータの冗長化、高可用性を実現する方式は、下記の二つがあります。 マルチリージョン デュアルリージョン かなり似た概念で、混乱すると思うので下記表でまとめます。どちらも、複数のリージョンにデータを複製する手法です。 マルチリージョン デュアルリージョン データの場所 複数の大陸にまたがる2つ以上のリージョン 例）アジアとヨーロッパのリージョン 特定の2つのリージョン 例）アジア内の二つのリージョン 可用性 非常に高い（広範囲な障害に対応） 高い（リージョンレベルの障害に対応） レイテンシ グローバルアクセスに最適 特定の地域へのアクセスに最適 コスト 高 （マルチリージョンと比較すると）低 ユースケース グローバル、ミッションクリティカルなアプリケーション リージョンレベルの障害対応、地域特化型アプリケーション、データ所在地規制 ストレージクラス Cloud Storageには ストレージクラス と呼ばれるオプションがあり、 保存するデータの性質によって適切な選択 をすることでコストパフォーマンスを最大化することができます。 BigQueryの章で紹介したパーテイショ二ングと組み合わせることで、 要件に合わせた高コスパなデータ保管 が実現できます。 また、オブジェクトに対する操作の状況に応じて自動的にストレージクラスを設定することができる「 オートクラス機能（Autoclass） 」といった便利なものも存在します。 各クラスの概要は下記のとおりです。 ストレージクラス 最小保存期間 オペレーション料金 ストレージ料金（GB/月）※東京リージョン Standard なし なし $0.023 Nearline 30日 $0.01/GB $0.016 Coldline 90日 $0.02/GB $0.006 Archive 365日 $0.05/GB $0.0025 最小保存期間 Standard以外のクラスには「最小保存期間」が設定されています。 オブジェクトがバケットに保存された後、削除や移動を行った場合でも、各storageクラスで定められた最小保存期間分の料金が発生します。 例えば、Nearlineのバケットに保存したオブジェクトを10日後に削除した場合でも、30日分の料金が発生します。その分、 移動等をせず保存しておくだけなら料金が抑えられる ってことですね。 オペレーション料金 Standard以外のクラスには「オペレーション料金」が設定されています。 バケットに保存されたオブジェクトデータ（またはメタデータ）を読み取り、コピー、移動、書き換えする際に発生します。 長期保存（Archive）の予定だったけど、思いのほかオペレーションの対象になってしまった。となると、割高な料金が発生してしまいます。 データ転送ツール BigQuery Data Transfer Service（BDTS） BDTS は、あらかじめ設定されたスケジュールに基づいて BigQuery へのデータの移行を自動化するマネージドサービスです。 下記を使用することが可能です。 Google Cloudコンソール bqコマンドラインツール BigQuery Data Transfer Service API サポートされているデータソースの全容は 公式ドキュメント をご参照ください。Googleのサービス（Google広告、Youtubeなど）だけでなく、 AWSやSalesforce、Olacle のサービスのほか、オンプレミスからの転送もサポートしている点は把握しておく必要があります。 Storage Transfer Service（STS） STS を使用することで、オンプレミスや他ストレージサービスから、 Cloud Storage へのデータ移動をシームレスに行うことができます。 下記の特徴があります。 データ転送を自動化 ：手動プロセス、カスタムスクリプトが不要 大規模データ転送 ：ペタバイト単位のデータも移動可能 ネットワークパフォーマンスを最適化 ：シンプルさを求めるならマネージド転送。ルーティングと帯域幅を制御したいなら自己ホスト型エージェントを使用 移行ステータスの確認が可能 ：移行ステータスの詳細なレポートを取得可能 Transfer Appliance Transfer Appliance は、Googleアップロード施設に転送して安全にデータを保存できる大容量ストレージデバイスで、データはGoogleアップロード施設から Cloud Storage にアップロードされます。 実際には、下記手順で実施します。 Transfer Applianceをリクエスト：要件に適したアプライアンスを選択 データをアップロード：アプライアンスにデータをアップロード Transfer Appliance を返送：データアップロード完了後、アプライアンスを返送する Google がデータをアップロード：Cloud Storage バケットにデータがアップロードされる 代表的なユースケースとしては、下記が考えられます。 インターネット経由のデータ移動に 時間がかかりすぎる 場合 データ移動に使用できる 帯域が十分に確保できない 場合 オフライン でのデータ移動を行いたい場合 セキュリティ要件 が高い場合 Looker 模擬試験を解いて、一番驚いたのが「Looker」に関する出題です。 ここでは要点だけ書きますが、Lookerが初耳の方は 公式のドキュメント をご確認ください。 Lookerは、一言で言うと 「可視化ツール（BIツール）」 です。 LookML というモデリング言語を使用し、SQLデータベース内のデータを使って、ビジネスユーザーが理解しやすい形でデータ分析を行うための土台を作ります。 LookMLの主な要素 Lookerでは、Viewファイル内でDimensionとMajorを定義し、データを集計・分析します。 Explorer：ユーザが実際にでーあを探索、分析するためのインタフェースを定義する。 View：データベースのテーブルやビューを指す。分析の対象となるデータを定義する。 Dimension：分析の軸（観点）となる項目（日付、地域、商品名など）を定義する。 Major：集計、計算される値（売上、利益、顧客数など）を定義する。 Lookerでのアクセス制御 LookerではGoogle CloudのIAMと同様、ユーザを「グループ」でひとまとめにし、まとめて権限を付与することができます。 Google Cloud同様、Lookerにおいてもグループへの権限付与がベストプラクティスとされています。 まとめ いったん、ここまでの内容（＋これまでの知識）で試験挑んできます。 更新なかったら察してください、、、
本記事は 新人ブログマラソン2024 の記事です 。 皆さんこんにちは！入社して間もない新米エンジニアの佐々木です。 最近、Snowflakeの比較的新しい機能である「 コンピュートプール 」について調査する機会がありました。 そこで本記事では、コンピュートプールについて調べたことを皆さんと共有したいと思います！ 特に、公式ドキュメントに記載されている細かい内容というよりも、 コンピュートプールの概要について初学者でも分かりやすいようにお話できればと思います。 まだ触れたことのない方も、既に利用している方も、ぜひご覧ください！ コンピュートプールとは何か？ コンピュートプールとは、 1つ以上の仮想マシン（VM）ノードを複数集めたサーバー群 です。 分かりづらい方は「コンピューターの力を集めた場所」と考えてください。例えるなら、複数の人が集まって一つのチームとして働くようなものです。 仮想マシンとは、一台の物理コンピューターの中で動く、仮想的なコンピューターです。このVMをたくさん集めて、まとめて使えるようにしたものが、仮想マシンノードを集約したコンピュートプールです。 他にも似たクラウドサービスの代表例として、Amazon EC2、Google Compute Engine、Microsoft Azure Virtual Machinesなどがあります。 コンピュートプールの作成 では、実際にコンピュートプールを作成する際の手順についてですが至って簡単です。 コンピュートプールは CREATE COMPUTE POOL コマンドを使って、ユーザーが自由に作成・管理することができます。 具体的には、ワークシートで以下のクエリを実行することで、コンピュートプールを作成することが可能です。 CREATE COMPUTE POOL tutorial_compute_pool MIN_NODES = 1 MAX_NODES = 3 INSTANCE_FAMILY = CPU_X64_XS ; 上記で設定している必須プロパティの意味は以下の通りです。 MIN_NODES ：コンピューティングプールで起動する最小ノード数。 MAX_NODES ：コンピューティングプールがスケールできる最大ノード数。これにより、Snowflakeの自動スケーリングによって予期せぬ数のノードがコンピューティングプールに追加されることを防ぐことができます。 INSTANCE_FAMILY ：コンピューティングプールノードにプロビジョニングするマシンタイプ。 これらのプロパティをプロジェクトの規模やニーズに応じて変更することで、スケーラビリティの確保やコスト最適化などにつなげることができます。 他にも設定できるプロパティは複数あるのでプロパティの詳細について気になる方は、以下の公式ドキュメントを参照してみてください！ CREATE COMPUTE POOL | Snowflake Documentation コンピュートプールの利点 ではコンピュートプールの利点は何なのか？についてですが、私が調査した限りだと以下の5つが挙げられるかと思います。 柔軟なリソース管理： 複数のVMノードをプールとして管理できるため、ワークロードに応じて柔軟にリソースを割り当て、最適化できます。 コスト効率の向上： 個々のVMノードは必要な時に必要な分だけリソース（CPUやメモリ）を使います。そのため、使用していないVMノードを自動的にスケールダウンすることで、コストを削減できます。 高可用性の実現： プール内のVMノードに障害が発生した場合でも、自動的に別のVMノードに切り替えることで、高可用性を実現できます。 スケーラビリティ: ワークロードの負荷に応じて、VMノードを簡単に追加、削除をすることができます。これにより、ワークロードのピーク時でも、プール内のVMノードを自動的にスケールアップすることで、パフォーマンスを維持できます。 管理の簡素化： たくさんのVMを個別に管理するのは大変ですが、コンピュートプールを使うと、まとめて管理できます。VMの状態を監視したり、ソフトウェアをアップデートしたりするのが簡単になります。 特に上記で既述した「スケーラビリティ」について触れると、コンピュートプールは自動的にサイズ調整する自動スケーリングの仕組みを持っています。 まず、プールを作成すると、Snowflakeは最低限必要な数の仮想マシン（ノード）を起動します。その後、作業量が増えて現在のノードでは処理しきれなくなると、自動的に追加のノードを起動して処理能力を増強します。 例えば、既に2つのサービスが動いていて、新たに別のサービスを追加すると、そのサービスに必要なリソースに応じて自動的に新しいノードが追加されます。 逆に、ある期間、ノードがほとんど使われなくなると、Snowflakeは不要になったノードを自動的に削除してコストを削減します。そのような場合でも、コンピュートプールは最低限必要なノード数を維持します。 つまり、コンピュートプールは、作業量に合わせて自動的にサイズを調整し、常に最適なリソースを使用する仕組みになっているということです。ユーザーは、常に最大の処理能力を確保しつつ、無駄なコストを削減できます。 考えられる利用用途 コンピュートプールの利用用途として考えられるものを以下にいくつか挙げてみました。 1. データウェアハウス処理： 複雑なSQLクエリの実行： 大量のデータを集計、分析、変換するための複雑なSQLクエリを実行します。例えば、数年分の売上データを地域別、商品別に集計して、売れ筋商品を特定するような処理です。 大規模データセットの結合： 複数のテーブル（例えば、顧客テーブル、注文テーブル、商品テーブル）を結合して、より詳細な分析を行います。 高度な分析： データ分析に必要な高度なSQL関数（例えば、移動平均、累積和、順位付け）を実行します。 2. データエンジニアリング： ETL/ELTパイプラインの実行： 外部システムからデータを抽出（Extract）、変換（Transform）、ロード（Load）するプロセスを実行します。 データ変換： データをクレンジング、整形、標準化し、分析しやすい形に変換します。 データ検証： データの品質を維持するために、データの整合性や正確性を検証します。 3. ビジネスインテリジェンス（BI）: BIツールとの連携： Tableau、Power BI、LookerなどのBIツールからSnowflakeに接続し、データを可視化するためのクエリを実行します。 ダッシュボードの作成： 重要なビジネス指標を監視するためのダッシュボードを作成します。 レポートの生成： 定期的なレポートを生成します。 4. データサイエンス/機械学習： 特徴量エンジニアリング： 機械学習モデルのトレーニングに必要な特徴量をデータから抽出します。 モデルのトレーニング： Snowflakeのデータを活用して、機械学習モデルをトレーニングします。 モデルのデプロイと予測： トレーニング済みのモデルをSnowflakeにデプロイし、新しいデータに対する予測を行います。 リアルタイムデータ分析： ストリーミングデータソースからリアルタイムに近い形でデータをSnowflakeにロードし、分析します。 他にも利用用途は複数あるとは思いますが、上記だけでもコンピュートプールが様々なユースケースで役立ちそうなことが分かるかと思います。 まとめ 本記事では、Snowflake のコンピュートプールについて大まかな概要を調査しました。 その結果コンピュートプールは、複数の仮想マシンノードを束ね、クエリ実行やデータ処理といったワークロードを処理するための強力なリソースだと感じました。ただし、コンピュートプールを効果的に利用する上では、ワークロードの特性をよく理解し、適切なサイズと構成を選択することが何よりも重要だと思いました。 しかし、今回の調査だけではコンピュートプールの表面しか見ることができなかったのが実状です、、、 そのため今回の調査を踏み台に、次回以降で実際にコンピュートプールを活用したチュートリアルを実施して、コンピュートプールとは何ぞや？をもう少し深ぼってみたいと思います！
本記事は 新人ブログマラソン2024 の記事です 。 こんにちは。SCSKの さとです。2025年がもう6分の1が終わろうとしていることに愕然としています。 さて、2月にAmazon Bedrock Flows新機能のエージェントノードにおけるマルチターン会話がプレビュー公開されたので、今回はその「やってみた」記事です。 アップデートの概要 Amazon Bedrock Flows がマルチターンの会話サポートのプレビューを発表 - AWS AWS の新機能についてさらに詳しく知るには、 Amazon Bedrock Flows がマルチターンの会話サポートのプレビューを発表 aws.amazon.com Amazon Bedrock Flowsは、基盤モデルやプロンプト、Amazon Bedrockエージェントなどを ノードとして扱い 、 GUI上で相互に関連付ける ことで生成AIワークフローを簡単に構築できるようになるというサービスです。 今回のアップデートでは、エージェントがタスクを行うにあたり、必要に応じてフローを停止し、会話の往復の中で情報を取得しタスクを完了することが可能になりました。これにより、アクションの完了のために追加の情報取得が必要になった場合でも同一フローを用い続けることができず、エージェントがコンテキストを忘れてしまうという問題が解消されるようになります。 やってみた：企業の情報取得ボットの作成 というわけで、早速アップデートされたAmazon Bedrock Flowsのマルチターン会話を試してみたいと思います。 今回は、社員番号によって給与の額が決まる架空の企業「Exploitation Inc.」に関する情報を答えるチャットボットという設定でフローを組んでみます。このため、給与に関する質問を投げかけられると、チャットボットは社員番号について情報提供を依頼する必要があります。 Amazon Bedrock Flowsに触れるのは今回が初めてということで、本筋とは離れますが条件分岐を用いた複数種類のクエリへの対応も試してみました。フロー構成は以下の公式ブログを参考にしています。 Introducing multi-turn conversation with an agent node for Amazon Bedrock Flows (preview) | Amazon Web Services Today, we’re excited to announce multi-turn conversation with an agent node (preview), a powerful new capability in Flow... aws.amazon.com 処理の流れ ご覧のように、全体としてはFlow inputからユーザーの入力が各ノードに渡され、最終的にFlow outputへ到達したデータがレスポンスとなります。今回は、ユーザーからの質問をざっくりと「給与関係」「それ以外」に分け、それぞれで回答を行うようフローを作成しました。主要なノードの役割とその設定は以下の通りです。 Promptノード: QueryClassifier Promptノードは、フロー内で基盤モデルにプロンプトを送信し、その応答を取得するために使用することができます。ユーザーからの入力（Flow Inputの出力）はこのノードが受け取り、質問の内容に応じて分類されます。プロンプトはBedrockのプロンプト管理機能からのプロンプトを用いることもできますが、ここではノードで新たに定義しました。 {{input}}を分析し、ユーザーからの質問が給与に関する事項ならばAを、それ以外ならばBを出力してください。出力は必ず1文字であり、それ以外は受け付けられません。 ここで、{{input}}は入力に対してデフォルトで割り当てられている変数名で、上のように波括弧で括ることで指定できます。また、回答の信頼性を高めるため、出力の温度は低めの0.1に設定しました。 Conditionノード: QueryType Conditionノードでは条件の判定結果に応じて次の処理を行うノードを指定することができます。 QueryClassifie r のOutputから QueryType のInputまでを線で接続することで入出力関係を指定し、分かりやすさのため、さらにこの入力にQueryTypeという名前をつけます。 次に、条件とその分岐先を指定します。 QueryClassifier において入力が「給与関係」ならば出力がA、「それ以外」ならばBと指定したので、条件式を QueryType==”A” とし、これが真ならば次のノードとして AboutSalary へ、そうでなければ AboutOtherTopics へ移るよう設定を行います。 Agentノード： AboutSalary 、 AboutOtherTopics 分岐先のAgentノードを設定します。ここでは、作成済みのBedrockエージェントに対して入力を送信する処理が行われます。 ユーザーからの入力をもとに回答を作成するので、Flow Inputから各AgentノードのInputまでを接続します。ここで、フローのダイヤグラムにおいて紫色の点線で示されるConditionノード-Agentノード間の接続はあくまで処理の分岐を表すだけで、 入出力関係を表している訳ではない ということに注意が必要です。 また、これらのノードに紐つけるBedrockエージェントを別途作成・準備します。給与に関して応答を行うエージェントには以下のプロンプトを与えました。 あなたは、ユーザーから受け取ったExploitation Inc.の給与に関する質問に回答します。 回答にあたり、以下の事実を用いてください。 <ルール> 給与は、社員番号のみによって決定する。 社員番号 1〜10000: 年収1億円 社員番号 10001〜: 年収0円 給与以外に関して応答するエージェントも同様に設定します （このエージェントはマルチターン会話とは関係がないので、プロンプトは割愛します） 。 それぞれをFlow Outputノードへと接続し、ユーザーへの返答にします。 フローをテストする 一通りの設定が完成したので、フローの設定画面右側からテストをしてみましょう。 給与を確認すると、上のように追加で社員番号を聞かれました。エージェントへのプロンプトは追加で確認をさせるような文言が入っていないので、デフォルトでこのような指示が組み込まれていると考えられます。 続いて、社員番号を与えてみます。 給与に関して回答してくれませんでした。よく見ると、1回目の質問への返答があった直後に「 Flow ended in 45 seconds 」とフローが終了していることが示されており、そのまま社員番号の情報だけ渡したためその他の質問として扱われてしまっているようです。 どうやら、追加の情報取得を行うにはBedrockエージェント側で「ユーザー入力」を有効にする必要があったようです。その他の設定からオプションを有効にし、改めて試してみます。 謎に謝られてしまいましたが、想定通りの回答になりました。一応、社員番号 1〜10000でも指定した回答になるか試してみましょう。 無事、年収が1億円になりました。今回は簡単のためにプロンプトに直接情報を入れてしまいましたが、実際の場面ではエージェントを通してナレッジベースから情報を取得するなどが可能です。 おまけ：その他の話題に関する質問 せっかくなので、もう一方の条件分岐先であるその他の話題についても適切に回答されるか試してみましょう。 こちらも、あらかじめ設定した通りの内容が回答されました。 おわりに いかがでしたか？これまでだと不足する情報に対し情報提供を求めるには処理フローを追加する必要がありましたが、今回のアップデートではそのような部分がBedrock側で自動化されるため、かなりシンプルに実装が可能になったのではないかという印象を持ちました。 最後までお読みいただき、ありがとうございました。
SCSKの畑です。 以前のエントリ で少し触れた通り、Redshift テーブルのデータメンテナンスアプリケーションの実装にあたり、テーブルデータの表示や編集に使用したライブラリの Tabulator について、使用した理由や特徴をまとめてみました。このため、今回は完全にアプリケーション実装に閉じた話題となります。 なお、Tabulator の公式 URL は以下の通りです。 Tabulator - Interactive JavaScript Tables Create interactive data tables in seconds with Tabulator. A free, open source, fully featured JavaScript table / data gr... tabulator.info ライブラリの要件及び選定理由 本案件事例における期間や工数の関係から、全ての機能を自前で作り込むのは難しいと考えていました。特に、テーブルデータの表示/編集については主要機能であり、かつ画面/ロジック両方の実装が必要になることから、できるだけ（出来の良い）外部ライブラリを使用しつつ必要に応じて手を加えるような形で進めるのが理想と考えていました。 ライブラリの選定における要件をまとめると、概ね以下の通りです。 ソフトウェアライセンスの観点で問題なく使用でき、かつ費用がかからないこと テーブル（表）形式のデータの表示及び編集機能を備えていること テーブル（表）形式のデータの表示及び編集のどちらについても基本的な機能を備えており、かつ必要に応じて拡張できること Nuxt(Vue) に対応していること（実装例があること） Web 上のドキュメントやナレッジがある程度充実していること で、平たく言うとこのような要件を満たすものとして一番筋が良さそうだったのが Tabulator でした。 まず、当時私が探した限り、1.及び2.を満たすライブラリがほとんど見当たらなかったのが一番大きな理由です。テーブル（表）形式のデータの表示のみであれば多種多様なライブラリがありましたが、いわゆるエクセルライクにテーブルデータを編集できるようなライブラリとなると数が大分限られました。その限られた選択肢においても出来の良さそうなものは表示機能のみなら無償だが編集機能を使用する場合は有償にとなったりしたため、この時点で実質的にはほぼ Tabulator の一択であったというのが正直なところです。 表示機能のみライブラリを使用し、編集機能（画面）は自前で実装する or 他のライブラリを活用するというアプローチも可能だったと思いますが、メンテナンス対象のテーブルやテーブル定義が変わり得る以上、各テーブルごとに編集画面を作成するのはコストや運用の観点から現実的ではありませんでした。各テーブルに拠らない汎用的な編集画面を作ろうとするとそれはそれでコストがかかる上、お客さんの画面イメージとしてもエクセルライクにテーブルの項目をそのまま編集できることが望ましいとのことで、やはりこのライブラリが良さそうだなと。 このため、3.以降は実質的にオマケというかあったら嬉しいな程度の内容だったのですが、それらの要件も満たしていたため最早このライブラリを選ばない理由がないと判断できました。 もちろん全てのライブラリを網羅して探すことはできなかったと思うので、もし他に良さそうなものがあればご教示頂けますと幸いです。それなりに気合を入れて探したつもりではあるので、簡単に見つかってしまったらちょっとショックかもしれないですが・・w ライブラリで特に役立った・あって良かった機能 使用方法や各機能については公式ドキュメントの出来が良いため本エントリでは割愛し、ここではアプリケーション実装において特に役立った、あって良かったと感じた機能について簡単に所感を述べていこうと思います。 現時点で最新バージョンが 6.3 であるため、公式ドキュメントへのリンクは全て同バージョン向けとなっています。 Tabulator - Documentation Create interactive data tables in seconds with Tabulator. A free, open source, fully featured JavaScript table / data gr... tabulator.info 検索（フィルタ）/ ソート / ページネイト いずれの機能もテーブルデータの表示機能において標準的に求められる機能だと思うのですが、これらの機能が全て標準で備わっていたのが良かったです。（最も、このような機能は他ライブラリでもある程度備わっていたものが多かったので、そこまで特筆すべきことではないのかもしれませんが・・） Tabulator - Filtering Data Use custom or built in filter fuctions to allow users to view a subset of table data tabulator.info Tabulator - Sorting Data Allow users to order table data with a range of built in and custom sorter functions tabulator.info Tabulator - Pagination Break data down into pages to make it easier to digest tabulator.info また、後述する項目とも共通しますがこれらの標準機能は細かな設定変更が可能なものが多く、これらの機能については完全にライブラリの標準機能のみで賄えたという点も良かったです。例えばエクセルの列フィルタライクな検索機能や、テーブル画面初期ロード時のソート条件指定、ページネイトにおける1ページあたりの件数指定の動的な変更などですね。 ローカルファイルからのデータロード こちらの機能もライブラリの標準機能でカバーできました。これも自前で実装するとなると地味に面倒な機能だったので良かったです。対応しているファイルフォーマットも複数種類あります。それほど柔軟性はなさそうなので、より細かい要件に対応する場合は自前でファイルのインポート処理を実装して、本ライブラリに組み込むことも可能です。 このような拡張性は後述する他機能においても充実しており、実装例も公式ドキュメントに一通り示されており開発も大きく躓くことなく進められたことも大きかったです。要件の項目で述べた通り、Web 上のナレッジもそれなりにはありました。 Tabulator - Loading Data Tabulator can load data from a wide range of sources, learn how to load data from arrays, JSON and AJAX sources tabulator.info データバリデーションチェック 実装コストの観点で最も助かったのがこの機能です。 Tabulator - Data Validation Validate user entered data before accepting it into the table tabulator.info 過去のエントリでも言及している通り本アプリケーションの主要機能（要件）でもあり実装は必須でしたが、テーブル定義や制約に準ずるバリデーションチェック機能を全て一から実装するのはさぞかししんどいだろうなと思っていたところ、データ型や標準的な PK/UK（単一列）、NOT NULL など制約のバリデーションチェックは標準機能で対応できたというのがまず助かりました。 複数列による PK/UK 制約（複合キー制約）や FK 制約については未対応だったのですが、ユーザで定義/実装した独自のバリデータを本ライブラリのバリデーション機能に組み込むことができるため、それを活用することでライブラリ側のバリデーションチェックの枠組みの中でこれらのチェックについても実施することができました。フロントエンド（画面）側の機能実装としては山場となったポイントの1つでしたが、これらの特徴のおかげで想定以上にコストを抑えられたのもありがたかったです。 また、バリデーションチェックのタイミングも幾つかの選択肢の中から任意に設定できる点も良かったです。デフォルトでは画面上でデータを編集した直後のタイミングなのですが、先述したローカルファイルからのロードについてはライブラリ上「編集」という扱いではないこと、一時的に列定義/制約に反するデータを入力したいケースもあることが想定されたことの2点より、任意のタイミングでバリデーションチェックを実行できる方が望ましかったのですが、そのような実装も可能だったため支障ありませんでした。 もちろん、バリデーションチェックを実行して合格しない限りはテーブルデータの更新ができない（更新フローが進まない）ようなロジックとしています。 データのプルダウン入力 主に FK 制約のある列の値入力に使用しました。 FK 制約により、入力可能な値は FK 参照先のテーブル/列の値に限定されるため、データを自由入力させずにそれらの値をプルダウン形式で入力できた方がユーザビリティの観点から優れていると考えて、この機能を使用しました。 Tabulator - Editing Data Use built in cell editors to allow users to edit table data, or build out your own for fully customizable table input tabulator.info プルダウン入力候補のデータを動的に定義できることは当然として、候補データのインクリメンタルサーチなども標準でサポートされていたためプルダウン候補の多いデータ入力にも支障ありませんでした。FK 参照先のテーブルからも同時に値を取得する必要があるなど、こちらの機能もフロントエンド（画面）側で山場となったポイントの1つでしたが、同様に実装コストを抑えることができました。 Mutators & Accessors テーブルデータをライブラリを使用して画面表示する際にデータを加工・変換するため機能です。それぞれ、Mutators はデータ自体を変換、Accessors は表示のみを変換します。 Tabulator - Mutators & Accessors Manipulate data as it enters or leaves a table tabulator.info 本アプリケーションにおいては、テーブルデータ内の一部の ID 値を論理名のような分かりやすい表示に変換するために使用しています。具体的には以下のような用途です。 FK 制約のある列に入る値（FK 参照先テーブルの ID 列の値）を、アプリケーションマスタで定義した論理名に変換 論理名自体も FK 参照先テーブルの値を使用しています。例えば、国マスタの ID を国名（論理名）に変換するような処理が可能です。 更新対象行の作成者/更新者列に入る値（ユーザ ID）を、ユーザの氏名表示に変換 ユースケースに応じて Mutators/Accessors を使い分けられる点も含めて機能自体が便利なことはもちろん、データの加工・変換ロジックは自由に実装できるようなライブラリの作りとなっていたため、FK 制約のようにやや複雑な変換ロジックにも対応できました。また、変換ロジックに該当しないようなデータはそのまま変換せず表示することも可能であるため、柔軟性も持たせることができています。 まとめ 正直、このライブラリなしでの本アプリケーションの実装はなかなか厳しかったのでは、と感じるレベルではお世話になりました。テーブル/表の編集機能が必要となるようなアプリケーションの実装では今後積極的に使用していこうと思えるレベルで作りが良かったです。 最も、躓いた点もいくつかあったことはあったので、機会があれば別エントリでまとめてみたいと思います。 本記事がどなたかの役に立てば幸いです。
こんにちは、ＳＣＳＫ 池田です。 LifeKeeperの購入前に、「LifeKeeper」がどういう製品か知りたいことってありますよね？ ネットで検索したり、メーカー公式ホームページを観たり、TechHarmonyを観たり、様々な確認方法があるかと思いますが、製品仕様の細かなところなどはどうしても記載されていないケースがあると思います。 購入前なのに質問できます！ そんな時はなんと購入前でも、メーカーであるサイオステクノロジー社のサポートに質問することができるんです！ サポートへのお問い合わせ方法 – SIOS LifeKeeper/DataKeeper User Portal まず、会社名、部署名、氏名、メールアドレス、連絡先電話番号を入力してください。 その後に「お問い合わせ内容のカテゴリ」を選択します。 選択肢は以下の通りです。 ■お問い合わせ内容のカテゴリ ・価格/構成 ・機能/動作 ・構築環境 ・実績/事例 ・その他 「お問い合わせ内容」を記載して、個人情報の提供にチェックを入れて、最後に「私はロボットではありません」の手続きを踏んでください。 たったこれだけで、サイオステクノジー社からお問い合わせに対する回答を得られます。 また何らかのミドルウェアの構築をご検討でしたら、LifeKeeperのSI&サポートパートナー(ゴールド)のSCSKまでメールにてお問合せください。 SCSK株式会社 LifeKeeperチーム メールアドレス： LK@scsk.jp 公式ホームページ： 「LifeKeeper」で安定稼働を実現 ｜ SCSK株式会社 お問い合わせ・ご相談： HAクラスターソフトウェア「LifeKeeper」 お問い合わせ｜ SCSK株式会社 20年以上に渡る豊富な設計、構築、サポート実績から、お客様の求める可用性の実現のお手伝いをさせていただきます。 それぞれの使い分けとしては、製品仕様など最新情報の入手時にはサイオステクノロジー社のWebフォームから、 SIをご希望、構築可能な構成、LifeKeeperに留まらない様々なパターンの可用性提案をご希望されるような時にはＳＣＳＫへ問い合わせするなどしていただければと思います。 もしＳＣＳＫ LifeKeeperチームでお答えできない場合でも、ＳＣＳＫ社内の有識者やサイオステクノロジー社と連携しながら、お客様の疑問にお答えさせていただきます！ まとめ 今回は、購入前の問い合わせ方法についてご紹介しました。 問い合わせ方法は大きく３つあります。 ・サイオステクノロジー社の公式サイトのWebフォームから問い合わせる ・ＳＣＳＫのメールアドレスに問い合わせる ・ＳＣＳＫの公式サイトのお問い合わせ・ご相談Webフォームから問い合わせ
Amazon EC2 の外からOSコマンドを実行させるには、AWS Systems Manager (SSM) の SendCommand を用いるのが常道だと思いますが、環境上の制約で使用できない場合もあるかと思います。そこでSSMを使用することなく、OSコマンドを実行させるシンプルな仕組みを作ってみます。 (sshでのコマンド実行は自明ですし、AWSに関係ないのでここでは触れません。) Systems Manager(SSM)とSendCommandについて 先ずはSSMとSendCommandについて軽く触れます。 SSMの SendCommand とは、SSMのマネージドノードとなっているEC2に対して、EC2の外からOSコマンドを送って実行できます。 「外から送って」と書くと、EC2に外からコマンドが入ってくる形のように思えますが、実際にはEC2で稼働しているssm-agent がSSMのエンドポイントに対してポーリングしており、 コマンドを取ってくる 形になっていると思われます。 (そうでなければEC2へのインバウンド通信許可を必要とするはずですが、実際にはそんなことはしません。) この構成を真似することにします。 構成の概要 上図の構成とします。SSMの位置にSQSを配置し、そこにOSコマンドを入れる。EC2はQueueを定期的に監視するシェルスクリプトを常駐させて、キューにコマンドが入っていればそれをフェッチして実行します。要するにssm-agentの簡易版で置き換えた形だというだけです。(がっかりした人はすみませんm(_ _)m ) 以下、EC2とSQSの内容について簡単に述べておきます。 SQSについて キューは以下の構成とします。 標準キューであるということと、メッセージ保持を1分にしています。あまり長くするとagent役のshellの障害時などにキューにコマンドがたまり、思わぬ昔のコマンドが実行されてしまうことを防いでいます。1分以上フェッチされなければそのコマンドは実行されませんが、そこは割り切っています。また、キューポリシーは適当に設定します。 EC2について シェルが動けば何でもいいですが、上記SQSキューに対して、 sqs:ReceiveMessage および sqs:DeleteMessage の権限が必要ですので、EC2にアタッチするIAMロールに付与しておきます。 ポーリングスクリプトとサービス化 ポーリングスクリプト ポーリングシェルは以下のように作成してみました。シェルの詳細についてはこの話題の主題ではありませんので細かくは触れません。 #!/bin/bash # SQSキューURL (適宜変更) QUEUE_URL="https://sqs.ap-northeast-1.amazonaws.com/xxxxyyyyzzzz/TestQueue" # ログディレクトリとファイル設定 LOG_DIR="/var/log/command-execution" LOG_FILE="$LOG_DIR/command_execution.log" # ログディレクトリの作成 if [ ! -d "$LOG_DIR" ]; then sudo mkdir -p "$LOG_DIR" sudo chown ec2-user:ec2-user "$LOG_DIR" sudo chmod 755 "$LOG_DIR" fi # ログファイル作成 touch "$LOG_FILE" chmod 644 "$LOG_FILE" echo "[$(date)] SQS polling service started." >> "$LOG_FILE" while true; do # SQSからメッセージ取得 RESPONSE=$(aws sqs receive-message \ --queue-url "$QUEUE_URL" \ --max-number-of-messages 10 \ --wait-time-seconds 10 \ --output json 2>/dev/null ) # RESPONSEが空ならデフォルト値を設定 if [ -z "$RESPONSE" ]; then MESSAGE_COUNT=0 else MESSAGE_COUNT=$(echo "$RESPONSE" | jq '.Messages | length' 2>/dev/null) if [ -z "$MESSAGE_COUNT" ]; then MESSAGE_COUNT=0 fi fi if [ "$MESSAGE_COUNT" -gt 0 ]; then echo "$RESPONSE" | jq -c '.Messages[]' | while IFS= read -r MESSAGE; do # ReceiptHandleとBodyを安全に取得 RECEIPT_HANDLE=$(echo "$MESSAGE" | jq -r '.ReceiptHandle' 2>/dev/null) COMMAND=$(echo "$MESSAGE" | jq -r '.Body | @sh' 2>/dev/null | sed "s/^'//;s/'$//") # 無効メッセージ判定 if [ -z "$RECEIPT_HANDLE" ] || [ -z "$COMMAND" ]; then echo "[$(date)] Warning: Invalid message detected. Skipping..." | tee -a "$LOG_FILE" continue fi # コマンド実行 TIMESTAMP=$(date "+%Y-%m-%d %H:%M:%S") echo "[$TIMESTAMP] Executing command: $COMMAND" | tee -a "$LOG_FILE" { echo "----- START: $COMMAND -----" eval "$COMMAND" EXIT_CODE=$? echo "Exit Code: $EXIT_CODE" echo "----- END: $COMMAND -----" } >> "$LOG_FILE" 2>&1 # メッセージ削除 DELETE_RESPONSE=$(aws sqs delete-message --queue-url "$QUEUE_URL" --receipt-handle "$RECEIPT_HANDLE" 2>&1) if [ $? -eq 0 ]; then echo "[$(date)] Command executed and message deleted." | tee -a "$LOG_FILE" else echo "[$(date)] Error deleting message: $DELETE_RESPONSE" | tee -a "$LOG_FILE" fi done fi sleep 5 done 5秒(sleep 5)ごとに指定のキューからメッセージの取得を試みます。この値はSQSの料金に影響します。 コマンド実行後はメッセージを削除しています。 また、受け取ったコマンドと実行結果をログに出力するようにしています。オプションでこのログをCloudWatch Logs に連携してもいいでしょう。配置場所は/usr/local/bin/sqs-polling.sh とします。パーミッションは適当につけておきます。 サービス化 上記スクリプトをサービス化するため、systemdのユニットファイルを作成します。 [Unit] Description=SQS Polling Service After=network.target [Service] ExecStart=/usr/local/bin/sqs-polling.sh Restart=no User=ec2-user Environment="PATH=/usr/bin:/usr/local/bin" [Install] WantedBy=multi-user.target 上記を/etc/systemd/system/sqs-polling.service として保存して、以下コマンドでサービス起動・確認します。active(running)を確認してください。 sudo systemctl daemon-reload sudo systemctl start sqs-polling.service sudo systemctl status sqs-polling.service 動作確認 ではキューにコマンドを置いてみます。簡単にSQSのマネコンから実行します。loggerコマンドで/var/log/messagesに文字列を吐き出してみます。 /var/log/messages Feb 28 14:25:59 ip-10-0-0-210 sqs-polling.sh[5414]: [2025-02-28 14:25:59] Executing command: logger "hello . Tech Harmony!!!!!!!!!!!!!!!!!!!!!!!!!!" Feb 28 14:25:59 ip-10-0-0-210 ec2-user[5415]: hello . Tech Harmony!!!!!!!!!!!!!!!!!!!!!!!!!! Feb 28 14:26:01 ip-10-0-0-210 sqs-polling.sh[5422]: [Fri Feb 28 02:26:01 PM JST 2025] Command executed and message deleted. シェルのログファイル [2025-02-28 14:25:59] Executing command: logger "hello . Tech Harmony!!!!!!!!!!!!!!!!!!!!!!!!!!" ----- START: logger "hello . Tech Harmony!!!!!!!!!!!!!!!!!!!!!!!!!!" ----- Exit Code: 0 ----- END: logger "hello . Tech Harmony!!!!!!!!!!!!!!!!!!!!!!!!!!" ----- [Fri Feb 28 02:26:01 PM JST 2025] Command executed and message deleted. となって動作が確認できました。 キューにコマンドを置くことができれば何でもいいので、例えばLambda関数が該当キューにOSコマンドをputすれば、Lambdaが間接的にEC2のOSコマンドを打ったことになります。 最後に EC2から他のAWSサービスへの連携はAWS CLIなどを使えば容易なのですが、AWSサービスからEC2(の中)への連携は手段が限られているように感じましたので、少し考えて作成してみました。 要点は、EC2から外部の状態を取りに行く、という点です。ここではSQSを例にしましたが、S3などを考えても面白いでしょう。 (定期的にS3のあるオブジェクトの存在を確認し、存在すればダウンロードして(以下略)) やったことはssm-agentの超簡易版を作成したに過ぎませんが、そこまで複雑でないことはわかっていただけたと思います。 コマンドの結果をサービス側で知るにはもうちょっと考える必要はありそうです。 SSMが使えるならそちらを使うべきだとは思いますが、色々な制限でそれが叶わない場合の選択肢として、皆様の参考になれば幸いです。 コードの使用は自己責任でお願いいたします。
本記事は 新人ブログマラソン2024 の記事です 。 こんにちは。入社一年目の曲渕です。 現在はAWSの技術習得に向けて勉強している最中です。その際に AWS Cloud9 を使ったAWSのハンズオンを実施したのですが、私のAWSアカウントではCloud9が使用できなくなっていました。そこで本記事では、私と同じような状況になっている方や今年入社される方の参考になればと思い、Cloud9に代わるサービスをご紹介させていただこうと思います。 背景 AWS Cloud9 とは AWSが提供するサービスの一つで、 ブラウザを通じてクラウドベースでコードの記述、実行、デバッグができる統合開発環境(IDE) です。利点として、リアルタイムで共同作業ができることや必要なツールなどがあらかじめ設定されており、開発環境のセットアップが簡単なことが挙げられます。 そんなCloud9ですが、私のAWSアカウントでサービスにアクセスしようとすると、以下のような表示が出ます。 原因は AWSが2024年7月25日以降のCloud9を含むいくつかのサービスで新規利用受付を終了 したためです。そのため、新人の方で私のように配属された後にAWSアカウントを作成した場合は、Cloud9が使用できなくなっています。もしかすると案件などでお客様側からAWSアカウントを払い出してもらった方も同じ状況かもしれません。 （2024年7月25日以前にAWSアカウントでCloud9を使用されていた方は現在でも利用可能です） この問題を解決するために、この記事ではCloud9の代替策となる3つのサービスの概要について記述します。 Cloud9の代替えサービス ご紹介させていただくサービスは以下の3つです。 Amazon SageMaker Studio コードエディタ 概要 Amazon SageMaker Studio コードエディタはAmazon SageMakerの機能の一部です。任意のVPC内に置くことができたりなど、ほぼCloud9と同等の環境を構築することができるというメリットがあります。デメリットとしては起動・削除に時間がかかることやリソースを消したい場合にドメインやユーザーの削除も必要な点が少し面倒です。また、デフォルトでdocker コマンドが使えないため、コンテナを使うためにDockerfileのイメージをリポジトリにプッシュしたいときなどはdockerコマンドのインストールが別途必要になります。 AWS CloudShell 概要 AWS CloudShell は Amazon Linux 2023 ベースのブラウザから操作できるシェル環境です。無料で使用することができ、すぐに実行できるというメリットがあります。ファイルのアップロード、ダウンロードも可能です。しかし、デフォルトのディスク容量が1GBのみのため、大きなファイルを実行するのには不向きというデメリットがあります。また、任意のVPC内に置くこともできません。 Amazon CodeCatalyst 概要 Amazon CodeCatalystは開発者がソフトウェアを迅速に構築、テスト、およびデプロイできるように設計された統合ソフトウェア開発サービスです。CI/CDパイプライン (ソフトウェアの変更を自動でテストし、ビルドし、デプロイするプロセス)を簡単に実現することができ、Cloud9のインスタンスを立ち上げることができるメリットがあります。しかし、現在（2025年2月25日）は東京リージョンで使用することができず、米国（オレゴン）リージョンと欧州（アイルランド）リージョンのみで使用可能となっています。またAWS Builder IDの作成などの初期設定が必要というデメリットがあります。 まとめ 今回はCloud9の代替サービスの概要について簡単にまとめてみました。案件によっては使えないサービスなどもあるかと思いますが、勉強のためのハンズオンの参考になれば幸いです。構築手順については参考資料を見ていただければと思います。また、Cloud9のほかに以下のサービスも新規利用の受付を終了しているようです。 S3 Select CloudSerch SimpleDB Forecast Data Pipeline CodeCommit 参考資料 AWS Cloud9が突然、新規利用不可に？ 代替策「SageMaker Studio コードエディタ」の利用手順 #cloud9 – Qiita AWS CloudShell を早速使ってみました #reinvent – Qiita 【CodeCatalyst 入門①】CodeCatalystの初期設定方法 | わかるブログ Amazon CodeCatalyst 触ってみた! #AWS – Qiita
こんにちは、SCSK株式会社の谷です。 前回、新たに私たちの部署に新入社員として加わった嶋谷さんが、 Mackerel を使ってAWS環境のDocker情報を可視化する方法と結果 についての記事を掲載しました。 ご覧になっていない方は、ぜひ目を通してみてください。 Mackerel で Docker を監視してみた – TechHarmony 今回は、MackerelにてAWSのサーバーレスサービスを監視し可視化しました。 監視対象のシステムについて 今回の検証のため、AWSが提供しているハンズオンから簡易的なWebアプリを構築しました。 名前を入力しボタンを選択すると、「Hello from Lambda」で始まり入力したテキストが続くメッセージが表示されるWebアプリです。 Webアプリの構成は以下の図になります。 構成しているサービスの中で今回は以下を使用して検証をしました。 Amazon DynamoDB 完全マネージド型の NoSQL データベースサービス Amazon API Gateway APIの作成および管理を簡単に行えるフルマネージドサービス AWS Lambda サーバーレスコンピューティングサービス 上記環境の構築手順について、この記事では説明を省略させていただきます。 詳しく知りたい方は、以下に詳細な構築手順が載っていますので、こちらをご覧ください。 AWS で基本的なウェブアプリケーションを構築する Mackerelでの監視設定手順 ここではMackerelで各サービスを監視するための設定手順について記載しています。 設定手順の詳細につきましては、Mackerel公式ヘルプをご参照ください。 AWSインテグレーション – Mackerel ヘルプ 設定手順について興味のない方は、このパートはスキップして「 Mackerel上で監視データの確認 」のパートに飛んでください。 インテグレーション用のIAMロールの作成 (1) Mackerelの管理画面で「オーガニゼーション名」＞「AWSインテグレーション」をクリックする。 (2)「新しいAWSインテグレーションを登録」というボタンが表示されるため、それをクリックする。 (3) 基本設定＞AWSアカウント 外部IDをコピーする。 (4) AWSのコンソールにログインし、左上の検索バーで「IAM」と入力し、エンターを押す。 (5) 左側のタブからロールを選択し、「ロールを作成」をクリックする。 (6) 以下に沿って入力し、すべて入力後、「次へ」をクリックする。 信頼されたエンティティタイプ ： AWSアカウント AWSアカウント ： 別のAWSアカウント アカウントID ： 217452466226（共通） オプション ： 外部IDを要求する (7) 今回はLambda、API Gateway、DynamoDBを監視したいため、それらに関するReadOnlyロールを選択し、「次へ」をクリックする。 (8) ロール名と説明を適宜入力し、「ロールを作成」をクリックする。 (9) 作成したロールの詳細画面で表示される、ARNをコピーする。 AWSインテグレーションの作成 (1) Mackerelの管理画面に戻り、先ほど開いた「新しいAWSインテグレーションを登録」画面を開く。 そこで、名前の入力とリージョンの選択を行い、ロールARNの欄に先ほどコピーしたARNを貼り付ける。 (2) メトリックを収集するサービスで、Lambda、API Gateway、DynamoDBを選択する。 他の取得可能なサービスにつきましては以下の公式ヘルプの「 対応しているクラウド製品 」を参照ください。 AWSインテグレーション – Mackerel ヘルプ (3) 「タグを指定して登録するホストを絞り込む」にて連携したいリソースのタグ、除外したいタグを入力する。 (4)「作成」をクリックする。 これで、インテグレーションが作成できました！ 連携確認 以上で設定は完了です。 ここからは、監視設定を入れたサービスの状態を見てみましょう。 ここまでの手順が完了すると、Mackerelの管理画面の「ホスト」のところですぐに確認することができます。 このように、Lambda、API Gateway、DynamoDBの3つのデータが取れていることがわかります。 Mackerel上で監視データの確認 設定作業はいかがでしたか？ 思っていたより簡単に監視ができると感じた方が多いのではないでしょうか。 では、ここからはAWSから連携された監視データがどのように見えているかを、サービスごとに一部抜粋してお見せしたいと思います。 API Gateway MackerelではリソースごとにAPI Gatewayを監視することができます。 API Gatewayでは、基本的に以下のメトリックを取得できます。 詳細はMackerel公式ヘルプをご参照ください。 AWSインテグレーション – API Gateway – Mackerel ヘルプ グラフ名 メトリック 説明 Requests Count 指定期間内のAPIリクエストの合計数 Errors 4XXError クライアント側のエラー数 5XXError サーバー側のエラー数 Cache CacheHitCount APIキャッシュから提供されたリクエストの数 CacheMissCount バックエンドから提供されたリクエストの数 Latency Latency クライアントからリクエストを受け取ってからレスポンスを返すまでの時間 IntegrationLatency バックエンドにリクエストを中継してからレスポンスを受け取るまでの時間 今回は、この中のRequestsのグラフをお見せします。 こちらのグラフは、APIのリクエスト数を可視化したグラフになります。 このデータを見れば、どのタイミングでリクエスト数が増えているかを視覚的に確認することができます。 DynamoDB MackerelではDBリソースごとにをDynamoDBを監視することができます。 DynamoDBでは、基本的に以下のメトリックを取得できます。 詳細はMackerel公式ヘルプをご参照ください。 AWSインテグレーション – DynamoDB – Mackerel ヘルプ グラフ名 メトリック 説明 ReadCapacityUnits ProvisionedReadCapacityUnits プロビジョンドされた読み取りキャパシティユニットの数 ConsumedReadCapacityUnits 読み取り操作で消費されたキャパシティユニットの数 WriteCapacityUnits ProvisionedWriteCapacityUnits プロビジョンドされた書き込みキャパシティユニットの数。 ConsumedWriteCapacityUnits 書き込み操作で消費されたキャパシティユニットの数 Requests ConditionalCheckFailedRequests 条件付き書き込みや更新操作が失敗したリクエストの数 SuccessfulRequestLatency 成功したリクエストのレイテンシー ThrottledRequests スロットルされたリクエストの総数 UserErrors ユーザーによって引き起こされたエラーの数 SystemErrors DynamoDB内部で発生したシステムエラーの数 ThrottleEvents ReadThrottleEvents 読み取り操作がスロットルされた回数 WriteThrottleEvents 書き込み操作がスロットルされた回数 TimeToLiveDeletedItemCount TimeToLiveDeletedItemCount TTL機能によって削除されたアイテムの数 SuccessfulRequestLatency SuccessfulRequestLatency 成功したリクエストのレイテンシー ReturnedItemCount ReturnedItemCount クエリやスキャン操作で返されたアイテムの数 RequestCount ReturnedItemCount クエリやスキャン操作で返されたアイテムの数 TransactionConflict TransactionConflict トランザクションの競合が発生した回数 今回は、この中のWriteCapacityUnitsグラフをお見せします。 こちらのグラフは、DynamoDBへの書き込みで消費されたキャパシティユニット数を示したグラフになっています。 このデータを見ることで、キャパシティを超えるような書き込みが行われていないかを視覚的に確認することができます。 Lambda Mackerelでは関数単位ごとにLambdaを監視することができます。 Lambdaでは、基本的に以下のメトリックを取得できます。 詳細はMackerel公式ヘルプをご参照ください。 AWSインテグレーション – Lambda – Mackerel ヘルプ グラフ名 メトリック 説明 Count Invocations 関数が呼び出された回数 Errors 関数の実行中に発生したエラーの数 DeadLetterErrors デッドレターキューへの送信失敗回数 Throttles スロットルされた呼び出しの数 Duration [ms] Duration 関数の実行時間 Iterator Age [ms] IteratorAge ストリームイベントの処理遅延時間 今回はエラーが分かりやすいようにCountグラフをお見せします。 こちらのグラフは、Lambdaの実行回数（invocations）とエラー回数（errors）を示したグラフになっています。 エラーをグラフ上に表示させるため、14:15頃から LambdaからDynamoDBへの書き込み権限ロールを一時的に削除しました 。 このデータを見れば、いつどのタイミングでエラーが発生し始めたのかを視覚的に確認することができます。 今回ご紹介したグラフはそれぞれ1つずつでしたが、かんたんなカスタムをすれば様々なグラフを作成することも可能です。 興味がある方はぜひ調べてみてください。 終わりに 記事の内容は以上になります。いかがでしたでしょうか。 今回初めてMackerelにて監視設定をいれたのですが、UIも直感的で操作しやすくスムーズに設定を入れることができました！ また、公式ドキュメントも豊富でしたので、疑問点や不明点を解決しやすいところも非常にやりやすかったです。 また、Amazon CloudWatchだと少し手間だと感じていましたが、 設定したいメトリクスを簡単に複数まとめて設定できる ところがMackerelの優れている点だと今回設定してみて感じました。 もう少しMackerelを触ってみようと思いますので、また何か気づきがありましたら記事を掲載します。 最後までお付き合いいただき、ありがとうございました。
はじめに 今回は今年の1月にリリースされたアクションプランという機能の説明と使い方を書いていきます。 アクションプランとは アクションプランとは、リスクのあるリソースが一覧化されており、そのリソースに対し最小限のアクションでリスク軽減をできるように調整された効果的な修復手順を提供し、クラウドリソースの保護に役立てることができます。 アクションプランの使い方 ここからはアクションプランの使い方について解説していきます。 アクションプラン担当者の割り振り Prisma Cloud コンソールにログインします。 このとき「System Admin」でログインしていることを確認します。 上のバーから「アクションプラン」を押下します。 以下画像のように遷移します。 各アクションプランには人を割り当てることもできます。 赤線部分の「Unassigned」部分を押下し、担当する人を選択することができます。 担当者を設定した後に「Assigned to me」を押下する自分がどのアクションプランを担当するか確認することができます。 フィルターの「譲受人」の部分でほかの人が担当するアクションプランを確認することもできます。 逆に担当者が割り当てられていないものは「Unassigned Action Plans」から確認することができます。 アクションプランを解決する場合 Prisma Cloud コンソールにログインします。 このとき「System Admin」でログインしていることを確認します。 上のバーから「アクションプラン」を押下します。 以下画像のように遷移します。 対象のアクションプランを押下して展開すると、対象のアクションプランのプライマリアセットと概要、その影響がとがでてきます。 「プライマリアセット」はどのリソースが対象なのか表示されています。 「概要」は影響を受けるリソースの概要の説明が表示されています。 「影響」は攻撃パス、アラート、脆弱性が表示されています。 展開後、「修正方法」を押下すると解決方法の手順が出てくるので手順実行して修正完了です。 ※修正方法に記載がありますが、「大規模な言語モデルやその他の生成AIを活用する場合があり、エラーが含まれる場合があります。」ということなので注意が必要です さいごに アクションプランを使用して簡単にクラウドリソースのリスクを減らせるようになったのでとても良い機能だと思います。 当社では、複数クラウド環境の設定状況を自動でチェックし、設定ミスやコンプライアンス違反、異常行動などのリスクを診断するCSPMソリューションを販売しております。 マルチクラウド設定診断サービス with CSPM｜ SCSK株式会社 CSPM ｜ Smart One Cloud Security® Powered by Prisma Cloud from Palo Alto Networks ｜ SCSK株式会社 ご興味のある方は是非、お気軽にお問い合わせください。
社内開催の AWS GameDay に参加してきました。AWSのワークショップ形式のイベントは初参加です！ 興味はありましたが、普段の案件はWeb/APのインフラ構築案件が多く、使うサービスややり方がほぼ固定で、 参加したは良いけど全然出来なかったらどうしよう、知らないサービスばっかりだったらどうしようと思い、尻込みしていました。 今回社内メンバーのみ、初心者向けの難易度ということで、これを逃したら二度と参加出来る気がしないと思い参加してみました。 自分について 普段はクラウドのインフラ構築案件をしています。 最近はGoogle CloudやAzure案件をやっていますが、5年ほどAWS案件をやっていました。 リーダとして管理や調整が多くなってきており、実際にコードを書いたり画面を触ってどうするみたいなところは時間が取れなくなってきています。 AWS re:Invent 等のスライドを見るようなものには何度か参加したことがありますが、ワークショップ形式は未経験です。 資格はAWS SAP、DOP、SCSを所有しています。 GameDay 概要 実施内容の詳細は公開NGとのことだったのでざっくりとした内容のみです。詳細は実際に参加する際のお楽しみに！とのことでした。 今回は社内のみの個人申し込みで運営の方が3-4人のチームを組んでくれました。 チームでAWS上に作られた仮のシステムで発生している様々な問題を解消していきます。 解消した内容に応じて決められたポイントが入り、その合計点で争うチーム戦です。 問題はある程度道筋を立てられるような流れになっていました。問題文を読んで原因を考え、調査して問題解決を目指していきます。 良かった点 普段の業務ではやらないやり方や使わないサービスの問題もありました。資格勉強で文字しか見ていないようなものを実際に触ってみることが出来てよかったです。 資格取得時に「なんとなくサービスは知っている、そういうことが出来ることは知っている」という知識も意外と役に立ちます。 メンバーによって得意不得意がある中で、「この問題を解きます」「ここどうする？？？」といった会話をして取り組む問題を決めたりサポートをするところがチームでやっている感があり楽しかったです。 単純に楽しい。私は自分責ではないトラブルを対応するのが大好きなので、今回のGameDayはすごく楽しかったです。 気になった点 初参加なのもあり、楽しかったのであまり気になる点はありませんでしたが 一点だけ申し込み前の葛藤がネックになるのかなあと思いました。 申込時の難易度が不明 自分のレベルと取り組む問題のレベル感がなかなか分かりにくいと思いました。私も今回始まるまでずっとドキドキしていました。 意外と何とかなったのと、いくら悩んでも参加するまでやっぱり分からないのでとりあえず一度参加してみるのがよいと思いました。 今回はアプリ開発レベルのプログラミング知識は不要で、インフラで多少スクリプトの経験があるようなレベル感で十分でした。 ちょっとしたコツ 問題文はよく読むこと！ どういうサービスを使うのか、既に用意済みのリソースは何か、作り方に指定は無いか 解くためのヒントが問題文にもあります。 なんでクリアにならないんだろうか？と思ったときに問題文をゆっくり読んでみたらすぐ解決みたいなこともありました。 感想 今回なんとチームの順位が2位でした。4人チームが多い中、3人チームだったのにすごい！ 自分が担当した問題の解決順はそこまで早くなかったのですが、他の方がめちゃ早で凄かったです。 知識としては知っているが、いざやってみると細かいやり方が分からない、勘違いをしていたといった点にも気づけました。 是非次は社外イベント等含めワークショップ形式のものに参加してみたいと思います！ 2位賞品＆参加賞としてAWS保冷バッグ＆ステッカーもらいました！
今回は、Prisma CloudのInvestigate機能を利用して、特定の条件に一致するリソースを検索する方法を解説していきます。 Prisma Cloud の Investigate（調査）機能 Prisma CloudのInvestigate（調査）機能を使用すると、シンプルで直感的なインターフェースでクエリを発行することができ、要件にあわせた検索をすることが可能です。Prisma Cloudで発行されるクエリはRQLと呼ばれ、Prisma Cloud独自のものとなっています。 検索方法は、大きく分けると以下の３つがあります。 ① 探したい条件を入力すると表示されるAI支援の提案からクエリを選択して検索する ② クエリの条件をコンソール画面に表示されるフィルター機能で指定して検索する ③ 検索欄にRQL文を直接入力して検索する 今回は上記３つの方法をそれぞれ説明していきます。 検索してみる 今回は分かりやすい例として、「パブリックIPを持っているEC2」をそれぞれの方法で検索してみたいと思います。 AI支援を利用した検索 Prisma Cloudコンソールの調査タブを表示すると、右側に「AI支援が有効」と表示されている検索欄（以下画像参照）が出てきます。 ここに「パブリックIPを持っているEC2」と入力してみます。 すると以下のように、AIによって入力内容に当てはまりそうなクエリが選択肢として表示されてきます。 「AWS EC2 instance is assigned with public IP_RL」という名前のクエリが今回検索したい内容に一致しそうなのでクリックすると、自動でRQL文が入力され、接続しているクラウドアカウント上に存在するパブリックIPを持ったEC2の一覧が表示されます。 フィルタ機能を利用した検索 Prisma Cloudコンソールの調査タブを表示すると、「＋クエリの種類を選択してください」というフィルターが表示されます。クエリには以下のような種類があり、その中から要件に当てはまるものを選択します。 クエリタイプ 概要 RQL文の形式 サポートしているモード アセット 包括的なセキュリティコンテキストを含むすべてのクラウドアセットを表示 ー シンプル 設定 クラウド API と JSON ルールに基づいて構成ファイルを検索 “config from cloud.resource where”から始まる シンプル・上級 脆弱性 お使いの環境内で発見された主な脆弱性を調査 ー シンプル ネットワーク設定 ネットワークパスを探索し、インターネットに公開されているアセットを特定 config from network where”から始まる 上級 ネットワークフローログ ネットワークフローログを調査して、インシデントや脅威の検出と調査を行う network from vpc.flow_record where”から始まる 上級 監査イベント 調査とフォレンジックのために監査ログを探索 event from cloud.audit_logs where”から始まる 上級 アプリケーションアセット ソフトウェアデリバリーチェーンとエンジニアリングのアタックサーフェスを調査 ー シンプル 許可(IAM) 取り込まれた IAM ポリシーに基づいてネット リソースのアクセス許可を表示 “config from iam where”から始まる 上級 今回は「パブリックIPを持っている」という”設定”に当てはまるEC2を検索したいので、「設定」を選択します。 検索対象とする期間を選びます。「＋追加」をクリックするとフィルタ条件を追加できます。 今回はEC2の設定情報(パブリックIPを持っているかどうか)を条件にしたいので、EC2インスタンスの情報を参照するAPIを指定します。 条件とする詳細な設定値は「JSONルール」フィルターを利用して指定していきます。 JSONルールを選択すると以下のように実際のJSON形式で設定項目が表示されるので、条件にしたい設定項目をクリックします。今回はパブリックIPの値が入る項目をクリックしました。 指定した項目がどのようになっていたら検知するかを指定します。 今回は「publicIP」の項目が存在する＝パブリックIPを持っている※ということを検知の条件にしたいので、「exists」を選択しました。 その他の選択肢については、Prisma Cloudの公式ドキュメント（ RQL演算子 ）を参照ください。 ※パブリックIPがないEC2のJSONにはそもそも「publicIP」の項目がありません 条件を指定できたら「検索」をクリックします。パブリックIPを持ったEC2の一覧が表示されます。 RQL文を直接編集して検索 フィルタ機能を利用した検索の説明で紹介したクエリタイプで、サポートされているモードに「上級」が含まれているクエリタイプの場合は、検索欄にRQL文を直接入力して検索することができます。 「設定」クエリタイプは「上級」モードをサポートしているので実際に試してみます。 PrismaCloudコンソールの「調査」タブを表示し、「＋クエリの種類を選択してください」をクリックして「設定」を選択します。 すると、右側に「シンプル」と「上級」を選択できる箇所が出てくるので、「上級」を選択します。 「config from～」から始まるRQL文を入力できる欄が出てきたので、以降のRQL文を入力していきます。 直接テキストを入力していくことも可能ですし、入力しようとすると選択肢が表示されるのでそこから選択してRQLを作成することも可能です。 RQL文が文法的に問題なく検索できる状態まで入力すると、RQLの左横にあるアイコンが緑色に変わります。 緑色になっていることを確認して「検索」をクリックします。 パブリックIPを持ったEC2の一覧が表示されます。 まとめ Prisma CloudのInvestigate（調査）機能を利用して検索をかける方法を3つご紹介しました。調査機能を利用することで、特定の条件に一致するリソースの一覧を簡単に作成できます。また、Prisma Cloudのポリシーはクエリ(RQL)を利用しているため、個々の環境の要件に合わせたカスタムポリシー作成する際にも参考になるかと思います。調査機能を有効活用して、セキュリティとコンプライアンスの強化に役立てましょう。 今後も、Prisma Cloud の活用方法について実用的な情報をお届けできればと思います。 また、当社では、複数クラウド環境の設定状況を自動でチェックし、設定ミスやコンプライアンス違反、異常行動などのリスクを診断するCSPMソリューションを販売しております。 マルチクラウド設定診断サービス with CSPM｜ SCSK株式会社 マルチクラウド環境のセキュリティ設定リスクを手軽に確認可能なスポット診断サービスです。独自の診断レポートが、運用上の設定ミスや設計不備、クラウド環境の仕様変更などで発生し得る問題を可視化し、セキュリティインシデントの早期発見に役立ちます。 www.scsk.jp ご興味のある方は是非、お気軽にお問い合わせください。
SCSKの畑です。 2個前のエントリ で少し言及した通り、外部公開されるサービスの AWS WAF 設定でハマった話について記載します。 アーキテクチャ図 いつものやつです。今回は AWS WAF 設定に関連する内容ということで、対象は以下構成において外部からアクセス可能なサービスとなる、Amazon CloudFront、Amazon Cognito、AWS AppSync の3つです。 背景 さて、その 2個前のエントリ において、お客さんの環境ポリシーにより CloudFront に AWS WAF を設定する必要があったことを取り上げました。本アプリケーションはインターネット上に公開せず、アクセスできるネットワーク/IP アドレスのレンジを限定する必要があったためですが、アーキテクチャ図の通り Cognito ユーザプール及び AppSync の GraphQL API エンドポイントについても同様にクライアント端末からアクセスすることになるため、AWS WAF を設定する必要がありました。 それらのサービスについても外部からアクセスしてくるのは同じようにクライアント端末の属するネットワークであるため、CloudFront と同じような AWS WAF 設定をすれば良いと考え、お客さんにその旨依頼していたのですが・・ エラー発生（AppSync） お客さんの AWS 環境にアプリケーション一式を移行して動作確認を行っていたところ、バックエンド用 Lambda 処理を伴うクライアント処理時に以下のようなエラーが出力されました。（汎用エラー表示用コンポーネント上での扱いから JSON 形式です） { message: 'Connection failed: {"errors":[{"errorType":"WAFForbiddenException","message":"403 Forbidden" } クライアント端末上のアプリケーションから Lambda を介さない AppSync API は実行できていたため当初はちょっと戸惑ったものの、errorType の通り WAF でアクセス拒否されていることは分かったので、先述の通りクライアント端末以外からのアクセスを許可していない WAF 設定が怪しいことにすぐ思い至りました。確かに Lambda も クライアント端末上のアプリケーションも、AppSync の GraphQL API エンドポイントにアクセスする立場は同じなので、バックエンド用 Lambda についてもクライアント端末と同様に AWS WAF でのアクセス許可が必要なのではないか？という（その時点での）推測です。 バックエンド用 Lambda がエラーで正常動作しない以上、アプリケーションの移行や動作確認も進まないことと同義であるため、いの一番に対応しました。解決策については Cognito 側と全く同じなので後述します。 エラー発生（Cognito ユーザプール） 一方、Cognito ユーザプールについては、バックエンド用 Lambda から boto3 経由でアクセスする処理が正常に動作していたこと、アプリケーションの一連の動作確認でもユーザ認証部分は特に問題がなかったことの2点から、当初はあまり深く理由を考えないまま大丈夫なのかな？と考えていたのですが・・ たまたま違う日に Web ブラウザ上で開いているアプリケーション（ログイン中）をリロードしたところ、TOP ページにリダイレクトしてしまう事象が発生しました。弊社の AWS 環境では事象が再現しなかったためお客さんの AWS 環境の問題と考え、当初は CloudFront や AWS WAF の設定あたりに問題があると考えたのですが、特に原因となるような設定はありませんでした。また、ブラウザのコンソール上にも特にエラーメッセージは表示されていませんでした。 そこで改めて TOP ページへのリダイレクト履歴を Web ブラウザから追いかけたところ （リロードした時点のページ） ⇒ /login（ログイン後の初期処理ページ） ⇒ /（TOPページ） という順番でリダイレクトしていることが分かりました。アプリケーション側のルーティングロジックの詳細は 過去のエントリ で記載していますが、簡単に整理すると /login へのリダイレクト： Cognito ユーザ未認証の場合のリダイレクトパターン / へのリダイレクト： Cognito ユーザ認証済みのリダイレクトパターン となります。 つまり、上記のルーティングロジックに従うと、リロードした時点では Cognito ユーザ未認証と判定されているものの、Cognito ユーザ認証自体は完了しているため / へリダイレクトされる時点では Cognito ユーザ認証済みと判定されていることになります。Nuxt3 によるルーティングはサーバ側でも処理されるため、フロントエンド側の Lambda で Cognito ユーザ未認証とみなされているのではないかと推測しました。そこで、アプリケーションをデプロイした CloudFront 配下のフロントエンド用 Lambda のログを CloudWatch から見てみると・・ 2025-02-18T06:41:20.957Z 9dd22dc5-039f-45ee-86f6-b3ce9230ec0a INFO ForbiddenException: Request not allowed due to WAF block. at file:///var/task/.output/server/node_modules/@aws-amplify/auth/dist/esm/foundation/factories/serviceClients/cognitoIdentityProvider/shared/serde/createUserPoolDeserializer.mjs:11:15 at process.processTicksAndRejections (node:internal/process/task_queues:105:5) at async fetchUserAttributes (file:///var/task/.output/server/node_modules/@aws-amplify/auth/dist/esm/providers/cognito/apis/internal/fetchUserAttributes.mjs:31:32) at async runWithAmplifyServerContext (file:///var/task/.output/server/node_modules/aws-amplify/dist/esm/adapter-core/runWithAmplifyServerContext.mjs:20:24) at async useUserInfo (file:///var/task/.output/server/chunks/build/server.mjs:7155:26) at async file:///var/task/.output/server/chunks/build/server.mjs:7526:113 at async Object.callAsync (file:///var/task/.output/server/chunks/nitro/nitro.mjs:5850:16) at async file:///var/task/.output/server/chunks/build/server.mjs:7733:26 { underlyingError: undefined, recoverySuggestion: undefined, constructor: [class AuthError extends AmplifyError] } 1行目にそのものズバリなメッセージ「ForbiddenException: Request not allowed due to WAF block.」が出ている通り、フロントエンド側の Lambda から Cognito ユーザプールへのアクセスが WAF によりブロックされていたことが分かりました。 過去のエントリ に記載している middleware のコード通り、Cognito ユーザ認証されない場合も今回のように WAF でブロックされた場合も同じように例外を catch して /login にリダイレクトしているので、このような挙動になったということになります。 余談ですが、この原因の切り分けもといデバッグにはそこそこ時間を要しました。フロントエンド側 Lambda の CloudWatchLog を見なければいけないというところに思考が至るまでに時間がかかってしまったのが原因です。 普段 Nuxt3 の開発をローカルで実施している時はフレームワーク側が気を利かせてくれて、ローカルで立てている開発用サーバ側のログも Web ブラウザのコンソールで出してくれたりするんですよね。しばらくその感覚でいたので、本来 /login にリダイレクトした際に上記のようなエラーが出ると思っていたのが出なかったこともあり、このロジック以外でリダイレクトしてしまうようなことがあり得るのか？みたいなところに思考が向いてしまっていました。その結果、CloudFront なり AWS WAF の設定あたりを疑うところから始めてしまったという・・ なお、Cognito ユーザの認証処理自体が正常に実施されていた理由もシンプルで、クライアント側の処理だったためです。そもそも、URL を叩いて表示されたログイン画面にユーザ/パスワードを入力してログインしようとしている時点で、クライアント側の処理であることは自明ですね。。また、実装の都合上他の AppSync API を叩くような処理（＝Cognito ユーザ認証が必要な処理）は基本的にほぼクライアント側で明示的に実行するようにしているため、本事象の影響は出ていませんでした。このあたりは Nuxt3 で Universal Rendering (Server-Side Rendering) を使用しているが故の内容と思います。 ということで、こちらも後述する解決策により対応したのですが・・納得できない部分が残りました。 エラー内容の深掘（AWS サポート問い合わせ） というのも、先般の通りバックエンドの Lambda 関数から boto3 経由で Cognito ユーザプールにアクセスする処理は元々問題なく動作していたためです。AppSync については、バックエンドの Lambda 関数からも実質的にアプリケーションからのアクセスと同じように GraphQL API を叩くような実装となっており、boto3 は使用していなかった（使えなかった）ため同じように AWS WAF にブロックされることも納得できたのですが、では boto3 経由のアクセスが AWS WAF にブロックされないのは何故なのか？ ということで、この点を AWS サポートに問い合わせてみたところ、実に明快な回答を頂きました。というかドキュメントをもうちょっと読んでから問い合わせれば良かったと思ったくらいには明確に書いてあったので、少なからず申し訳ない気分になりましたが・・ Cognito ユーザプールの場合 AWS WAF ウェブ ACL とユーザープールの関連付け - Amazon Cognito AWS WAF ウェブ ACL を Amazon Cognito ユーザープールに関連付けることができます。ウェブ ACL は不要な HTTPS リクエストをブロックしてログに記録できます。 docs.aws.amazon.com 上記 URL に記載の通り、正に今回の事象を端的に説明できる内容でした。 AWS 認証情報による認証を不要とするパブリックなユーザープール API へのリクエストに対しては適用される クライアント端末やフロントエンド用 Lambda で Cognito 認証情報を扱うような処理に該当 AWS 認証情報による認証が必要なユーザープール API へのリクエストに対しては適用されない バックエンド用 Lambda から boto3 を叩くような処理に該当 確かに理屈というか考え方としても納得できるところで、AWS 認証情報による認証が必要な API については認証情報の有無がそのままアクセス制限となりますし、アプリケーションのログイン処理においてはその時点で AWS 認証情報は持たない（ログイン後に Cognito 経由で付与される）以上 API としてはパブリックとすべきであり、その上でアクセス制限をしたい場合の機能として WAF が適用できるというように理解できました。 また、先述したような「boto3 経由のアクセスについて許可されている」という表現ももちろん間違っており、バックエンド用の Lambda において boto3 経由で実行していたのが AWS 認証情報による認証が必要なユーザープール API へのリクエストのみであったため、結果的にそのような挙動になっていたというのが実態でした。これまでのエントリやアーキテクチャ図に記載の通り、バックエンド用 Lambda は AppSync 経由で実行される想定のため、Lambda 内で Cognito の認証情報を直接扱う必要がないことから必然的にそのような実装になったとも言えるかもしれません。 AppSync の場合 AWS WAF を使用して AWS AppSync API を保護する - AWS AppSync GraphQL AWS WAFウェブ ACL を作成し、AppSync API に関連付けて、攻撃から保護する方法について説明します。 docs.aws.amazon.com Welcome - AWS AppSync AWS AppSync provides API actions for creating and interacting with data sources using GraphQL from your application. docs.aws.amazon.com こちらも上記 URL に記載がありましたが、Cognito ユーザプールの場合とは少し考え方が異なるようでした。 AppSync にて作成された GraphQL API に WAF が適用されている場合、同 API へのリクエストに対して一律で WAF が適用される 2つ目 の URL に記載されている API へのリクエストについては WAF は適用されない 考え方としてはシンプルで、GraphQL を含む AppSync API 自体の管理操作自体には WAF が適用されず、作成した AppSync API を叩くような操作については WAF が適用されるというように理解できました。逆に言うと、バックエンド用 Lambda の実行ロールに appsync:GraphQL が付与され対象の GraphQL API を実行できる権限があっても、Cognito の場合と異なり GraphQL API へのアクセスである以上 WAF が適用されるため、先述した通りの挙動となったということですね。作成した GraphQL API のエンドポイント URL が明示的に払い出されることも踏まえ、直感的な仕様だと感じました。 ちなみに気になったのですが、boto3 に AppSync で作成した API を叩くような機能がないのは何故なんでしょうね？主としてフロントエンドを含むアプリケーションから実行される以上（何となく boto3 ＝管理用のライブラリというイメージがあったこともあり）boto3 の用途にそぐわないからかなと勝手に想像してたのですが、一方で Cognito ユーザプールについてはちゃんとユーザ認証機能あるんですよね。ん？機能としては同じような文脈というか用途じゃないですか？という。 Lambda (Python) から AppSync で作成した API を叩くのに requests パッケージなどが必要となるのですが、Lambda の 標準 Python ランタイムには含まれておらず、レイヤー経由でインポートしないといけなかったりして手間なので、boto3 経由で実行できるようにしても良いんじゃないかと思うんですけど需要がないんですかね？確かにフロントエンドとしての需要は少ないかもですが・・ AppSync - Boto3 1.36.26 documentation boto3.amazonaws.com 解決策 ということで、Lambda 関数から AppSync/Cognito の API エンドポイントを叩きに行く際の IP アドレスについても許可するよう、AppSync 及び Cognito ユーザプールの AWS WAF 設定をお客さんに修正頂いてクローズと相成りました・・が、お気づきの方もいると思いますが、この解決策が取れるかどうかは Lambda 関数がどこに構成されているかに依存します。デフォルトだと VPC 外（AWS が管理しているネットワーク上）に構成される以上 IP アドレスは不定になると思われ、WAF で指定できない可能性がありました。 AWS の IP アドレスレンジは下記 URL の通り JSON 情報として取得できるようですので、Lambda のエンドポイント FQDN を解決した際の IP アドレスがどのレンジ内のものかを突合して、サービス単位での IP アドレスレンジを導入するなどのテクニックがあるようです。ただ、当然ながら IP アドレスのレンジが変更される場合もあるため、静的な AWS WAF 設定として適用することは運用上難しかったものと思います。 AWS IP アドレスの範囲 - Amazon Virtual Private Cloud ip-ranges.json ファイルで、公開されている IP アドレス範囲を使用して、AWS サービスに出入りするトラフィックを特定し制御します。公開されている範囲の変更を経時的にモニタリングします。 docs.aws.amazon.com 幸いアーキテクチャ図の通り、お客さん AWS 環境において Lambda 関数はフロントエンド/バックエンド用どちらも VPC 内のプライベートサブネット上に構成されていたため、Lambda から AppSync/Cognito の API エンドポイントを叩きに行く際のソース IP アドレスとなる、NAT Gateway のパブリック IP アドレスを指定頂き、無事に解決できました。 なお、本アーキテクチャにおいて AppSync や Cognito ユーザプールの API を叩くためにはどちらも認証が必要であるため、エンドポイント自体がインターネットに公開されていても大きな問題ではなかったとは思います。ただ、お客さんの環境ポリシーに適合しなくなることも確かなので、その場合の調整コストなどを鑑みると今回のような構成を取れて良かったというのが正直なところです。 まとめ AppSync についてはアプリケーションの動作に直接的な影響があったこともあってすぐに対応できたのですが、そのタイミングで Cognito についてももう少し深掘りするべきだったというのが反省点です。元々の AWS WAF 導入時の観点が外部アクセスの制限にあったことが多少のエクスキューズにはなるかもしれませんが、構成上同じような事象が発生し得るということまでは気付いていただけに。。 また、AWS WAF を適用できる他のサービスについても、今回のようにリクエストの内容などにより適用される範囲が変わりそうだなと感じたので、もし次に触る機会があれば留意しておきたいと感じました。 本記事がどなたかの役に立てば幸いです。
概要 Azureの既存Prepaymentから新規Azureテナントのサブスクリプションを払い出してみました。 Microsoft Learnに記載されている手順を参照するだけですが、私が対応した際にアカウントやサブスクリプションの関連が理解が浅かったためつまづいたポイントや補足事項を残します。 この手順はいろいろなライセンス形態の中での一例でしかないため、正式な手順はライセンス販売企業様の案内に沿っていただければと思います。 登場するリソース 既存Prepaymentが紐づくテナントA(作成済み前提) テナントAで新規作成するアカウント所有者B 新規作成するテナントB テナントB上で新規作成するサブスクリプションB 用語等については以下公式資料を参照ください。 Microsoft Azure利用ガイド 手順、補足 １．テナントBを新規作成する。 下記URLから新規テナントBを作成する。 Microsoft 365 E3 (Teams なし) ポイント1→本人確認のセキュリティチェックで電話番号を登録しSMS認証か音声通話認証を実施するのですが、弊社内からは下記のエラーとなりました。弊社プロキシが影響していることを想定し、弊社貸与のスマホのブラウザから実行したところエラーは解消しました。 2.テナントAでアカウントBを新規作成し有効化する。 ・アカウント所有者の登録（エンタープライズ管理者の操作） Azure portal での EA 課金管理 – Microsoft Cost Management | Microsoft Learn ポイント2→アカウントの追加の中で指定する[アカウント所有者のメール]で新規作成したテナントBで登録したユーザのユーザープリンシパル名を指定します。 ← ポイント3→有効化後テナントBのアカウントのプロパティにテナントAの課金アカウント情報も表示されます。 3.テナントBでサブスクリプションBを新規作成する サブスクリプションの作成（上記操作で登録したアカウント所有者での操作） Enterprise Agreement サブスクリプションを作成する – Azure Cost Management + Billing | Microsoft Learn つまづきポイントは特にありませんでした。 以上、難しい手順はありませんが、それぞれの結び付けを理解していないとどのテナントでどの操作をすればよいかわかりませんでした。もし同じようなところでつまづいている方へこの情報が届けば幸いです。
こんにちは！SCSKの新人、黄です。 前回までの記事では、Rubrikの基本機能と、その強力なランサムウェア対策について詳しくご紹介しました。多くの方に興味を持っていただき、とても嬉しかったです！ 「まだ読んでいない！」という方は、ぜひ以下の記事をご覧ください。 Rubrikとは？クラウド＆オンプレにも対応する次世代バックアップ管理を紹介 – TechHarmony Rubrikのランサムウェア対策：仕組みとシミュレーションで確認 – TechHarmony さて、今回ご紹介するのは、Rubrikのもう一つの注目機能、「 Rubrik Sensitive Data Discovery 」です。 名前の通り、機密データを検知し、適切に管理できる機能です。 興味がある方は、ぜひ詳しく見ていきましょう！ Sensitive Data Discovery とは？ 「どこに機密情報があるのか分からない…」 「気づかないうちに重要なデータが公開されていたらどうしよう…」 「膨大なデータの中から機密データを手動で探すのは大変…」 上記のような悩みを解消し、データの安全性を高めるために役立つのが Rubrik Sensitive Data Discovery です。 Sensitive Data Discoveryは、設定したルールに基づいてバックアップデータをスキャンし、機密データを自動的に検出する機能です。 特に以下の 3 つのポイントがメリットです。 バックアップデータを活用したスキャン 通常の業務データに影響を与えず、バックアップデータを活用して機密情報をスキャンできます。 これにより、負担なくデータの安全性を確保できます。 自動検出とリスク分類 設定されたルールにより、氏名やクレジットカード番号などの機密データを自動で検出し、リスクレベルを分類できます 手動での確認作業を減らし、効率的な管理が可能です。 直感的なレポート機能 分析結果はダッシュボードで可視化され、どこにリスクがあるのか一目で把握できます。 これにより、迅速な対策が可能になります。 実際に使ってみた！Sensitive Data Discovery シミュレーション ここまで、Sensitive Data Discoveryについてご紹介してきましたが、 「実際の運用イメージがわからない！」 と感じる方もいらっしゃるのではないでしょうか？ そこで今回は、 VMware vSphere上の仮想マシン（VM） を例に、Sensitive Data Discovery を実際に動かすシミュレーションを解説します！ このシミュレーションを通じて、どのように機密データが検出され、管理されるのかを具体的にイメージしていただけると思います。 vSphere と RSC（Rubrik Security Cloud） の連携の仕組み 参考資料： vSphere仮想マシン RSCは、 VMware vSphere 環境 とシームレスに連携し、仮想マシン（VM）のデータ保護と管理を実現します。 vCenter Server 接続 RSC は vCenter Server と接続し、VM を自動検出・管理します。 複数クラスター管理 1つの vCenter を複数の Rubrik クラスターで管理可能。VM の保護範囲を柔軟に設定できます。 SLA ドメイン適用 VM に SLA ドメイン（バックアップポリシー）を適用し、自動保護を実現 シミュレーションの全体像 Sensitive Data Discovery を使ったシミュレーションは、以下のような流れで進めてみました。 ステップ1 Sensitive Data Discovery の基本設定 アナライザーとポリシーの作成 ステップ2 初期分析 既存の全バックアップデータを自動スキャン ステップ3 テストデータの準備 機密データあり/なしのファイルを作成 ステップ4 Sensitive Data Discovery実行 機密データの検出 ステップ5 結果確認 ダッシュボードで結果を可視化 ステップ 1: Sensitive Data Discovery の基本設定 まず、RSC コンソールの 「Data Security Posture」 メニューを選択し、Sensitive Data Discovery の設定画面に移動します。 ここでは、Sensitive Data Discovery の 「脳」 とも言える、 アナライザー と ポリシー の2つの設定を行います。これらの設定を行うことで、Rubrik が機密データを自動的に検出し、管理できるようになります。 アナライザーの設定 アナライザーは、機密データを検出するためのルールセットです。 Rubrik では、以下の2種類のアナライザーを利用できます。 事前定義済みアナライザー 62種類 のテンプレートから選択可能です。 例えば、 IPアドレス や Google APIキー など、一般的な機密データのパターンを簡単に検出できます。 カスタムアナライザー 独自のルールを追加可能です。特定のキーワードやパターンに基づいて、柔軟に機密データを定義できます。 今回は、 「社外秘」または「部外秘」 というキーワードを含むファイルを検出するカスタムアナライザーを作成しました。 ポリシーの設定 ポリシーは、アナライザーをどのオブジェクトに適用するかを指定します。 これにより、特定の環境に特化したSensitive Data Discoveryが可能になります。 具体的な操作として、 まずポリシーに含まれるアナライザーを確認し、ポリシーの名称を設定します。 今回使用するのはカスタムで作成した 「Japan Confidential」 アナライザーです。 なお、1つのポリシーに複数のアナライザーを含めることも可能です。 次に、分析対象のオブジェクトを指定します。 ここで特に重要なのは、 SLA ドメインルールが設定されているオブジェクトのみが機密データ分析の対象になる という点です。 SLAドメインルールとは、 「このデータをどのように保護するか」を決めるルール のことです。例えば、「毎日バックアップを取る」「1年間保存する」といった設定が含まれます。このルールが適用されていないオブジェクトは分析できないため、事前に設定を確認しておく必要があります。 Rubrik は下図のような 2 つの方法を提供しており、 オブジェクトタイプ別： 特定のオブジェクトを選択する方法 クラスター別： Rubrik CDM を指定し、CDM 配下のすべての SLA ドメインを持つオブジェクトを分析する方法 今回は、特定の vSphere の仮想マシンを分析するため、1 つ目の「 オブジェクトタイプ別 」を選択します。 以下の図のように、Rubrik は複数のプラットフォームと連携しており、異なる環境に存在するオブジェクトも RSC（Rubrik Security Cloud）を通じて一元管理できます。これも Rubrik の大きな利点の一つです。 今回としては、vSphereプラットフォームをクリックして、特定のVMを選択します。 ステップ 2: 初期分析 ポリシー設定後、Rubrik は 自動的に 初期分析を行います。 初期分析では、対象となるVMのすべてのバックアップ世代をスキャンします。 つまり、今後取得するバックアップデータだけでなく、 Sensitive Data Discovery機能を利用する前に取得したバックアップデータも含めて 機密データの有無を分析することも可能です。 ステップ 3: テストデータの準備 検出精度を検証するため、VM 内に以下の2種類のファイルを作成： 機密データあり ：「社外秘」を含むmail.txtファイル 機密データなし ：mail_normal.txtファイル ステップ 4: Sensitive Data Discovery実行 Rubrik Sensitive Data Discovery は手動で実行する必要がありません。 ポリシーとアナライザーを設定するだけで、対象のオブジェクトがバックアップデータを取得するたびに自動的に実行されます。 Rubrik の公式説明によると、最大 24 時間以内にスキャンが完了するとされていますが、今回のシミュレーションでは バックアップ取得後、約 30 分で機密データの検知結果が反映 されました。 それでは、結果を一緒に確認してみましょう！ ステップ 5: 結果確認 下図のように、 Data Security Posture ダッシュボードで簡単に確認可能です。 Sensitive Data Discovery が vSphere VM 内の機密データを適切に検出し、一つの中リスクのファイル （mail.txt） が存在することが判明しました。 なぜ中リスクなのかというと、設定したアナライザー「Japan Confidential」のリスク評価を中リスクに指定しているためです。 メニューの「 機密データ 」をクリックすると、下図に示すように、 どの VM のどのファイルに機密情報が含まれているのかを追跡でき、適切な対応 が可能になります。 さらに、下図のように、Sensitive Data Discovery はすべてのバックアップ世代をスキャンするため、 どの時点のバックアップデータから機密データが含まれるようになったのか特定 することも可能です。 最後に Rubrik Sensitive Data Discovery を使えば、機密データの管理がグッと楽になります。 ✔ 機密データを自動で検出し、可視化 ✔ バックアップデータを活用し、通常業務に影響を与えない ✔ ポリシー設定だけで継続的に監視可能 実際に試してみると、どこにどんな機密情報があるのか一目で分かるので、データ管理の負担を減らせます。 興味がある方がいらっしゃいましたら、ぜひぜひ 機密データの監視 | Rubrik をご覧ください。 また、Rubrik Sensitive Data Discovery は、今回のシミュレーションで使用したテキストファイルだけでなく、PDF、Excel、Word など多様なファイル形式に対応しています。詳しくは サポートされているファイル形式 をご確認ください。 ここまでご覧いただき、ありがとうございました。 今後も、Rubrik の便利な機能について紹介していく予定です。それでは、また次回！
管理者
