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

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

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

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

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

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

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

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

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

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

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

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

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

本記事は、SCSKの運営する本エンジニアブログ「TechHarmony」の Catoクラウドのまとめ記事 になります。 ※ Catoクラウドの記事がかなり増えて来たので、適宜まとめ記事を作成する予定です。まとめ記事については、定期的に内容を更新する予定です。 SCSKでは、2019年よりCato Networks社のCatoクラウド（Cato Cloud/Cato SASE Cloud）の取り扱いを開始しており、すでに30社以上のお客様にご契約、ご利用をいただいております。 一方で、Catoクラウドは、日本語の情報が非常に少ないため、2022年7月から FAQサイト の運営を開始し、2023年8月から、本エンジニアブログ「 TechHarmony 」にて、 Catoクラウド、ゼロトラスト/SASE/SSEに関するニュースや最新動向・技術トレンド、Catoクラウドで新たにリリースされた機能の検証結果などを記事 にしています。 FAQやTechHarmonyで、Catoクラウドの日本語でのお役立ちサイトを目指し、CatoクラウドやSASEの知名度向上に少しでも寄与できればと考えています。 Catoクラウドの概要 Catoクラウドについて サービス体系について（2024年最新版） 旧サービス体系について（2024年1月末まで） 2024年2月の価格体系変更について   Catoクラウドの各機能概要 Catoクラウドの管理ポータル Cato管理アプリケーション（CMA）について SD-WAN、ZTNAについて QoSについて FWaaS、SWGについて Firewall機能について LAN Firewall機能について IPS、NGAMについて DNS Security、RBIについて RBI機能について CASB、DLPについて CASB機能について CASBでのアプリケーション制御について アプリケーション数ではなくカバレッジが重要 DLP機能について EPP、XDRについて 世界初SASEベースのXDRについて   Catoクラウドのご利用 はじめの一歩 ログの確認方法 Cato Statusページ   よくご質問いただく事項（Top5） 1. 送信元IPの固定化 2. Socketなしですべてモバイルユーザにする場合の注意点 3. 拠点接続の冗長化構成 4. 既存WANからの移行方法 5. クライアント常時接続機能（Always-On）   トラブルシューティング 拠点接続の不具合時 クライアント接続の不具合時   Deep Dive TLS Inspection機能で躓く証明書の仕組み TCP Acceleration の仕組みと効果測定 CASBでQUIC プロトコルをブロックすべき理由   その他関連サイト Catoクラウドサービス紹介ページ Catoクラウド FAQサイト Catoクラウド導入・運用の悩みは“パートナー選び”で解決 SASE実態調査（2023年度版） SASEとSSEの違いについて 2023年ゼロトラストネットワーキング10大ニュース   まとめ Catoクラウドに少しでも興味をお持ちになられた方は、ご遠慮なくSCSKまで お問い合わせ ください。 SASE、Cato Networks、Catoクラウド（Cato Cloud/Cato SASE Cloud）自体の知名度がまだまだ低い状況です。 SCSKでは、2021年からSASEの主要ソリューションを一同に紹介を行うオンラインセミナー「SCSK SASE Solution Summit（通称S4 エスフォー）」を定期的に開催しております。 これまで14回開催し、1,800名以上の方にご参加いただいております。 S4については、2024年2月に開催済みで、次回は2024年4月以降に開催予定ですので、改めてご案内します。 来月（2024年3月14日）に、Catoクラウドの主要機能を2時間・デモ形式でご覧いただけるセミナーを開催しますので、ご興味のある方は是非ご参加ください。 Catoクラウドデモセミナー～Catoクラウドの主要機能を2時間で網羅～ 本セミナーでは、世界初のSASEである「Catoクラウド」の概要をたっぷり2時間、デモ形式でご覧いただきます。 また、ご希望の方（先着10名様）は、デモ環境に対して、お手元の環境からハンズオン形式でCatoクラウドに触れて頂くことが可能な参加型セミナーです。 www.scsk.jp SASE、Catoクラウドセミナー以外に、Catoクラウドのお客様導入事例の制作、FAQサイト運営、この TechHarmony（技術ブログ）で、皆様のお役に立て、Catoクラウドの知名度アップに少しでも貢献できればと考えておりますので、よろしくお願いします。

本記事の内容は、Cato Networks社の以下の記事を元に日本語へ意訳、再構成したものとなります。 Cato Management Application Catoクラウドでは、管理ポータルである Cato管理アプリケーション （ Cato Management Application 、以下、 CMA ）は、お客様のCatoクラウドのすべての環境を完全に可視化し、コントロールすることが可能です。 管理者は、CMAでセキュリティとネットワーキングのポリシーを定義し、サイトとユーザー接続を管理し、インシデントを調査することができます。 CMAは、Catoプラットフォームのネイティブな部分であり、ソフトウェアのインストールやハードウェアの導入は不要で、Webブラウザで利用することができます。 ※CMAは、URLが “cc.catonetworks.com” だったことから、以前はCC2（シーシーツー）と言われていました。 どこでも一貫したポリシー Catoのすべての機能は、CMAと連携して開発されており、Catoクラウドのデプロイメントを管理するための真のシングルペイン（一つの画面で必要な情報が全て閲覧できること）を保証します。FWaaS、Threat Prevention、CASB、DLP、RBI、および今後リリースされるすべてのセキュリティエンジンのポリシーは、CMAにすべて一元管理され、Catoクラウドプラットフォーム全体で一貫して適用されます。しばしばセキュリティポスチャにギャップを生じさせ、攻撃対象領域を拡大するような、バラバラのセキュリティアプライアンス製品に設定をプッシュするような必要はありません。Catoクラウドを使用することで、管理者は、組織全体・全世界でわずか数分で変更が反映される包括的なグローバルセキュリティの適用範囲を保証することができます。 ワンストップのネットワーク管理 Catoクラウドは、すべてのネットワーキングとセキュリティ機能を単一のソフトウェアスタックから提供し、真に統合された管理アプリケーションを実現します。ネットワークの設定、監視、トラブルシューティングは、CMAで一元管理することができます。お客様は、CatoのSD-WANエッジ（Socket/vSocket）、IPsecまたはCross Connectを介した物理ネットワークとクラウドネットワークの接続性、およびCatoのグローバルプライベートバックボーンを介した企業のルーティング、DNS、DHCP、QoS、ネットワーク最適化を完全に可視化し、制御することができます。ネットワークチームとセキュリティチームは、1つのプラットフォームを使用してインシデントの解決に協力できるため、効率性と生産性が向上します。 実用的な情報を瞬時に可視化 CMAは、ハイレベルなトポロジービューから、サマリーダッシュボード、特定のサイト、ユーザー、イベントまで、企業環境全体を全て可視化します。トポロジービューは、すべてのサイトとユーザーの位置、接続性、主要統計に関する情報をリアルタイムで表示します。ダッシュボードは、脅威、クラウドおよびアプリケーションの使用状況、ネットワークパフォーマンス、リモートアクセスなどの主要な次元にわたって要約された情報を提供します。イベントディスカバリーエンジンにより、アカウント内のすべてのイベント（セキュリティ、ネットワーク、アクセス、デバイス）をカスタマイズして検索することができます。リアルタイム表示から履歴ダッシュボード、そして数回のクリックでイベントのフィルタリングされたリストに移動できる機能により、CMAは管理者にとって非常に効率的なモニタリングおよびトラブルシューティングツールとなります。 セキュリティインシデントの合理化された調査 Catoクラウドは、セキュリティチームがネットワークとセキュリティ管理を提供する同じプラットフォーム内でインシデントに対処することを可能にします。侵害の指標は、Cato XDRによって「ストーリー」としてグループ化され、専用のCMA XDRワークベンチでセキュリティチームに提示されます。ストーリーをワンクリックすると、調査ツールのフルセットとともにインシデントの詳細が表示されます。情報の構文、オブジェクト、イベントとポリシーへの参照は一貫しており、非常に理解しやすくなっています。CMAを通じて修復ステップを簡単に開始できるため、企業の攻撃への対応能力がタイムリーに向上します。 ※Catoの「ストーリー」は、1つまたは複数のセンサーによって生成されたイベントの相関関係。 きめ細かなRBACによる管理者のプロビジョニングと管理 管理者のCMAアクセスを保護および制御することは、組織の強固なセキュリティ体制を確保する上で最も重要です。CMAは、SSOおよびMFAプロバイダとポリシーのサポートにより、IT組織構造にシームレスに適合するように設計されています。きめ細かな役割ベースアクセス制御（ Role-based Access Controls：RBAC ）を定義することで、特定の管理者やチームが特定の地域や担当ドメインを制御できるようになります。すべての管理者の活動は、包括的な監査証跡に記録され、SASE環境の完全な管理責任を保証します。 ライセンスとSD-WANエッジを一元管理 CMAは、ライセンスとSD-WANエッジのハードウェアであるSocketの可視性を提供します。管理者は、サイト、ユーザー、およびサービスのライセンス割り当てを一目で確認できるため、現在の展開と将来の成長に対して適切なカバレッジを確保できます。Cato Socketのステータスは、出荷追跡、展開ステータス、ソフトウェアアップデート、および 故障修理対応（ Return Merchandise Authorization ： RMA ）に至るまで、デバイスのライフサイクル全体を通じて追跡できます。ライセンスとハードウェアのインベントリ管理を CMA に取り込むことで、管理者は Cato 環境の全範囲を包括的かつシンプルに管理できるようになります。 まとめ Catoクラウドの管理ポータルであるCato管理アプリケーション（CMA)について解説をしました。 Catoクラウドに少しでも興味をお持ちになられた方は、遠慮なくSCSKまでお問い合わせください。 SASE、Cato Networks社、Catoクラウド（Cato Cloud/Cato SASE Cloud）自体の知名度もまだまだ低い状況です。 SCSKでは、2021年からSASEの主要ソリューションを一同に紹介を行うオンラインセミナー「SCSK SASE Solution Summit（通称S4 エスフォー）」を定期的に開催しております。これまで14回開催し、1,800名以上の方にご参加いただいております。 S4については、次回2024年4月以降に開催する予定ですので、改めてご案内いたします。 来月、2024年3月14日には、Catoクラウドの主要機能を2時間・デモ形式でご覧いただけるセミナーを開催しますので、ご興味のある方は是非ご参加ください。 Catoクラウドデモセミナー～Catoクラウドの主要機能を2時間で網羅～ 本セミナーでは、世界初のSASEである「Catoクラウド」の概要をたっぷり2時間、デモ形式でご覧いただきます。 また、ご希望の方（先着10名様）は、デモ環境に対して、お手元の環境からハンズオン形式でCatoクラウドに触れて頂くことが可能な参加型セミナーです。 www.scsk.jp SASE、Catoクラウドセミナー以外に、Catoクラウドのお客様導入事例の制作、FAQサイト運営、この TechHarmony（技術ブログ）で、皆様のお役に立て、Catoクラウドの知名度アップに少しでも貢献できればと考えております。

こんにちは、広野です。 AWS AppSync を使用したアプリケーションを開発する機会があり、リゾルバ、主に VTL の書き方に関してまとまった知識が得られたので紹介します。前回からの続きもので、UpdateItem の書き方を紹介します。 本記事では、VTL の書き方にフォーカスしています。ご了承ください。 AWS AppSync、リゾルバ、VTL の説明については以下の記事をご覧下さい。 AWS AppSync リゾルバ (VTL) の書き方サンプル No.1 - Amazon DynamoDB GetItem Amazon DynamoDB に VTL で GetItem をかけるときの基本的な書き方を紹介します。 blog.usize-tech.com 2024.01.09 AWS AppSync リゾルバ (VTL) の書き方サンプル No.2 – Amazon DynamoDB BatchGetItem Amazon DynamoDB に VTL で BatchGetItem をかけるときの基本的な書き方を紹介します。 blog.usize-tech.com 2024.01.19 AWS AppSync リゾルバ (VTL) の書き方サンプル No.3 – Amazon DynamoDB Query Amazon DynamoDB に VTL で Query をかけるときの基本的な書き方を紹介します。 blog.usize-tech.com 2024.02.26 AWS AppSync リゾルバ (VTL) の書き方サンプル No.4 - Amazon DynamoDB PutItem Amazon DynamoDB に VTL で PutItem をかけるときの基本的な書き方を紹介します。 blog.usize-tech.com 2024.02.26 AWS AppSync を使って React アプリからキックした非同期ジョブの結果をプッシュ通知で受け取る 非同期ジョブを実行した後、結果をどう受け取るか？というのは開発者として作り込み甲斐のあるテーマです。今回は React アプリが非同期ジョブを実行した後に、AWS AppSync 経由でジョブ完了のプッシュ通知を受け取る仕組みを紹介します。 blog.usize-tech.com 2022.12.01 Amazon DynamoDB に UpdateItem する VTL 例えば、AWS AppSync から以下のリクエストを受けたとします。Amazon DynamoDB には適切なデータがある想定です。テーブル名はリゾルバの別の設定 (Data Source) で行います。 引数となるパラメータ：　input の中にパーティションキー pkey、ソートキー skey、任意の属性データ 今回は受け取ったパーティションキーとソートキーのパラメータをそのまま UpdateItem の条件に当てはめて、input の中に格納されている属性をそのまま使用してデータを更新します。 リクエストマッピングテンプレート { "version": "2018-05-29", "operation": "UpdateItem", "key": { "pkey": $util.dynamodb.toDynamoDBJson($ctx.args.input.pkey), "skey": $util.dynamodb.toDynamoDBJson($ctx.args.input.skey) }, #set( $expNames = {} ) #set( $expValues = {} ) #set( $expSet = {} ) #set( $expAdd = {} ) #set( $expRemove = [] ) #foreach( $entry in $util.map.copyAndRemoveAllKeys($ctx.args.input, ["pkey", "skey"]).entrySet() ) #if( $util.isNull($entry.value) ) #set( $discard = ${expRemove.add("#${entry.key}")} ) $!{expNames.put("#${entry.key}", "${entry.key}")} #else $!{expSet.put("#${entry.key}", ":${entry.key}")} $!{expNames.put("#${entry.key}", "${entry.key}")} $!{expValues.put(":${entry.key}", $util.dynamodb.toDynamoDB($entry.value))} #end #end #set( $expression = "" ) #if( !${expSet.isEmpty()} ) #set( $expression = "SET" ) #foreach( $entry in $expSet.entrySet() ) #set( $expression = "${expression} ${entry.key} = ${entry.value}" ) #if ( $foreach.hasNext ) #set( $expression = "${expression}," ) #end #end #end #if( !${expAdd.isEmpty()} ) #set( $expression = "${expression} ADD" ) #foreach( $entry in $expAdd.entrySet() ) #set( $expression = "${expression} ${entry.key} ${entry.value}" ) #if ( $foreach.hasNext ) #set( $expression = "${expression}," ) #end #end #end #if( !${expRemove.isEmpty()} ) #set( $expression = "${expression} REMOVE" ) #foreach( $entry in $expRemove ) #set( $expression = "${expression} ${entry}" ) #if ( $foreach.hasNext ) #set( $expression = "${expression}," ) #end #end #end "update": { "expression": "${expression}", #if( !${expNames.isEmpty()} ) "expressionNames": $utils.toJson($expNames), #end #if( !${expValues.isEmpty()} ) "expressionValues": $utils.toJson($expValues), #end }, "condition": { "expression": "attribute_exists(#pkey) AND attribute_exists(#skey)", "expressionNames": { "#pkey": "pkey", "#skey": "skey" } } } operation には、UpdateItem を書きます。これは Amazon DynamoDB に UpdateItem するぞ、という意思表示です。 アプリから受け取った引数はマッピングテンプレート内では $ctx.args 内に格納されます。今回は input の中に必要なキーや属性をまとめて格納しています。そうすることで、パーティションキー、ソートキー以外は任意のデータを可変で入れ込むことができます。 このコードは以下の AWS 公式サイトのドキュメントを参考にしました。正直、これを独力で書くのは難しいです。コード内、pkey と skey の部分だけ書き換えれば使えます。 DynamoDB のリゾルバーのマッピングテンプレートリファレンス - AWS AppSync AWS AppSync の DynamoDB のリゾルバーのマッピングテンプレートリファレンス docs.aws.amazon.com レスポンスマッピングテンプレート 結果は配列に格納されます。戻ってきたデータをそのままアプリ側に戻す書き方です。 $utils.toJson($context.result) VTL に関しては以下の AWS 公式ドキュメントも必要に応じてご確認ください。 Resolver mapping template reference for DynamoDB - AWS AppSync Resolver Mapping Template Reference for DynamoDB for AWS AppSync. docs.aws.amazon.com まとめ いかがでしたでしょうか。 UpdateItem も AWS AppSync のサブスクリプションで使用することがあります。他のオペレーションと比べて難解なコードになっていますが、AWS 公式ドキュメントのコードが非常に良くできているので、ほぼそのまま使えます。 本記事が皆様のお役に立てれば幸いです。

こんにちは、広野です。 AWS AppSync を使用したアプリケーションを開発する機会があり、リゾルバ、主に VTL の書き方に関してまとまった知識が得られたので紹介します。前回からの続きもので、PutItem の書き方を紹介します。 本記事では、VTL の書き方にフォーカスしています。ご了承ください。 AWS AppSync、リゾルバ、VTL の説明については以下の記事をご覧下さい。 AWS AppSync リゾルバ (VTL) の書き方サンプル No.1 - Amazon DynamoDB GetItem Amazon DynamoDB に VTL で GetItem をかけるときの基本的な書き方を紹介します。 blog.usize-tech.com 2024.01.09 AWS AppSync リゾルバ (VTL) の書き方サンプル No.2 – Amazon DynamoDB BatchGetItem Amazon DynamoDB に VTL で BatchGetItem をかけるときの基本的な書き方を紹介します。 blog.usize-tech.com 2024.01.19 AWS AppSync リゾルバ (VTL) の書き方サンプル No.3 – Amazon DynamoDB Query Amazon DynamoDB に VTL で Query をかけるときの基本的な書き方を紹介します。 blog.usize-tech.com 2024.02.26 AWS AppSync を使って React アプリからキックした非同期ジョブの結果をプッシュ通知で受け取る 非同期ジョブを実行した後、結果をどう受け取るか？というのは開発者として作り込み甲斐のあるテーマです。今回は React アプリが非同期ジョブを実行した後に、AWS AppSync 経由でジョブ完了のプッシュ通知を受け取る仕組みを紹介します。 blog.usize-tech.com 2022.12.01 Amazon DynamoDB に PutItem する VTL 例えば、AWS AppSync から以下のリクエストを受けたとします。Amazon DynamoDB には適切なパーティションキー、ソートキーがある想定です。テーブル名はリゾルバの別の設定 (Data Source) で行います。 引数となるパラメータ：　input の中にパーティションキー pkey、ソートキー skey, 任意の属性データ 今回は受け取ったパーティションキーとソートキーのパラメータをそのまま PutItem の条件に当てはめて、input の中に格納されている属性を全てそのまま書き込みます。 リクエストマッピングテンプレート { "version": "2018-05-29", "operation": "PutItem", "key": { "pkey": $util.dynamodb.toDynamoDBJson($ctx.args.input.pkey), "skey": $util.dynamodb.toDynamoDBJson($ctx.args.input.skey) }, "attributeValues": $util.dynamodb.toMapValuesJson($ctx.args.input), "condition": { "expression": "attribute_not_exists(#pkey) AND attribute_not_exists(#skey)", "expressionNames": { "#pkey": "pkey", "#skey": "skey" } } } operation には、PutItem を書きます。これは Amazon DynamoDB に PutItem するぞ、という意思表示です。 アプリから受け取った引数はマッピングテンプレート内では $ctx.args 内に格納されます。今回は input の中に必要なキーや属性をまとめて格納しています。 これで Amazon DynamoDB に PutItem をかけることができます。 レスポンスマッピングテンプレート 結果は配列に格納されます。戻ってきたデータをそのままアプリ側に戻す書き方です。 $utils.toJson($context.result) VTL に関しては以下の AWS 公式ドキュメントも必要に応じてご確認ください。 Resolver mapping template reference for DynamoDB - AWS AppSync Resolver Mapping Template Reference for DynamoDB for AWS AppSync. docs.aws.amazon.com まとめ いかがでしたでしょうか。 PutItem は AWS AppSync のサブスクリプションを使用したいときに必ず使用します。あえて紹介するまでもないと思いましたが、一応紹介させて頂きました。 本記事が皆様のお役に立てれば幸いです。

本記事の内容は、以下のCato Networks社の記事を元に日本語へ意訳、再構成したものとなります。 Cato Software Defined WAN (SD-WAN) Cato Universal Zero Trust Network Access (ZTNA) Catoクラウドの標準サービス機能であるSD-WAN、およびモバイルユーザ（リモートアクセス）のZTNA機能について解説します。 Catoクラウドでは、モバイルユーザ（リモートアクセス）は、ZTNAではなくSDPと言います。 ※SDP･･･Software Defined Perimeter（ソフトウェア定義境界）は、ZTNAの別名で、従来型のリモートアクセスとは異なり、ゼロトラストの原則に則ったセキュアなリモートアクセスです。Catoクラウドのリモート（モバイル）アクセスを意味します。 それでは、SD-WANとZTNA（SDP）について解説します。 Cato SD-WANについて Cato SD-WANは、オンプレミスやクラウド上の拠点やデータセンターに安全で弾力性のある接続性を提供し、これまでの通信キャリアが提供する高価な閉域網を置き換えることができます。ゼロタッチの導入モデルにより、拠点へのロールアウトも迅速かつシンプルに行うことができます。管理者は、アプリケーショントラフィックのパフォーマンスと優先順位付けを包括的に可視化、制御することができます。 あらゆるトランスポート上で最適化された信頼性の高いサイト接続性 CatoのSD-WANエッジデバイスであるCato Socketは、ケーブル、ファイバー、ブロードバンド、セルラーなど複数のインターネット接続を単一の論理トンネルへ集約します。Catoは、アプリケーションプロファイル、優先度、リンクステータスに基づいて、利用可能なリンク上にアプリケーショントラフィックをインテリジェントに誘導します。CatoのSD-WANソフトウェアと複数の冗長トランスポートの組み合わせにより、リンクブラックアウトやブラウンアウトを克服し、これまでは閉域網でしか実現できなかった可用性の高いネットワークサービスを提供することができます。 最も重要なアプリケーションパフォーマンス保証 Cato SD-WANでは、割り当てられた QoSポリシー に基づいてアプリケーションのトラフィックがルーティングされ、優先順位付けされます。Catoは、カスタマイズ可能なアプリケーションの優先順位付けポリシーを提供し、音声、ビデオ、リモートデスクトップなどの遅延の影響を受けやすいアプリケーションが、バックアップなどの帯域幅を必要とするバックグラウンドアプリケーションよりも常に優先的にネットワークにアクセスできるようにします。アプリケーションのパフォーマンスをさらに向上させるため、Catoはラストマイルのインターネット接続とミドルマイルでのパケットロスを克服します。 TCPアクセラレーション は、ネットワークの効率と速度を向上させ、データ転送時間を短縮します。リンク回復力、アプリケーションの優先順位付けと高速化、パケットロスの軽減により、Catoはビジネスクリティカルなアプリケーションを使用する際のユーザーエクスペリエンスを向上させ、生産性を最大化します。 ラストマイルのモニタリングとトラブルシューティング ラストマイル接続の状態を監視することは、パフォーマンスと接続性の問題をトラブルシューティングするために重要です。Cato Socketは、SD-WANトンネルの外側のパフォーマンスを継続的に測定することで、接続されたインターネット回線の品質を自動的に監視します。パケットロス、ラウンドトリップタイム、ホップ数などの詳細なオーバータイム分析が提供され、特定のインターネットサービス回線のパフォーマンス低下を迅速に特定します。インターネット接続の持続的な劣化は、顧客にラストマイルプロバイダーの切り替えや接続設定のアップグレードを促すことができます。 SD-WAN パフォーマンスと使用状況のリアルタイム分析 過去のデータやレポートを使用してリアルタイムのネットワーク劣化をトラブルシューティングすることは困難です。Cato を使用すると、管理者は特定の場所やアプリケーションのジッター、パケットロス、スループット、距離を含むさまざまなメトリクスをリアルタイムで表示できます。リアルタイムの表示により、誤ったアプリケーションの識別や優先順位付け、高帯域幅の消費、定期的な輻輳など、考えられる根本原因を迅速に特定できます。 SLA保証された高速なグローバルプライベートバックボーン グローバル企業は信頼性の高い長距離トランスポートに依存しており、多くの場合、SD-WANと並行してグローバルMPLS契約を維持することを余儀なくされています。 Cato SD-WANは、世界中のCatoのPoPを相互接続する複数のSLA（ 99.999% ）に裏付けされたTier1プロバイダを使用して構築されたCatoのグローバルプライベートバックボーンにネイティブ接続されています。Catoは、MPLSの数分の一のコストで、公衆インターネットよりも優れた予測可能なミドルマイルを構築します。Catoを利用することで、お客様の組織はグローバルプライベートネットワークに即座にアクセスできるようになり、中国を含む世界中のあらゆる場所で、最新のアプリケーションに必要な弾力性とパフォーマンスで、本社、支店、クラウド、さらにはモバイルユーザーを接続することができます。 ゼロタッチデプロイメントによる迅速なインストール Cato Socketのインストールは簡単で、デバイスの事前設定を必要としないため、真のゼロタッチデプロイメントが可能です。Socketは遠隔地にある支店に配送され、専門的な知識がなくても、現地スタッフが数分で配備することができます。電源とインターネットに接続されると、Socketは自動的にCato管理アプリケーションに表示され、サイトに割り当てる準備ができます。Cato Socketはクラウドから完全に管理され、適用されるすべてのポリシーが自動的にダウンロードされます。ゼロタッチモデルは高可用性セットアップに拡張され、2つのCato Socketが同じサイトに割り当てられると、自動的にHAが構成されます。 あらゆる拠点・DCと接続するSD-WANアプライアンス Cato Socketは、小規模な拠点から大規模なオフィス・データセンターまで、様々なユースケースに対応する3つのモデル（X1500/X1600/X1700）があり、単一のトンネルで最大10Gbpsのスループットを提供します。ブランチモデルにはオプションでWi-Fiとセルラー機能が統合されており、ブランチのハードウェアフットプリントを削減し、導入を簡素化します。データセンターモデルはファイバー・ハンドオフをサポートし、デュアル電源を搭載しています。すべてのモデルは、2台のデバイスを使用した高可用性（HA）構成をサポートしています。Cato Socketは、低コストのサブスクリプションベースで提供されるため、時間とコストのかかるハードウェアの更新サイクルが不要で、設備投資も不要です。   Cato ZTNAについて Universal Zero Trust Network Access（ZTNA）により、企業はリスクと最小権限の原則に基づいて企業リソースへの単一のアクセスポリシーを作成し、オフィス、自宅、リモートなど場所に関係なくすべてのユーザーに適用することができます。 どこでも単一のZTNAポリシーを適用 CatoのUniversal ZTNAは、単一のリスクベースのポリシーを使用して、アイデンティティと、デバイスセキュリティポスチャ（Device Security Posture）、ユーザーの地域、アプリケーションのリスク、コンプライアンス評価などのさまざまなアクセスコンテキスト属性を使用して、機密データへのユーザーアクセスを制御します。Catoは、グローバルなクラウドサービスと、オフィス、自宅、遠隔地などの場所に関係なく、すべてのユーザーに一貫してZTNAポリシーを適用します。 継続的なデバイスポスチャ評価 Catoは、接続時およびセッションを通して、オペレーティングシステムとパッチ、アンチウイルス、ディスク暗号化、デバイスファイアウォール、地理的位置、デバイス証明書を含む接続 デバイスポスチャ（Device Posture） を評価します。デバイスポスチャのチェックに失敗した場合、Catoはユーザーの接続を完全に終了させたり、デバイスが準拠するまで特定のリソースへのアクセスをブロックしたりすることができます。継続的なデバイスポスチャ評価により、デバイスが最低限の要件を満たしていることを確認することで、組織のセキュリティポスチャを強化し、侵害されたエンドポイントからのデータ漏えいのリスクを低減します。 一貫したユーザーエクスペリエンスのためのアプリケーション最適化 リモートユーザーから、アプリケーションのパフォーマンスが低下し、生産性に影響が出るという苦情が寄せられることがよくあります。これは通常、信頼性の低いインターネット接続と、セキュリティ検査のために中央ロケーションにトラフィックをバックホールすることが原因です。 Catoクラウドには、堅牢な最適化とQoS機能を備えたグローバルプライベートバックボーンが含まれており、どこからでもクラウドとオンプレミスのリソースに最適化されたアクセスを提供することを目標としています。Catoを利用すれば、Catoクラウドに接続されたリモートユーザーは、オフィスのユーザーと同じように最適化されたアプリケーションアクセスを利用できます。 サードパーティとBYOD向けクライアントレスアクセス Catoは、Catoクライアントをインストールできないユーザのために、 プライベートアプリケーションへのWebブラウザベースのクライアントレスアクセスをサポート しています。管理者は、アプリケーションをWebポータルに簡単に公開し、アクセスポリシーを作成し、どのユーザーに対しても瞬時に安全なアプリケーションアクセスを可能にすることができます。Catoのクライアントレスアクセスは、最小限のセットアップで済み、選択した外部のSSOおよびMFAプロバイダからのセキュアな認証、またはCatoのユーザデータベースを使用して展開できます。 完全なリモートアクセスの可視化と制御 Catoは、リモートユーザーの接続とアクティビティを監視するための専用ダッシュボードを管理者と監査者に提供します。ダッシュボードには、現在接続しているユーザー、その場所、接続元デバイスと接続姿勢、アプリケーションの使用状況分析が表示されます。ワンクリックのフィルタリングにより、関連するネットワーキング、アクセス、セキュリティイベントをユーザーごとに分析し、新しいアクセスポリシーの作成をサポートします。 あらゆるユースケースに対応（社給・BYOD、全OSのサポート） Cato Universal ZTNAクライアントは、 Windows、MacOS、iOS、Android、Linuxをサポート しており、デバイスが企業所有であるかBYODであるかに関係なく、最大限のカバレッジを提供します。管理者がレガシーVPNからCato Universal ZTNAにシームレスに移行できるように、一般的なモバイルデバイス管理（MDM）を介した中央展開がサポートされています。MDMを使用しない外部の請負業者や企業には、ユーザープロビジョニング用のセルフサービスポータルが用意されています。 継続的な脅威防御とデータ保護 Catoは、脅威防御とデータ保護のために、すべてのユーザートラフィックを継続的に評価します。Catoのシングルパスクラウドエンジン（SPACE）は、FWaaS、SWG、IPS、NGAM、CASB、DLP、RBIなどを含む複数のセキュリティエンジンを使用して、ユーザーのセッショントラフィックを検査します。悪意のあるトラフィックや機密データへの不正アクセスは、特定、監査、ブロックされます。Catoは、企業が単一のプラットフォームを使用してリモートアクセス、脅威防御、データ保護の要件に対処できるよう支援し、リモートアクセスのケースをサポートするためにしばしば必要となる複雑なルーティングや統合プロジェクトを回避します。   まとめ Catoクラウドの標準サービス機能であるSD-WANとリモートアクセス ZTNAの記事をご紹介させていただきました。 Catoクラウドに少しでも興味をお持ちになられた方は、遠慮なくSCSKまでお問い合わせください。 SASE、Cato Networks社、Catoクラウド（Cato Cloud/Cato SASE Cloud）自体の知名度もまだまだ低い状況です。 SCSKでは、2021年からSASEの主要ソリューションを一同に紹介を行うオンラインセミナー「SCSK SASE Solution Summit（通称S4 エスフォー）」を定期的に開催しております。これまで14回開催し、1,800名以上の方にご参加いただいております。 S4については、次回は2024年4月以降に開催する予定ですので、改めてご案内します。 来月、2024年3月14日に、Catoクラウドの主要機能を2時間・デモ形式でご覧いただけるセミナーを開催しますので、ご興味のある方は是非ご参加ください。 Catoクラウドデモセミナー～Catoクラウドの主要機能を2時間で網羅～ 本セミナーでは、世界初のSASEである「Catoクラウド」の概要をたっぷり2時間、デモ形式でご覧いただきます。 また、ご希望の方（先着10名様）は、デモ環境に対して、お手元の環境からハンズオン形式でCatoクラウドに触れて頂くことが可能な参加型セミナーです。 www.scsk.jp SASE、Catoクラウドセミナー以外に、Catoクラウドのお客様導入事例の制作、FAQサイト運営、この TechHarmony（技術ブログ）で、皆様のお役に立て、Catoクラウドの知名度アップに少しでも貢献できればと考えております。

Cato クラウドには TCP Acceleration という機能があり、この機能は Cato クラウド経由で行う TCP 通信を高速化するための機能です。この機能にどの程度効果があるのか気になりましたので、実際に測定を行ってみました。 TCP 通信が遅くなる原因 インターネット回線を敷設して十分な帯域を契約しているのに、期待するほどスループットが出ないといった経験をお持ちではないでしょうか？ 利用しているネットワーク機器や通信相手の帯域・混雑が原因でスループットが出ないことがありますが、それ以外の原因でスループットが出ないこともあります。特に、海外との間で大きなデータを送受信する際に数 Mbps のスループットになってしまうようなケースがあり、これは TCP の通信特性が原因であることが多いです。 TCP は信頼性のある通信プロトコルであり、受信確認 (ACK) と再送の仕組みによりパケットロスが発生しても確実にデータを届けることができるようになっています。このとき、1つのパケットを送信して受信確認が返ってきてから次のパケットを送信するというのでは通信効率が非常に悪いため、受信ウィンドウ (Window) というパラメータを受信者が指定することで一定量のパケットをまとめて送信・受信確認する仕組みも用意されています。 さらに、TCP の実装 (Windows、macOS、Linux などの OS) はネットワーク上での輻輳発生を防ぐために輻輳ウィンドウ (Congestion Window) を動的に変更して送信量を制御する仕組みを持っており、輻輳が発生しない範囲で効率的な通信を行えるようにもなっています。各ウィンドウのサイズがどのように変動して定まるかについては複雑なのでここでは説明せず一部後述するに留めますが、メモリサイズの上限、パケットロスの発生、レイテンシの変動などによって定まるものと理解ください。 TCP のスループットはパケットロスや輻輳が無ければ「ウィンドウサイズ ÷ RTT」という式で概ね近似できます。例えば、ウィンドウサイズが 64KB で RTT が 5ms の場合、102.4Mbps (64 / 1000 * 8 / 0.005) となります。通信を行う2点間の距離が遠いほど RTT が大きくなりますので、スループットは反比例して低くなっていきます。ウィンドウサイズを大きくすればスループットは高くなりますが、輻輳が発生するとパケットロスやレイテンシの悪化によって輻輳ウィンドウサイズが小さくなるため、制限なく大きくできるということはありません。 こういった TCP の通信特性により、海外との通信ではスループットが期待するほど高まらないという結果に繋がります。 TCP Acceleration 機能が通信を速くする仕組み Cato クラウドの TCP Acceleration 機能は、2点間の TCP 通信を複数の TCP 通信に分割することで実現されています。Knowledge Base の次のページにも仕組みが記載されていますので、そちらもご参照ください。 Explaining the Cato TCP Acceleration and Best Practices Accelerating and Optimizing Traffic ここでは例として、アメリカ東海岸に出張した社員が Cato クライアントで Ashburn_DC2 PoP に接続し、Tokyo_DC2 PoP に接続された日本国内の拠点にある社内サーバにアクセスするケースで説明します。 通常は出張した社員の PC と社内サーバとの間で1つの TCP 通信が行われますが、TCP Acceleration 機能が有効だと次の3つの TCP 通信に分割されます。 出張した社員の PC と Ashburn_DC2 PoP の間の TCP 通信 社内サーバと Tokyo_DC2 PoP の間の TCP 通信 Ashburn_DC2 PoP と Tokyo_DC2 PoP の間の TCP 通信 1と2の通信は比較的近距離で行われ、RTT は数ミリ秒程度なので高速な通信を行えます。 3の通信は日本とアメリカ東海岸の間で行われる遠距離通信で、インターネット経由だと RTT は 150ms 以上あります。この通信は Cato のプライベートバックボーン上で行われ、インターネットで通信するよりも低レイテンシで信頼性の高いネットワークとなっているようです。 TCP Acceleration 機能を利用するとスループットに影響を与える RTT は3の TCP 通信の値になって小さくなりますので、全体としてスループットの高速化が実現されています。 効果測定 TCP Acceleration 機能が実際にどの程度効果があるのか測定してみました。 測定環境 効果測定にあたり Amazon EC2 の東京リージョンとバージニア北部リージョン (アメリカ東海岸) にそれぞれ1台ずつ Linux マシンを用意し、バージニアから東京に向けてトラフィックを流すような測定を行いました。ここでは便宜上、東京のマシンをサーバ、バージニアのマシンをクライアントと呼ぶことにします。 また、測定のために、スループットやレイテンシの測定によく利用されるツールである iperf2  を利用しました。 測定パターン 測定パターンは次の5つです。 インターネットだけを用いた通信 Cato クラウドの WAN 通信 (TCP Acceleration 機能あり) Cato クラウドの WAN 通信 (TCP Acceleration 機能なし) クライアントマシンは Ashburn_DC2 PoP に接続し、その PoP からインターネット経由でサーバマシンに通信 (TCP Acceleration 機能あり) クライアントマシンは Ashburn_DC2 PoP に接続し、Tokyo_DC2 PoP からインターネット経由でサーバマシンに通信 (TCP Acceleration 機能あり) TCP Acceleration 機能を有効にするかどうかは CMA (Cato 管理画面) の [Network] – [Network Rules] の設定画面で変更でき、”Voip Voice” カテゴリ (Zoom や SIP など音声通信系のアプリケーション) 以外の通信では TCP Acceleration 機能がデフォルトで有効となっています。 これに加えて、3の測定を行う前には TCP Acceleration 機能を無効にする次のような Network Rule を追加しました。 また、Cato クラウド経由でインターネットアクセスを行う場合、通常は接続した PoP からインターネットに通信が行われますが、5の測定を行う前に Tokyo_DC2 PoP からインターネットに通信が行われるようにする Network Rule も追加しました。 測定指標 測定した指標は次の4つです。 ping を用いた RTT トラフィック無制限時の平均スループットと、そのときの最大レイテンシ 少量トラフィック (2Mbps) を流したときの最大レイテンシ 測定結果 各測定パターンについて1度ずつ測定した結果は次の通りとなりました。 測定パターン ping による RTT 無制限時の平均スループット 無制限時の最大レイテンシ 少量スループット時の最大レイテンシ 1 165ms 68.6Mbps 246ms 83.6ms 2 159ms 153Mbps 1900ms 132ms 3 同上 9.61 Mbps 296ms 763ms 4 163ms 75.2Mbps 1619ms 131ms 5 161ms 183Mbps 1796ms 136ms 今回の環境では、インターネットだけを用いたとき (測定パターン1) は開始から10秒後にスループットが 80Mbps 程度まで上昇し、その後はその速度で安定して通信できていました。上記の測定とは別で UDP を用いてさらにトラフィックを流してみたところ、1Gbps のトラフィックも問題なく流せましたので、それと比べると TCP のスループットは低いです。インターネット回線で長距離通信なので高トラフィックを流すとパケットロスが発生しやすく、1Gbps の UDP トラフィックでは 1.5% 程度、100Mbps だと 0.011% 程度発生しましたので、パケットロスも影響して TCP のスループットが低くなっているものと考えられます。 TCP Acceleration 機能を有効にした WAN 通信 (測定パターン2) やインターネット通信 (測定パターン5) を見ると、スループットは2倍以上に上昇しています。時間的な変動があり安定した速度ではありませんでしたが、有意に速くなっています。ただし、TCP 通信が3つに分割されたことや Cato クラウドによるトラフィック検査などの影響もあり、レイテンシが増えてしまっています。無制限時の最大レイテンシは見かけ上かなり大きくなっているだけなので特に気にしなくても良いですが、少量スループット時のレイテンシが 83.6ms から 50ms 程度大きくなっている点は利用者の体感にもいくらか影響を与えるものかもしれません。 測定パターン2と3を比較すると、TCP Acceleration 機能を無効にしたパターンは非常に悪い値となってしまっています。測定パターン3は1と同程度の値となると予想していたため、予想外の結果でもあります。通常は無効化することはない設定を無効化したためにこのような結果になったのかもしれません。 測定パターン4と5は日本とアメリカ東海岸の間でインターネットを経由するか Cato クラウドのバックボーンを経由するかの違いですが、バックボーン経由のほうが有意に良い結果となっています。ただし、パターン1と4を比較するとわずかにスループットが上昇しており、TCP Acceleration 機能というよりも Cato クラウドを利用することで通信が高速化したと言えるかもしれません。 Cato クラウドの輻輳制御に関して 前項の効果測定において、Cato クラウドのプライベートバックボーンを通るパターン (2,5) はそうでないパターン (1,4) に比べてスループットが2倍以上になっています。しかし、RTT は日米間の物理的な距離の影響が大きいため、わずかに減少しているだけです。そこで「ウィンドウサイズ ÷ RTT」というスループットの近似式を改めて見つめなおすと、RTT の減少ではなくウィンドウサイズの増加によってスループットが上昇したものと考えられます。 ウィンドウのうち、輻輳ウィンドウは TCP 通信で用いる輻輳制御アルゴリズムの種類によって異なる変動をします。Windows、macOS、Linux の現在主流のバージョンでは、デフォルトの輻輳制御アルゴリズムとして CUBIC が採用されています。このアルゴリズムはパケットロスが発生しない間はウィンドウを増加させ、パケットロスが発生するとウィンドウを減少させることで、輻輳が発生しない状態を維持しつつ極力多くのデータを送信するというものです。 一方、Cato クラウドでは輻輳制御アルゴリズムとして BBR の利用が推奨されており、各テナントの CMA の [Administration] – [Advanced Configuration] の中で BBR を利用するようデフォルト設定されています。 BBR はパケットロスではなくレイテンシを指標とし、レイテンシが悪化しない程度までウィンドウを増加させるアルゴリズムです。ただし、ネットワーク状況によってレイテンシが悪化することがあるため、定期的にウィンドウを最小に戻すという操作も行われます。 効果測定の結果や輻輳制御アルゴリズムの違いを踏まえると、Cato クラウドのプライベートバックボーン中では大きなトラフィックを流してもレイテンシが悪化しにくくなるような何らかのトラフィック制御が行われているものと推測されます。 まとめ 測定結果から、TCP Acceleration 機能に効果があることが確認できました。特に、物理的に距離が離れた通信で Cato クラウドのネットワークを経由するような形で TCP Acceleration を有効にすると、スループットが2倍以上に上昇するのは期待以上の効果でした。 インターネットとの通信において TCP Acceleration を適切に機能させるには、通信先のサーバと近い PoP からインターネットに出ていくように Network Rule を設定する必要がありましたので、この点は要注意です。 日本国内の TCP 通信については TCP Acceleration の仕組みや TCP 通信の特性上あまり効果は期待できず、測定により Cato クラウドのネットワークに負荷をかけることになってしまうため、今回は測定しませんでした。逆に、日本国内の通信における TCP Acceleration 機能を無効化することでパフォーマンスをチューニングできるのかどうかについては気になるところではありますので、機会があれば試すかもしれません。 Skeed 高速ファイル転送ソリューションのご紹介 今回のように日本と海外との間の通信を高速化するソリューションとして、弊社のグループ会社である Skeed 社もご紹介します。 Skeed高速ファイル転送ソリューション | 株式会社Ｓｋｅｅｄ 日米欧で特許取得した独自技術をベースに、遠距離間での大容量ファイル転送を高速かつ安全・確実、簡単に実現するSkeedの高速ファイル転送ソリューション。転送シミュレーションや比較優位性をご紹介します。 skeed.jp このソリューションは大容量ファイルの転送に特化したものであり、TCP 通信の課題を UDP 通信によって乗り越えるというものです。一般的な通信に向けたものではありませんが、日本と海外との間で大容量ファイル（映像データ、ビッグデータ、データベースのバックアップデータなど）をやり取りしたいという際には、このソリューションもご検討いただければ幸いです。

こんにちは、広野です。 AWS AppSync を使用したアプリケーションを開発する機会があり、リゾルバ、主に VTL の書き方に関してまとまった知識が得られたので紹介します。前回からの続きもので、Query の書き方を紹介します。 本記事では、VTL の書き方にフォーカスしています。ご了承ください。 AWS AppSync、リゾルバ、VTL の説明については以下の記事をご覧下さい。 AWS AppSync リゾルバ (VTL) の書き方サンプル No.1 - Amazon DynamoDB GetItem Amazon DynamoDB に VTL で GetItem をかけるときの基本的な書き方を紹介します。 blog.usize-tech.com 2024.01.09 AWS AppSync リゾルバ (VTL) の書き方サンプル No.2 – Amazon DynamoDB BatchGetItem Amazon DynamoDB に VTL で BatchGetItem をかけるときの基本的な書き方を紹介します。 blog.usize-tech.com 2024.01.19 AWS AppSync を使って React アプリからキックした非同期ジョブの結果をプッシュ通知で受け取る 非同期ジョブを実行した後、結果をどう受け取るか？というのは開発者として作り込み甲斐のあるテーマです。今回は React アプリが非同期ジョブを実行した後に、AWS AppSync 経由でジョブ完了のプッシュ通知を受け取る仕組みを紹介します。 blog.usize-tech.com 2022.12.01 Amazon DynamoDB に Query する VTL 例えば、AWS AppSync から以下のリクエストを受けたとします。Amazon DynamoDB には適切なデータがある想定です。テーブル名はリゾルバの別の設定 (Data Source) で行います。 引数となるパラメータ：　パーティションキー pkey、ソートキー skey 必要なレスポンス：　パーティションキーにマッチし、ソートキーのパラメータとして渡された文字列から始まるデータ全て 今回は受け取ったパーティションキーとソートキーのパラメータをもとに、Query の条件に当てはめます。ソートキーは begins_with のキー条件式を使用します。このサンプルでは、最大 30 件のデータのみ取得するようにしています。 リクエストマッピングテンプレート { "version": "2018-05-29", "operation": "Query", "query": { "expression": "#pkey = :pkey AND begins_with (#skey, :skey)", "expressionNames": { "#pkey": "pkey", "#skey": "skey" }, "expressionValues": { ":pkey": $util.dynamodb.toDynamoDBJson($context.arguments.pkey), ":skey": $util.dynamodb.toDynamoDBJson($context.arguments.skey) } }, "limit": $util.defaultIfNull($context.arguments.first, 30), "nextToken": $util.toJson($util.defaultIfNullOrEmpty($context.arguments.after, null)), "consistentRead": false, "select": "ALL_ATTRIBUTES" } operation には、Query を書きます。これは Amazon DynamoDB に Query するぞ、という意思表示です。 アプリから受け取った引数はマッピングテンプレート内では $context.arguments 内に格納されます。 pkey や skey というアイテム名であれば問題はないのですが、DynamoDB の予約語がアイテム名になっている場合は必ず # や : を使用してエスケープのような処理をしないとクエリが動作しません。おまじない的に、このように書くことをお勧めします。 これで Amazon DynamoDB に Query をかけることができます。 レスポンスマッピングテンプレート 結果は配列に格納されます。戻ってきたデータをそのままアプリ側に戻す書き方です。 $utils.toJson($context.result) VTL に関しては以下の AWS 公式ドキュメントも必要に応じてご確認ください。 Resolver mapping template reference for DynamoDB - AWS AppSync Resolver Mapping Template Reference for DynamoDB for AWS AppSync. docs.aws.amazon.com まとめ いかがでしたでしょうか。 Query は非常によくオペレーションで、キー条件式をいろいろ変えて使うことが多いと思います。あえて紹介するまでもないと思いましたが、一応紹介させて頂きました。 本記事が皆様のお役に立てれば幸いです。