みなさんこんにちは（日本だとこんばんは？）、SCSKの高本です。 Snowflake の待望のフラグシップイベントであるSnowflake Data Cloud Summit 24が Moscone Center, San Francisco にて開幕しました！！ 現地時間6月3日（月）-6日（木） の4日間にわたり 基調講演や、先進事例セッション、テーマ別のブレイクアウトセッションなどなど、 注目のサービスアップデートや最新の技術動向、Genarative AIからセキュリティ、自動化に至るまで, Snowflake のあらゆることに関するセッション が用意されております。 本記事では、4日間に及ぶSnowflake Data Cloud Summit 24 の「 Day1 開幕速報 」として、現地の最新情報を皆様にいち早く共有できればと思います。 [ 速報] Opening Keynote K1（Mon, June 03, 05:00 PM PDT） 概要 現地時間6月3日PM 5:00～PM 6:15にかけて、目玉となるOpening Keynoteセッションが行われました。 現地速報として、セッションや会場の周辺の様子や雰囲気をいち早くお伝えしたいと思います。 ＊その他Keynoteセッションの様子の詳細については、後日追って共有したいと思います。 [ 現地写真] Keynote HALL会場の様子 約30分前からホール会場に入場開始可能となっており、入場開始とともに一気にオーディエンスが押し寄せ、何個あるか数えきれない席がすぐに埋め尽くされるほどでした。 入場開始から会場全体がSnowflakeカラーであるブルーの照明とノリノリの音楽で包まれ、始まるまでの時間もワクワクした気分で過ごすことができました。セッションスタートのカウントダウンと同時に歓声が沸き起こるなど、会場は大盛り上がりでした！！ セッションサマリー Snowflake CEOであるRAMASWAMY氏によるオープニングトークから始まり、NVIDIA CEOのHUANG氏との対談、JPモルガン・チェース、エリクソン、NYCヘルス+ホスピタルズ、Booking.comの各社とのパネルディスカッションなど盛りだくさんのコンテンツでした。 オープニングトーク： SRIDHAR RAMASWAMY（Chief Executive Officer, Snowflake） RAMASWAMY氏は、歓迎の言葉とともに、このData Cloud Summit 24が世界中からのAIとデータ専門家の集まりであることについて言及。 Snowflakeのデータクラウドプラットフォームが過去10年間で急成長している点について強調。 毎日何千もの顧客がデータを共有し、毎日50億件のクエリに対応していることを言及。 RAMASWAMY氏は、データとビジネスをSnowflakeに託してくれた顧客に感謝の意を表示。 AIデータクラウドが企業のあらゆる場所に光を当てているが、これはまだ始まったばかりであると強調。 RAMASWAMY氏は、新たに「Polaris Catalog」を発表。 組織内の誰もが流動的で自然な言語でデータと対話できるようになったと言及。 Snowflakeは「エンタープライズAIの時代（The era of Enterprise AI）」を切り開いていると強調。 今後10年間で、過去20年、30年で成し遂げられたことをはるかに上回るほどのイノベーションが生まれるだろうと言及。 ただ一方、Snowflake社だけではこれを成し遂げることはできず、Snowflake Village全体の協力が必要であり、そのために幾社とのパートナーシップを結んでいることを強調。 RAMASWAMY氏は「我々がこのAIの旅を前進させる上で、NVIDIAのようなパートナーがいるのは素晴らしいことだ」と述べ、われわれはエンタープライズAIの時代にいることを改めて強調。   対談： SRIDHAR RAMASWAMY（Chief Executive Officer, Snowflake） JENSEN HUANG（Founder and CEO, NVIDIA） 両社はAIを理想の理論から現実へと移行させていると強調。 両社の提携発表により、顧客とパートナーはNVIDIA AIを活用したSnowflakeでカスタマイズされたAIデータアプリケーションを構築できるようになると言及。 「初めて、HPCと高速化されたGenAIコンピューティングをデータに持っていく」とJENSEN氏は言及。 強化されたNVIDIA × Snowflakeコラボレーションについて、「NeMo Retrieverはセマンティッククエリライブラリであり、データの埋め込みを行う。企業にとって最も重要な資産はそのプライオリティデータだが、それはSnowflake上に存在する」とJENSEN氏は言及。 両CEOによれば、この先には多くの潜在力、可能性、そして機会が広がっていると強調。   パネルディスカッション： DENISE PERSSON（Chief Marketing Officer, Snowflake） THOMAS DAVEY（Chief Data Officer, Booking.com） CAITLIN HALFERTY（Chief Global Data Officer, Ericsson） ANU JAIN（Head of Data and Technology, JPMC） SHAHRAN HAIDER（Deputy Chief Data Officer, NYC Health + Hospitals） DENISE PERSSON（Snowflake）によるパネリストの紹介：JPモルガン・チェースのANU JAIN、エリクソンのCAITLIN HALFERTY、NYCヘルス+ホスピタルズのSHAHRAN HAIDER、Booking.comのTHOMAS DAVEY HALFERTY氏（Ericsson）は、CDOが持つべき重要な特性は好奇心を持ち、継続的な学習を受け入れることだと強調。 HAIDER氏（NYC Health + Hospitals）は、組織のデータ要求すべてに対応することは不可能であり、ビジネスの優先事項に忠実であり続けることが重要だと強調。 DAVEY氏（Booking.com）は、Booking.comがML、AI、そして今ではGenAIを多用していると述べ、新しいGenAI機能はそのツールボックス内のもう1つのツールにすぎないと考えていると言及。 JAIN氏（JPMC）は、JPモルガン・チェースのこれまでのAI活用は主にコスト削減に重点を置いていたが、収益創出へと移行しつつあると言及。   おまけ：現地会場（Moscone Center）の様子 今回のSnowflake Data Cloud Summit 24は、サンフランシスコの『Moscone Center』にて開催されました。 サンフランシスコと日本との時差は約16時間ほどで、日本と比較するとかなり肌寒いです。現地の人は半袖の人も見かけますが、日中でも長袖の上着が欲しいところです。 一方、海が近く風が強いのにもかかわらず、空気はどこもカラッと澄んでいて気持ちがよく、とても過ごしやすいです。 ▽Moscone Center外観 ▽Moscone Center付近の街の景観 ▽会場内のグッズ売店 ▽会場内の雰囲気   会場MAP   最後に 今回はSnowflakeのフラグシップイベントである Snowflake Data Cloud Summit 24について、現地の実際の模様を速報ベースでお届けしました。 会場の中にいると、まさにSnowflakeがデータ利活用、AI/MLのトレンドの渦の中心にあるサービスなんだなと、改めて肌で感じることができました。 今後もSnowflakeに関する耳寄りな情報を皆様にいち早くお届けできたらと思っています。 最後まで読んでいただき、ありがとうございました！！！

今回はPrisma Cloud APIの解説をしていこうと思います。 その後、実際にPrisma CloudのAPIとPythonを用いてPrisma Cloudで検知した1か月分のアラート件数を取得するプログラムを作成します。 Prisma Cloud APIとは Prisma Cloud APIはプログラムを介してPrisma Cloudの機能にアクセスできるインターフェースです。APIを使用することで、Webコンソールで行っている操作をプログラムで実行することが可能になります。 Prisma CloudではAPIを実行するときにAPIキーを必要とします。まずはそのAPIキーを取得するために事前準備を行い、ログインAPIでAPIキーを取得してから、APIを実行する流れとなります。 事前準備 事前準備として以下のものが必要になります。 ・Prisma CloudのACCESS_KEY ・Prisma CloudのSECRET_KEY ・Prisma CloudのAPI URL API URLはドキュメントを参照: Cloud Security API | Develop with Palo Alto Networks (pan.dev) アクセスキーの発行方法 Prisma CloudのACCESS_KEYとSECRET_KEYを発行していない場合発行する必要があります。 Prisma Cloudコンソールに行き、右上の「Settings」> 左ペイン「Access Control」> 右上の「Add」> 「Access Key」を押下します。 押下後「Name」と「Enable Expiration」の設定値が求められますが、任意で入力してください。 ※Enable Expirationはアクセスキーの有効期限を決めるかの設定値になります。オフであれば有効期限はありません。 作成後以下の画像のようにAccess Key IDとSecret Access Keyがでてくるので必ず保存してください。 ※「Download.csv file」を押下するとAccess Key IDとSecret Access Keyの入ったファイルが保存されます。 ログイン処理 ここからはログイン処理のコードを書いていきます。 まず必要なライブラリをインポートします。 import requests from time import sleep import json リクエストするための情報を書いていきます。 url変数には事前準備で準備したURLを入力し、末尾にはAPIの/loginを入れてください。 usernameには事前準備で用意したACCESS_KEY passwordには事前準備で用意したSECRET_KEYを入力します。 wasResponseErrorはレスポンスのステータスコードが200以外の時に再リクエストするための変数です。 変数のpayload, headersには以下のドキュメントを参考に作成しました。 Login APIドキュメント: Login | Develop with Palo Alto Networks (pan.dev) url = "https://api.anz.prismacloud.io/login" username = "ACCESS_KEYを入れる"  password = "SECRET_KEYを入れる" wasResponseError = False payload = '{\"username\":\"' + username + \     '\",\"password\":\"' + password + '\"}' headers = {     "Accept": "application/json; charset=UTF-8",     "Content-Type": "application/json; charset=UTF-8" } Prisma Cloudにリクエストを送信していきます。 最初にresponse変数を作成してその変数の中身にリクエストするコードを書いていきます。 リクエストの中身にはPOST、先ほど変数で定義したurl、data=には変数で定義したpayload、headers=には同じく定義したheadersを入れます。 while True:     response = requests.request(         "POST", url, data=payload, headers=headers) 次に ステータスコードが200の場合にレスポンスからtokenだけを取り出す処理を書きます。このtokenがAPIキーとなります。 この時ステータスコードが200であれば wasResponseErrorをFalseにしてwhileを終わらせます。                             ステータスコードが200ではない場合(elseの場合)ステータスコードを表示して、過去にレスポンスのステータスコード200以外が返却されたことがあれば、プログラムを終了し、ステータスコード200以外が返却されるのが初めてであれば一定時間経過後、再度リクエストします if response.status_code == 200:         token = json.loads(response.text)['token']         wasResponseError = False         break     else:        print(f"You couldn't be authenticated [status_code:{response.status_code}]")         if wasResponseError:             exit()         else:             sleep(32)             wasResponseError = True ステータスコード200のレスポンスは以下の感じで返ってきます。 {     "message": "login_successful",     "token": "TokenID",     "customerNames": [         {             "customerName": "SCSK",             "prismaId": "12345678910",             "tosAccepted": true         }     ] } ログイン処理の全体コードが以下になります。 import requests from time import sleep import json url = "https://api.anz.prismacloud.io/login" username = "ACCESS_KEYを入れる"  password = "SECRET_KEYを入れる" wasResponseError = False payload = '{\"username\":\"' + username + \     '\",\"password\":\"' + password + '\"}' headers = {     "Accept": "application/json; charset=UTF-8",     "Content-Type": "application/json; charset=UTF-8" } while True:     response = requests.request(         "POST", url, data=payload, headers=headers)     if response.status_code == 200:         token = json.loads(response.text)['token']         wasResponseError = False         break     else:         print(f"You couldn't be authenticated [status_code:{response.status_code}]")         if wasResponseError:             exit()         else:             sleep(32)             wasResponseError = True アラート件数の取得 ログイン処理を作成したので次はアラート件数を取得していきます。 querystring辞書のdetailedキーの値はFalseにしておきます。 payloadはドキュメントを参照し、作成しました。 timeRange内のstartTimeとendTimeは4/1 ～ 4/31までのミリ秒のUnix時間になっています。 headersはx-redlock-authを追加し、そこにログイン処理で変数を作成したtokenを格納します。 Alert APIドキュメント: List Alerts V2 – POST | Develop with Palo Alto Networks (pan.dev) wasResponseError = False alert_url = "https://api.anz.prismacloud.io/v2/alert" querystring = {"detailed": False} payload = {     "detailed": False,     "fields": [],     "limit": 5000,     "offset": 0,     "pageToken": "",     "sortBy": ["alertTime:asc"],     "timeRange": {         "type": "absolute",         "value": {             "startTime": 1711897200000,             "endTime": 1714575599000                         }     } } headers = {     "content-type": "application/json; charset=UTF-8",     "x-redlock-auth": token } リクエスト処理です。 ここはログイン処理と同様になっています。 変わっているところとすれば、requestメソッドにjson、params引数が追加されたことです。 while True:     response = requests.request(         "POST", alert_url, json=payload, headers=headers, params=querystring)     if response.status_code == 200:         alertdata = json.loads(response.text)         wasResponseError = False         break     else:         print(f"Bad Request(/v2/alert)[status_code:{response.status_code}]")         if wasResponseError:             exit()         else:             sleep(32)             wasResponseError = True 取得したアラート一覧からアラートIDのみを抽出する処理です。 アラートIDを抽出して、リストに格納し、アラート件数を表示します。 alert_ids = [item['id'] for item in alertdata['items']] print(f"4/1 ～ 4/31までのアラート数は{len(alert_ids)} です。") 全体のコードです。 wasResponseError = False alert_url = "https://api.anz.prismacloud.io/v2/alert" querystring = {"detailed": False} payload = {     "detailed": False,     "fields": [],     "limit": 5000,     "offset": 0,     "pageToken": "",     "sortBy": ["alertTime:asc"],     "timeRange": {         "type": "absolute",         "value": {             "startTime": 1711897200000,             "endTime": 1714575599000                         }     } } headers = {     "content-type": "application/json; charset=UTF-8",     "x-redlock-auth": token } while True:     response = requests.request(         "POST", alert_url, json=payload, headers=headers, params=querystring)     if response.status_code == 200:         alertdata = json.loads(response.text)         wasResponseError = False         break     else:         print(f"Bad Request(/v2/alert)[status_code:{response.status_code}]")         if wasResponseError:             exit()         else:             sleep(32)             wasResponseError = True alert_ids = [item['id'] for item in alertdata['items']] print(f"4/1 ～ 4/31までのアラート数は{len(alert_ids)} です。") レスポンス時の中身です。 ※一部を切り取っていますので詳細はドキュメントを参照してください。 "items": [         {             "id": "P-12345",             "status": "resolved",             "reason": "RESOURCE_DELETED",             "firstSeen": 1711898107130,             "lastSeen": 1712157098580,             "alertTime": 1711898107130,             "lastUpdated": 1712157098580,             "policyId": "abcdef-12ab-1234-abcdef-123abcdef",             "saveSearchId": "ab12345n-123f-1234-abcd-abbbcs",             "metadata": {                 "saveSearchId": "abcdefg-123456-abcd"             },     ] プログラム全体 今回書いたプログラムの全体になります。 import requests from time import sleep import json # ログイン処理 url = "https://api.anz.prismacloud.io/login" username = "ACCESS_KEY" password = "SECRET_KEY" wasResponseError = False payload = '{\"username\":\"' + username + \     '\",\"password\":\"' + password + '\"}' headers = {     "Accept": "application/json; charset=UTF-8",     "Content-Type": "application/json; charset=UTF-8" } while True:      response = requests.request(          "POST", url, data=payload, headers=headers)      if response.status_code == 200:          token = json.loads(response.text)['token']          wasResponseError = False          break      else:          print(f"You couldn't be authenticated [status_code:{response.status_code}]")          if wasResponseError:             exit()          else:             sleep(32)             wasResponseError = True # アラート取得 wasResponseError = False alert_url = "https://api.anz.prismacloud.io/v2/alert" querystring = {"detailed": False} payload = {     "detailed": False,     "fields": [],     "limit": 5000,     "offset": 0,     "pageToken": "",     "sortBy": ["alertTime:asc"],     "timeRange": {         "type": "absolute",         "value": {             "startTime": 1711897200000,             "endTime": 1714575599000                         }     } } headers = {     "content-type": "application/json; charset=UTF-8",     "x-redlock-auth": token } while True:     response = requests.request(         "POST", alert_url, json=payload, headers=headers, params=querystring)     if response.status_code == 200:         alertdata = json.loads(response.text)         wasResponseError = False         break     else:         print(f"Bad Request(/v2/alert)[status_code:{response.status_code}]")         if wasResponseError:             exit()         else:             sleep(32)             wasResponseError = True alert_ids = [item['id'] for item in alertdata['items']] print(f"4/1 ～ 4/31までのアラート数は{len(alert_ids)} です。") 実行結果 以下画像が実行結果です。 おわりに 当社では、複数クラウド環境の設定状況を自動でチェックし、設定ミスやコンプライアンス違反、異常行動などのリスクを診断するCSPMソリューションを販売しております。 マルチクラウド設定診断サービス with CSPM｜ SCSK株式会社 ご興味のある方は是非、お気軽にお問い合わせください。

Prisma Cloudは、クラウド環境のセキュリティとコンプライアンスを一元管理するツールで、リアルタイムの脅威検出やリソースのチェックが可能です。 今回は、実際にAWS環境をPrisma Cloudに接続して、アラート内容を確認してみました。 Prisma Cloud から AWS に接続 11ステップあります。 ①Prisma Cloudに管理者権限でログインし、設定を押下します。 [作業場所：Prisma Cloudコンソール] ②左のメニューから「プロバイダ」を選択し、右上の「プロバイダーに接続する」から「クラウドアカウント」を押下します。 [作業場所：Prisma Cloudコンソール] ③接続するプロバイダを選択してください。今回の場合はAmazon Web Servicesです。 [作業場所：Prisma Cloudコンソール] ④今回はAWSアカウント単体を接続するため「アカウント」選択し、その他は項目を必要があればチェックしてください。今回は「CSPM」機能のみを利用するため、個別のチェックは外しています。「Next」を押下します。 [作業場所：Prisma Cloudコンソール] ⑤「アカウントID」に接続するクラウド環境のアカウントIDとアカウント名に任意の名前を入力します。「IAMロールの作成」を押下するとAWSコンソールに遷移しIAMロールの作成に作業に移ります。 [作業場所：Prisma Cloudコンソール] ⑥AWSマネジメントコンソールにログインするとCloudFormationのスタック作成画面に遷移するので「スタック名」を記入します。今回はデフォルトの”PrismaCloudApp”を使用しています。下部の青いボックスの「AWS～承認します」にチェックを入れます。 「スタックの作成」を押下します。 [作業場所：AWSマネジメントコンソール] ⑦スタックの作成が完了したことを確認します。 [作業場所：AWSマネジメントコンソール] ⑧出力を押下し、PrismaCloudAppARNをコピーします。 [作業場所：AWSマネジメントコンソール] ⑨Prisma Cloudコンソールに戻り「IAMロールARN」にコピーしたARNをペーストし、「Next」を押します。 [作業場所：Prisma Cloudコンソール] ⑩ステータス画面にて全ての項目で「成功」となっていることを確認して、「保存して閉じる」を押下します。 [作業場所：Prisma Cloudコンソール]   ⑪アカウントが追加されていることを確認して接続作業完了です。 [作業場所：Prisma Cloudコンソール] PrismaClodでアラートの確認をしてみる Prisma Cloud上のアラートから、検知されたアラートを見ることができます。 *以下手順の作業場所はすべてPrisma Cloudコンソールとなっています。 画面上部の「アラート」を選択すると、アラートを検知したポリシーの一覧が出ます、展開するとそのポリシーで検知したアラートが表示されます。   アラート一覧のアセット名をクリックするとアセットの概要が表示されます。また、結果のタイプから、アセットに関連付けられた様々な脅威またはセキュリティの問題が確認できます。 アラート一覧のアラートIDを押下するとアラートの対処手順が表示できます。設定の妥当性の評価と修正が必要な場合はこの対処手順に従って対処いただけます。 まとめ 今回はPrisma CloudにAWS環境を実際に接続してみて、環境のチェックしてみました。 接続作業をした感想としては、ガイドもありわかりやすく、簡単に接続できました。作業自体もだいたい10~15分ほどだったと思います。 Prisma Cloudコンソールでの調査も直感的でわかりやすいと感じました。 この記事でPrisma Cloudの導入イメージや使用感などが少しでも伝われば嬉しいです。 Prisma Cloudにはアラートの可視化など他にもクラウド環境設定のセキュリティチェックに便利な機能がありますので、他の記事でまたご紹介できればと思っています。   また、当社では、複数クラウド環境の設定状況を自動でチェックし、設定ミスやコンプライアンス違反、異常行動などのリスクを診断するCSPMソリューションを販売しております。ご興味のある方はお気軽にお問い合わせください。リンクはこちら↓ マルチクラウド設定診断サービス with CSPM｜ SCSK株式会社 マルチクラウド環境のセキュリティ設定リスクを手軽に確認可能なスポット診断サービスです。独自の診断レポートが、運用上の設定ミスや設計不備、クラウド環境の仕様変更などで発生し得る問題を可視化し、セキュリティインシデントの早期発見に役立ちます。 www.scsk.jp

こんにちは。SCSKの上田です。 今年も、延べ12万人が来場する国内最大級のICTイベント「 Interop Tokyo 2024 」が、 6月12日(水)～6月14日(金) の3日間、 幕張メッセ で開催されます。Interop Tokyoはインターネットテクノロジーのイベントで、毎年国内外から数百の企業・団体が参加し技術動向とビジネス活用のトレンドをいち早く体感できる場です。 SCSK は Zabbixプレミアムパートナー として、 Zabbixブース（ブース番号：6F04）に出展します！！ ↓↓↓ご来場を希望される方は、以下のリンクから来場者登録をよろしくお願いします！↓↓↓ 詳しくはこちら　＞ SCSK の出展内容 SCSK は、 Zabbixブース内（ブース番号：6F04） で 弊社のサービスや導入事例の紹介 します。 オープンソースの監視ツールであるZabbixに興味のある方は、ぜひご来場ください！ また、同ブース内で ショートセミナー も開催します。 タイトル：【Zabbixに乗り換え検討されてる方必見】Zabbixへの移行とAIによる効率化で運用の安定を！ 登壇日時：①6月12日(水)15:10～15:25 　　　　　②6月13日(木)17:15～17:30 　　　　　③6月14日(金)11:25～11:40 発表内容：既存監視ツールからZabbixへの移行、AIを使った運用効率化 本記事執筆者の上田も②の枠で登壇致します！ 各セッションの内容は同じですので、ご都合のつく回にぜひお越しください！ ShowNetへの参加 Interop Tokyoの同時開催イベントとして「 ShowNet 」があります。ShowNetは、Interop会場内で実際にネットワークを構築し、運用するイベントです。 出展社から提供された約2000の製品・サービス と、 約700名ものトップエンジニア達 が幕張メッセに集結して行われる巨大プロジェクトです。これは、幕張メッセ全体をインターネットに接続した実稼働ネットワークであり、各種相互接続の実証やチャレンジが行われます。 ZabbixもShowNet内での製品状態監視に導入 され、 SCSK はZabbix構築サポート として プロジェクトに参加します！ Interopにご来場された際は、是非ShowNetにもお越しください。 それでは、 当日はZabbixブースへのご来場を心よりお待ちしております！   ★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

こんにちは。ひるたんぬです。 春が終わりを告げ、夏が近づいてきましたね。 最近はニュースや新聞などで「今年は最も暑い」や、「観測史上一番の暑さ」「季節外れの暑さ」など、連日ホットな話題が報道されています。野菜やオリーブオイルも高騰が続いており、最近は手に取るのを躊躇してしまいます。 …ところで、皆さんは「夏」と「冬」、どちらが好きですか？ 私は圧倒的に冬派¹なのですが、周囲に聞く限り少数派のようでした。 ¹ 冬派な理由としては、寒いのは「着ればなんとかなるから」です。暑いのには対処の限界がありますからね… 少し古い資料にはなりますが、日本リサーチセンターが2016年5月に行った調査によると、 日本人全体でみれば、 「夏」が52%と半数を超えて、「冬」（21％）の倍以上多い 。 性別でみると、男⼥ともに「夏」が優位だが、男性では58％と半数を超えて特に多い。 エリア別では、 「夏」は東⾼⻄低の傾向がみられ、北海道・東北では6割を超える 。 年代別でみても、いずれも「夏」が優位だが、15〜19才では「冬」が3割以上で比較的多い。 出典：日本リサーチセンター「 【NRCレポート】あなたはどっち？日本人の好み調査　Part3：生活とライフスタイル 」P.10 という結果でした。この結果を見る限り、夏派の方は涼しい地域の方に多い傾向があるので、夏が暑くなってきている今、その割合は減っているんでしょうかね？少しばかりですが気になります。 話題がそれてしまいましたが、本題に入ります。 今回は2023年4月にGAとなった「CodeCatalyst」を色々触ってみたので、それについてお話ししようと思います。 そもそも…CodeCatalystって？ CodeCatalystについて初めて耳にする方もいるかと思いますので、簡単にご説明いたします。 詳細について知りたい方は、Black BeltのCodeCatalystシリーズをご覧になることをおすすめします。（全部で9編あるので、中々のボリュームです。） サービス別資料 | AWS クラウドサービス活用資料集 アマゾン ウェブ サービス (AWS) は安全なクラウドサービスプラットフォームで、ビジネスのスケールと成長をサポートする処理能力、データベースストレージ、およびその他多種多様な機能を提供します。それらを活用するために役立つ日本語資料、動画... aws.amazon.com CodeCatalystを一言で表すと「 統合ソフトウェア開発サービス 」です。 出典：AWS「 AWS Black Belt Online Seminar – Amazon CodeCatalyst Overview 編 」P.11 これを聞くと、「既にCodeBuildやCodePipelineなどがあるじゃないか」と思う方もいると思います。個人的には Code ○○が 一つにまとまって提供されている点 、 複数人での開発（コラボレーション）のしやすさ において、CodeCatalystの使いやすさがあるのではないかと思います。 やってみたこと プライベートで作りたいものがあったので、CodeCatalystを開発環境に設定し開発を進めました。 開発を進める中で、せっかくならCI/CDについても勉強したくなり、今回の記事を作成しております。 今回の記事では、下記フローを自動で行います。 前準備 CodeCatalystの利用にあたっては、AWS Builders IDの取得が必要です。 また、初期設定が必要となっておりますが、このあたりにつきましては参考サイトのご紹介のみさせていただきます。参考サイトなどをご覧の上、 自分のCodeCatalyst Spaceを作成 CodeCatalystで使用するRoleを作成 新規の空のプロジェクト（Start from scratchより）を作成 してください。 Amazon CodeCatalystを使ってblueprintでアプリを作るまで - Qiita CodeCatalyst挑戦の経緯仕事の案件とは全く関係ない趣味の範囲＆自主学習用にWebアプリを作っております。今までは作ったものをローカルで動作させて、DBもSQLiteで…みたいな感じで作… qiita.com 20221207-CodeCatalystを触ってみた zenn.dev Amazon CodeCatalystで作るAWS CDKコントリビュート環境のススメ | DevelopersIO Amazon CodeCatalystの開発環境の変更方法と、CodeCatalyst上にAWS CDKのコントリビュート環境を構築する方法について解説します dev.classmethod.jp 作成が終わったら、下記のようなProjectのページができていることを想定しています。 また、ソースコードの格納先である任意のS3バケットが必要です。 あらかじめ作成しておいてください。 バケットではバージョニングを有効にしてください。 CDを行う際にオブジェクトのバージョンが必要となるためです。 リポジトリの作成 今回はCodeCatalyst内にリポジトリを作成します。（GitHubのリポジトリを紐づけることも可能です。） 上図画面から「Source repositories」欄右上の「Add repository」→「Create repository」を選択してください。 リポジトリ作成画面で適切に情報を入力し、「Create」を押下します。 今回の手順ではPythonを用いるので、.gitignoreはPythonを選んでおくと良いと思います。 作成が完了すると、リポジトリが表示されます。 開発環境の準備 CodeCatalystでは、開発環境としてCloud9やVS Codeなどを選択できます。 左側ペインより「Code」→「Dev Environments」を選択し、「Create Dev Environment」を押下します。今回は「Visual Studio Code」を選択します。 Visual Studio Codeがインストールされていない、など利用ができない場合は、Cloud9を選択してください。本記事ではVisual Studio Codeの例を示しますが、手順は大きくは変わりません。 下図が表示されリポジトリに関する設定や、開発環境のリソースの設定ができます。 今回は特に設定を変更せず「Create」を押下します。 しばらく待つと、作成が完了した旨のメッセージが表示されるので、作成された開発環境の「Open in Visual Studio Code」を押下します。 はじめてCodeCatalystからVS Code環境に接続した際などに、拡張機能(AWS Toolkit)のインストールや初期設定を求められます。手順に従い対応してください。 VS Codeが起動し、左下に「SSH: aws-devenv-…」と表示があれば接続に成功しています。 ここで、検証用の簡単なファイルを作成します。今回は以下のサイトを参考に、fizzbuzz問題のプログラムを作成します。 pytestで簡単にカバレッジを出力する方法 | とあるエンジニアのエソラゴト テストコードを書いていると、どれくらいテストコードを書くべきか迷うことがあります。その時に有効なのが、カバレッジです。カバレッジとは、開発したプログラムに対するテストのカバー率のことを言います。カバレッジが高いとテストの網羅率が高いと判断が... ya6mablog.com また、ここで作成する「resource.yaml」は以下のコードを複製してください。 AWSTemplateFormatVersion: "2010-09-09" Parameters: BucketName:   Type: String LambdaVersionId:   Type: String Resources: FizzBuzzFunction:   Type: "AWS::Lambda::Function"   Properties:     Code:       S3Bucket: !Ref BucketName       S3Key: "Artifacts/src.zip"       S3ObjectVersion: !Ref LambdaVersionId     Environment:       Variables:         bucket_name: !Ref BucketName     Handler: "get_index.lambda_handler"     Runtime: "python3.12"     Timeout: 10     FunctionName: "FizzBuzz-Function"     Role: !Ref FizzBuzzRole FizzBuzzFunctionLogGroup:   Type: "AWS::Logs::LogGroup"   Properties:     LogGroupName: !Sub "/aws/lambda/${FizzBuzzFunction}"     RetentionInDays: 30 FizzBuzzFunctionVersion:   Type: AWS::Lambda::Version   Properties:     FunctionName: !Ref FizzBuzzFunction FizzBuzzRole:   Type: AWS::IAM::Role   Properties:     RoleName: Lambda-FizzBuzzRole     AssumeRolePolicyDocument:       Version: '2012-10-17'       Statement:         - Effect: Allow           Principal:             Service:               - lambda.amazonaws.com           Action:             - sts:AssumeRole     ManagedPolicyArns:       - arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole 最終的にファイル構成が下図のようになっていればOKです。 ここまでできたら、一旦VS Codeの拡張機能「AWS Toolkit」を選択し、「CODECATALYST」→「Stop Dev Environment」を押下し、開発環境を一旦停止させます。 VS Codeを ✕ で閉じた場合、開発環境は稼働したままの状態になっています。 今回の設定(初期設定)では、非アクティブの場合、15分で自動停止されるようになっていますが、利用可能な時間枠を消費してしまいますのでご注意ください。 誤ってVS Codeを ✕ で閉じた場合は、CodeCatalystのページより該当の開発環境を選択し、「Stop」を押下することで停止させることができます。 環境の登録 リソースをデプロイする先のAWSアカウントをここで指定します。 左側ペインより「CI/CD」→「Environments」を選択し「Create environment」を押下します。 設定値は以下のようにしてください。 Environment name：分かりやすい名前を設定します。今回は「Dev」としました。 AWS account connection：ご自身のAWSアカウントIDを選択してください。 設定ができたら、「Create environment」を押下します。 CI/CDワークフローの構築 …ここからが本番ですね。笑 左側ペインより「CI/CD」→「Workflows」を選択し「Create workflow」を押下します。 workflowの作成画面で、先ほど作成したリポジトリを選択し、「Create」を押下します。 これにより、workflowが作成されました。 workflowはStep Functionsと同じように、ブロック(Visual)もしくはコード(YAML)で作成することができます。今回は初めてということもあるので、Visualで説明を進めます。 CI: Continuous Integration 上図のうち、「PC」と「Source Repositoiry」の部分については既に作成されています。 そのため、単体テストを行うための準備をします。 Test Workflow編集画面の左上にある「Action」より、「Test」を探し、右下の「+」を押下します。 すると右側に設定項目が出てきますので、今回は以下に従って設定してください。 Inputs 何も変更しません。 Configuration Action name：分かりやすい名前に変更します。今回は「Test」としました。 Shell commands：以下のスクリプトを入力します。 - Run: pip install -r ./requirements.txt - Run: PYTHONPATH=. - Run: pytest --cov=src/ test --cov-report=xml - Run: pytest --junitxml=./unit_test.xml Packages 何も変更しません。 Outputs 何も変更しません。 CD: Continuous Deployment 単体テストを終えた作成物については、承認を挟んだ後にデプロイをするという流れを取っています。 Approval 先ほどの「Actions」の横にある「Gates」から「Approval」を追加します。 右側に出てくる設定項目を以下の通りに設定してください。 Inputs 何も変更しません。「Depends on」に、先ほどの「Test」が設定されていることを確認してください。 Configuration Gate name：分かりやすい名前に変更します。今回は「Approval」としました。 Deploy 今回はCloudFormationでのデプロイを行います。 そのため、ここでは リソースファイル（resource.yaml）と、ソースコードをS3にアップロードする ソースコードのオブジェクトバージョンを取得 リソースをデプロイ の3つに分けて手順をご説明します。 1. S3へのアップロード 「Actions」から「Build」を探し、追加します。 右側に出てくる設定項目を以下の通りに設定してください。 Inputs Variables：以下のキーと値を設定してください。 キー：bucket_name 値：(ソースコードなどを保管するバケット名) Depends on：「Approval」を選択してください。 Configuration Action name：分かりやすい名前に変更します。今回は「TransferArtifactsToS3」としました。 Environment：「Dev」を選択します。 AWS account connection：ご自身のAWSアカウントIDを選択します。 Role：事前準備で作成したロールを選択します。 Shell commands：以下のスクリプトを入力します。 - Run: sudo yum install zip -y - Run: cd ./src - Run: zip ./src.zip *.py - Run: cd ../ - Run: aws s3 mv ./resource.yaml s3://${bucket_name}/Resources/resource.yaml - Run: aws s3 mv ./src s3://${bucket_name}/Artifacts/ --recursive --include "*" Packages 何も変更しません。 Outputs Variables：「Add variables」を押下し、Nameに「bucket_name」と入力します。 2. オブジェクトバージョンを取得 先ほどと同様に「Actions」から「Build」を探し、追加します。 右側に出てくる設定項目を以下の通りに設定してください。 先程のS3へのコピーと同じブロックで実行しても良いのですが、分かりやすさのために、あえて分けてます。 Inputs Depends on：「TransferArtifactsToS3」を選択してください。 Configuration Action name：分かりやすい名前に変更します。今回は「GetObjectVersion」としました。 Environment：「Dev」を選択します。 AWS account connection：ご自身のAWSアカウントIDを選択します。 Role：事前準備で作成したロールを選択します。 Shell commands：以下のスクリプトを入力します。 - Run: src_info=$(aws s3api list-object-versions --bucket ${TransferArtifactsToS3.bucket_name} --prefix Artifacts/src.zip) - Run: src_version=$(echo ${src_info} | jq '.Versions[] | select(.IsLatest) | .VersionId') - Run: echo '{"Parameters":{"LambdaVersionId":'$src_version', "BucketName":"${TransferArtifactsToS3.bucket_name}"}}' | jq > ./version.json Packages 何も変更しません。 Outputs Artifacts：「Add artifact」を押下します。 Build artifact name：分かりやすい名前を設定します。今回は「ArtifactVersion」としました。 Files produced by build：「./version.json」と入力します。 3. リソースのデプロイ 「Actions」から「Deploy AWS CloudFormation stack」を探し、追加します。 右側に出てくる設定項目を以下の通りに設定してください。 Inputs Artifacts：「ArtifactVersion」を選択してください。 Depends on：「GetObjectVersion」を選択してください。 Configuration Action name：分かりやすい名前に変更します。今回は「DeployAWSCloudFormationStack」としました。 Environment：「Dev」を選択します。 AWS account connection：ご自身のAWSアカウントIDを選択します。 Role：事前準備で作成したロールを選択します。 Stack name：適当なスタック名を入力します。今回は「Lambda-CICD」としました。 Stack region：スタックをデプロイしたいリージョンを選択してください。東京リージョンでも問題ありません。 Template：「./resource.yaml」と入力します。 Advanced：オプションを展開し、以下を設定します。 Capabilities：IAMリソースを作成するため、「CAPABILITY_NAMED_IAM」にチェックを入れます。 Parameter overrides：オブジェクトバージョンを上書きするため、以下のように設定します 「Specify overrides using a file」を選択 ファイル名：file:///artifacts/DeployAWSCloudFormationStack/ArtifactVersion/version.json なお、パラメータの上書きについては以下のドキュメントを参考にしました。 "Deploy AWS CloudFormation stack" action YAML definition - Amazon CodeCatalyst The following is the YAML definition of the Deploy AWS CloudFormation stack action. To learn how to use this action, see... docs.aws.amazon.com すべてが完了したら、下図のようなフローが出来上がっていると思います。 確認ができたら左上の「Commit」を押下します。するとフローが動き出し、テストを開始します。 フローの進捗状況確認 左ペインより「CI/CD」→「Workflows」を選択することで確認できます。 また、それぞれのリンクをクリックすることで詳細な進捗を確認できます。 テスト結果の確認 フローの「Test」をクリックすると、テストの詳細を確認できます。例えば「Reports」タブをクリックすると、行われたテストの結果やカバレッジをひと目で確認することができます。 承認 今回は「Test」のあとに承認（Approval）を追加しているので、単体テスト終了後にApprovalを選択すると、以下のような画面が表示されます。 ここでテストのレビューを行い、承認するかどうかを選びます。 承認する（Approve）と先のフローに進み、却下する（Reject）とそこでフローが終了します。 デプロイ確認 フローが最後まで完了すると、指定したAWS環境にリソースがデプロイされています。 マネジメントコンソールのCloudFormationから、もしくはWorkflowの最後のブロック（DeployAWSCloudFormationStack）選択し、「Summary」タブを押下することで確認することができます。 おわりに 今回は比較的新しいサービスに触れてみました。 公式ドキュメントが英語であったり、「やってみた」というような記事が少なかったため試行錯誤するところが多かったです。 また、私自身CI/CDの枠組みに初めて触れてみて、改めて自動化の簡単さ・便利さに気づくことができました。 ▼ 今回参考にした、数少ない日本語の公式ブログです。 Amazon CodeCatalyst を用いたワークフローによるビルド、テスト、デプロイの実現 | Amazon Web Services (この記事は Using Workflows to Build, Test, and Deploy with aws.amazon.com

こんにちは、SCSK　池田です。 すっかり桜も散り、新緑がまぶしい季節となりましたが、皆さまいかがお過ごしでしょうか？ ブログの更新が少しあいてしまいましたが、心機一転がんばっていきます！ さて、「 第４回　【LifeKeeper】AWSでは仮想IPアドレスが使えない！？をこうして解決する！！ 」では、 同一VPCからの接続方式 について、ルートテーブルシナリオをお伝えしましたが、読者のかたから「 AWSの外から接続する場合はどうするのですか？ 」とご質問をいただきました。 第８回目の今回は、AWSの外（例えばオンプレミスのデータセンターなど）から、AWS内のHAクラスターシステムにアクセスする場合の仕組みについて解説します。 ◆おさらい◆　ルートテーブルシナリオとは ルートテーブルを使用した接続方式 AWSでは仮想IPアドレスの機能が提供されていません。その為、LifeKeeperを構成するサーバが存在するVPCのCIDR外に「ダミーの仮想IPアドレス」を用意し、その「ダミーの仮想IPアドレス」と「稼働系サーバのENI」をルートテーブルで紐づけることによって、稼働系サーバにアクセスできるようになります。 イメージ図は以下の様になります。   （１）クライアントは「ダミーの仮想IPアドレス」（図では10.1.0.10）にアクセスします。 （２）ルートテーブルには予め「ダミーの仮想IPアドレス」のTargetとして稼働系サーバのENI（図では10.0.2.4）を 指定しておくことによって、クライアントからの通信が稼働系サーバに送信されます。 （３）障害が発生しフェイルオーバ処理が必要となった際には、LifeKeeperの機能(AWS CLIによる自動実行)により、 ルートテーブルの「ダミーの仮想IPアドレス」のTargetが待機系サーバのENI（図では10.0.4.4）に書き換えられます。 この時は、接続元（クライアント）はLifeKeeperを構成するサーバと同一のVPC内に存在していました。   AWS外からの接続にどう対応する！？ さてここからが本題となります。 AWS外から接続する場合は、Transit Gatewayを経由させることで可能となります。 Transit Gatewayとは 少し話はそれますが、Transit Gatewayについても簡単にご説明します。 Transit Gatewayとは、AWS公式サイトでは「 VPC とオンプレミスネットワークを中央ハブで接続 します」とあります。 Transit Gatewayを使用しない場合は、このように蜘蛛の巣上にサイトごとを接続する必要がある為、管理が煩雑となります。 ◆Transit Gatewayを使わない場合 これをTransit Gatewayを使用すると、こんなにスマートに！ ◆Transit Gatewayを使った場合 Transit Gatewayを中央ハブとして シンプルな構成になんですね さて、Transit Gatewayが便利そうだなと、なんとなくご理解いただいた上で、いよいよAWS外からの接続をどうやって実現しているのかに進みます。 AWS外からの接続にはTransit Gatewayのルートテーブル使う AWS外（今回の例ではデータセンター）から接続するケースでみていきましょう。 構成イメージは以下の通りです。 データセンター内にあるコンピュータ（サーバやクライアントなど）から接続する場合の流れを順を追って解説します。 （１）クライアントは、接続先として「ダミーの仮想IPアドレス」（図では10.1.0.10）を指定します。 （２）Transit Gatewayのルートテーブルには、予め接続先(10.1.0.10)に対するTargetとして、接続先のHAクラスターが存在するVPCのセグメントが設定してあります。その為、通信は対象VPCに向けられます。 （３）対象VPCのルートテーブルには、予め接続先(10.1.0.10)に対するTargetとして、稼働系サーバのENIが設定してあるので、通信は稼働系サーバに到達します。   まとめ 今回は、AWS外からAWS内のクラスタ化したシステムへアクセスする方法について解説しました。基幹システムのパブリッククラウドへのシフト／リフトが急速に進む中で、オンプレミスとAWSの相互接続の要件は以前に増しています。また最近では、パブリッククラウド同士をネットワーク接続する、マルチクラウド構成の利用も活発化しています。そのような場面で、今回解説した接続構成が活用できるのではないかと思います。 まとめますと AWS外からの接続は以下で実現可能 ・Transit Gatewayのルートテーブルを利用する ・さらにVPCのルートテーブルも利用することで稼働系サーバに通信可能となる

Catoクラウドにリモート接続する際に、個人所有のPCやスマートデバイスなどのBYOD利用を制限するというニーズは多く、Catoのデバイス制御機能を使用しているお客様も数多くいらっしゃいます。 Catoのデバイス制御は、2024年5月現在では以下の3つの機能があります。 Catoで設定できるデバイス制御 １.Device Posture デバイスのセキュリティ状態をチェックして、条件を満たした場合Cato接続を許可します。 自社の標準PCの仕様に合わせてCato側の設定を行えるので手間なくデバイス制御が実装できます。 当初はSDPユーザーのみがサポート対象でしたが、Cato Socket配下でもDevice Posture機能が適用されるようになりました。但し、SDPユーザーではblockされてもSocket配下からアクセスすると接続できてしまったり、 Always-On 設定と組み合わせて使用する事が推奨だったりするので、現時点ではSDPユーザーに対する利用がベターです。 2.Device Authentication 認証局で発行したルート証明書をCatoクラウドに登録し、各デバイスにはクライアント証明書をインストールして証明書認証によるデバイス制御を行います。証明書の配布や更新の手間はあるかもしれませんが柔軟なコントロールが可能です。 証明書による認証については以下の記事をご参照下さい。 Catoクラウドでのデバイス証明書認証について Catoクラウドでのデバイス証明書認証の設定方法、エラー事例をご紹介します。 blog.usize-tech.com 2024.01.11 【Catoクラウド】iPhoneでのデバイス証明書認証 Catoクラウドのデバイス証明書認証について、iPhoneへの設定例とエラー事例を解説します。 blog.usize-tech.com 2024.01.04 3.MAC Authentication こちらは補足となりますが、Cato Socket配下のデバイスに対してMACアドレスによるデバイス認証が可能です。 実装方法は、Cato接続を許可するデバイスのMACアドレスを記載したcsvファイルを作成しCatoクラウドにアップロードします。 MACアドレスの追加や削除がある場合はCato Management Application（CMA）で操作はできず、都度csvファイルを更新する必要があります。 それでは、今回はDevice Postureの設定と動作結果をご紹介します。 Device Postureの設定方法 Device Postureの設定方法は以下の ３Step です。 [条件]を作成する Cato側で準備されている “OSの種類・ベンダー名・プロダクト名” などを選択して「条件」を作ります。 [条件]を組み合わせて[プロファイル]を作る 「条件」を組み合わせて「プロファイル」を作成します。プロファイルとは条件の組み合わせです。 例えば、Windows Firewallが有効になっているという条件と、会社指定のウィルス対策ソフトがバージョンxx以上になっているという条件を組み合わせて1つのプロファイルにするといったものです。 [プロファイル]を用いて[ポリシー]を作る Device Postureを適用するユーザー・プロファイル・アクションなどを決めて「ポリシー」を作成します。 では、実際にDevice Postureの設定を行いその挙動をみてみましょう。 <検証>Windows Firewallが無効のPCをブロックする 1.条件（Device Check）を作成する Device checkの設定は、Cato Management Application（CMA）のAccess ＞Device Posture ＞Device Checksで行います。 「New」ボタンをクリックすると設定ウィンドウが開きます。設定ウィンドウの最初にある「Device Test Type」（図1）でチェックに使いたいベンダーやプロダクトを設定していく事になります。 図1. Device Test Typeの画面 2024年5月時点では以下の6つタイプがありますが、Catoのアップデートによりタイプの種類はどんどん増えています。 各タイプで指定できる条件と選択できるプロダクトをいくつかピックアップしてみました。 No タイプ 指定条件と選択できるプロダクト例 1 Anti-malware 各種ウイルス対策ソフトウェアがインストールされているか？ Windows Defenderや、Trend Micro、McAfeeなど 2 Firewall 各種ファイアウォールソフトウェア(OS標準のFirewall含む)がインストールされているか？ Windows Firewallが有効、Trend Micro Deep Security Agent、Crowdstraikeなど 3 Disk Encryption ディスクの暗号化がされているか？ 4 Patch Management 各種パッチ管理ソフトウェアがインストールされているか？ Intune Client、 McAfee ePolicy Orchestrator Agentなど 5 Data Loss Prevention 各種DLPソフトウェアがインストールされているか？ Trend Micro Apex One Security Agent、 McAfee DLP Endpointなど 6 Cato Client Catoクライアントが指定のバージョンかどうか？ 今回の検証ではシンプルに「Windows FirewallをオフにしているPCはCato接続させない」という設定を行います。 下記の通りタイプは「Firewall」を選択し「Microsoft Corporation」から「Windows Firewall」という条件を作成します。 尚、Windows Firewallのversion指定もできますが、今回は「any version」を選択しています。 図1. Device Checkの設定 図2のように指定のversionとイコール若しくは指定のバージョン以上という設定も可能です。 図2. Device Checkの設定（バージョン指定）   2.プロファイルを定義する 次に、作成した条件からプロファイルを定義します。今回は「Windows Firewall」の1つのみとしますが、前述の通り複数の条件をまとめてプロファイルを定義する事もできます。 設定箇所は Access ＞Device Posture ＞ Device Posture Profilesです。ここで 「New」ボタンをクリックして以下の設定ウィンドウで設定を行っていきます。ここではプロファイル名をつけた後は全て選択形式となっています。 図3. プロファイル設定 3.ポリシーを作る ポリシーの設定は、Access ＞ Client Connectivity Policyで行います。 ここでも「New」ボタンをクリックして、これまでと同様に表示される設定ウィンドウに設定をしていきます。 ポリシーの設定項目は以下の通りです。 ・制御対象のユーザー/グループを選択します ・プラットフォームでOSの指定ができます ・制御対象の国を選択できます ・作成したプロファイルを選択します ・アクションでAllowかblockを選択します 設定画面を貼り付けると縦に長くなるので設定後に表示される画面を以下に添付します。 また、このDevice PostureもFirewallと同様で、上位のポリシーからマッチしたもが適用されるという動きなので「順番」は要注意です。 図4. 作成したポリシー    複数のポリシーを作成する例としては、例えばグループ会社毎にPC環境の違いや導入しているアプリケーションが異なる場合、会社毎のポリシーを作成して接続を許可するという使い道があります。 ポリシー01（A社用）： Windows Firewallが有効 ＋ McAfee Agentのバージョンが××以上 ＋ 指定の証明書が入っている ポリシー02（B社用）： Windows Firewallが有効 ＋ TrendMicro Agentのバージョン××以上 ＋ 特定のディスクドライブの暗号化 <検証>モバイルユーザーからアクセスした結果 今回作成したDevice Postureの設定はWindows Firewallが有効なPCはCato接続を許可し、Windows Firewallが無効になっているPCはブロックするという設定です。 実際にCato Client を入れたPCでWindows Firewallを有効/無効にして接続を試してみました。 Windows Firewallが有効だと問題なく接続できましたのでこの説明は割愛させていただき、次にWindows Firewallを無効にして接続してみました。 図5. Windows Firewallを無効化 この状態でCatoに接続しようとすると、図6の通り認証エラーとなりました。 エラー画面の「Details」をクリックすると「Windows Firewall」のルールでブロックされたとの内容が確認できます。 ネットワーク管理者は、ユーザーからこの内容を聞き出す事で切り分けができると思います。 図6. ブロックエラー画面 図6. ブロックの理由 また、CMAではブロックされたログが出力されていました。 図7. CMAのブロックログ 設定したプロダクトやバージョンを検出してくれない Device Postureで設定したベンダーのプロダクトやバージョンを期待通りに検出してくれず、稀にClient Connectivity Policyのルールをスルーする事があるようです。 その原因ですが、Cato Clientは「OPSWAT Framework」を使用してアプリケーションの識別をしているため、実際のプロダクト・バージョンと何らかの差異があった場合に検出がされないようです。 ＜参考＞OPSWATのカテゴリ Windows https://software.opswat.com/OESIS_V4/Win/docs/support_charts/support_charts.html macOS https://software.opswat.com/OESIS_V4/Mac/docs/support_charts/support_charts.html 2024年5月時点で、上記URLにあるOPSWATのカテゴリのうち、以下がDevice Checkの対応製品となりますがこれ以外のカテゴリは未対応です。 Device Test Type（Cato） OPSWAT Category Anti-Malware  ANTIMALWARE Firewall FIREWALL Patch Management  PATCH_MANAGEMENT Data Loss Prevention DATA_LOSS_PREVENTION また、OPSWAT Frameworkの更新がされる際は、Catoのプロダクトアップデート情報にて次の様な内容が掲載されます。 Updated Vendors and Versions for Device Posture Checks:  We updated the  OPSWAT framework used by the Client to version x.x.xx.xxx 期待通りに検出されない場合の対処法は、一旦バージョン指定を無くして「Any-version」にするとか、別のベンダープロダクトに変更するかしか今のところはないように思います。 ただアップデートの頻度は多いので、暫くすると改善される可能性はあるかと思います。 まとめ 今回はDevice Postureの簡単な設定例をご紹介しました。 実際のDevice Checkでは複数の条件を組み合わせてポリシーを作成し、期待通りに接続が許可されるか又はブロックされるかのテストが必要になります。 またCatoが用意している条件はかなりの数があるので、そこから自社のデバイス環境に合うものを選択して動作テストする事も必要です。 更に条件のアップデートもどんどん行われるので、自社の環境により合うものをウォッチする必要もあるかもしれません。 ちょっと大変そうな気もしますが、ただこういった機能の利用をコンソール1つでコントロールできるのはクラウドならではの事だと思いますので是非活用してみて下さい。

こんにちは、SCSK株式会社の川原です。 今年も、延べ 30,000 人が参加する、日本最大の “AWS を学ぶイベント” AWS Summit Japan 2024 が  6月 20 日（木） 、 21 日（金） の二日間に渡り 幕張メッセ にて開催されます。 AWS Summit Japan 2024では、基調講演や150を超えるセッション、250を超えるEXPOコンテンツが用意されており、クラウド技術の最前線に触れる絶好の機会です。 SCSKはプラチナスポンサー として、パートナーセッションでの事例紹介とブースの出展を行います！ すでに満席のセッションもございますので、お早めにご登録ください ↓↓ ※登録の際は、招待コード【 SPC7274802 】のご入力をお願いします。 SCSKセッションのご紹介 パートナーセッション（セッションID：AP-27）では、「 データセンターのラックぜんぶ抜く！SCSK だからできる脱オンプレの秘策とは？ 」というテーマで、 沖電気工業様と当社メンバーの取り組みを事例に基づきご紹介いたします。 開始日時：6/21（金）16:00～16:30 登壇者： 沖電気工業株式会社 常務理事 情報責任者 髙島 豊徳様 　　　　 SCSK株式会社 ソリューション事業グループ クラウドサービス事業本部 事業推進部　岸岡　学 【概要】 クラウドのメリットを理解し活⽤を進めようとするものの、様々な理由で「まだ⾏けない」「やっぱり⾏けない」と踏みとどまっている企業は多く存在します。Lift/Shift フェーズで障壁となる既存システム課題、コネクティビティ、どこまでクラウドネイティブに作るかなど。数多くの⼤規模クラウド移⾏にて AWS のベストプラクティスとクラウドコネクティビティをフル活⽤して開発した「クラウド Lift & Shift の秘訣」を、⼤⼿製造業の沖電気⼯業株式会社 CIO 髙島様と共に語ります。”ラックぜんぶ抜く” ために両社がどう⼿を取り合い、その難局を超えたのか。そしてクラウドネイティブへどう旅をしていくのか。本講演では、そのクラウドジャーニーへの挑戦記録を秘訣と共にお伝えします。 本セッションでは、 SCSKのクラウド移行のノウハウと知見を共有し、参加者の皆様の課題解決の糸口を提供できればと思います。 ぜひセッションをご登録してお待ちください！   「AWS 愛が、凄い 。SCSK」 ブースのご紹介 展示ブースでは、「 AWS愛が、凄い。SCSK 」をテーマに、 お客様のAWS利活用ステージに合わせて、クラウド移行、データ活用、生成AI、製造現場のデジタル化など、SCSKの独自ソリューションをご紹介します。 さらに、 ミニシアターでは7つのAWS関連ソリューションについて発表いたします。 最新のクラウド技術を活用したSCSKの取り組みやソリューションを間近でご体感いただけます。 ぜひAWS Summit JapanでSCSKのブースにお立ち寄りください！ では皆様、 AWS Summit Japanを楽しみにお待ちください。 当日はSCSKセッションならびに展示ブースへの来場を心よりお待ちしております！

こんにちは。SCSKの山口です。 先日、あるアーティストのライブに当選したのですが、当選通知＆料金支払いのメールが迷惑メールフォルダに入っていて、せっかくの強運が危うくオジャンになるところでした。 メールのフィルタリング基準が気になって少し調べたのですが、URL等が含まれているメールだとフィッシングを疑われてしまい、迷惑メールと判断されることがあるそうです。 しっかりと守ってくれていることはいいことですが、過保護すぎて必要なものまでブロックされてしまうのは考え物ですね。 「URLが含まれてるから怪しいメールだけど、コイツこのライブ申し込んでたから必要なメールだ。仕方ねえ通してやるか。」 みたいな判断をしてくれたらいいのに。と感じました。 いきなり何の話だと皆さん思っているころだと思いますが、先日業務でも似た（？）ような場面がありました。 通信要件：インスタンスからの下り通信を全拒否したいが、特定のURLへの通信だけは許可したい 要するに、 IPアドレス制御で下り通信を全拒否 しつつ、 FQDN制御で特定サイトへのアクセスを許可 する。ということです。 さらに嚙み砕くと、「 外部のサイトは危険なものも多いから、アクセスできないようにする 」かつ「 特定のサイトだけは通信ができるようにする 」ということです。 二段階で噛み砕きましたが、全然要約できていない気がするので、次章から詳しく書いていきます。   実現したいこと 今回実現したいことを図式化します。 ①GCEからの下り通信を全拒否（IPアドレスで制限） こちらはファイアウォールルールを設定することで簡単に実現可能ですね。 ②特定のURL（https://xxxx.jp）への通信を許可 問題はこっちです。Google Cloud のVPCファイアウォールルールでは、「 IPアドレスによる制御 」のみが可能です。FQDNによる制御は出来ません。 FQDNによる制御は、 ファイアウォール ポリシー ルール を使用することで実現することができます。 今回は、すでに FWルール（IPアドレス制御） がある状態で、新たに FWポリシールール（FQDN制御） を作成し、合わせ技で要件を実現してみます。   ファイアウォール ポリシー ルール 概要については、今回使用する部分のみ簡単に説明します。 詳細については下記ドキュメントをご参照ください。 参考資料 ファイアウォール ポリシー： https://cloud.www.google.com/firewall/docs/firewall-policies-overview?hl=ja   FWルールとFWポリシールールの評価順序 前述したとおり、今回はFWルールとFWポリシールールの合わせ技になります。（名前がややこしいですがついてきてください。。。） そのため、両者の 評価順序 が非常に重要になります。 デフォルト状態での評価順序は以下の通りです。上から下の順序で評価されます。 ①階層型 FW ポリシールール 　①-1 プロジェクトを含む組織レベル 　①-2 プロジェクトから最も遠い（上位）フォルダレベル 　①-3 プロジェクトに近い次のフォルダレベル ② VPC FW ルール ③ネットワーク FW ポリシールール 　③-1 グローバルネットワークのFWポリシールール 　③-2 リージョンネットワークの FW ポリシールール ④暗黙の FW ルール（上り全拒否＋下り全許可） 図にすると以下の通りです。   実践①：FWルールとFWポリシールールの合わせ技による通信制御 改めて、要件を整理します。 要件①：GCEからの下り通信をすべて拒否する 要件②：特定のURLへの下り通信のみ許可する 今回は要件②で使用するFQDNとして「 www.google.com 」を使用します。 環境準備 下記環境を用意します。 要件①：GCEからの下り通信をすべて拒否する 下記FWルールを作成します。 FWルール名称 yamaguchi-egress-deny-all 説明 GCEからのすべての下り通信を拒否 ネットワーク vpc-test-yamaguchi 優先度 65534 方向 下り（内向き） 一致した時のアクション 拒否 ターゲットフィルタ IP範囲：0.0.0.0/0 プロトコルとポート all これによって、GCE（gce-test-yamaguchi）からのすべての下り通信が拒否されるはずです。 試しに www.google.com への疎通確認をしてみます。 pingを打っても応答がありません、下り通信が正常にブロックされているようです。 要件②：特定のURL（ www.google.com ）への下り通信のみ許可する 次に、FWポリシールールを使用して、 www.google.com への通信を許可します。 下記FWポリシーを作成します。 FWポリシー名称 fwpolicy-test-yamaguchi 説明 （省略） デプロイのスコープ リージョン リージョン asia-northeast1(東京) ※1 ルールの追加 なし（デフォルトで設定されるルール削除） ※2 ポリシーと VPC ネットワークの関連付け vpc-test-yamaguchi ※1 ルールの追加 ・この項目でFWポリシールールを作成することもできます。今回は説明のためにFWポリシーのみをまず作成し、その後ポリシーに含めるルールを作成します。 ※2 ポリシーと VPC ネットワークの関連付け ・FWポリシーはVPCに関連付けることができます。今回は「vpc-test-yamaguchi」に関連付けます。 作成したFWポリシーを見てみましょう FWポリシールールを作成しなかったので、デフォルトのポリシールールのみが表示されています。 デフォルトのポリシールールでは、上り/下りの通信を全て 「次に移動」 するルールがIPv6とIPv4で設定されています。 FWポリシーでは、「許可/拒否」に加えて 「次に移動」 のアクションが用意されています。それぞれ以下のように動きます。 許可 トラフィックを通す（階層が下位のルールは見ない） 拒否 トラフィックを通さない（階層が下位のルールは見ない） 次に移動 階層の下位のルールに評価を委ねる つまり、「次に移動」では「ここでは評価しないけど、次で決めてもらって。」みたいに次に当たるルールに判断を任せる動きをします。 では、作成したFWポリシーに「 www.google.com 」へのアクセスを許可（次に移動）するルールを作成していきましょう。 FWポリシーの詳細画面（上図）の 「+ルールを作成」 のボタンから作成することができます。 優先度 2147483640 説明 www.google.com への下り通信を許可（TCP/443,ICMP） トラフィックの方向 下り 一致した時のアクション 許可 ログ オフ ※1 対象 サービスアカウント サービスアカウントのスコープ このプロジェクト内 ターゲットサービスアカウント Compute Engine default service account 宛先 FQDN： www.google.com 送信元 10.20.30.0/24 プロトコルとポート 指定したプロトコルとポート TCP ポート：443 その他 icmp ※1 対象 FWポリシールールでは、ターゲット（対象）に「ネットワークタグ」を使用することができません。 代わりに、「ターゲットVPCネットワーク」もしくは「ターゲットサービスアカウント」を使用する必要があります。 今回は、「ターゲットサービスアカウント」を使用しています。 参考資料 ： https://cloud.google.com/vpc/docs/using-firewall-policies?hl=ja#limitations では、この状態で www.google.com へpingを飛ばしてみましょう。 おや？？？ www.google.com へのicmp通信を許可するポリシールールを作成したのに通信ができませんね。 タネ明かしは次の章で行います。   再掲：FWルールとFWポリシールールの評価順序 初めの方に述べた、「FWルールとFWポリシールールの評価順序」の図をもう一度貼ります。 一番下の段に注目です。 評価順序が、 「② VPC FWルール　→　③ ネットワークFWポリシールール」 となっています。 つまり、今回の要件では 先に「GCEからの下り全拒否」のFWルールが適用されてしまっている ため、 その後の「 www.www.google.com 」への許可ルールが意味をなしていません 。 じゃあ要件みたせないじゃん、、、となりそうですが、なんとこの 評価順序を変更する方法 があります。次の章で説明します。   実践②：FWポリシールール適用順序変更 下記のコマンドを実行することで、FWルールとFWポリシールールの評価順序を入れ替えることができます。 コマンド gcloud compute networks update VPC-NETWORK-NAME \     –network-firewall-policy-enforcement-order  BEFORE_CLASSIC_FIREWALL(AFTER _CLASSIC_FIREWALL ) 参考資料 ： https://cloud.google.com/firewall/docs/firewall-policies-overview?hl=ja#change_policy_and_rule_evaluation_order FW ポリシー適用順序変更コマンドでの適用順序の変化 1. デフォルト状態 ① 階層型 FW ポリシールール ②  VPC FWルール ③  ネットワークFWポリシールール ④ 暗黙のFWルール（上り全拒否＋下り全許可） 2. 以下を実行 gcloud compute networks update VPC-NETWORK-NAME \     –network-firewall-policy-enforcement-order  BEFORE_CLASSIC_FIREWALL ① 階層型 FW ポリシールール ②  ネットワークFWポリシールール ③  VPC FWルール ④ 暗黙のFWルール（上り全拒否＋下り全許可） 3. 以下を実行 gcloud compute networks update VPC-NETWORK-NAME \     –network-firewall-policy-enforcement-order  AFTER _CLASSIC_FIREWALL ① 階層型 FW ポリシールール ②  VPC FWルール ③  ネットワークFWポリシールール ④ 暗黙のFWルール（上り全拒否＋下り全許可） ⇒デフォルト状態に戻る 先ほどの実践①の環境でこのコマンドを実行します。 プロンプトが塩対応で適用できているか不安ですが、再度pingを飛ばしてみます。 応答が返ってきました。大成功です。 他のURL（FQDN）へのアクセスはというと 想定通り拒否されていますね。大成功です。 適用順序をもとに戻して再度 www.google.com へpingを投げてみましょう。 想定通り、通信できなくなりました。大成功です。 実践①、実践②で試した方法を使うことで、「インスタンスからの下り通信を全拒否したいが、特定のURLへの通信だけは許可する」という要件を満たすことができました。   まとめ 今回は、「インスタンスからの下り通信を全拒否したいが、特定のURLへの通信だけは許可したい」という要件を、FWルールとFWポリシールールの合わせ技で実現してみました。 今回はインスタンスからの下り通信を全拒否をあらかじめFWルールで実装しました（ちょうどその環境があった）が、初めから今回のような要件が見えている場合は、ルールを作成する際に 「FWポリシーの作成」の中にすべて吸収させた方が良い と感じました。 そうすることで、作成時の混乱を避けることができますし、管理やメンテナンスがより簡単になると思います。 今後の教訓にしたいと思います。

こんにちは。SCSK三上です。 今回は、先日参加したパートナー向けのAmazon Bedrockセミナーのセッションの1つにあった、 “ 本番稼働に至る生成AIプロジェクトにするための4つの質問 ” がとても印象的だったので、共有させていただこうと思います。 背景 最近ホットな生成AIですが、皆様 生成AIプロジェクトの本番稼働はうまくいっていますでしょうか？ 一般的に、学習なしで利用できる生成AIは日本企業でのAI活用を約20%伸長させるポテンシャルがあります。 その一方で、日本では米国と約7倍差で、データ活用が売上増加やコスト削減に繋がりにくい傾向があると言われています。 生成AI活用も大体70~90%で失敗 、 機械学習プロジェクトは80%の確率で失敗 すると言われています。 実際に、皆様このようなお悩みを抱えていないでしょうか。 パートナーの方は、 PoC案件が多く、本番稼働に移れない 。本番環境に値する生成AIを活用した ユースケースの探索 に課題がある。 ユーザの方は、 生成AIをどのような業務に活かして良いか分からない 。生成AIを活用したいがどう進めて良いか分からない。 このようなお悩みを抱えている皆様に、少しでも役立つ4つの質問をご紹介します！ これは、AWSのAI活用事例をもとに導かれた質問なので実践的に活用いただくことが出来ると思います。   生成AIプロジェクトを本番稼働にするために必要な4つの質問 生成AIが利益につながるための3つのステップ 質問を始める前に、生成AIが利益につながるためには3つのステップが重要です。 この先は、このステップに沿った質問を順番にご紹介します。 Biz：生成AIによる成長サイクルを設計する インパクトがあり実現・実装可能なユースケースを選ぶ Dev：迅速に顧客体験を検証する マネージドサービスを活用し、小さく・多く経験する ML：顧客から得られたフィードバックで体験を改善する より良い体験をコスト効率、よいモデルで提供する   第1問： 『生成AIの活用にあたり求められている成果はありますか。また、「あなた」の業績評価やキャリアにどのような影響がありますか？』 質問 『生成AIの活用にあたり求められている成果はありますか。』 １．自社のプロダクトに組み込み「売り上げ」を拡大する ２．自社の業務・開発プロセスを改善し「コスト」を削減する ３．良く分からない 『 また、「あなた」の業績評価やキャリアにどのような影響がありますか？ 』 背景 この質問の背景としては、以下の通りです。 生成AIの活用にあたり求められている成果はありますか。 売り上げ・コストといった経営指標を改善するのか、市場認知を取ることなのか、従業員の意識改革なのかで施策が異なる。 また、「あなた」の業績評価やキャリアにどのような影響がありますか？ 評価にかかわらない活動にモチベーション高く取り組むのは困難。 Biz：生成AIによる成長サイクルを設計する AI/MLで価値が高まるサイクルは、 ①顧客体験の改善②ユーザ増加による利益の増加③データの蓄積によるモデルの改善④データドリブンな意思決定 です。  実際に生成AIプロジェクトで成功している理想的な企業はどのようにこのサイクルを実現しているでしょうか？ 事例①：デザイン作成サービスCanvaの価値が高まるサイクル ①顧客体験の改善：作りたいパンフレットに適したイラストがなければテキストで要望を書けばよい ②ユーザ増加による利益の増加：画像の生成量が増えると編集機能（有償）を使いたい人も増える ③データの蓄積によるモデルの改善：蓄積されたログから需要の高い用途に特化したモデルを生成 事例②：画像共有サービスPinterestの価値が高まるサイクル ①顧客体験の改善：分析したいアイディアをテキストで書けば、テーブルやクエリの提案が受けられる ②ユーザ増加による利益の増加：短期間で分析できれば、収益につながる様々な仮説を検証できる ③データの蓄積によるモデルの改善：蓄積されたテキストと実行可否をもとに、よりモデルの生成を制御できる ★各事例の共通ポイント★ 使用頻度が高いユースケースに挑戦している。 使用頻度が高く、効果が高い、ハイインパクトのユースケースに注目すること。 ★生成AIプロジェクトを進める第一歩★ 「ピザ2枚チーム」で素早く活動を開始する。 小規模なチーム（10名未満）で意思決定の速度を上げる。 参考： ジェフ・ベゾスの秘策｢ピザ2枚｣ルール。 アマゾンはこれで無駄をなくした | Business Insider Japan   第2問： 『身軽なチームで頻繁かつ改善効果が高いユースケースに注目していますか？ 』 質問 『身軽なチームで頻繁かつ改善効果が高いユースケースに注目していますか。』 背景 この質問の背景としては、以下の通りです。 生成AIは進化が早い。身軽なチームが自社のフィードバックだけでなく外部の技術変化にも適応していく必要がある。 その一方で、 身近なチームは組織的権力が弱い傾向があるため、ハイインパクトではにと関係者の協力を得ることが難しい 。 Dev：迅速に顧客体験を検証する Devフェーズで検証すべきポイントとしては、②ユーザ増加による利益の増加 重要なこと 実際にやってみないと成立するかわからない。ので…迅速かつ低コストで検証したい。 事例から見る学び 事例①Canva： 3週間 で画像生成機能を実装。 事例②Pinnterest：テキストからSQLを生成するLLMをパートタイムのエンジニア 2人2ヶ月 で構築。データ分析の時間を40%効率化。 ⇒ AWSの20件以上の生成Ai事例でも、大半が小規模で2~3ヶ月でリリースされている。 ★注目ポイント★ 高頻度のユースケースに着目して高い効果を出す 有価証券報告書、毎日の文書作成、営業日報、会議、デザイン 分析時間の40%効率化、700時間の削減。   少人数・短時間 2~4名、数週間から1~3ヶ月 ★重要なこと★ リリース基準をきめておくこと。 評価の観点は、3H(Helpful/Honest/Harmless) ⇒ リリース基準がない状態だと、プロンプトの改善が生産的にならない。   第3問： 『短期間で本番稼働しフィードバックを得るには、どんな人を評価に巻き込む必要がありますか？』 質問 『短期間で本番稼働しフィードバックを得るには、どんな人を評価に巻き込む必要がありますか。』 Dev：迅速に顧客体験を検証する Who：評価者は？ What：評価にはどんなデータを使うか？ How：どのように評価するか？ ML：顧客から得られたフィードバックで体験を改善する 生成AIを蓄積したデータでカスタマイズすることで顧客体験や業務プロセスを競争優位にする。 生成AIをそのまま使うこともできるが、それだと成長しない。優位に立てない。 通常の機械学習モデルを学習し続けると競争優位に立てる 。 競争優位につながる改善ポイント より良い応答を、より小さいモデルで実現する 体験向上によるインパクト増加、モデル縮小によるコスト削減 より良い応答へ改善する手段 プロンプトをチューニングする 回答の精度を上げるために、回答を人間が3段階で評価。 モデルそのものをチューニングする。 Amazon BedrockでFine Tuningを実施可能。 プロンプトの改善からモデル学習へ移行するタイミングは意外と早い。 第4問： 『生成AIによるインパクトを継続的に高めていくにはどんなデータを蓄積し誰に伝える必要がありますか？』 質問 『生成AIによるインパクトを継続的に高めていくにはどんなデータを蓄積し誰に伝える必要がありますか。』 ML：顧客から得られたフィードバックで体験を改善する 生成AIはまだ発展途上の技術のため、 継続的改善を前提 に考えてもらう。 改善結果が社内の認知や関係者の業績評価に繋がるよう な組織内のレポートラインの構築も不可欠 最後に、ポイントをまとめます。 ★今日から始めるチャレンジ★ １．生成AIで狙う効果と関係者にとっての意義は？ ２． 身軽なチームが効果の高い用途に注目しているか？ ３．短期間でのフィードバック獲得を実現する関係者は？ ４．蓄積するデータと共有先は？ まとめ いかがでしょうか。私自身、お客様に生成AIを活用いただくために、この4つの質問は役立つと思いました。 特に印象に残った点は、①評価者はだれなのか？評価基準はなにか？を明確にすること。②高頻度のユースケースに着目し高い効果に着目すること。そのためには、お客様に”社内にはどんなユースケースが存在するか”を把握していただくことが大切だと感じました。 これから生成AIプロジェクトを進めていこうと思っている方は、ぜひ参考にしてみてください。 また、この日のセミナーのメインセッションはAmazon Bedrockについてでした。Amazon Bedrockは、API経由で基盤モデルにアクセスが可能となるサービスです。 こちらもとても興味深かったので、また記載していこうと思います！

こんにちは、SCSK松岡です。 本記事では、Power BIからSnowflakeにSSO(シングルサインオン)を使用して接続するための一連の手順と注意点をご紹介します。 Snowflakeに蓄積したデータをBIツールで可視化することは、データの価値を最大限引き出すために重要なポイントの一つです。 Microsoftのサービスと高い親和性を持つPower BIでは、SSOによりMicrosoft Entra IDの認証を利用して、データへのセキュアな接続が可能です。 SSOによりユーザーはシステム毎に別アカウントでログインする手間が省かれますが、そのためにはSnowflake側でのセキュリティ統合や、Power BI側での有効化などの事前設定が必要となります。 前提 これからご紹介する手順には、Snowflakeのアカウント全体に影響する設定と、Microsoftの組織全体に影響する設定が含まれます。そのため、設定を行うには次のユーザーが必要です。 ACCOUNTADMINロールを持つSnowflakeユーザー グローバル管理者権限を持つPower BIユーザー また、手順は以下のマニュアルをベースに記載していますので、設定の際は合わせてご参考ください。 Microsoft Learn：Power BI サービスで Snowflake に接続する Power BI で Snowflake に接続する - Power BI Power BI で Snowflake に接続し、SSO 認証またはゲートウェイ用に Microsoft Entra ID を使って構成する方法について説明します。 learn.microsoft.com   設定の流れ (Snowflake設定) Power BIセキュリティ統合 まず初めに、Snowflake側でPower BIとのセキュリティ統合の設定を行います。設定にはACCOUNTADMINロールを持つユーザーが必要です。 設定にあたり、Microsoft Entra ID (旧称：Microsoft Azure Active Directory)のテナントIDが必要なので、事前に取得しておきましょう。テナントIDは、Entra IDのトップページ(概要)から取得できます。 テナントIDが取得できたら、その値を「external_oauth_issuer」に含める形で以下のようなコマンドを実行します。 create security integration powerbi type = external_oauth enabled = true external_oauth_type = azure external_oauth_issuer = 'https://sts.windows.net/ [テナントID] /' external_oauth_jws_keys_url = 'https://login.windows.net/common/discovery/keys' external_oauth_audience_list = ('https://analysis.windows.net/powerbi/connector/Snowflake', 'https://analysis.windows.net/powerbi/connector/snowflake') external_oauth_token_user_mapping_claim = 'upn' external_oauth_snowflake_user_mapping_attribute = 'login_name' 例として、テナントIDがa828b821-f44f-4698-85b2-3c6749302698の場合、 external_oauth_issuerは、https://sts.windows.net/a828b821-f44f-4698-85b2-3c6749302698/　となります。 テナントIDの後にスラッシュ(/)を含める点に注意してください。 CREATE SECURITY INTEGRATION （Snowflake OAuth） | Snowflake Documentation docs.snowflake.com   (Snowflake設定) ユーザー作成 セキュリティ統合が成功すれば、Entra IDユーザーのUPN属性値と、Snowflakeユーザーのlogin_name属性値が紐づきます。 逆に言うと、Entra IDのユーザーからSSOを使用してSnowflakeに接続するためには、対象のUPNと同じlogin_nameのSnowflakeユーザーを作成する必要があります。 各ユーザーのUPN(ユーザープリンシパル名)は、Entra IDのユーザー一覧から、対象のユーザーを選択した概要ページから確認できます。 取得したUPNをもとに、SQLの実行等でSnowflakeユーザーを作成しましょう。 CREATE USER [ユーザー名(任意)] PASSWORD = '[パスワード(任意)]' LOGIN_NAME = ' [EntraIDのUPN] ' DEFAULT_ROLE = [デフォルトロール] CREATE USER | Snowflake Documentation docs.snowflake.com 注意点として、ユーザーを作成する際は、後にPower BIのレポートから参照しようとしているデータに応じた権限をデフォルトロールで設定する必要があります。また、Power BIから使用されるウェアハウスに対するUSAGE権限が付与されている必要があります。 付与された権限に不足がある場合、PowerBI側の認証時にエラーになってしまいます。 Snowflake Community Join our community of data professionals to learn, connect, share and innovate together community.snowflake.com   (Power BI設定)Snowflake SSOの有効化 続いて、Power BI側の管理設定です。 グローバル管理者権限を持つユーザーでPower BIにサインインし、 [設定]>[Power BI設定] > [管理ポータル]　を選択します。 そこから、[テナント設定] > [統合の設定]　> [Snowflake SSO] を選択して展開し、 設定を[有効]に切り替えた後、[適用]を選択します。 マニュアルだと、有効にしてから反映までに最大1時間かかるとの記載がありました。   (Power BI Desktop設定) データソースの追加 ここからは、Power BIでSnowflakeのレポート作成する際の考慮点になります。 まず、レポートを作成するためにはデータソースの用意が必要ですが、 データソースとしてSnowflakeに接続する場合、Power BI Desktopから行う必要があります。 Power BI Desktopと、ブラウザのPower BIサービス(クラウドベース)の違いや、 Power BI Desktopの取得方法は以下をご参考ください Power BI Desktop と Power BI サービスの比較 - Power BI Power BI Desktop ダウンロード アプリケーションとクラウドベースの Power BI サービスの違いについて説明し、比較します。 learn.microsoft.com Power BI Desktop の取得 - Power BI Power BI Desktop をダウンロードできるさまざまな方法と、それをインストールするために使用できるオプションについて説明します。 learn.microsoft.com 大まかな違いとしては、 Power BI Desktopはレポート作成用途の機能が充実しており、 Power BIサービス（クラウドベース）は、レポートの共有用途の機能が充実しています。 Power BI Desktopは、PowerBIサービスと同じアカウントでサインインできます。 データソースとしてSnoflakeに接続する場合は、レポートのデータ追加画面から、「別のソースからデータを取得する」をクリックし、Snowflakeを選択します。 Snowflakeのサーバ情報、ウェアハウス情報を入力した後にユーザー情報が聞かれますが、SSOを使用する場合はこのときに、「Microsoft Account」を選択します。 Snowflake側の設定が上手くいっていれば、Entra IDのユーザー情報による認証で、Snowflakeのデータが参照できるようになるはずです。   (Power BI設定) セマンティックモデル設定 Power BI Desktopで作成したレポートは「発行」ボタンからPower BI サービスに共有が可能です。 Power BI Desktop からの発行 - Power BI セマンティック モデルとレポートを Power BI Desktop から Power BI サービスに発行する方法について説明します。これにより、モデル内のデータが Power BI ワークスペースに発行されます。 learn.microsoft.com 発行先のワークスペースを選択すると、レポートとセマンティックモデルがPower BIサービスにアップロードされます。 Power BIのセマンティックモデルには、データソースに接続する際の認証に必要な情報が含まれます。 アップロードされたセマンティックモデルの設定にアクセスし、[データソースの資格情報]に進んでから[資格情報を編集]を選択します。 認証方法が「OAuth2」に選択されている場合、SSOを利用した設定が引き継がれています。 Power BI サービスのセマンティック モデル - Power BI Power BI サービスのセマンティック モデルについて説明します。これはレポート作成と視覚化の準備ができたデータのソースを表します。 learn.microsoft.com   最後に 上記の手順だと、利用ユーザーが増えるたびに手動でSnowflakeユーザーを作成する必要があります。追加でプロビジョニングの設定を行えば、その作業を自動化することも可能なようです。 チュートリアル: Snowflake を構成し、Microsoft Entra ID を使った自動ユーザー プロビジョニングに対応させる - Microsoft Entra ID Snowflake に対してユーザー アカウントのプロビジョニングとプロビジョニング解除を自動的に実行するための Microsoft Entra ID の構成方法について説明します。 learn.microsoft.com これで、接続のための設定は完了です。 設定してみて詰まったポイントがいくつかあったので、少しでも参考になれば幸いです!

みなさん、こんにちは。SCSKで飼われているひつじです！ 最近の私、なんと週3でサウナに通ってるんだ。サウナって最高だよね！ さてさて、半年前くらいからちょっとしたことがきっかけで、当社新人様の指導をすることになっちゃったんだ。そしたらね、みんなで一緒に考えたんだけど、新人のみんなが自分たちでテックブログを書いてみんなで楽しめるイベントをやろうってことになったんだ！ うちの会社にはね、ありがたいことに「TechHarmony」というブログサイトがあるんだよ。そこで新人のみんなが自由に発信できるんだ。それを使って新人たちにブログを書いてもらっちゃったんだ。楽しみだよね、みんなの書いたブログを読むの。 そもそもなんでブログを書くのか？ 新人様の取り組みとしてなぜブログなのか。以下に列挙したいと思います！ 人に伝えようとすることで自分の理解になる。 昔の人は言いました「100回の購読より、1回の寄稿だと。」 新人様はインプットする機会は多いですがアウトプットすることで知識定着に寄与できます。 「テックブログを書く」という道の最初の一歩を作る。 テックブログなんて社外に発信できるなんてすごいエンジニアだけなんだ。という畏怖の取り除きを解消することができます。 新人育成の中で先輩社員がリードしてあげることで新人様の最初の一歩を促すことができます。 社内外に顔を売るチャンスを作る。 社外発信することにより人目につき、名前や顔が売れていきます。 パブリックな活動を評価するような仕組みも社外にはあるので、そこに取り上げてもらうことで当社としても個人としても対外的な評価を受けれるのは素晴らしいことです。また社内向けには報告会を行うこと新人様と役職者をつなげるような活動にも発展できます。 新人様の取り組み紹介 ということで今期取り組んだ新人様4名の記事を紹介したいと思います。 ヒルタさんの記事 AWS関連のブログをメインに寄稿頂きました。ブログ寄稿を通じて得られた自身の体験をわかりやすく整理していただきました！ マセダさんの記事 親しみやすい記事をモットーにAWS、AIサービス関連のブログを寄稿頂きました。 ブログ寄稿にあたり最新の技術アップデートを意識できるようになったとのことです！ サトウさんの記事 明るく楽しく元気よくをキャッチフレーズに当社クラウドサービス「USiZE」に関する寄稿をいただきました。 ブログ執筆を通してお客様からフィードバックを頂いたりと良いご経験もあったようです！ エギさんの記事 Google関連のカンファレンスの参加レポートやご自身のGCP関連の業務に関する記事を投稿頂きました。 「知識の整理になった！」「創造性の刺激になった！」「カンファレンスのモチベになった！」など前向きに取り組んでいただきました。 まとめ 今期はなんと、4人の新人たちがブログに寄稿してくれたんだ！さらに、たくさんの役職者に向けて成果をプレゼンしたよ。 忙しい日々だけど、これからも会社内外で情報発信を頑張っていきたいね！初めの一歩を忘れずに！ 末筆になりますが、ご査収のほど、よろしくお願い申し上げます。

はじめまして。SCSK渡辺(大)です。 シティーハンターの実写映画が面白かったので続編を熱望しています。 今回は、 Amazon Bedrock の Knowledge Base で 文字変換 をやってみました。 Pythonのreplaceメソッドを使えば簡単に文字変換することが出来るのですが、敢えてBedrockのKnowledge Baseを使いました。 まだまだ修行中の身ですので間違いが多々あるかもしれませんが、暖かい目で見て頂けると幸いです！ 目標 文字変換前のテキストファイルをS3にアップロードするだけで、文字変換後のテキストファイルを得ることが出来るようになる！ 結果 先に結果を見たい方のみクリック！ 　　 ２回目で想定通りに変換することが出来ました！ 概要 フロー図 処理の流れ ①．ユーザーは変換前のテキストを所定の S3 にアップロードします。 ②．Lambda は S3 にファイルがアップロードされたことをトリガーにして実行されます。 ③．Lambda は Bedrock を呼び出し、変換前のテキストを渡します。 ④．Bedrock は Knowledge Base OpenSearch に変換ルールの有無を確認します。 ⑤．Knowledge Base OpenSearch は Bedrock に変換ルールを返します。 ⑥．Bedrock は変換ルールに沿って変換前のテキストを変換することで、変換後のテキストを生成します。 ⑦．Bedrock は変換後のテキストを Lambda　に返します。 ⑧．Lambda は変換後のテキストを所定の S3 にアップロードします。 Agents for Amazon Bedrock で Claude モデルに問い合わせる分岐のある RAG をつくる Agents for Amazon Bedrock を使用して簡単な RAG をつくってみましたので、RAG の分岐部分の設定や基盤モデルへの問い合わせコードを紹介します。 blog.usize-tech.com 2024.02.26   構築手順 記事執筆時点ではBedrockのKnowledge Baseを使えるリージョンはバージニア北部とオレゴンのみでしたので、今回はバージニア北部（us-east-1） で各資源を作成しました。Knowledge Baseを使えるリージョンの最新情報は ユーザーガイド を確認してください。 S3 S3バケットの作成 まずはS3バケットを3つ作成します。 バケット名を入力し、その他の設定はノールック（＝デフォルト）で作成します。 変換ルール格納先 ： Bedrock Knowledge Baseと再同期する際に変換ルール以外のファイルが存在していると、想定通りの変換をしない 可能性があるため専用で作成。 変換前テキスト格納先 ： Lambdaのトリガーになるバケットであり、ここに変換前テキスト以外が格納されてしまうと、そのタイミングでもLamdaが 稼働してしまうため専用で作成。 変換後テキ スト格納先 ： 上記に伴い、専用で作成。 変換ルールのアップロード 変換ルール格納先のS3バケッ トに「rule.txt」 をアップロードします。 このテキストに記載されているルールに則って変換処理を行ってください。 ルール①：りんご→赤色の丸い果物 ルール②：オレンジ→オレンジ色の丸い果物 ルール③：葡萄→紫色の丸くて小さい果物 ルール④：メロン→緑色の丸くて大きい果物 ルール⑤：バナナ→我が子がこよなく愛する黄色い果物 ルール⑥：ルール①からルール⑤のどれにも当てはまらない場合は、未知の果物   Bedrock Knowledge Base Bedrock Knowledge Base の作成 下記の記事を参考にBedrock Knowledge Baseを作成します。 生成AI初心者がAmazon BedrockのKnowledge baseを使ってRAGを試してみた AWS re:Invent2023にて、Amazon BedrockのKnowledge baseとAgentsがGAされたと発表がありました。今回はこのうちKnowledge baseを利用して、RAG（Retrieval Augment Generation）を試してみたいと思います。 blog.usize-tech.com 2023.12.07 続いて、下記の記事を参考に機械学習モデルの有効化を行います。 今回は流行りのClaude 3 Haikuを使用したかったので、有効化されていることを確認しました。 Amazon Bedrockの良いところを実感しよう Amazon Bedrockがリリースされました。python boto3を使ってAPIアクセスします。2つのモデルへの簡易的なアクセスをするプログラムを比較し、Amazon Bedrockの特徴を考えます。 blog.usize-tech.com 2023.10.02 ナレッジベースIDを控える Lambda（Python）の中でナレッジベースIDを指定する必要があるため控えておきます。   Lambda Lambdaの作成 「関数の作成」→「設計図の使用」にて下記で作成します。 設計図名：Get S3 object（Python3.10） 実行ロール：AWSポリシーテンプレートから新しいロールを作成 ポリシーテンプレート – オプション：Amazon S3 オブジェクトの読み取り専用アクセス権限 S3トリガー バケット：変換前テキスト格納先のバケット イベント：PUT ランタイム設定の変更 最新のPythonランタイムに変更します。 今回はPython3.12に変更しました。 アクセス制限の変更 LambdaがBedrockを使用できるようにする為、ロールにインラインポリシーで下記を追加します。 { "Version" : "2012-10-17" , "Statement" : [ { "Effect" : "Allow" , "Action" : "bedrock:*" , "Resource" : "*" } ] } また、AWSLambdaS3ExecutionRoleがアタッチされていますが、S3からファイルを取得（Get）する権限しかない為、こちらはデタッチします。 {     "Version": "2012-10-17",     "Statement": [         {             "Effect": "Allow",             "Action": [                 "s3:GetObject"             ],             "Resource": "arn:aws:s3:::*"         }     ] } 代わりにAmazonS3FullAccessをアタッチします。 {     "Version": "2012-10-17",     "Statement": [         {             "Effect": "Allow",             "Action": [                 "s3:*",                 "s3-object-lambda:*"             ],             "Resource": "*"         }     ] } boto3のバージョンアップ 下記の記事にある通り、boto3 ver.1.28.72が内包されているPython3.12がリリースされた為、boto3のバージョンアップは実施不要です。 後程出てきますが、私が理解出来ていなかっただけで、バージョンアップは必要でした。 Amazon Bedrock(Titan Textモデル)でAWSブログを要約して通知する 昨年、AWSブログの更新を検出しTeamsに通知するという記事を発信しました。 そこで今回はこれに生成AIの要素を追加し、記事を要約して通知することにチャレンジしてみたいと思います。 blog.usize-tech.com 2023.12.25 コードの修正 最初に掲げた目標の通りにLambdaが動くよう、コードを修正します。 下記は私が人生で初めて書いたPythonのコードです。ご査収ください。 RAGの一般的な使い方では資料リンクを付けて回答させるのが良いかと思いますが、今回は文字変換させたいだけで変換ルールテキスト（rule.txt）の リンクを貰っても使わないので、回答にリンクは付いてこないようにしています。 モデルID はリンクから確認してしてください。 ★の３箇所は適宜修正してください。 import json import boto3 import urllib.parse import sys s3 = boto3.client('s3') boto3 = boto3.client('bedrock-agent-runtime')   # Bedrock処理 def convert_text(knowledge_txt):     response = boto3.retrieve_and_generate(         input={"text": knowledge_txt},         retrieveAndGenerateConfiguration={             "type": "KNOWLEDGE_BASE",             "knowledgeBaseConfiguration": {                 'generationConfiguration': {                     'promptTemplate': {                         'textPromptTemplate': 'あなたは、ユーザーがs3にアップロードしたテキストの内容を変換して回答するエージェントです。'\                         '変換のルールは「rule.txt」に記載されています。回答は必ず日本語にしてください。'\                         'ユーザーには変換後のテキストのみを回答してください。ユーザーには変換前のテキストを回答しないでください。'\                         '$search_results$'                     }                 },                 "knowledgeBaseId": "★ナレッジベースID★",                 "modelArn": "arn:aws:bedrock:us-east-1::foundation-model/anthropic.claude-3-haiku-20240307-v1:0",                 "retrievalConfiguration": {                     "vectorSearchConfiguration": {                         "overrideSearchType": "HYBRID"   # or SEMANTIC                     }                 },             },         },     )     return response["output"]["text"] def lambda_handler(event, context):     # トリガーされたイベントからバケット名とオブジェクトキーを取得     bucket = event['Records'][0]['s3']['bucket']['name']     key = urllib.parse.unquote(event['Records'][0]['s3']['object']['key'])          # 元のオブジェクトの内容を取得     response = s3.get_object(Bucket=bucket, Key=key)     original_txt = response['Body'].read().decode('utf-8')     # Bedrock処理コール     response_output = convert_text(original_txt)     # 新しいオブジェクト名を決める     new_key = ★新しいオブジェクト名★     # 書き換えた内容を新しいオブジェクトとしてS3にアップロード     bucket = ★変換後テキスト格納先S3バケット名★     s3.put_object(Bucket=bucket, Key=new_key, Body=response_output.encode('utf-8'))     print(f'Successfully uploaded {new_key} to {bucket}')     return {         'statusCode': 200,         'body': 'Object uploaded successfully'     }     sys.exit()   いざ出陣！ ついに変換前テキストが出陣する時が来ました。 今回はAWSコンソールのS3画面から、下記の「果物.txt」を変換前テキスト格納先にアップロードしました。 りんご バナナメロン 葡萄 Orange オレンジ パパイヤ ドーナツ 林檎はりんごです りんごは林檎です エラー発生 下記のエラーとなりました。 [ERROR] ParamValidationError: Parameter validation failed: Unknown parameter in retrieveAndGenerateConfiguration.knowledgeBaseConfiguration: "generationConfiguration", must be one of: knowledgeBaseId, modelArn Unknown parameter in retrieveAndGenerateConfiguration.knowledgeBaseConfiguration: "retrievalConfiguration", must be one of: knowledgeBaseId, modelArn Traceback (most recent call last):   File "/var/task/lambda_function.py", line 48, in lambda_handler     response_output = convert_text(original_txt)   File "/var/task/lambda_function.py", line 10, in convert_text     response = boto3.retrieve_and_generate(   File "/var/lang/lib/python3.12/site-packages/botocore/client.py", line 553, in _api_call     return self._make_api_call(operation_name, kwargs)   File "/var/lang/lib/python3.12/site-packages/botocore/client.py", line 962, in _make_api_call     request_dict = self._convert_to_request_dict(   File "/var/lang/lib/python3.12/site-packages/botocore/client.py", line 1036, in _convert_to_request_dict     request_dict = self._serializer.serialize_to_request(   File "/var/lang/lib/python3.12/site-packages/botocore/validate.py", line 381, in serialize_to_request    raise ParamValidationError(report=report.generate_report()) boto3のバージョン更新履歴と思われるページ を見てもいまいち分からず。 Claude 3 Haikuに聞いてみました。 認識できないAPIがある様子なので、最新のboto3をインストールしてLambdaレイヤーにセットすることにしました。 boto3インストールはAWS CloudShellから実施しました。 全量ではありませんがログは下記の通りです。 なお、最新のboto3はv.1-34-100でした。 [cloudshell-user@ip-xx-xxx-xxx-xx ~]$ mkdir boto3work [cloudshell-user@ip-xx-xxx-xxx-xx ~]$ pip install -t ./boto3work boto3 Collecting boto3   Downloading boto3-1.34.100-py3-none-any.whl (139 kB)      |████████████████████████████████| 139 kB 3.6 MB/s           Collecting botocore<1.35.0,>=1.34.100   Downloading botocore-1.34.100-py3-none-any.whl (12.2 MB)      |████████████████████████████████| 12.2 MB 26.9 MB/s           Collecting jmespath<2.0.0,>=0.7.1   Downloading jmespath-1.0.1-py3-none-any.whl (20 kB) Collecting s3transfer<0.11.0,>=0.10.0   Downloading s3transfer-0.10.1-py3-none-any.whl (82 kB)      |████████████████████████████████| 82 kB 413 kB/s             Collecting python-dateutil<3.0.0,>=2.1   Downloading python_dateutil-2.9.0.post0-py2.py3-none-any.whl (229 kB)      |████████████████████████████████| 229 kB 44.1 MB/s           Collecting urllib3<1.27,>=1.25.4   Downloading urllib3-1.26.18-py2.py3-none-any.whl (143 kB)      |████████████████████████████████| 143 kB 49.3 MB/s           Collecting six>=1.5   Downloading six-1.16.0-py2.py3-none-any.whl (11 kB) Installing collected packages: six, urllib3, python-dateutil, jmespath, botocore, s3transfer, boto3 Successfully installed boto3-1.34.100 botocore-1.34.100 jmespath-1.0.1 python-dateutil-2.9.0.post0 s3transfer-0.10.1 six-1.16.0 urllib3-1.26.18 [ cloudshell-user@ip-xx-xxx-xxx-xx   ~ ] $ mv ./boto3work ./python [cloudshell-user@ip-xx-xxx-xxx-xx ~]$ zip -r boto3-1.34.100.zip ./python 以下省略 zipファイルをダウンロード後、レイヤーを作成し、Lambdaにセットしました。 ということで、再度「果物.txt」をアップロードしてみました。 タイムアウト発生 エラーは解消されましたが、タイムアウトが発生しました。 2024-XX-XXXXX:XX:XX.XXXX XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX Task timed out after 3.02 seconds Claude 3 Haikuから回答を得るまでに3秒以上掛かっているようなので、タイムアウトを30秒に変更してみました。 ということで、再々度、「果物.txt」をアップロードしてみました。 成功？ 変換後テキストが作成されました！ 中身を確認してみます。 りんご 黄色い果物メロン 紫色の丸くて小さい果物 オレンジ色の丸い果物 オレンジ 未知の果物 未知の果物 りんごはりんごです りんごはりんごです 惜しいですね。 質問するたびに回答精度が上がるかもしれないので、もう一度、変換前テキストをアップロードしてみました。 成功！ 赤色の丸い果物 我が子がこよなく愛する黄色い果物、緑色の丸くて大きい果物 紫色の丸くて小さい果物 オレンジ色の丸い果物 オレンジ色の丸い果物 未知の果物 未知の果物 赤色の丸い果物 赤色の丸い果物 空白行を詰められてしまいましたが、、、 ２回目で想定通りに変換することが出来ました！ まとめ 良かった点は、新技術に触れることが出来たことは勿論として、業務経験が浅くても頑張ればモノづくりが出来ることに気づけたことです。 反省点としては、エラーとなってしまったboto3バージョン不足については事前に気づくべきでした。 また、後から気づいたのですが、今回のやってみたをやってみる前に下記の記事を見ておくべきでした。 ガイドラインに則ったプロンプトであれば、１回目で想定通りに変換することが出来たかもしれませんね。 Amazon Bedrockでプロンプトエンジニアリングを学ぶ Amazon Bedrockを使ってプロンプトエンジニアリングのコツやパラメータ調整についてご説明します。 blog.usize-tech.com 2024.01.25

こんにちは、SCSK松岡です。 本記事では、クラウドデータプラットフォームであるSnowflakeが提供する数多くの機能のうち、データの共有/複製に焦点を当ててご紹介します。 データ分析・活用基盤の構築において、データの共有や複製は、システムの柔軟性や拡張性を高め、また管理を容易にするためのとても重要な機能です。 Snowflakeにおける代表的な共有/複製機能を特徴から分類し、それぞれのユースケースを記載しました。実現したい目的に応じてご参考いただければ幸いです。 Snowflakeとは Snowflake (Snowflake Cloud Data Platform)は、Snowflake社が提供するSaaS型のクラウドデータプラットフォームです。 データ管理、セキュリティ、ガバナンス、可用性、データレジリエンスをサポートしたフルマネージド型のサービスであり、ウェアハウスのスケーリング/ポリシー制御/データ共有の柔軟性などから、デジタルデータの一元管理に優れたプラットフォームとして注目を集めています。 プラットフォームの概要 Snowflakeのクラウドデータプラットフォームが世界的に、あらゆる規模、あらゆる業界において、をほぼ無制限の同時実行ワークロードで強化した方法をご紹介します。 www.snowflake.com   Snowflakeの共有/複製機能の分類 Snowflakeの主な共有/複製機能は、大きく以下の2観点で分けることができます。 「アカウントをまたいでデータ共有・複製するか」 「物理的にデータをコピーして共有・複製するか」 こちらの観点に基づき、Snowflakeの機能を4タイプに分類してみました Snowflakeにおける「アカウント」とは、ユーザーやリソースを管理するための単位です。 通常、部門やプロジェクトごとにアカウントを分割して管理します。 それぞれの機能についてご紹介します。   ゼロコピークローン ゼロコピークローン は、データの物理的なコピーを行わずにクローンを即座に作成できる機能です。 アカウント内のデータベース、スキーマ、テーブルをそれぞれの単位で自由にクローンすることができます。 概要を図で表すと以下のようになります。 メタデータ層は、データオブジェクト（テーブル、ビュー、インデックスなど）に関する構造的な情報を管理します。 ストレージ層は、Snowflakeで管理されるデータの物理的な保管場所です。 ストレージのコストを抑えながら(※)、スナップショットを容易に作成できることから、テスト環境を準備するようなユースケースで役立ちます。 ※クローン時点で追加のストレージコストは発生しませんが、 クローンしたデータを変更した場合は、それに応じてストレージの料金が発生します。 また、定義された期間の任意の時点にアクセスできるタイムトラベル機能を利用し、過去の履歴データを対象にクローンすることで、オブジェクトをリカバリするような使い方も可能です。 クローニングに関する考慮事項 | Snowflake Documentation docs.snowflake.com   データシェアリング Snowflakeでは、 データシェアリング の機能を活用することで、異なるアカウント間であっても柔軟にデータの共有が可能です。 データシェアリングでは、データのコピーは行わずに、データの共有先アカウント(コンシューマー)に読み取り専用の権限を付与します。 迅速かつ簡単に共有できることから、最新のデータに基づく分析を、異なる部門・組織間で行いたいようなユースケースで役立ちます。 Secure Data Sharingの紹介 | Snowflake Documentation docs.snowflake.com   アンロード (エクスポート) ゼロコピークローンがデータコピーを行わずにオブジェクトを複製する一方で、バックアップや他システムとの連携など、外部にデータをコピーしたいケースもあるかと思います。 Snowflakeでは、データを外部のクラウドストレージに アンロード(エクスポート) する機能も用意されています。 アンロードする際の対象データは、SQLクエリを用いて柔軟に指定することが可能です データのアンロードの概要 | Snowflake Documentation docs.snowflake.com   データベースレプリケーション/ アカウントレプリケーション 災害時の備えとして リージョン間の冗長性を持たせたい場合のように、異なるアカウント間でデータのコピーを行いたいケースもあるかと思います。 Snowflakeの データベースレプリケーション の機能では、複製スケジュールを設定した上で、 柔軟にアカウント間のデータを同期させることが可能です。 アカウントがBusiness Critical以上のプランであれば、上位の機能として、 ウェアハウス、ユーザー、ロール等も含めて同期させることができる アカウントレプリケーション が利用できます。 複数のアカウント間にわたるデータベースとアカウントオブジェクトの複製 | Snowflake Documentation docs.snowflake.com   最後に 「共有」「複製」といっても、Snowflakeでは様々な機能やオプションが提供されています。 目的に合ったものを見つけるためには、いったん立ち止まって「どこ・誰との共有か」「何のための複製か」を明確にすることが重要だなと今回整理して再認識しました。 公式サイトでは、各機能のより詳細な仕組みや考慮事項の説明があるので、そちらも合わせてご参考ください。

Cato クラウドの XDR Cato クラウドでは、ネットワークのトラフィックやエンドポイントの振る舞いなどの各種ログを Cato 独自の AI や機械学習アルゴリズムによって分析し、セキュリティ上の攻撃や脅威を自動的に検知する機能が提供されています。 この機能は XDR (Extended Detection and Response) と呼ばれており、問題を早期に発見・対処することを目的として、検知された問題を確認するダッシュボードやそれを分析するための一連のツールが用意されています。 この機能は情報セキュリティにおけるインシデントレスポンスを行う上で非常に有益なものであるのですが、活用するにはハードルが高いものであるとも感じています。そこで本記事では、そのギャップを埋めてお客様に XDR 機能を活用していただくために、XDR 機能を用いた運用例について説明します。 なお、Cato クラウドの XDR の紹介や基本的な利用シナリオについては次の記事にも記載しておりますので、そちらを先にご覧ください。（翻訳記事のため読みにくい部分がありますが、ご容赦ください。） CatoクラウドのEPPとXDRについて Catoクラウドで新たにリリースされたEndpoint Protection（EPP）とExtended Detection and Response（XDR）についての解説をしています。 blog.usize-tech.com 2024.02.14 世界初SASEベースのXDRについて Catoクラウドの世界初のSASEベースのXDRについて、とあるセキュリティアナリストの一日に焦点を当てた記事になります。 blog.usize-tech.com 2024.02.07 XDR 機能を用いたセキュリティ運用例 Cato クラウドの XDR 機能では、検知したセキュリティを脅かすインシデントのことを「ストーリー」と呼んでいます。1つのストーリーは基本的に異なるセキュリティ上の問題を示していますので、ストーリー単位で運用を行っていきます。 XDR 機能を用いたセキュリティ運用としては、次のように実施していくのが良いと考えています。 1. 新しいストーリーが作成されたことを認識する まずは、ストーリー・ダッシュボード画面やストーリー・ワークベンチ画面を定期的に確認し、新しくストーリーが作成されていないか確認しましょう。各画面は、CMA の [Monitoring] > [Stories Dashboard] や [Stories Workbench] から見れます。画面の詳細な見方については、先述の「 世界初SASEベースのXDRについて 」の記事を参照ください。 また、定期的に確認する運用では新しいストーリーに気付くのが遅れる可能性がありますので、後述のようにメール通知などによって気付けるようにすると良いです。 2. ストーリー一覧を確認する 新しいストーリーが作成されていれば、ストーリー・ワークベンチ画面で現在オープン中のストーリーの一覧を確認しましょう。 一覧画面で注目すべき項目は次の3か所です。 注目べき項目 内容 Criticality 重要度を表す 1 (低) ～ 10 (高) の値 Cato クラウド独自のアルゴリズムで算出される Indicator ストーリーの内容を簡潔に表す識別名 Producer ストーリーのタイプ 2024年4月時点では、Producer として次の5種類が定義されています。 (参考) Producer 内容 Threat Prevention IPS 機能で攻撃の振る舞いを検知した Threat Hunting イベント情報やより多くのトラフィックデータをもとに、広い範囲の攻撃の振る舞いが見つかった Usage Anomaly アプリケーションで通常とは異なる使用状況の兆候が見つかった (アップストリーム通信の帯域幅が通常と異なるなど) Events Anomaly 通常とは異なる量のセキュリティイベントを発生させているモノの兆候を検知した Network XDR ネットワークに関する劣化 (Socket ダウンやリンクダウン) が発生した Cato クラウドの Threat Prevention (旧 IPS) オプションを契約のお客様の環境では、「Threat Prevention」と「Network XDR」の2種類がストーリーとして検知されます。全ての種類を検知させるには、XDR Security Pro オプションの契約が必要となります。 また、「Network XDR」タイプは Socket の障害や拠点のインターネット回線の障害などによって発生しますが、障害が回復するとストーリーも自動でクローズされます。そのため、ストーリーに対して具体的に何らかの運用が必要になるというわけではありません。 以下では、「Threat Prevention」タイプに絞って、詳細の確認方法や対処方法について説明します。 3. ストーリーを分析する ストーリー・ワークベンチ画面でストーリーを選択すると、ストーリーの詳細を確認できます。ストーリーの詳細を確認する目的は、該当のストーリーがセキュリティ上問題があるものなのかどうか分析し、必要なら何かしら対処することにあります。 詳細画面には多くの情報が掲載されていますが、特に注目すべき項目は次の箇所です。 注目すべき項目 内容 Description (Details の中) Indicator (識別名) を詳しく表現した説明 Direction (Details の中) 関連する通信の向き (Inbound, Outbound, WANbound, All の4種類) Mitre Tags (Details の中) 該当する MITRE ATT&CK の種類 どのようなセキュリティ上の問題の可能性が検知されたか Target Actions 関連する通信が Cato クラウドのセキュリティ機能 (IPS, DNS Protection, Suspicious Activity など) でどう扱われたか Targets 関連する通信の相手に関する情報 Target (ホスト名・IPアドレス) や Registant Country (国名) が特に重要 Attack Related Events 関連する通信のイベント情報 Target (ホスト名・IPアドレス) や Destination Port (宛先ポート番号) が特に重要 これら情報をもとに、検知されたストーリーがセキュリティ上問題のあるものなのかどうか分析して判断しましょう。基本的には通信相手のホスト名や宛先ポート番号を見ればどういった通信か推測できることが多いと思います。単一の通信だけでなく、似た通信や異なる時間帯の通信も1つのストーリーに纏めて関連付けられていますので、分析しやすくなっています。それ以外にも、対象の通信の前後の時間帯で他にどのような通信が行われていたか、イベントログを確認すると分析の役に立ちます。 通信を行ったクライアントの情報も画面上で確認できますので、問題のあるものか判断しにくい場合はユーザにヒアリングしてみるのも良いですね。ただし、ユーザが認識していない通信 (例えば、アクセスした Web サイトに表示されている悪意ある広告など) の場合もあるという点に留意する必要があります。 実際は XDR 機能を利用する上でこの分析作業が最も難しく、機械的に行えるものでもないため、経験を積んで知見を蓄積していくしかない部分でもあります…。 4. ストーリーに対処する ストーリーを分析した結果、それがセキュリティ上問題があるものだった場合、そのような通信がブロックされるように Internet Firewall や WAN Firewall 機能に設定を追加しましょう。IPS などのセキュリティ機能でブロックされていたとしても、将来の通信がセキュリティ機能をすり抜ける可能性や Cato クラウド側のアルゴリズム変更でブロックされなくなる可能性がありますので、Firewall 機能でブロックするのが確実です。 その後、ストーリー詳細画面の右上にある三点アイコンの Story Actions メニューから、ストーリーのステータスをクローズ (Closed) に変更しましょう。 その際、「Analyst Verdict」という入力欄では、どのように分析したか次の4つから選択する必要があります。 Malicious (悪意ある) Suspicious (疑わしい) Informational (情報) Benign (無害) 選択した項目に応じてタイプや分類など詳細を任意で選択することもでき、入力しておけば将来的な分析にも役立てられるかと思います。 問題あるものか無害なものか判断できない場合は、ステータスを保留 (Pending Analysis または Pending More Info) に変更しておき、状況が変化したときにまた判断を行うというのでも良いです。 また、ストーリーがセキュリティ上問題のない無害なものだった場合、同様のストーリーが今後作成されないようにミュート (抑制) しましょう。この操作は Story Actions メニューにある「Add to new Muted Stories rule」というリンクから行えます。CMA の [Security] > [Detection & Response] > [Mute Stories] 画面からミュートを設定することもできますが、条件を手動で入力する必要があり、入力を間違えると問題あるストーリーまでミュートしてしまう可能性がありますので、ストーリーのステータスを変える際に合わせてミュートすることを推奨します。( 参考 ) その他：ストーリーの作成・更新通知を設定する CMA の [Security] > [Detection & Response] > [Reponse Policy] 画面から、ストーリーが作成・更新されたときにメール通知や Webhook 送信などを行うことができます。( 参考 ) CMA のストーリー・ダッシュボード画面やワークベンチ画面を定期的に確認する運用では新しいストーリーに気付くのが遅れてしまう可能性があるため、確実に気付けるよう通知設定を行うようにしましょう。ストーリーのタイプや重要度などの特定の条件に当てはまるものだけ通知することもできますが、まずは無条件で全て通知するようにしておき、通知量が多くなってきたら条件を付けて調整するのが良いと思います。 所感・課題点 本記事では XDR 機能を用いた基本的なセキュリティ運用の例を説明しましたが、実際に運用しようとすると超えるべきハードルや悩ましい点が多いというのが実情です。 まず、利用上の問題やセキュリティ上の実害が起きない限り、セキュリティ運用を実施する動機も沸かないのではないでしょうか。私自身としても、Cato クラウドが良きに働いてセキュリティ面で守ってくれるよう完全にお任せしてしまいたいと思っています。しかし、Cato クラウドで検知されたストーリーの内容を把握するようにすれば、企業システムの Cato クラウド以外の部分で発生した根本的な問題に気付けるというメリットもあります。例えば、PCがマルウェアに感染して不正な通信を行っているような場合、Cato クラウドの機能でそのことに気付くことができれば、素早く適切な対応を行えます。そのため、Cato クラウドに任せっきりにせずに、セキュリティ運用はしっかりと実施していかないといけません。 次に、やはり検知されたストーリーの内容の把握・分析・判断は難しく、なんとなく理解して推測できるものの確信を持てないことが多いです。ストーリーに該当する通信をブロックしてしまうとどこかで業務上の影響が発生してしまう可能性もあるため、セキュリティ上の問題の有無を判断するための基準や指針が必要となってきます。気軽に通信をブロックし、業務上の影響が発生したら元に戻せば良いという運用で良いのであれば気楽ではあるのですが、お客様の会社の規模によってはそういうわけにいかないこともあるかと思います。 そして、Cato クラウドがストーリーとして検知する際のアルゴリズムが非公開でよくわからないという点も悩ましいです。インターネット上で観測される様々な攻撃パターンや Cato の多数の顧客のトラフィック情報などをもとにアルゴリズムは日々改良されているものと推測されますが、どの程度の精度でストーリーが検知されているのかイマイチよくわかりません。また、故意に検知される方法もわからないため、運用テストも行えないのが困ります…。 とはいえ、いろいろ課題はあるものの XDR 機能は有益であることは間違いありませんので、より活用しやすくなる方法について今後も検討を続けていきます！

こんにちは。SCSKの山口です。 皆さん、誰しも一度は「過去に戻ってやり直したい」と思ったことがあるはずです。（唐突） 学校の花瓶を割ってしまったときや、大事なプレゼンで盛大に噛んでしまったとき、そして、 BigQuery テーブルの大事なデータを消してしまったとき。 大丈夫、 ３つ目は救えます 。 今回はそんなブログです。   BigQueryのタイムトラベル機能 BigQueryには、過去データへアクセスできる「タイムトラベル機能」という大変便利な機能が備わっています。 この機能を活用することで、以下のことが可能です。 特定の時点のデータをクエリで取得 特定の時点のテーブルを復元 ただし、タイムトラベル機能を使用できる期間は 7日間（デフォルト） となっています。 タイムトラベル期間の長さは 2~7日の範囲 で、 データセットレベル で設定することができます。 救えます。と堂々と前述しましたが、7日というタイムリミットはあります。人生そこまで甘くはありませんね。   過去のデータを一定期間保持しているとなると、気になるのが 課金 です。 デフォルトでは7日間のデータを保持していますが、必要に応じてタイムトラベル期間を短くすることで、物理ストレージの課金モデルを採用している場合に限り、「ストレージ費用」を節約できます。 論理ストレージの課金モデルを使用する場合は例外となるので、ご注意ください。（詳細は参考資料をご参照ください。） 過去のデータへのアクセス： https://cloud.google.com/bigquery/docs/time-travel?hl=ja タイムトラベルとフェイルセーフによるデータの保持： https://cloud.google.com/bigquery/docs/access-historical-data?hl=ja ストレージの課金モデル： https://cloud.google.com/bigquery/docs/datasets-intro?hl=ja#dataset_storage_billing_models ストレージの課金モデル更新： https://cloud.google.com/bigquery/docs/updating-datasets?hl=ja#update_storage_billing_models   実践①：特定の時点のデータをクエリで取得 ここから実践です。 まずは特定の時点のデータをクエリで取得してみます。 準備：テーブル 下記テーブルをテスト用として準備します 「INSERT_TIME」カラムには、データを入れた日時を入れています。 クエリ実行 では、準備したテーブルの【—- Check Point —-】の時点のデータを取ってみましょう。 過去のデータへのアクセス  |  BigQuery  |  Google Cloud に記載のあるSQLを参考に、日時を指定してデータを取得します。 実行SQL 実行結果 SELECT   * FROM   `evocative-entry-277709.yamaguchi_test.TIMETRAVEL_TEST`   FOR SYSTEM_TIME AS OF "2024-04-17 15:41:00+09:00" ※実行SQLでは、【—- Check Point —-】も含めるために敢えて15:41を指定しています。 結果として、【—- Check Point —-】より後のデータが入っていない状態に戻りました。大成功です。 （トリミングでギリギリを攻め過ぎましたが、ほんとに戻りました。）   実践②：特定の時点のデータをクエリで復元 今度は、一度削除してしまったデータを復元してみます。 準備：データを一部削除 実践①で使用したデータの【—- Check Point —-】以前に投入されたデータを一度削除します。 削除前 削除後 データの順序が前後していてかなりわかりづらいですが、【—- Check Point —-】以前に挿入されたCLM1が日本語のデータが消えている状態です。 この状態から、削除されたデータを復元します。 クエリ実行 実行SQL 実行結果 INSERT INTO   `evocative-entry-277709.yamaguchi_test.TIMETRAVEL_TEST` SELECT   * FROM   `evocative-entry-277709.yamaguchi_test.TIMETRAVEL_TEST`   FOR SYSTEM_TIME AS OF "2024-04-17 15:39:00+09:00" エラー： Table ‘evocative-entry-277709.yamaguchi_test.TIMETRAVEL_TEST’ is referenced with multiple snapshot read timestamps. For example, if ‘FOR SYSTEM_TIME AS OF’ expressions are used on the table, they should use the same TIMESTAMP value. Using the table as DML destination table references the table at query start time. エラーを吐かれました。 どうやら、復元先と復元元に同じテーブルを指定することはできないようです。 一度別名のテーブルにデータを復元し、その後元のテーブルに挿入する 方法をやってみます。   実行SQL① 実行結果 INSERT INTO   `evocative-entry-277709.yamaguchi_test. tmp_TIMETRAVEL_TEST ` SELECT   * FROM   `evocative-entry-277709.yamaguchi_test.TIMETRAVEL_TEST`   FOR SYSTEM_TIME AS OF "2024-04-17 15:39:00+09:00" ※一時テーブルを別途作成する必要があります   実行SQL②   INSERT INTO   `evocative-entry-277709.yamaguchi_test.TIMETRAVEL_TEST` SELECT   * FROM   `evocative-entry-277709.yamaguchi_test. tmp_TIMETRAVEL_TEST ` データの順序が逆転していますが、一度削除されたデータを復元し、テーブルを初期状態に戻すことができました。大成功です。 あとは元テーブル（TIMETRAVEL_TEST）を削除して、ALTER文でリネームとかしてあげると完全に元の状態に戻りますね。 （テーブルの名前を変更する： https://cloud.google.com/bigquery/docs/managing-tables?hl=ja#renaming-table ）   実践③：削除されたテーブルを復元 今度は、一度削除されてしまったテーブルを復元します。 実践①,②で使用したテーブルを削除します。 過去のデータへのアクセス  |  BigQuery  |  Google Cloud に記載のある方法で復元してみます。 コマンド bq cp [データセット名].[テーブル名1]@ XXXXXXX [データセット名].[テーブル名2] 「 XXXXXXX 」部分には、「 相対オフセット 」もしくは「 Unixエポック時刻 」を指定します。 相対オフセット：現在の時刻からの相対時間（ミリ秒単位） Unixエポック時刻：Unix エポック時刻からの経過時間（ミリ秒単位） Unixエポック秒は下記で取得可能です。 実行SQL 実行結果 SELECT   UNIX_MILLIS(TIMESTAMP(‘2024-04-17 18:00:00’,”Asia/Tokyo”))   下記コマンドを実行し、テーブルを別名の一時テーブルへ復元します。 実行コマンド 実行結果  bq cp yamaguchi_test.TIMETRAVEL_TEST@ -3600000   yamaguchi_test.tmp_TIMETRAVEL_TEST ※3600000 ms前（＝1時間前）を指定 bq cp yamaguchi_test.TIMETRAVEL_TEST@ 1713344400000  yamaguchi_test.tmp_TIMETRAVEL_TEST どちらのコマンドでも削除されたテーブルを復元できました。大成功です。   まとめ 今回はBigQuery のタイムトラベル機能を使って、特定時間のデータの取得、削除されたデータやテーブルの復元をやってみました。 私は、今回実践したSQLをプロジェクトクエリに保存しており、いつでも使えるようにしています。 大変便利な機能ですので、皆さんも是非ご活用ください。

こんにちは。SCSKの山口です。 今回は、BigQueryのドライランを実際にやってみたブログです。 業務で非常にお世話になり、便利すぎて感動したのでブログ化しちゃいました。皆さんも是非ご活用ください。   BigQueryドライラン概要 ドライランとは、クエリの検証、料金/データ見積もりを ”クエリを実際に実行することなく” 把握する事ができるモードです。 クエリを実際に実行しない（クエリスロットを使用しない）ため、課金なしで実行できるという何ともありがたい機能になっています。 公式のドキュメントには以下の通り記載されています。 BigQueryのドライランモードでは、次の情報が提供されます。 ・オンデマンドモードでの料金見積もり ・クエリの検証 ・キャパシティモードでのクエリのおおよそのサイズと複雑さ ドライランはクエリスロットを使用しないため、ドライランの実行に対しては課金されません。 ドライランによって返された見積もりを料金計算ツールで使用すると、クエリの費用を計算できます。 引用元： https://cloud.google.com/bigquery/docs/running-queries?hl=ja#perform_dry_runs   今回の活用方法 以前投稿した BigQuery Migration Service を使用することで大量のSQLをGoogleSQLの構文に変換しました。 しかし、SQL変換を用いたとしても、必ずしも完璧な（そのまま使用できる）SQLが生成されるわけではありません。 そんなこんなでSQLの修正作業が必要になったのですが、どのSQLが修正対象なのか一つひとつ開いて確認するのがまあメンドクサイ、、、 そんな時に、「ドライランを活用すれば修正が必要なSQLとそうでないものを簡単に分けることができる。」と思いつき実践したところ大変簡単で便利だったので紹介します。   実践：ドライランを使ってエラーを吐くSQLを特定する 準備：テーブル 以下のテーブルを準備します データも入れておきます 準備：SQLファイル 今回は以下の5つの簡単なSQLファイルを用意します。（奇数番目が成功、偶数番目が失敗するSQL例です。） -- testSQL1.sql SELECT * FROM `evocative-entry-277709.yamaguchi_test.dryrun_test` ; -- testSQL2.sql せれくとあすたぁふろむ`evocative-entry-277709.yamaguchi_test.dryrun_test` -- testSQL3.sql INSERT `evocative-entry-277709.yamaguchi_test.dryrun_test` (clm1, clm2, clm3) VALUES ('test', 'test', 'test') ; -- testSQL4.sql いんさあといんとぅ`evocative-entry-277709.yamaguchi_test.dryrun_test` 「あすたぁ」と「いんとぅ」が気になりますね。   準備：Pythonスクリプト 今回はPythonコード内でbqコマンドを叩くという形にします。 「–dry_run」オプションをつけることでドライランを実行することができます。 dryrun.py ''' dryrun.py'''   import   os from   subprocess  import   Popen, PIPE   # プロジェクトID project_id  =   "evocative-entry-277709"   # ドライラン結果テキストファイル result_path  =   "/home/sho_yamaguchi/Blog/DryRun/result.txt"   # SQLファイルのディレクトリ SQLs_path  =   "/home/sho_yamaguchi/Blog/DryRun/SQLs"   # SQLファイルのリストを取得 sql_files  =   [f  for   f  in   os.listdir(SQLs_path)  if   f.endswith( ".sql" )]   # 結果ファイルを開く with  open (result_path,  "w" ) as result_file:      for   sql_file  in   sql_files:          # SQLファイルのパス          sqlfile_path  =   os.path.join(SQLs_path, sql_file)            # SQLファイルの内容を取り込む →query_job          with  open   (sqlfile_path,  "r" ) as f:              query_job  =   f.read()                                # ドライランコマンド          dryrun_command  =   [ "bq" ,  "query" ,  "--use_legacy_sql=false" ,  "--dry_run" ,  "--project_id" , project_id, query_job]            # ドライラン実行          process  =   Popen(dryrun_command, stdout = PIPE, stderr = PIPE)          stdout, stderr  =   process.communicate()            # 結果をファイルに書き出す          result_file.write(f "--- {sql_file} ---\n" )          result_file.write(stdout.decode( "utf-8" ))          if   stderr:              result_file.write(f "エラー：{stderr.decode('utf-8')}" ) 準備は以上です。後はPythonスクリプトを実行するのみです。   実行結果 実行結果のテキストファイルは以下の通りです。 --- testSQL4.sql --- Error in query string: Syntax error: Illegal input character "\343" at [1:1] --- testSQL2.sql --- Error in query string: Syntax error: Illegal input character "\343" at [1:1] --- testSQL5.sql --- Query successfully validated. Assuming the tables are not modified, running this query will process 0 bytes of data. --- testSQL3.sql --- Query successfully validated. Assuming the tables are not modified, running this query will process 0 bytes of data. --- testSQL1.sql --- Query successfully validated. Assuming the tables are not modified, running this query will process 15 bytes of data. いい感じ！！ 「Error in query string: 」が吐かれている「testSQL2.sql」と「testSQL4.sql」が今回の修正対象だと一目でわかりますね。 クエリがエラーを吐かない場合、それぞれのクエリ実行に消費するバイト数も出力してくれています。 大規模なデータを扱う際や、大量のSQLを使用する際に、 「課金額を把握する術」 としても有効活用できます。   クエリ対象のテーブルの方はというと 狙い通り、何も起こっていません。 今回のテストSQLが実際に実行されると、テストデータがINSERTされ、最終的にDROPされてしまうはずですが無傷です。 実際のテーブルに影響を与えることなく クエリが成功するか失敗するかを判断してくれています。   まとめ 今回はBigQuery のドライラン機能をbqコマンドで実行してエラーが吐かれるSQLを特定してみました。 Pythonスクリプトに条件分岐を増やして、shutilで自動的にエラーSQLを他ディレクトリに移動させたりするとより便利ですね。 メンドクサイと思ったそこのあなた、 Geminiさんに書いてもらいましょう！

こんにちは。ひるたんぬです。 今回は小ネタですが、プライベートでAWS環境に触っていてハマったこと、その解決方法についてご紹介いたします。 ハマったこと ずっと眠っていた 学生時代のノートPCから、AWS環境に触ってみよう～と思ったことが発端です。 最近勉強中のCodeCatalyst環境に入ろうとAWS Builder IDでサインインしようとしたところ… …あれ？サインインができませんでした。 自分の中で考えうる問題点を以下のように洗い出し、確認していきました。 パスワードが違う → そんなことはなかった（別PC・iPadでサインインできた） AWSの障害 → そんなことはなかった（別PC・iPadでサインインできた） おかしいなぁ…と思い、今度はマネジメントコンソールはどうなっているか気になったので、同じようにサインインしてみました。 すると、サインインはできたものの、マネジメントコンソールの表示に何か違和感を感じたのです。 「アプリケーション」のデータが取得できていないのです。 もちろん他の端末では問題なく表示できていたため、権限が不足している、などではありませんでした。 原因調査 根本的な原因が分からなかったので、他のリソースのページなどの挙動からヒントが得られないか、様々なページを見てみることにしました。 すると、Lambdaの関数一覧を表示するページに気になる文言がありました。 Signature not yet current : 20240421T160656Z is still later than 20240421T160552Z (20240421T160052Z + 5 min.) …どうやら時刻がずれているため認証などがうまく行っていないのではないか ということに気づくことができました。PCの時刻を確認したところ、 約6分進んでいました。「ずっと眠っていた」ということがここにきて響いていたのですね。 解決 PCの設定より時刻の再同期を実行し、正しい時刻に戻しました。 これによりAWS Builder IDでのサインインやAWSマネジメントコンソールが正常に表示することができました。 おわりに 今回は短いですが、困ったこと・思ったより解決に時間にかかったため記事にまとめました。 同じような症状にお悩みの方にこの記事が届くことを願っております… CodeCatalystの勉強成果については、近日中に記事にまとめたいと思います。 こちらもトラブル中なので…

実際にCatoクラウドを利用されているお客様から、Webサイトへのアクセスが失敗するといったお問い合わせをいただくことがあります。 今回は、実際に問題に直面された方の事象例やその対処法をご紹介したいと思います。 Webサイトへのアクセスが失敗するとはどういう状況か 実際にお問い合わせをいただいたWebサイトへアクセスができない事象について、下記のようなケースがありました。 ・WebサイトへアクセスをするとCatoの Block ページが表示されて先に進まない ・証明書エラーとなりページが表示されない ・「403 Forbidden」や「このサイトにアクセスできません」が表示されてしまう ・ページが正しく表示されない(テキスト表示になってしまう) 上記の状況でどのように原因を発見し解決してきたのかをご紹介します。 記事内に出てきます設定値はあくまでも例になります。 設定を行う際は、ご利用の環境に合わせて設定ください。 WebサイトへアクセスをするとCatoの Block ページが表示されて先に進まない Cato接続時に本来なら閲覧できるはずのWebサイトがなぜかBlockされるというお問合せをいただくことがあります。 その原因の大半はInternet Firewall (FW) により脅威のないサイトが意図せずBlockされていたというものが多いと感じました。 CatoクラウドのInternet FW は、企業のネットワークを保護するために不可欠ですが、時には意図しない形で正当な通信をブロックしてしまうことがあります。 今回は実際にあった２パターンのトラブル例と対処法について記載します。 Internet Firewallの詳細につきましては下記ブログをご参照ください！ CatoクラウドのFirewall機能について CatoクラウドのFirewall機能について解説いたします。 blog.usize-tech.com 2023.09.28 パターン1 Firewallの上位のルールでBlockされていた CatoクラウドのInternet Firewall (FW) は、ルールに基づいて通信を制御しますが、必要な通信が上位のルールで誤ってBlockされてしまっていたケースがあります。 問題の発見方法 CatoのBlockページやCMAのEventsをチェックして、どの機能のルールで通信をBlockしているのかを特定しましょう。 BlockページやEventsでの確認方法 まず以下画像のCatoのBlockページにて「Block Reason」を見てみましょう。 「Corporate Internet Policy Violation」と記載されており、インターネットポリシー(Internet FW)によってBlockされていることがわかります。 次にEventsを確認してみましょう。 [Monitornig]>[Events] 上記の場合は、フィルター機能で「Action」をBlock、「Domain Name」をアクセスしたサイトのドメインとして該当の通信を探しました。Blockされた通信ログを発見できたら「Sub-Type」と「Rule」を確認して、実際にどの機能のどのルールによりBlockされたのか確認してみましょう。 ・Eventsから通信を確認する際は、誰がいつどこにアクセスをしたのかを記録し、フィルターでログを絞ることで、該当する通信ログが発見しやすくなります。 ・「Sub-Type」を見ると、IPSやInternet FW等、Catoのどの機能で Block されているかがわかります！ トラブルシューティングを行うためにフィルター機能を活用していきましょう！ 対処方法 原因であるInternet FWルールを特定できたので、あとは上位に対象通信を許可するルールの追加や例外設定を追加することで事象は解消できます。 Blockルールに例外設定を追加する方法 Blockルールに例外設定を追加する場合はルール横の[…]をクリックし、「Add Exeption」をクリックください。 すると以下画像の設定画面が出てきますので、要件に合わせて例外設定を行ってください。 [Security]> [Internet Firewall] パターン2 異なるカテゴリに分類にされBlockされていた CatoのSWG（Secure Web Gateway）機能により、Webサイトの内容と異なるカテゴリに分類され、本来許可されるべきアクセスがInternet FWにより Block されてしまうことがあります。 問題の発見方法 パターン1と同じ手順で、EventsからInternet FWのどのルールによりBlockされたのかを確認してみましょう。 多い例として誤ってカテゴリが「Games」等に分類されてしまい、デフォルトの Block ポリシーに引っかかってしまうというものがあります。 対処方法 こちらもパターン1のように許可ルールや例外設定で回避することができますが、もっと簡単な方法は、カテゴリを手動で修正してしまうことです。 CMAの[Assets]>[App Catalog]の[Domain Lookup]タブからカテゴリの修正が可能です。 [Domain Lookup]からカテゴリ修正を行う方法の詳細については以下のブログ記事を参照ください！ Catoで業務通信がブロックされてしまう事象の解決策！～SWGで誤分類されたサイトを管理者で修正する機能～ Catoを使っていると、業務でアクセスするドメイン（URL）が誤ったカテゴリに分類され、通信できない！ということがあります。今回は、そんな問題が発生した場合の新しい回避策「カテゴリの手動修正」を紹介します。 blog.usize-tech.com 2024.02.22 証明書エラーとなりページが表示されない Catoクラウドでは、TLSインスペクション機能を通じてHTTPS通信のセキュリティを強化していますが、証明書の書き換えが許可されていないWebサイトへアクセスしてしまうと証明書エラーが発生してしまいページが表示されないケースがあります。 問題の発見方法 ブラウザ側でのエラーとなるため、Eventsを見てもBlockのログは表示されません。そのためブラウザ側で「この接続ではプライバシーが保護されません」、「このWebサイトのセキュリティ証明書には問題があります」といった画面が表示されたら、考えられる原因の一つとしてTLSインスペクション機能があることを頭に入れておきましょう。 対処方法 TLSインスペクションが原因で問題が起きている場合、Webサイトに対してTLSインスペクションを動作させないよう除外リストに追加することで回避ができます。 まず「Security」> 「TLS Inspection」から「New」をクリックしBypassルールを作成しましょう。 新しく作成するTLS Inspectionの名前を記載し、「What」の項目にてIP Range、Domain、FQDN等を設定します。 「Action」の項目では「Bypass」を選択します。 ※その他の設定は環境に合わせて設定ください。 以上が、TLSインスペクションの除外設定となります。 TLSインスペクション機能の詳細につきましては下記ブログ記事をご覧ください！ CatoクラウドのTLS Inspection機能で躓く証明書の仕組み Cato クラウドでHTTPS通信のセキュリティ対策を行うためのTLS Inspection機能で躓くことの多いTLS証明書関連の仕組みや課題について解説します。 blog.usize-tech.com 2023.10.06 「403 Forbidden」や「このサイトにアクセスできません」が表示されてしまう EventsではBlockのログは出ていないのに、「403 Forbidden」や「このサイトにアクセスできません」が表示されて正常にページが表示されない事例がございます。 原因の一つとして、Webサーバや、Firewall（UTM）において、JPNICのIPアドレスのみを許可しているといったように、日本からのアクセスのみに制限をしているため、Cato経由でのアクセスがブロックされるケースがございます。 なぜかというと、 Cato PoPのIPアドレスはJPNICでなく、上位のAPNICからIPアドレスを取得しているからです。 そのため、Webサーバ、Firewall（UTM）にて「日本のアクセスのみに制限する」や、JPNIC DBのみの制限を行われている場合は、APNICアドレスとなるCatoからのアクセスができません。 対処方法 2024/4/8時点での対処方法としましては、３つございます。 1.IPアロケーションで取得したグローバルIPアドレス(Egress IP)経由で、対象のWebサイトへアクセスするよう Network Rulesに設定し、サイト管理者へIPアドレスのアクセス許可依頼を行う。 Catoを利用したままサイトへのアクセスを行いたい場合は、Catoで確保したEgress IPをWebサイト側で許可してもらうことで閲覧が可能になります。 Egress IPとは何かご不明な方は、以下のブログ記事をご参照ください！ CatoクラウドにおけるEgress IP（送信元IP、出口IP）について CatoクラウドにおけるEgress IPについて解説します。 blog.usize-tech.com 2023.08.22 対応手順 まずCMAの[Network]>[IP Allocation]からEgress IPアドレスを取得しましょう。 ※標準で３つまで取得可能で、4つ目以降は有償となります。 次に、取得したEgress IPアドレス経由で、対象のWebサイトへアクセスを行うように[Network]> [Network Rules]から[New]をクリックして新しいNATルールの作成を行いましょう。 環境に合わせて設定いただき、App/Categoryには対象サイトのDomainもしくはFQDNを設定ください。 Routing MethodのRoute/NATで”NAT”を選択し、上記で取得したIPアドレスを設定しましょう。 NAT設定を行う際に「Preserve source port」という項目があります。 この設定はNAT変換時にIPヘッダ内のSource Portを保持する機能です。 一般的なWEBブラウジングなどの場合、ポート番号が変換されても影響ございませんので、チェックは不要です。 NATの設定が完了したら最後にWebサイトの管理者へ、設定したEgress IPを許可いただくよう依頼を行いましょう。 2.対象のWebサイトへのアクセスをCato経由で行わない そもそもCato経由でアクセスを行わないといった方法もございます。 Socket配下(拠点)接続の場合はBypass機能、SDPユーザ(モバイルユーザ)からの接続の場合はSplit Tunnel機能を利用することで、Catoを経由させず直接アクセスさせることができます。設定方法は以下をご参照ください。 ・Catoを経由させない設定のため、Catoによるセキュリティ検査、管理は行われません。 ・Bypass、Split Tunnel機能は、FQDNやドメイン設定は行えず、IPアドレスのみでの設定になります。 (2024/4/8時点) Socket配下(拠点)のBypass設定 [Network]>[Sites]からBypass設定を行いたい拠点を選択し、[Site Configuration]>[Bypass]をクリックします。 Destination(宛先)への通信もしくは、Source(送信元)からの通信をBypassするか選択ができますので、環境に合わせて設定ください。 設定の際は[New]をクリックください。 上記画像の設定項目から宛先もしくは送信元のIPアドレスを設定しましょう。 オプションとしてトラフィックプロトコルやトラフィックをインターネットに直接出力するポートを選択することもできます。 [Apply]、[Save]をクリックし保存を行うと設定が完了します。 SDPユーザのSplit Tunnel設定 まず、[Network] > [IP Ranges]から、[New]をクリックし除外したいIPアドレスを設定します。 [Apply]、[Save]をクリックして保存したら、次に[Access] > [Split Tunnel Policy]から[IP Ranges]で設定したIPを割り当てましょう。 [New]をクリックし、[Split Tunnel]セクションで[Exclude specific IPs]をクリックします。 ※[Exclude specific IPs]は、インターネットに直接ルーティングを行うという設定になります。 すると[Split Tunnel IPs]が出現しますので、上記で設定したIP Rangeを選択します。 ルールの対象となる[User/Groups]や[Platform]等のその他の設定については、ご利用の環境に合わせて設定ください。 最後に[Apply]、[Save]をクリックして設定が完了します。 3. Socket設置拠点に別のインターネット回線がある場合は拠点のインターネットからアクセスを行う こちらは利用例が少ないですが、Socket設置拠点に別のインターネット出口がある場合、Backhauling および Network Rules 設定をすることで、Cato PoPからではなく、拠点のインターネットからWebサイトへアクセスを行うことができます。 ・Network Rulesにて制御を行うため、FQDNやドメインでの設定も可能です。 ・BypassやSplit Tunnelとは異なり、Backhaulingを設定した特定拠点までの通信はCato PoPを通ります。 Backhauling設定の詳細につきましては以下のKnowledge Baseをご参照ください。 Just a moment... support.catonetworks.com ページが正しく表示されない(テキスト表示になってしまう) Cato経由でWebサイトへアクセスすると、画像など必要な部分が正しく表示されずサイトが崩れてしまっているように見える（テキストのみ表示されるように見える）ケースがございました。 一例といたしましては、Internet FWにてPrompt設定を行ったWebサイトで発生しました。 原因 事象が発生したWebページのレンダリングの一部が、Internet FWのPrompt設定によりブロックされてしまっていたためでした。 Internet FWのPrompt設定とは一致するトラフィックをメッセージ付きのWebページにリダイレクトし、ユーザーに対して続行するかどうかを決定するようにさせる設定です。 対処方法 ページ内でブロックされているドメインを確認し、Internet FWルールの例外に設定することで回避が可能です。 本項では、一例としまして、Internet Firewallにてアプリケーション”Fire Storage”をPrompt設定した際の対処方法を記載します。 まず、ブロックされているドメインの確認（Chromeの場合）を行いましょう。 該当のWebサイトへアクセスし、「Prompt」されたページへ遷移します。 次にブラウザから[設定]＞[その他のツール]＞[デベロッパーツール]＞[Console]タブをクリックし開き「Prompt」ページから「進行する」をクリックし、実際のWebページへ遷移します。 [Console]タブに表示されたURLを確認し、ブロックされているドメインの中から、 Webページに関連しているドメインを記録します。 ※例として、Firestorageのサイトの場合は、「firestorage」が入っているドメインを記録します。 ※なお、ドメインはFilterで絞ることも可能です。 ※Edgeの場合は、[設定]＞[その他のツール]＞[開発者ツール]からご確認いただけます。 Blockされているドメインが判明したので、Internet FWルールで例外設定を行いましょう。 まず、Internet FWルールより、[Prompt]設定をしているルールから[…]＞Add Exceptionをクリック。 作成された[Exceptions]のApp/Categoryに、上記で記録したドメインを入力します。 ※その他の設定は環境に合わせて設定ください [Apply]、[Save]で設定が完了です。 設定完了後、Webサイトへアクセスすると、表示崩れは改善されていました。 まとめ 本投稿では、Cato経由でのWebサイト接続のトラブル例とその対処法について説明いたしました。 トラブルでお困りの方のお役に立てれば幸いです。 なお、弊社の FAQ サイトでは 、よくあるご質問やCato クラウドのアップデート情報を公開しておりますので、是非ご参照ください！

こんにちは。SCSKの山口です。 今回は、案件業務で活用した「BigQuery 上に大量テーブルを一括作成する便利な方法」をブログ化します。 私はこの方法で約900のテーブルをBigQuery 上に一括作成しました。   BigQuery テーブル作成方法 BigQuery 上にテーブルを作成する際は、コンソール上で作成する方法とデータ定義言語（DDL）ステートメントを使用する方法があります。 https://cloud.google.com/bigquery/docs/tables?hl=ja#create-table コンソール上で作成する方法は、直感的にテーブルを作成することができ大変便利です。 しかし、大量のテーブルを作成したい際は天文学的な時間を要してしまい、もうBigQuery のコンソールミタクナイ、、、とグロッキーになってしまう可能性があります。 皆さんにBigQuery LOVEのままでいてもらうために、今回はDDLを連続的に実行してBigQuery 上にテーブルを一括作成する方法をご紹介します。   実践：DDLを連続的に実行しBigQuery テーブルを一括作成する DDLファイル ・今回はお試しとして、以下の5つのDDLを準備します testDDL1.ddl — testDDL1.ddl   CREATE TABLE evocative-entry-277709.yamaguchi_test_execDDL.create_table_test1 (   `clm1` STRING,   `clm2` STRING,   `clm` STRING ) ; testDDL2.ddl — testDDL2.ddl   CREATE TABLE evocative-entry-277709.yamaguchi_test_execDDL.create_table_test2 (   `clm1` STRING,   `clm2` STRING,   `clm` STRING ) ; testDDL3.ddl — testDDL3.ddl   CREATE TABLE evocative-entry-277709.yamaguchi_test_execDDL.create_table_test3 (   `clm1` STRING,   `clm2` STRING,   `clm` STRING ) ; testDDL4.ddl — testDDL4.ddl CREATE TABLE evocative-entry-277709.yamaguchi_test_execDDL.create_table_test4 ( `clm1` STRING, `clm2` STRING, `clm` STRING ) ; testDDL5.ddl — testDDL5.ddl CREATE TABLE evocative-entry-277709.yamaguchi_test_execDDL.create_table_test5 ( `clm1` STRING, `clm2` STRING, `clm` STRING ) ;   Pythonスクリプト 今回はBigQuery 用のPython用のクライアントライブラリを使用して、PythonスクリプトからDDLファイルを実行します。 以下が今回作成したPythonスクリプトです。 execDDL.py ”’ execDDL.py”’   import os from google.cloud import bigquery   # DDLファイルのパス ddls_path = ‘/home/sho_yamaguchi/Blog/execDDLs/DDLs’   # SQLファイルのリストを取得 ddl_files = [f for f in os.listdir(ddls_path) if f.endswith(“.ddl”)]   for ddl_file in ddl_files:     # DDLファイルのパス     ddlfile_path = os.path.join(ddls_path, ddl_file)       # DDLファイルの内容を取り込む →query     with open (ddlfile_path, encoding=’utf-8′)as f:         query = f.read()       # BigQuery クライアント作成     client = bigquery.Client()       # クエリ実行     query_job = client.query(query) 今回のPythonスクリプトは「ファイルを開く→内容をクエリとして取り込む→クエリ実行」という作りにしています。   後はPythonスクリプトを実行するだけです。 実行結果 Pythonスクリプト実行後の対象データセット内は以下の通りです。 狙い通り5つのテーブルが作成されていますね。 ジョブ履歴からもDDLが実行されていることが確認できました。 まとめ 今回はDDLを連続的に実行してBigQuery 上にテーブルを一括作成する方法を実際にやってみました。 DDLファイルの量が多くなるとその分時間ががりますが、一度スクリプトを流してしまえば放置でOKなのでとても楽です。 今回のPythonスクリプトの作りとしては、「ファイルを開く→内容をクエリとして取り込む→クエリ実行」という単純な作りなので、 アイデア次第でテーブル作成以外の他のことにも使えそうですね。 最後まで読んでいただきありがとうございました。