TECH PLAY

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

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

1268

こんにちは、広野です。 React アプリに Amazon Bedrock に問い合わせる画面をつくってみたのでコードを紹介します。よくある生成系 AI チャットボットのように、回答文が作成されながら表示されるやつです。↓ アーキテクチャ 生成系 AI の基盤モデルには、Amazon Bedrock の Anthropic Claude 2.1 を使用しています。 Amazon Bedrock に問い合わせるのは AWS Lambda 関数 (Node.js 20) です。 AWS Lambda 関数は関数 URL を持たせており、React アプリから直接呼び出します。 AWS Lambda 関数からのレスポンスはレスポンスストリーミング対応にしています。それにより、Amazon Bedrock が回答を作成しつつ、レスポンスを画面に表示できるようにしています。Amazon Bedrock を呼び出す API はレスポンスストリーミング対応のInvokeModelWithResponseStreamCommand を使用しています。 補足ですが、React アプリから AWS Lambda 関数 URL を認証付きで呼び出す構成は以下参考記事の構成にしています。本記事では説明を割愛します。 やってみたら面倒くさい、React アプリからの Amazon Cognito 認証付き AWS Lambda 関数 URL 呼出 Amazon Cognito 認証を施した React アプリから、認証済みユーザのみ AWS Lambda 関数を呼び出せるようにする React コードを紹介します。 blog.usize-tech.com 2024.01.15 AWS Lambda 関数コード AWS Lambda 関数に関数 URL を持たせる設定や、レスポンスストリーミングを有効にする設定は以下 AWS 公式ドキュメントを参照ください。この点において難しいことはありません。 Lambda 関数 URL の作成と管理 - AWS Lambda Lambda 関数の URL を設定して、他の AWS のサービスとの統合を必要とせずに、HTTP エンドポイントを Lambda 関数に割り当てます。 docs.aws.amazon.com ストリームレスポンスに Lambda 関数を設定する - AWS Lambda レスポンスをストリーミングする Lambda 関数を作成します。 docs.aws.amazon.com 難しいのは関数コードです。 invokeModelWithStreamResponseCommand の API が Amazon Bedrock からのレスポンスを chunk 分割された状態で受け取るので、chunk ごとに React アプリへのレスポンス用ストリーム responseStream に放り込んで (write) います。レスポンスは Blob なので、途中で人が読み取れるテキストデータに変換する処理が入っています。 const { BedrockRuntimeClient, InvokeModelWithResponseStreamCommand } = require("@aws-sdk/client-bedrock-runtime"); const bedrock = new BedrockRuntimeClient({region: "ap-northeast-1"}); exports.handler = awslambda.streamifyResponse(async (event, responseStream, _context) => { try { console.log((JSON.parse(event.body)).prompt); const prompt = (JSON.parse(event.body)).prompt; if (prompt == '') { responseStream.write("No prompt"); responseStream.end(); } const enclosed_prompt = "\n\nHuman: " + prompt + "\n\nAssistant:"; const body = { "prompt": enclosed_prompt, "max_tokens_to_sample": 3000, "temperature": 0.5, "top_k": 250, "top_p": 1, "stop_sequences": ["\n\nHuman:"], "anthropic_version": "bedrock-2023-05-31" }; const input = { modelId: 'anthropic.claude-v2:1', accept: 'application/json', contentType: 'application/json', body: JSON.stringify(body) }; const command = new InvokeModelWithResponseStreamCommand(input); const res = await bedrock.send(command); const actualStream = res.body.options.messageStream; const chunks = []; for await (const value of actualStream) { const jsonString = new TextDecoder().decode(value.body); const base64encoded = JSON.parse(jsonString).bytes; const decodedString = Buffer.from(base64encoded,'base64').toString(); try { const streamingCompletion = JSON.parse(decodedString).completion; chunks.push(streamingCompletion); responseStream.write(streamingCompletion); } catch (error) { console.error(error); responseStream.write(null); responseStream.end(); } } //log entire chunks 結合されたレスポンス。今後履歴データとしてDynamodBに放り込む予定 console.log("stream ended: ", chunks.join("")); responseStream.end(); } catch (error) { console.error(error); responseStream.write("error"); responseStream.end(); } }); Python を採用していない理由は、AWS 公式ドキュメントにもありますが AWS Lambda 関数がレスポンスストリーミングをネイティブにサポートしているランタイムが Node.js のみだからです。※執筆時点 Node.js のコードを ES2015 (ES6) 構文にしていない理由は、私が AWS Lambda 関数を AWS CloudFormation でデプロイしていることに起因しています。AWS CloudFormation で Node.js の Lambda 関数をデプロイすると Lambda 関数コードファイルの拡張子が .js になってしまうため、ES2015 を使用できない (CommonJS 一択になる) のです。まあ他の方法でデプロイしろよって話なのですが、CFn テンプレート一撃で全アプリ環境を作りたいのでそこにこだわっております・・・。 React コード React アプリ側は、Lambda 関数 URL を呼び出すために fetch を使用します。レスポンスストリーミング対応にするには fetch が良いのだとか。 AWS Lambda 関数 URL から chunk 分割されたレスポンスが送られてくるので、それを順次、直前の chunk と繋げて state に突っ込むだけの、非常に原始的なループのコードです。もっと簡単かつ効率的な処理になる SDK を AWS が開発してくれることを期待しております。SSR 対応フレームワーク限定になってしまうのかもですが。 //レスポンス表示用state const [response, setResponse] = useState(""); //送信したいプロンプト const body = { prompt: prompt }; //Lambda関数URL呼出 try { const res = await window.fetch( "https://xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.lambda-url.ap-northeast-1.on.aws", { method: 'POST', body: JSON.stringify(body), headers: signedRequest.headers //認証用の署名(説明割愛) } ); const reader = res.body.getReader(); const decoder = new TextDecoder(); const sleep = ms => new Promise(resolve => setTimeout(resolve, ms)); while (true) { const { value, done } = await reader.read(); if (done) break; const chunk = decoder.decode(value, { stream: true }); if (chunk) { setResponse(prevData => prevData + chunk); } await sleep(100); //100msごとに届いたchunkを処理(=画面更新) } } catch (error) { console.error('Error fetching:', error); } sleep のミリ秒数を調整することで、受け取ったレスポンス文章表示の流暢さを調整できます。 まとめ いかがでしたでしょうか。 レスポンスストリーミングの仕組みが未だ根本的に理解できていませんが、経験を積んで理解を深めたいと思います。今回は参考になるドキュメントが少なくて苦労しました。 本記事が皆様のお役に立てれば幸いです。
こんにちは。自称ネットワーク技術者の貝塚です。SCSKでAWSの内製化支援『 テクニカルエスコートサービス 』を担当しています。 業務でヤバいくらいお世話になっているひつじちゃんがVPCエンドポイントについての記事を書いていました。 Amazon VPC エンドポイントについて整理してみる VPC エンドポイントの役割について説明したいと思います。 blog.usize-tech.com 2023.12.10 ひつじちゃんリスペクト記事として、VPCエンドポイントに関する役立ちそうで役立たない豆知識を書きます。 問題 インターフェース型のエンドポイントの IPはプライベート となります。 ( Amazon VPC エンドポイントについて整理してみる より引用) とありますが、プライベートIPアドレスがつけられたエンドポイント(例えばSystems Manager用のインターフェース型エンドポイント)に、VPC内のEC2インスタンスなどがアクセスできているのはどうしてでしょうか? 答え Route 53 Resolverが返すIPアドレスが書き換わっているから。 解説 Route 53 Resolverとは、Amazon Provided DNSなどとも呼ばれる、EC2インスタンスを作成したときにデフォルトで指定されているDNSのことです。 さて、AWSの各種サービスにアクセスするためのインターフェース型エンドポイントにはDNS名がついています。 たとえばec2messagesサービスの場合はこうです。 ec2messagesインターフェース型エンドポイントが ない VPCからこの名前を解決してみると以下のようになります。 [ec2-user@ip-10-32-1-157 ~]$ dig ec2messages.ap-northeast-1.amazonaws.com (略) ;; ANSWER SECTION: ec2messages.ap-northeast-1.amazonaws.com. 58 IN A 52.119.223.180 (略) グローバルIPアドレスが返ってきています。 ec2messagesインターフェース型エンドポイントが ある VPCから名前解決するとこうなります。 [ec2-user@ip-10-33-1-124 ~]$ dig ec2messages.ap-northeast-1.amazonaws.com (略) ;; ANSWER SECTION: ec2messages.ap-northeast-1.amazonaws.com. 32 IN A 10.33.1.68 (略) VPC内のIPアドレスが返ってきます。 このようにDNSの名前解決の仕組みによって、本来インターネット上にあるAWSのサービスエンドポイントを、利用者が意識することなくVPC内の通信にしてくれているわけです。 インターネットゲートウェイがなくてもとりあえずVPC内にssmとssmmessagesとec2messagesのエンドポイントを作っておけばSession ManagerでEC2インスタンスにログインできるようになる、とおまじないのように覚えている方の理解を深める一助になれば幸いです。 役に立たない豆知識 インターフェース型エンドポイントは、どこのVPCからの通信か、とか気にしてないので、たとえばVPCピアリングしたお隣のVPCにいるEC2インスタンスのhostsにこんな感じで書いてあげれば、お隣VPCのインスタンスにもSession Managerで接続できるようになります。 [ec2-user@ip-10-32-1-157 ~]$ cat /etc/hosts 127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 ::1 localhost6 localhost6.localdomain6 # Added for connection to VPC interface endpoints 10.33.1.68 ec2messages.ap-northeast-1.amazonaws.com 10.33.1.138 ssmmessages.ap-northeast-1.amazonaws.com 10.33.1.21 ssm.ap-northeast-1.amazonaws.com いちいちこれ設定するくらいなら各VPCにエンドポイント作った方が面倒がなくてよくない?というのはあります……。 それではご査収ください。
こんにちは、広野です。 AWS Lambda 関数 URL がサポートしているレスポンスストリーミングを使用したくて、React アプリから Amazon Cognito ID プール (フェデレーテッドアイデンティティ) の一時的なクレデンシャルを取得し IAM 認証付きの AWS Lambda 関数 URL を呼び出せるようにしようとしたところ、激ハマリしました。 やりたいことは↓コレなんですが、一時的なクレデンシャルを取得して以降の Lambda 関数 URL 呼出に関する AWS 公式情報が具体的なものがなく、ネット上の有志の方のブログ情報を見ても環境の違いやモジュールのバージョン違いのためそのままでは動かず、苦労しました。 認証情報の取得 - Amazon Cognito Amazon Cognito を使用して権限が制限されている一時的な認証情報をアプリケーションに提供し、ユーザーが AWS リソースにアクセスできるようにすることが可能です。このセクションでは、認証情報を取得する方法と、ID プールから Amazon Cognito ID を取得する方法について説明します。 docs.aws.amazon.com Lambda 関数 URL におけるセキュリティと認証モデル - AWS Lambda リソースベースのポリシーに加え AuthType パラメータを使用して、Lambda 関数 URL へのアクセスを保護および制限します。 docs.aws.amazon.com 以降、動いたコードなどを紹介します。 あらためて、やりたいこと React アプリに Amazon Cognito でユーザ認証する。 認証済みユーザに、AWS Lambda 関数 URL を呼び出せる権限を付与する。(AWS IAM ロールによる) React アプリから、AWS Lambda 関数 URL を呼び出す。 これにより、アプリの認証済みユーザだけが AWS Lambda 関数 URL を呼び出せることになるので、セキュアな仕組みを構築できます。AWS Lambda 関数 URL は CORS もサポートしていますし、アクセスが少なく重要度の低いビジネスロジックであれば API Gateway は不要になります。 (余談) 関数 URL は Amazon API Gateway と違って IPv6 もサポートしています。Amazon CloudWatch Logs に残した AWS Lambda 関数のログを見ると、アクセス元デバイスの IPv6 アドレスが残っていました。AWS WAF はアタッチできないのと、スロットリングとかはできないのでそういう要件が必要になると Amazon API Gateway と統合しないとです。 参考までに、同様の構成で「Amazon Cognito 認証済みユーザのみが Amazon S3 バケットに書き込める」構成を以下ブログに書いておりましたが、このときは AWS が Amazon S3 に書き込むための SDK を用意してくれていたので簡単でした。 AWS Amplify Storage を AWS CloudFormation でマニュアルセットアップする サーバーレス WEB アプリ (SPA) から、ファイルをバックエンドにアップロードして処理したいことがあります。AWS Amplify と連携させた Amazon S3 バケット「AWS Amplify Storage」を使用すると、アプリとセキュアに連動したストレージを簡単に作ることができます。 blog.usize-tech.com 2022.05.31 Amazon Cognito ID プールから払い出される IAM ロールに AWS Lambda 関数 URL を呼び出す権限をどのように付けるかは、以下に書いてあるように、”Action”: “lambda:InvokeFunctionUrl” を許可してあげれば OK なので簡単です。 Lambda 関数 URL におけるセキュリティと認証モデル - AWS Lambda リソースベースのポリシーに加え AuthType パラメータを使用して、Lambda 関数 URL へのアクセスを保護および制限します。 docs.aws.amazon.com 続いて AWS Lambda 関数 URL を呼び出す情報は以下に書いてあるんですが、「いや、聞きたいのはそんなことじゃなくてね・・・もちょっと具体的なコードを教えてくれない?」って思う内容でして。 Lambda 関数 URL の呼び出し - AWS Lambda ウェブブラウザ、curl、Postman、または任意の HTTP クライアントを使用して、専用の HTTP エンドポイントを介して Lambda 関数を呼び出します。 docs.aws.amazon.com ドキュメントを読んで何がわからないかと言うと。 関数 URL が AWS IAM 認証を使用する場合、リクエストには AWS Signature Version 4 (SigV4) による署名が必要。 って何? ここについて、実用的な説明がないんですね。細かい、内部仕様?の説明はあるんですが、私の実力ではそれだけじゃコードに落とせなくて。Amazon S3 に書き込むときには、この部分を Wrap した SDK を AWS が用意してくれていたので署名について何も意識せずに済んでいたのです。 で、ネット上をめっちゃ調べて、何とか動くようになった React コードを紹介します。(前置き長っ) 動いた React コード 執筆時点の React モジュール環境は以下です。今後、バージョンアップ等で動かなくなる可能性大です。 react 18.2.0 aws-amplify 6.0.12 axios 1.6.5 @smithy/protocol-http 3.0.12 @smithy/signature-v4 2.0.19 @aws-crypto/sha256-universal 5.2.0 ちなみに本記事ではアプリ稼働環境に AWS Amplify Console は使っていませんが、Amplify 関連モジュールはあくまでもモジュールなので使えます。 import { fetchAuthSession } from 'aws-amplify/auth'; import { HttpRequest } from '@smithy/protocol-http'; import { Sha256 } from '@aws-crypto/sha256-universal'; import { SignatureV4 } from '@smithy/signature-v4'; import axios from 'axios'; const sample = async () => { //Lambda関数URLを指定 const apiUrl = new URL("https://xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.lambda-url.ap-northeast-1.on.aws"); //Cognito ID プールから一時的なクレデンシャル(IAMアクセスキー等)を取得 const { credentials } = await fetchAuthSession(); //このあたりからが、SigV4 署名をするコード。以下のパラメータは絶対必須。 const signer = new SignatureV4({ service: 'lambda', region: 'ap-northeast-1', credentials: { accessKeyId: credentials.accessKeyId, secretAccessKey: credentials.secretAccessKey, sessionToken: credentials.sessionToken }, sha256: Sha256 }); //Lambda関数に POST したいパラメータ const body = { test: 'test' }; //以下も変更不可。POSTの場合bodyを含めないとAWS側で署名をverifyしたときにエラーになる。 const httpRequest = new HttpRequest({ headers: { 'Content-Type': 'application/json', 'Host': apiUrl.hostname }, hostname: apiUrl.hostname, method: 'POST', protocol: 'https:', path: apiUrl.pathname, body: JSON.stringify(body) }); const signedRequest = await signer.sign(httpRequest); //axiosでLambda関数URLを呼び出す。改めてbodyに加え、署名済みのヘッダー情報を付加する。 const res = await axios.post( "https://xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.lambda-url.ap-northeast-1.on.aws", body, { headers: signedRequest.headers } ); //とりあえずレスポンス確認だけ console.log(res); }; 前提として、App.js 等に Amplify.configure で Amazon Cognito ユーザープールと ID プールの情報を定義できていないと、fetchAuthSession が機能しません。 Set up Amplify Auth - React - AWS Amplify Documentation Amplify uses Amazon Cognito as the main authentication provider. Learn how to handle user registration, authentication, account recovery and other operations. A... docs.amplify.aws ちなみに axios ではなく fetch を使う場合は以下の記述になります。axios と入れ替える部分だけ紹介します。AWS Lambda のストリームレスポンスを使用する場合は fetch でないと動作しないようです。 const res = await window.fetch( "https://xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.lambda-url.ap-northeast-1.on.aws", { method: 'POST', body: JSON.stringify(body), headers: signedRequest.headers } ); 紹介したコードには固定値が入ってしまっているので適宜修正ください。 まとめ いかがでしたでしょうか。 AWS Lambda 関数 URL を使えば Amazon API Gateway はいらなくなるぞー、と息巻いていたのですが、Amazon API Gateway の Cognito オーソライザーと同等の認証をしようとすると やたらめんどくさい w。AWS がそれ用の SDK を出してくれることを待っております・・・。 本記事が皆様のお役に立てれば幸いです。
Catoクラウドのモバイル接続では、接続できる端末を制限したい場合(例.会社支給の端末に限りたいなど)の機能として、 デバイス認証(Device Authentication)機能 があります。 指定した電子証明書(デバイス証明書、別名クライアント証明書)がインストールされている端末からのみ、Catoクラウドへの接続を許可する 機能で、Catoクライアントが対応するすべてのOS(※)にて利用可能です。 ※ Windows, macOS, iOS(iPhone/iPad), Android, Linux デバイス認証は多くのお客様で利用いただいている機能ですが、導入時の注意点がいくつかあります。そこで、この記事ではデバイス認証の概要と設定の流れ、各OSでの注意点などをご紹介します。 前提と制約 Catoクラウドのデバイス認証には、以下の前提および制約がありますので、ご留意ください。 前提 デバイス認証機能は、Catoクライアントでの接続時に、その端末にインポートされているデバイス証明書(クライアント証明書)が、Catoの管理画面(CMA)にアップロードされている認証局証明書(CA証明書)で、検証(Verify)できるかどうかを判定し、OKであれば接続を許可する機能です。 Catoクラウドでの制約 以下は2024年1月時点の仕様です。Catoクラウドは毎週機能拡張されているため、以下の内容についても、今後機能強化される可能性があります。 ユーザまたはデバイスと証明書の紐づけ情報は保持していません。このため、 同じデバイス証明書を複数ユーザ・複数端末が利用していても、認証OK となります。 証明書失効リスト(CRL)には対応していません。 認証局にて対象のデバイス証明書を失効させても、Catoクラウドのデバイス認証機能には影響せず、認証OKとなります。 端末がSocketの配下にいるとき(=Catoクライアントによるユーザ認証が行われないとき)には、デバイス認証機能による証明書確認は行われません。 Catoクラウドにアップロードできる認証局証明書(CA証明書)の上限は5つです。6つ以上の認証局を利用することはできません。 サポートされている認証局証明書(CA証明書)の最大ファイルサイズは4096byteです。 サポートされているデバイス証明書(CRTファイル)の最大ファイルサイズは2048byteです。 ※ .p12ファイルのサイズではなく、その元となる.crtファイルの制限です デバイス証明書の準備 まずは、認証に使用するデバイス証明書(=クライアント証明書)を準備します。 証明書の発行方法 証明書の発行方法は、大きく分けて2つあります。 自前の認証局から証明書を発行する 証明書発行サービスを利用する 1. 自前の認証局から発行する 社内のActive DirectoryにてADCS(Active Directory Certificate Services)機能を使って発行する方法や、OpenSSLを利用しプライベート認証局を構築して発行する方法などがあります。 安価に構築可能ですが、認証局の管理・運用を自分で行う必要があります。 2. 証明書発行サービスを利用する 有償のサービスを利用する方法です。「クライアント証明書発行サービス」などで検索するといくつかのサービスが見つかります。提供元で認証局を管理しており、利用者は管理画面からの簡単な操作でデバイス証明書を発行できるサービスです。利用者が認証局を管理しなくて良いため、手軽に利用できます。 サービス選定のポイントは、認証局がセキュアに管理されている、信頼できるサービス提供元を選ぶこと、また、提供元によって価格体系が異なる(証明書×費用、ユーザ数×費用、等)ため、必要な証明書の数と費用感を比較検討することです。 なお、Catoクラウドでは前述のとおり、ユーザとデバイスの紐づけや、失効リストに対応していないため、証明書発行サービスの機能を十分には生かせない点をご了承ください。 各端末へのデバイス証明書配布 デバイス証明書が準備できたら、各端末へ配布し、インポートします。 配布方法は様々ですが、端末が多い場合の配布手段として、端末管理システムやMDM経由で配布する、Active Directoryからグループポリシーで適用するなどの方法があります。 また、OSごとにインポート時の注意点がありますので、以下にご説明します。 全OS共通の準備 端末へ配布する デバイス証明書は .p12形式 で準備します。OSバージョンによってはインポートパスワードが必須なものがあるため、 インポートパスワードを設定 しておきます。 Windowsの注意点 Catoクライアントはデバイス認証の際、「ローカル コンピューター > 個人」にある証明書を参照します。このため 証明書をインポートする際は必ず、保存場所に「ローカル コンピューター」を、証明書ストアに「個人」を指定 してください。 MacOSの注意点 対象のデバイス証明書が、 キーチェーンアクセスの「ログイン」 にインポートされている必要があります。 インポート後、以下の画面例のように「証明書が信頼されていない」旨の警告が表示される場合には、証明書をダブルクリックし、信頼する設定に変更してください。 また、Catoクライアントでの接続時、クライアントからキーチェーンへのアクセスを許可するかどうか、確認画面が表示されますので、アクセスを許可してください。 なお、.p12ファイルのインポート時、パスワードの入力画面が繰り返されインポートできない場合、以下をご確認ください。 .p12ファイルにインポートパスワードが正しく設定されているか。 ※パスワードなしの.p12がインポートできなかった事例があります .p12ファイルをOpenSSL3系で作成している場合、legacyオプションを付与して再作成し、改善するか。 ※OpenSSL3系のデフォルト設定で作成した.p12ファイルが、MacOS13でインポートできなかった事例があります iOS(iPhone/iPad)の注意点 iPhone/iPadに直接証明書をインストールせずに、MDM等で作成した 構成プロファイルで証明書とVPN設定を配布することが必須 です。詳細は以下の記事をご参照ください。 【Catoクラウド】iPhoneでのデバイス証明書認証 Androidの注意点 OSバージョンによって表記が異なりますが、以下が注意点です。 デバイス証明書のインポート時に選択肢が出た場合は「VPNとアプリユーザ証明書」を選択する デバイス証明書が、設定 >セキュリティ > 暗号化と認証情報 > ユーザ認証情報 にインポートされていること、「VPNとアプリ用」になっていることを確認する 証明書が認識されていれば、Catoクライアントの接続時に、利用する証明書の選択画面が出るので、該当の証明書を選択する なお、証明書のインポート自体に失敗する場合には、.p12ファイルにインポートパスワードが正しく設定されているかをご確認ください。 ※パスワードなしの.p12がインポートできなかった事例があります Linuxの注意点 初回接続時のみ、以下のコマンドでデバイス証明書をインポートします。その後は通常どおり接続してください。 cato-sdp import-cert <.p12ファイルの場所> Catoクラウド側の設定 端末側の準備ができたら、Catoの管理画面(CMA)から、デバイス証明書認証の設定を行います。 CA証明書のアップロード CMAに、デバイス証明書を検証(Verify)するCA証明書をアップロードします。 アップロードは、CMA の Access > Client Access > Device Authentication の箇所で行います。「New」ボタンを押し、任意の名前を指定の上、CA証明書をアップロードします。 なお、ここでは デバイス証明書を署名したCAの証明書をアップロードする 必要があります。つまり、デバイス証明書が中間CAから発行されている場合には中間CA証明書、そうでない場合にはルートCA証明書になります。 証明書の発行元を確認したい際は、Windowsの場合、「コンピューター証明書の管理」から「個人」を開き、対象のデバイス証明書の「証明のパス」を参照します。階層の一番下が証明書で、そのひとつ上が発行元の証明機関です。 以下の図の例1は、中間CAが存在し、中間CAからデバイス証明書が発行されている例です。この場合、CMAには中間CA証明書をアップロードします。例2はルートCAから発行されており、ルートCA証明書をアップロードする例です。 証明書認証のテスト 接続テストを行うにあたり、デバイス証明書認証の設定を全体に適用すると影響が大きいため、 まずは接続テストを実施するユーザのみに適用 することをおすすめします。 CMA の Access > Users で、テストを行うユーザを選択します。 User Configuration > Device Authentication で、「Override account Device Authentication settings」にチェックを入れ、証明書認証をテストしたいOSを選択し「Save」します。この設定で、このユーザのみにデバイス証明書認証を有効化できます。 設定を保存したら、対象のユーザにて、デバイス証明書をインポートした端末でのCatoクライアント接続をテストします。 デバイス証明書での認証に成功すると、CMAのEventsにて、Event Type Connectivity に以下のようなログが記録されます。通常の接続情報に加えて、証明書有効期限と証明書情報が表示されます。 Catoクライアントでエラーが表示され接続できない場合には、このあとの「トラブルシュート」の項目をご参照ください。 証明書認証の本番設定 テストにて問題がなければ、CMA の Access > Client Access > Device Authentication にて、全ユーザへ設定を適用します。 なお、デバイス証明書による認証は、上記 Device Authentication でのOSごとの適用の他に、Client Connectivity Policy にて、他の条件と組み合わせてより細かな設定も可能 です。Client Connectivity Policy については本記事の最後にて補足します。 トラブルシュート デバイス証明書認証を有効化した後、Catoクライアントにて接続エラーが表示される場合は、以下をご参照ください。 ※2023年12月時点のCatoクライアントバージョンでの確認内容です なお、問題の切り分けとして、デバイス証明書認証を無効化し、正常に接続できるかどうかをご確認ください。無効化しても接続できない場合は、原因が証明書関連ではないと考えられます。 Windowsクライアントのエラー Device certificate error. No matching certificate found. Please contact you network administrator. 端末内の、ローカル コンピューター > 個人 に証明書が存在しません。「コンピューター証明書の管理」から「個人」に対象のデバイス証明証が正しくインポートされているか確認してください。 Device certificate error. Please contact you network administrator. デバイス証明書は存在するものの、CA証明書での検証に失敗しています。「コンピューター証明書の管理」から「個人」に対象のデバイス証明証が正しくインポートされていること、またCMAにアップロードしたCA証明書と正しく紐づいていることをご確認ください。 MacOSクライアントのエラー Failed to authenticate with Certificate. デバイス証明書が認識されていない、またはCA証明書で検証できない状態です。以下の点をご確認ください。 キーチェーンアクセスの「ログイン」に、対象のデバイス証明書がインポートされていること そのデバイス証明書が信頼されていること CatoクライアントからキーチェーンへのアクセスがOS内で許可されていること デバイス証明書と、CMA上のCA証明書が正しく紐づいていること iOSクライアントのエラー 下記記事の「トラブルシュート」をご参照ください。 【Catoクラウド】iPhoneでのデバイス証明書認証 Androidクライアントのエラー 赤文字で「C=JP, ST=XXX, O=XXX …」といった、CAのSubject Name情報が表示される。 デバイス証明書が認識されていない、またはCA証明書で検証できない状態です。以下の点をご確認ください。 デバイス証明書が 設定 >セキュリティ > 暗号化と認証情報 > ユーザ認証情報 にインポートされていること ※設定の項目名はAndroidのバージョンや端末によって異なります 上記の証明書が「VPNとアプリ用」になっていること Catoクライアントでのアクセス時に、その証明書を選択したこと (拒否していないこと) デバイス証明書と、CMA上のCA証明書が正しく紐づいていること Linuxクライアントのエラー Certificate error. [C=JP, ST=XXX, O=XXX …] デバイス証明書が認識されていない、またはCA証明書で検証できない状態です。以下の点をご確認ください。 接続前にデバイス証明書のインポート (cato-sdp import-cert …) を行っていること デバイス証明書と、CMA上のCA証明書が正しく紐づいていること 上記を確認後も接続不可の場合、一度認証情報をリセットするため、CLIより 「–reset-cred」を付けて接続をお試しください。 補足情報  Client Connectivity Policy について Client Connectivity Policyは、端末が指定の条件に一致している場合にのみCatoクライアントの接続を許可する(または拒否する)機能です。 本記事にてご説明したデバイス認証(Device Authentication)と機能が重複していますが、Client Connectivity Policyでは、 クライアント証明書の有無やOSの他、指定のセキュリティソフトの指定のバージョンが動作しているかどうか、Real time protectionが有効になっているか等のDevice Posture条件を細かく指定 できます。また、ポリシーの適用範囲として、全体・ユーザ個人の他、ユーザグループを指定することが可能です。 デバイス認証(Device Authentication)では設定したい条件を満たせない場合、Client Connectivity Policyで実現可能かご検討ください。 まとめ デバイス証明書認証は、いざ導入しようとすると、デバイスにうまくインポートできなかったり、Cato固有の制約にひっかかったりすることが多いため、PoC時の検証をおすすめしております。 デバイス証明書以外にも、Catoクラウドでお困りの際は、ぜひ当社FAQサイト「よくあるご質問」もご参照ください。 よくあるご質問 | Cato Cloud ケイトクラウド - SCSK Cato SASE Cloud Platform. powered by SCSK cato-scsk.dga.jp
こんにちは。自称ネットワークエンジニアの貝塚です。SCSKでAWSの内製化支援『 テクニカルエスコートサービス 』を担当しています。 先日、EC2 Amazon Linuxを使って検証をしておりまして、付け焼刃でネットワーク周りの設定ファイルを変更してOSを再起動したところ、インスタンスに接続できなくなりました。その時回復するためにやったことを本稿にメモとして残したいと思います。 まずは状況整理 使用していたOSはAmazon Linux 2023。AWSの公式AMIから作成したものです。 OSにはセッションマネージャーを使用してログインしていました。OSのIPアドレス周りの設定を変更しOSの再起動をしたところ、セッションマネージャーで接続ができなくなりました。細かい切り分けはしていませんが、状況的にインスタンス側のネットワークの問題と断定してよいでしょうから、sshなどIPアドレスを使ってログインする手段はいずれもダメだと考えられます。 EC2シリアルコンソール 何か手段なかったか……?と考えていたところ、そういえばシリアルコンソールの機能があったな、と思い当たります。でも普段使っているEC2ではシリアルコンソールの接続ボタンは押せなかったような記憶が……などと考えつつ、藁にもすがる思いで画面を開きます。 Nitroかあ……。実はNitro Systemというのにあまり興味がなく、どのインスタンスタイプがNitroなのか全く知りません。まずは調べるところから。 インスタンスタイプ - Amazon Elastic Compute Cloud Amazon EC2 では、コンピューティング、メモリ、ストレージ、ネットワークの能力が異なるさまざまなインスタンスタイプが提供されています。 docs.aws.amazon.com T3がNitroのようです。……よかった。どんな高額インスタンスが必要なのかドキドキしてしまいました。t2.microが好きすぎてT3すらほとんど使ったことありませんでした。早速インスタンスタイプを変更して起動。今度は接続ボタンが押せるようになっていて、一安心。コンソールを流れていく文字列を眺めていると、cloud-initが169.254.169.254に接続できません、みたいなログが出ています。やっぱりネットワーク設定が悪かったんだな、さてどこをどう直せばいいのだろうな…… あー……パスワード設定してあるユーザ、いないですね。 ルートボリュームのデタッチ&アタッチ レスキューモード(エマージェンシーモード?)で起動すればいける気がするけれど、GRUB起動メニューにアクセスしなければいけないはずで、シリアルコンソールの画面を起動したときにはとっくにOS起動処理が始まっていたから、EC2ではGRUB起動メニューにアクセスできないのかなあ。あ、そういえばEC2ではルートボリュームをデタッチして別のインスタンスにアタッチできると聞いたことがあるような。 少々検索し、こちらの記事にたどり着きます。 起動できないEC2インスタンスをレスキューインスタンスを使って修復する blog.k-bushi.com まさに探していた情報そのものです。レスキュー用のLinuxインスタンスを準備し、早速試します。 インスタンス一覧から起動しなくなったインスタンスをチェックし、「ストレージ」タブからルートボリュームを特定。 ルートボリュームを選択し、アクション→ボリュームのデタッチを実行。 レスキュー用インスタンスにアタッチするために再度そのボリュームを選択し、アクション→ボリュームのアタッチを選択。 一覧からレスキュー用インスタンスを選択。デバイス名はデフォルトで表示されていた/dev/sdfとしました。(スクリーンショットに表示されているインフォメーションの通り、レスキュー用インスタンスのOS側では/dev/xvdf に変更されていました) レスキュー用インスタンスにデバイスが認識されていることを確認し、mount。 [ec2-user@ip-10-32-1-157 ~]$ sudo lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS xvda 202:0 0 8G 0 disk ├─xvda1 202:1 0 8G 0 part / ├─xvda127 259:0 0 1M 0 part └─xvda128 259:1 0 10M 0 part /boot/efi xvdf 202:80 0 8G 0 disk ├─xvdf1 202:81 0 8G 0 part ├─xvdf127 259:2 0 1M 0 part └─xvdf128 259:3 0 10M 0 part [ec2-user@ip-10-32-1-157 ~]$ [ec2-user@ip-10-32-1-157 ~]$ sudo mount -t xfs /dev/xvdf1 /mnt/ mount: /mnt: wrong fs type, bad option, bad superblock on /dev/xvdf1, missing codepage or helper program, or other error. あれれ。だめですね。wrong fs type とか言われていますが、ファイルシステムはxfsで間違いないはず……。 またしばし検索……。 うん、これですね。 Change the UUID on a xfs file system Change the UUID on a xfs file system www.it3.be なるほど、そういえば、起動しなくなったインスタンスも、レスキュー用インスタンスも、同じAMIから作ったAmazon Linux 2023のインスタンスでした。/ のUUIDが同じだからエラーになったのですね。確認してみたところ、確かに同じUUIDでした。 [ec2-user@ip-10-32-1-157 ~]$ sudo lsblk --fs NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINTS xvda ├─xvda1 xfs / 439aed1d-715f-48fd-bfa0-0e5f1a23088b 6.4G 20% / ├─xvda127 └─xvda128 vfat FAT16 C86C-DC3E 8.7M 13% /boot/efi xvdf ├─xvdf1 xfs / 439aed1d-715f-48fd-bfa0-0e5f1a23088b ├─xvdf127 └─xvdf128 vfat FAT16 C86C-DC3E 上記記事の手順に従ってUUIDの変更を実施し、再びmount。 [ec2-user@ip-10-32-1-157 ~]$ sudo uuidgen 12e50054-6690-41a6-b532-e75946ba9c6b [ec2-user@ip-10-32-1-157 ~]$ sudo xfs_admin -U 12e50054-6690-41a6-b532-e75946ba9c6b /dev/xvdf1 Clearing log and setting UUID writing all SBs new UUID = 12e50054-6690-41a6-b532-e75946ba9c6b [ec2-user@ip-10-32-1-157 ~]$ [ec2-user@ip-10-32-1-157 ~]$ sudo mount -t xfs /dev/xvdf1 /mnt/rescue/ [ec2-user@ip-10-32-1-157 ~]$ [ec2-user@ip-10-32-1-157 ~]$ ls /mnt/rescue/ bin boot dev etc home lib lib64 local media mnt opt proc root run sbin srv sys tmp usr var OKですね! 起動しなくなった原因のファイルを取り除き、umountした上で、今度はレスキュー用インスタンスからボリュームをデタッチします。そして再び起動しなくなったインスタンスにボリュームをアタッチ。ルートボリュームなのでデバイス名は /dev/xvda を指定します。 インスタンス起動!シリアルコンソールで起動を見届け…… grub> あれえ……。 そういえばすっかり読み流していましたが、先ほどの記事の末尾に Finallly, we can start digging into the content of the device mount on  /mnt  and do whatever was required. Perhaps, one note if this device will be moved back to the original EC2 instance do not forget to updat the  /mnt/etc/fstab  file with the updated UUID of this modified boot device. ※ Change the UUID on a xfs file system  より引用 UUIDが変わったから /etc/fstab の変更を忘れるなよって書いてありました。ドキュメントはよく読もう! 再度、ルートボリュームをレスキュー用インスタンスにアタッチし、fstabを修正します。 今度こそ! grub> あっれえ…。 その後、 AWS re:Postの関連しそうな記事 を参照し、fstabのオプションを変更してファイルシステムのチェックを無効にしたり、XFSのリペアをしたりいろいろ試しますが、相変わらずgrubのプロンプトになってしまいます。ひとつ試すたびにボリュームの付け替えをしているので、ひたすら面倒です。 最終的には、fstab以外におそらくgrubの設定ファイルにもUUIDが含まれていそうな気がする!だけどもう調べるの面倒くさい!となって、一度変更したファイルシステムのUUIDを元のUUIDに戻してあげることでOSの起動に成功したのでした。 教訓 パスワードを設定したOSユーザ作っておくの大事。(でも軽い検証のときはそのひと手間も面倒ですよね) UUID被りを避けるため、レスキュー用インスタンスはレスキューされるインスタンスとは異なるOSバージョンにしておくと面倒がない。(でも違うディストリビューションとかにしちゃうと操作感が違って面倒くさいしねえ) ドキュメントはよく読もう(でもちゃんと読んでもうまくいかないことはある) 後日談 その1 後日確認したら、grubの設定ファイルにUUIDが書かれていました。検証してないけれど、ここも追加で書き換えれば起動できていたはず。 $ sudo cat /boot/loader/entries/e8e94dc055b04f2484035693fbb04115-6.1.56-82.125.amzn2023.x86_64.conf title Amazon Linux (6.1.56-82.125.amzn2023.x86_64) 2023 version 6.1.56-82.125.amzn2023.x86_64 linux /boot/vmlinuz-6.1.56-82.125.amzn2023.x86_64 initrd /boot/initramfs-6.1.56-82.125.amzn2023.x86_64.img options root=UUID=439aed1d-715f-48fd-bfa0-0e5f1a23088b ro console=tty0 console=ttyS0,115200n8 nvme_core.io_timeout=4294967295 rd.emergency=poweroff rd.shell=0 selinux=1 security=selinux quiet grub_users $grub_users grub_arg --unrestricted grub_class amzn その2 この記事を書くために資料整理していたら、先述のルートボリュームのデタッチ・アタッチを解説した記事から以下の記事へリンクが張られているのを発見しました。 Amazon EBSマウント時の「wrong fs type, bad option, bad superblock on…」というエラーを解決する方法を教えてください | DevelopersIO Amazon EBSマウント時にUUIDの重複エラーが発生した時の解決方法を紹介します。 dev.classmethod.jp 1. 一時的にマウントするために、UUIDの重複を無視する アタッチしたボリュームは一時的にマウントするためのものであり、本来のEC2にアタッチし直す場合は、このアプローチを採用します。 マウント時にUUIDの重複を無視するオプション( -o nouuid )を渡します。 ※ Amazon EBSマウント時の「wrong fs type, bad option, bad superblock on…」というエラーを解決する方法を教えてください より引用。 UUIDの重複を無視するオプションがあったようですね。もう少しだけ丁寧に調べていればこんな苦労しなくて済んだのに……(よくある) まとめ 疲れました。
こんにちは、SCSKでAWSの内製化支援『 テクニカルエスコートサービス 』を担当している貝塚です。 先日、AWS Network FirewallのアウトバウンドTLSインスペクション使ってみた記事を投稿しました。  AWS Network FirewallでアウトバウンドトラフィックをTLSインスペクションする AWS Network Firewallで、アウトバウンド(egress)のTLSインスペクション機能を検証しました。アウトバウンドTLSインスペクションにより、クライアントPC(社内)から外部のウェブサーバへのHTTPS通信の内容を検査することができるようになります。 blog.usize-tech.com 2023.12.27 アウトバウンド(Egress) TLS インスペクションを記事にしたのだから、以前からあるインバウンド(Ingress) TLS インスペクションも記事にしてしまおう、ということで、追加で検証してみました。 TLSインスペクションとは SSL/TLSで暗号化された通信内容をチェックする機能です。 HTTPSなどのSSL/TLSで保護された通信は、クライアント-サーバ間で通信内容が暗号化されているため、通常、中継するネットワークデバイスで通信内容をチェックすることができません。SSLサーバ証明書をうまく使って中継デバイスで通信内容をチェックできるようにしたのがTLSインスペクションです。 インバウンド(Ingress) TLSインスペクション インバウンド(AWSのドキュメントではIngressと呼ばれる)TLSインスペクションは、自サイトでTLSを用いて暗号化通信をしているウェブサーバ等を保護するために使用されます。たとえば自サイトでwww.example.comというサーバ証明書をインストールしたサイトを運営しているとしたら、Network Firewallにも同じwww.example.comの証明書をインストールしてやります。Network Firewallはウェブサーバに向かう通信を、そのサーバ証明書を用いて復号化し、検査した後に再びサーバ証明書を用いて暗号化して、何食わぬ顔でウェブサーバに転送します。 検査したい対象サーバのサーバ証明書を入手しなければ検査ができないので、必然的に自身の管理下にあるサーバのみが検査対象になります。 本稿でも、前の記事と同様、Network Firewallの基本的な設定については扱いません。Network Firewallのデプロイ、ファイアウォールポリシーの作成、ルールグループの作成などの基本的な設定手順については以下の記事などを参考にしてください。 AWS Network Firewallについて学んでみた! AWS Network Firewallについて、学んだことをアウトプットしたいと思います。 blog.usize-tech.com 2023.12.24 アウトバウンド(Egress) TLSインスペクション アウトバウンド(AWSのドキュメントではEgressと呼ばれる)方向、つまり、自分たちの管理下にあるクライアントPCが、自分たちの管理下にないSSLサーバ証明書をインストールした外部のサーバと通信するときに通信内容を検査する機能です。こちらの機能の検証記事は下記をご覧ください。 AWS Network FirewallでアウトバウンドトラフィックをTLSインスペクションする AWS Network Firewallで、アウトバウンド(egress)のTLSインスペクション機能を検証しました。アウトバウンドTLSインスペクションにより、クライアントPC(社内)から外部のウェブサーバへのHTTPS通信の内容を検査することができるようになります。 blog.usize-tech.com 2023.12.27 Ingress TLSインスペクション設定の流れ Ingress TLSインスペクション機能検証のために実施した設定は以下の通りです。 ACMでサーバ証明書を作成する Network FirewallのTLS検査設定を作成する Network Firewallのファイアウォールポリシーを作成する Network Firewallをデプロイしてファイアウォールポリシーを関連付ける なお、既に作成済みのファイアウォールポリシーにTLS検査設定を追加することはできません。Network Firewallデプロイ時の流れで空のファイアウォールポリシーを作成することができますが、空のファイアウォールポリシーに後からTLS検査設定は追加できないので注意が必要です。 動作確認の流れ Ingress TLSインスペクションの動作確認で実施した内容は以下の通りです。 Network Firewallのルールグループに検証用のルールを追加する クライアントPCからHTTPSアクセスして挙動を確認する Network FirewallのAlertログを確認する Ingress TLSインスペクション設定 ACMでサーバ証明書を作成する まず、ACMで証明書を作成します。Network Firewallのドキュメントによると、 インポートでもACMからリクエストするのでもどちらでも問題ありません が、 自己署名証明書はサポートされていません 。 証明書の作成手順については、 AWSの公式ドキュメント やインターネット上の各種記事をご参照ください。 なお、今回は、ACMでリクエストして証明書を作成しました。 Network FirewallのTLS検査設定を作成する AWSマネジメントコンソール、ネットワークファイアウォールのTLS検査設定から「TLS検査設定を作成」をクリックします。 「インバウンド SSL/TLS 検査用のサーバー証明書」で、作成した証明書を選択します。証明書は複数追加できるようなので、今回は、複数のサイトをインスペクションできることを確認するために、ACMで作成した証明書をふたつ選択しました。 「TLS 検査設定の詳細」を埋めた後、「スコープ設定」で検査対象とする送信元/送信先IPとポートを指定します。なお、ここで指定した範囲に含まれるTLS通信が上で選択した証明書を使用 していない 場合、正常な通信ができなくなってしまうようなので、検査に必要な最小限の範囲を指定するようにしましょう。 以降の設定項目も適切に入力して、TLS検査設定を作成します。 Network Firewallのファイアウォールポリシーを作成する ファイアウォールポリシー作成時にTLS検査設定を指定します。 作成途中で「TLS検査設定を追加」というステップがありますので、先ほど作成したTLS検査設定を指定します。それ以外は通常のファイアウォールポリシー作成と同様の手順で、ファイアウォールポリシーの作成を完了させます。 Network Firewallをデプロイしてファイアウォールポリシーを関連付ける Network Firewallをデプロイし、前項で作成したファイアウォールポリシーを指定します。手順はNetwork Firewallのドキュメントなどをご参照ください。 動作確認 Network Firewallのルールグループに検証用のルールを追加する TLSインスペクションが行われることにより、HTTPSの通信はHTTP用のルールで検査できるようになっているはずです。今回の検証ではルールグループに、以下のSuricata互換ルールを追加しました。 drop http $EXTERNAL_NET any -> $HOME_NET 443 (msg:"Detected access to tcp port 443 /index.html"; http.uri; content:"index.html"; sid:1000102; rev:1;) alert http $EXTERNAL_NET any -> $HOME_NET 443 (msg:"Detected access to tcp port 443 /scsk.html"; http.uri; content:"scsk.html"; sid:1000111; rev:1;) pass http $EXTERNAL_NET any -> $HOME_NET 443 (http.uri; content:"scsk.html"; sid:1000112; rev:1;) alert tls $EXTERNAL_NET any -> $HOME_NET 443 (msg:"TLS: Can't inspect this"; sid:1000121; rev:1;) pass tls $EXTERNAL_NET any -> $HOME_NET 443 (sid:1000122; rev:1;) 1~3行目のルールで、HTTPのURIをチェックしてindex.htmlへのアクセスはドロップし、scsk.htmlへのアクセスはアラートログに出力した上で通信自体は許可するように設定しています。 4~5行目のルールは、TLSインスペクションが行われない事態を検出するために入れた念のためのルールです。HTTPS(TLS)通信だった場合にアラートログに出力した上で通信自体は許可するように設定しています。もし万が一HTTPS(TLS)通信に対してTLSインスペクションが行われなかった場合はこのルールにマッチするはずです。 クライアントPCからHTTPSアクセスして挙動を確認する クライアントPCからウェブサーバにHTTPSアクセスします。 今回、ウェブサーバは、自前で立てたHTTPサーバの前にELBを置き、前述のTLS検査設定で指定したものと同じ証明書を用いてHTTPS化しています。 /index.htmlにアクセスしてみます。想定通り、コンテンツは表示されません。 次に、/scsk.htmlにアクセスしてみます。こちらも想定通り、問題なくコンテンツを表示できました。TLSインスペクションが働き、HTTPをチェックするルールが適用されていることが確認できました。 念のため証明書を確認してみます。 アウトバウンドTLSインスペクションの時 とは違い、発行者(Issued By)がAmazonになっている、ACMでリクエストした何の変哲もない証明書です。 今回、TLS検査設定でふたつ証明書を指定しているので、もうひとつの証明書に対応したFQDNでも同じことを試しましたが、同様の結果になりました。複数の証明書を設定しても問題なく動作するようです。 Network FirewallのAlertログを確認する Network Firewallのアラートログを確認したところ、以下のログが出力されていました。意図通りにHTTPの内容をチェックし、URIに基づいて通信を制御できていることがログからも分かりました。 また、同じサーバ証明書をインストールした別の(IPアドレスが異なる)ウェブサーバにアクセスしたところ、以下のログが出力されました。スコープ設定で検査対象に含まれていない通信はNetwork Firewallで復号されずにTLSプロトコルと認識されて通過していったことが分かります。 まとめ Network FirewallのIngress TLS Inspectionについて、簡単な検証の結果をまとめてみました。 AWSのマネージドサービスを使って高度なネットワークセキュリティを確保したいというニーズはわりとあるのではないかと感じているので、今後もNetwork Firewallのノウハウを蓄積して記事にしていきたいと考えています。
2024年最新版の CSPM について解説します。 クラウドセキュリティの代表的なツールのひとつがCSPMです。クラウドセキュリティとは、クラウドコンピューティング環境(クラウドサービス)におけるユーザー、データ、アプリ、インフラストラクチャーを保護するために設計された一連のセキュリティポリシー、手順、ツール、テクノロジーを指します。 本記事では、クラウドサービスとは、Amazon Web Services (以下、AWS)、Microsoft Azure(以下、Azure)、Google Cloud Platform(以下、GCP)、Oracle Cloud Infrastructure(OCI)などに代表されるのIaaS/PaaS/SaaSの各サービスを意味します。 クラウドサービスプロバイダー(CSP)は、ベンダーとしてのAWS、Microsoft、Googleを意味します。グローバルにサービスを大規模で展開するクラウドサービスプロバイダーは、ハイパースケーラーと言われますが、この記事では、クラウドサービスプロバイダーとして表記します。 CSPMとは? CSPMとは、 Cloud Security Posture Management ( クラウドセキュリティポスチャマネジメント )で、日本語訳は「 クラウドセキュリティ態勢管理 」で、クラウドサービスのセキュリティ設定の状況を可視化し、不適切な設定や、コンプライアンス違反、脆弱性の有無などのチェックし、アドバイス、または設定変更を行うソリューションのことです。 具体的には、 AWS、Azure、GCPなどのIaaS/PaaSを中心としたクラウドサービスにおける設定不備やミスで発生する情報漏洩やサイバー攻撃などのインシデントに対し、セキュリティ設定やコンプライアンス監視を行い、セキュリティリスクを検出し、設定変更のアドバイスや、実際の設定変更を行うソリューションとなります 。 Posture(ポスチャ)とは、姿勢・態度を意味し、”態勢(たいせい)”として略されていますが、”状態”の方が理解しやすいかと思います。 エンドポイント端末のセキュリティ状態をチェックして、アクセス制限をする Device Posture (デバイスポスチャ)については、以前からありますが、クラウドサービスを対象としたCSPMを始め、それ以外にも、 Data Security Posture Management (DSPM)、 SaaS Security Posture Management (SSPM)、 API Security Posture Management (ASPM)、 Application Security Posture Management (ASPM)など管理対象を変えたSecurity Posture Management( xSPM )が次々と出現しています。   クラウドサービスのセキュリティ不備によるリスク Is The Cloud Secure Gartner offers recommendations for developing a cloud computing strategy and predictions for the future of cloud security. www.gartner.com 今から5年前(2019年)にアメリカ調査会社のガートナーが「 クラウドは安全か? (Is the Cloud Secure?)」のレポートで予測した通り、昨年2023年だけでも不適切な設定による機密情報の漏えい(リスク)が数多く発生しました。 レポートには、クラウド予測に基づいて、以下の3点が予想されていました。 1. 2025年まで、パブリッククラウドの利用を管理できない組織の90%は、機密データを不適切に共有する。 2. 2024年まで、大半の企業はクラウドのセキュリティリスクを適切に測定することに苦慮し続けるだろう。 3. 2025年まで、クラウドのセキュリティ障害の99%は顧客の責任となる。 実際に、昨年2023年7月 トヨタ自動車 が同社の「T-Connect」「G-Link」サービス利用者の車両から収集した 約230万人分の個人データが、約10年間に渡って外部から閲覧できる状態 にあり、個人データの漏えいが発生したおそれのある事態が発覚(同日、個人情報保護委員会から指導を受け、再発防止策を公表) 企業規模の大小には関係なく、2023年10月には、若い世代を人気の位置情報共有アプリ「 NauNau 」で、 230万人以上のユーザー位置情報やチャットデータなどが外部から閲覧できる状態 になっており、データ漏えいのおそれがあった。 まさにクラウドサービス利用を適切に管理できない組織において、機密データが知らない間に不適切に共有(公開)され、そのことに気が付かずに長期間放置されていたことが明らかとなっています。不適切な共有は、今もなお数多く存在し、今後も同様のセキュリティインシデントは継続するものと思われます。 もちろん 責任は、クラウドサービス事業者ではなく、すべて利用者側 です。 ちなみに、一般企業だけではなく、自身がクラウドサービスプロバイダーである マイクロソフト でさえも、2023年9月にクラウドストレージ(Azure Storage)の設定ミスにより、同社の内部情報である、従業員の使用するパソコンのバックアップデータ、3万件以上のTeamsの会話履歴など 38TBのデータが外部からアクセス可能な状態になっていた ことも判明しています。   セキュリティ不備によるリスク発生の原因 クラウドサービスにおける 設定不備やミスの主な原因は、設定者の知識不足 です。 クラウドサービスは非常に複雑で、新しいサービスや機能が次々とリリースされていくため、そのスピードに設定者が追従することは困難です。 ひとつのクラウドサービスにおいても、最新の技術動向や仕様を正確に把握することが困難になっている上に、利用するクラウドサービスも、単一ではなく複数利用する(=マルチクラウド)が今や当たり前となっており、 複数のクラウドサービスそれぞれの最新技術動向や仕様を正確に把握し、それぞれで設定不備やミスがないことを、人手でチェックするのは至難の業 となっています。 マルチクラウドの最大のメリットは、クラウドサービスプロバイダーによるロックインのリスクを低減することですが、特定ユースケースに最適な機能を提供するクラウドサービスプロバイダーを選択することで、機能面以外に、俊敏性・拡張性・弾力性などのメリットを享受することができ、全体システムとしての復元力や移行機会も得ることも可能となります。 単一クラウドサービス、AWSであれば、AWSのみを対象とするCSPMとして「AWS Security Hub」があります。 AWS Security Hubで十分という方もおられますが、クラウドサービスはAWSしか利用されていないのであれば、AWSの最新技術動向や仕様を把握し、AWS Security Hub、さらに、その他ツール(AWS Config 等)を活用し、セキュリティ設定やコンプライアンス監視を実施し、セキュリティリスクを検出した場合には、メール通知し、適切に設定変更を行うことも可能かと思います。 しかしながら、AWS以外にAzureを利用される場合は、同じように「Azure Security Center」、さらにGCPも利用される場合は「Security Command Center」と、次々とそれぞれクラウドサービスプロバイダーが提供するCSPMや各種ツールをカバーして行く必要があります。 クラウドサービスの利用や運用を、すべて外部の開発ベンダーに任せている場合も同じです。 その委託先の開発ベンダーは、最新の技術動向や仕様を正確に把握し、設定不備やミスがないことをツール等を利用して確認しているでしょうか? クラウドサービスプロバイダーであるマイクロソフト自身でさえ設定ミスをし、外部から指摘されて初めて気が付く状況において、現実問題としては不可能だと言えるでしょう。   責任共有モデルの誤解 クラウドサービス利用する上の責任について最初に「 責任共有モデル 」というものが使われる場合が殆どです。 AWSにおける「 Shared Responsibility Model 」のことですが、マーケティング色の強い日本語訳「責任共有モデル」という言葉に訳されていますが、実際には責任の共有はしておらず、きちんと責任分界点を設けた「 責任分担モデル 」が正しい日本語訳といえます。 この「Shared Responsibility Model」の図を見てもらうと一目瞭然ですが、AWS側は一言でいうとインフラのみで、 セキュリティ設定の不備によるリスク発生率を考慮すると殆ど(=99%)は利用者側の責任 になります。 利用者は、AWSのインフラ(データセンターやハードウェア)が強固であるため、AWSを利用するだけで、セキュリティレベルが高くなる(高くなった)と勘違いをしている場合が多いのですが、実際には 99% の責任は利用者側に残ったままで、セキュリティレベルは、オンプレミスの時と何ら変わりません。 逆に、 簡単な設定でインターネット上にデータを共有(公開)できてしまうリスクはオンプレミスと比較すると非常に高くなっています 。 社外へ公開しているグローバルIPアドレス(WebサーバやFirewall)に対しては、年に数回(半年や四半期毎)は、脆弱性診断やペネトレーションテストを実施している企業は多いですが、同じようにクラウドサービスに対して、定期的に設定診断を実施している企業は殆ど存在しないのが現状です。 そのため、10年間以上に渡って不適切な共有を放置する事案が頻繁に発生しています。   CSPMの5つの機能 クラウドサービスのセキュリティ不備によるリスクを低減させるCSPMの主な機能としては、以下の5つとなります。 1. マルチクラウド対応 AWSだけではなく、Azure、GCPなどの複数のクラウドサービスプロバイダーをサポートしています。 マルチクラウド環境を1つの管理コンソールから管理することが可能で、単一クラウドにおいても、複数アカウントを管理コンソールから統一したポリシーにより一元的に管理することが可能となります。 2. 最新チェックルールによる確認 CSPMには、あらかじめチェックルールが準備されており、さらにルールは定期的に見直し(更新)や追加が行われます。セキュリティリスクを引き起こす設定不備やミスがあるかどうかは、このルールに基づいてチェックが行われます。 企業や組織ごとのセキュリティポリシーやコンプライアンス要件に合わせたカスタムルール設定などのカスタマイズも可能となっています。 3. 設定不備・脆弱性の検出・通知・修復 設定不備やミス、脆弱な箇所を識別し、リスクとなり得る設定や状態を自動で検出し、アラート通知を行うことができます。 「誰が、いつ、どのように」原因となる設定変更をしたのかも確認が可能となります。 インシデントを未然に防ぐとともに、適切な対応を促し、CSPMによっては設定を自動で修復する機能もあります。 4. 設定不備・脆弱性の可視化 セキュリティリスクやコンプライアンス違反の状況を具体的に、ダッシュボードやレポートとして可視化できます。これにより早期のリスク発見ができ、リスクの重要度から、対応の優先順位付けを行い、迅速に対応を行うことが可能になります。 5. グローバル標準のセキュリティコンプライアンスに対応 CSPMは、PCI DSS、HIPPA、GDPR、ISO/IEC 27017、NIST CSF、NIST SP 800-53、SOC 2 TYPE 2などの国際基準のセキュリティフレームワークとチェックルールが紐づけされています。 また、今後新しく施行されるルールにもいち早く対応を行うことが可能になります。 クラウドサービスを利用する上で、セキュリティ不備によるインシデント発生リスクを図るためのチェックシートを以下に示します。 単発でチェックするのではなく、継続的に実施できるのか?クラウドサービスの最新技術動向・仕様への追従だけではなく、セキュリティフレームワーク(各種規制)への対応も行えるのか?などが重要となります。   参考)クラウドセキュリティにおいて、CSPMを合わせてよく出現する言葉 様々なSecurity Posture Managementが出現していると前述しましたが、xSPMとしては以下があります。 ・ DSPM (Data Security Posture Management):データセキュリティ態勢管理 ・ SSPM (SaaS Security Posture Management):SaaSセキュリティ態勢管理 ・ ASPM (API Security Posture Management):APIセキュリティ態勢管理 ・ ASPM (Application Security Posture Management):アプリケーションセキュリティ態勢管理 ・ KSPM (Kubernetes Security Posture Management):Kubernetesセキュリティ態勢管理 その他にも、CSPMと合わせてよく使われる言葉としては以下があります。CWPP、CIEM、CNAPPについては、別途改めて記事にする予定です。 ・ CIEM (Cloud Infrastructure Entitlement Management) :クラウドサービスのアクセス権限の監視/管理 ・ CWPP (Cloud Workload Protection Platform):コンテナやサーバレスをはじめとするクラウドワークロードの監視/保護 ・ CNAPP (Cloud Native Application Protection Platform):CSPM/CIEM/CWPPを含むプラットフォーム。シーナップと呼ばれます。 ・ CASB (Cloud Access Security Broker):クラウドサービスの利用を可視化/監視/適切なアクセス制限を実施。キャスビーと呼ばれます。 まとめ 企業がクラウドサービスによる真のメリットを享受するには、クラウドサービスを正しく理解し、システムインテグレータに丸投げせずに「自分たちで運転」できるエンジニアを自社内に増やしていく必要があると言われています。 企業規模にもよりますが、マルチクラウドすべてを自社で正しく理解するのは、要員リソースも含めて難しいため、不適切な設定や、コンプライアンス違反、脆弱性の有無などのチェックは、人手に頼るのではなく、CSPMなどツールによる自動化を行うことが最適解だと考えています。 https://www.soumu.go.jp/main_content/000843318.pdf 令和4年(2022年)10月31日に総務省から公表された「 クラウドサービス提供・利用における適切な設定に関するガイドライン 」のベストプラクティスにおいても「 ルールの文書化だけでなく、 SASE(Secure Access Service Edge)などのセキュリティゲートウェイを必ず通すことや、CSPM (Cloud Security Posture Management)などの管理部門が把握できる監視ツールを使用する ことなどの対策も併せて実施することを推奨する 」とあります。 重大なセキュリティインシデントが発生する前に、CSPMを検討されてはいかがでしょうか? もしかすると、すでに長期間、機密データを不適切に共有し続けているかもしれません。 一方で、CSPMソリューション導入をいきなり検討するのではなく、脆弱性診断のようにまずはCSPMを利用したサービスを一度スポットでご利用されるのが良いのではないかと考えており、SCSKでは、Palo Alto Networks(パロアルトネットワークス)社のCSPM「Prisma Cloud」を採用したマネージドサービスを提供させていただいております。 「 マルチクラウド設定診断サービス with CSPM 」として、スポットでの診断サービス(30万円~)を提供しておりますので、まずは自社のクラウドサービスの脆弱性診断(=クラウド設定診断)を実施されてみるのはいかがでしょうか? 定期的(半年や四半期毎)にスポット診断を実施することも可能ですし、もちろん常時監視するサービスもご提供しております。 以下のサービス紹介ページに当社オリジナルの日本語での診断レポートサンプルもございますので、ご興味を持たれた方は、是非ダウンロードをお願いします。 マルチクラウド設定診断サービス with CSPM| SCSK株式会社 マルチクラウド環境のセキュリティ設定リスクを手軽に確認可能なスポット診断サービスです。独自の診断レポートが、運用上の設定ミスや設計不備、クラウド環境の仕様変更などで発生し得る問題を可視化し、セキュリティインシデントの早期発見に役立ちます。 www.scsk.jp
こんにちは、広野です。 AWS AppSync を使用したアプリケーションを開発する機会があり、リゾルバ、主に VTL の書き方に関してまとまった知識が得られたので紹介します。 本記事では、VTL の書き方にフォーカスしています。ご了承ください。 AWS AppSync とは AWS AppSync はサーバーレスアプリケーションのバックエンドを作成するときに使用するサービスです。GraphQL というクエリ言語を使用してアプリケーションからリクエストします。AWS AppSync が受けたリクエストを処理するためにリゾルバという設定があり、その中で VTL (Apache Velocity Template Language) という言語でコードを書きます。同じ目的で Amazon API Gateway と AWS Lambda を使用する構成の方がメジャーですよね。ここでは、AWS AppSync = Amazon API Gateway、リゾルバ = AWS Lambda と置き換えてもらえたらわかりやすいと思います。 AWS AppSync には Amazon API Gateway + AWS Lambda の構成と比較して、以下の利点があります。(ChatGPT に聞いてみた) パフォーマンス VTL は AWS AppSync 内で実行されるため、AWS Lambda 関数を呼び出すよりもレイテンシーが低い。サブスクリプションの機能をデフォルトで備えていることも含め、リアルタイム性が高いアプリケーションにおいて優位性がある。 コスト効率 VTL は AWS AppSync の一部として実行されるため、追加のコストがかからない。 スケーラビリティ AWS AppSync と VTL は自動的にスケーリングされる。AWS Lambda 関数は同時実行数の制約がある。 ただし、AWS AppSync のデメリットもあります。 VTL は低機能なため、AWS Lambda 関数で書いていたこと全てを実現できるわけではない。 → JavaScript で書けるようにもなっているので、それにより解決していると思われる。(本記事では紹介しない) また、本記事では本末転倒ではあるが、AWS AppSync と AWS Lambda を統合することも一般的に行われている。 AWS AppSync を使用するために必要な GraphQL が難解で、そもそも AWS AppSync に手を出せない。w 私の実感を加味してまとめると ・AWS AppSync のレスポンスは高速。 ・しかし裏で使われるリゾルバ (VTL) でできることが少ない。簡易な CRUD 処理であれば実装可。 ・GraphQL も勉強しないといけない。学習コスト高い。 リゾルバとは リゾルバは、AWS AppSync がアプリケーションから受け取った GraphQL クエリによるリクエストから、引数を取得してバックエンドにあるデータソース(データベース等)とのやり取りを仲介する役割を持ちます。Amazon API Gateway と Amazon DynamoDB の構成と比較すると以下のようになると思えばよいでしょう。 Amazon API Gateway → AWS Lambda → Amazon DynamoDB AWS AppSync → リゾルバ → Amazon DynamoDB 1つの Amazon API Gateway が複数の AWS Lambda と統合できるのと同じように、1つの AWS AppSync は複数のリゾルバを持つことができます。 しかし、注意しないといけないのは、基本、1つのリゾルバは 1つのデータソースしか統合できません。AWS Lambda 関数であれば、関数コード内で自由に複数のデータソースとのやり取りを書くことができると思いますが、そのような自由度はリゾルバにはありません。 ※リゾルバの書き方によっては一部例外はあります。後ほど紹介します。 リゾルバでは VTL という言語で以下 2つの処理を定義します。 リクエストマッピングテンプレート レスポンスマッピングテンプレート 役割としては リクエストマッピングテンプレートは、AWS AppSync が受けたリクエストの引数を受け取り、バックエンドに処理をさせるコードに置き換える。(マッピングする) バックエンドが Amazon DynamoDB であればそれ用の記述を、Amazon Aurora であればまたそれ用の記述になる。アプリケーション側ではバックエンドの違いを気にせず同じクエリでデータを取得することができる。(これは GraphQL のメリット) レスポンスマッピングテンプレートは、バックエンドが返してきたレスポンスを加工し、アプリケーションが期待するフォーマットに置き換える。(マッピングする) 以降、 Amazon DynamoDB から 1つのアイテムだけを取得する VTL のサンプルを紹介します。今後、シリーズものとしていくつか他のサンプルも用意するつもりです。 Amazon DynamoDB に GetItem する VTL 例えば、AWS AppSync から以下のリクエストを受けたとします。Amazon DynamoDB には適切なデータがある想定です。テーブル名はリゾルバの別の設定で行います。 引数となるパラメータ: パーティションキー pkey、ソートキー skey 必要なレスポンス: data1, data2 という属性の値 マッピングテンプレートは JSON 形式で記述します。その中に VTL が混在する感じです。わかりにくい。 リクエストマッピングテンプレート { "version": "2018-05-29", "operation" : "GetItem", "key": { "pkey": $util.dynamodb.toDynamoDBJson($context.arguments.pkey), "skey": $util.dynamodb.toDynamoDBJson($context.arguments.skey) }, "consistentRead" : false, "projection": { "expression": "#data1, #data2", "expressionNames": { "#data1": "data1", "#data2": "data2" } } } operation には、GetItem を書きます。これは Amazon DynamoDB に GetItem をするぞ、という意思表示です。 key には、受け取った引数を書きます。ここでは、pkey, skey というキーに対して受け取った引数 $context.arguments.pkey と $context.arguments.skey を指定していると思って下さい。受け取った引数はマッピングテンプレート内では $context.arguments 内に格納されるので、この記述のように取り出すことができます。 $util.dynamodb.toDynamoDBJson で囲んでいる理由ですが、Amazon DynamoDB にキーを渡すときに特有の JSON フォーマットにする必要があるため、それをいちいち手書きしなくてもよいようにしてくれます。手書きだと、例ですが “pkey” : { “S” : $util.toJson($context.arguments.pkey) } と書かないといけないことになります。 consistentRead は、結果整合性でよいか、強整合性が必要かを指定します。 projection は、Amazon DynamoDB から受け取りたい属性を指定します。expressionNames では、例えば data1 という属性名を内部的に #data1 という名前に置き換えて、expression で指定しています。これは、Amazon DynamoDB の予約語や AWS AppSync の禁止文字列などが属性名に使われているときにエラーを回避するお作法です。ちなみに projection の項目を書かなければそのアイテムの全属性を取得します。 これで Amazon DynamoDB に GetItem をかけることができます。 ドキュメントによっては $context.arguments を $ctx.args と書いてあるサンプルもあります。私の経験上ですが、どちらでも同じ動きをするようです。 レスポンスマッピングテンプレート #if(!$context.result || $context.result.isEmpty()) $util.toJson({ "data1": "no data", "data2": "no data" }) #else $util.toJson($context.result) #end 超基本は、$util.toJson($context.result) を 1行書くだけで成り立ちます。$context.result に Amazon DynamoDB から返ってきたデータが格納されます。気を付けないといけないのは、$util.toJson で囲まないといけないことです。実はマッピングテンプレート内部では、$context.result が JSON フォーマットで書かれていないからです。それを JSON に Parse してくれるのが $util.toJson なのです。 このサンプルで少々手を入れているのは、データが無かったときは data1 と data2 に no data というテキストを入れて返すようにしていることです。$context.result と同じ JSON フォーマットに合わせており、受け取るアプリ側はデータがあろうが無かろうが同じフォーマットでレスポンスを受け取れるようにしています。※すみません、エラーのときの処理は入れていません。 レスポンスマッピングテンプレートでは、受け取ったレスポンス $context.result の内容に応じて、if 文でデータを加工することができます。if 構文を書くときには、その構文の先頭に必ず # を入れます。最後には #end で閉じます。if 文のネストも可能です。 任意の JSON データをレスポンスとして返すときも、必ず $util.toJson で囲むようにしましょう。ドキュメントによっては $util を $utils と書いているサンプルがありますが、私の経験上はどちらでも同じように動いています。 VTL に関しては以下の AWS 公式ドキュメントも必要に応じてご確認ください。 Resolver mapping template reference for DynamoDB - AWS AppSync Resolver Mapping Template Reference for DynamoDB for AWS AppSync. docs.aws.amazon.com まとめ いかがでしたでしょうか。 Amazon DynamoDB への CRUD 処理の基本中の基本とも言える GetItem ですが、すでにおなかいっぱいなのではないかと思います。ですが、一度 VTL がどんなものか理解できれば、そうでもなく感じてしまうので不思議です。今後他の VTL パターンも紹介しますね。お楽しみに。 本記事が皆様のお役に立てれば幸いです。
AWS CodebuildでAndroid OSのビルドを試す機会がありましたので、ナレッジを紹介します。本記事を読むことで下記が分かります。ご参考にしていただければ幸いです。 Codebuildにおける、ビルド環境のメモリとストレージの拡張方法 ⇒ただし、Android OSのビルドに関しては、本記事の リソース拡張の方法では失敗 することが判明 ビルド仕様のファイル(buildspec.yaml) 内で、以前のコマンドに依存するコマンドを実行する方法 本記事では細かい操作方法は記載しておりません。上記2点のみを記載しています。細かい操作方法は、公式手順をご確認いただければと思います。 Android OSとは Android OSは、モバイルデバイス向けのオープンソースのOSであり、Googleが主導するプロジェクトです。ソースは下記からダウンロードできます。 ソースのダウンロード  |  Android オープンソース プロジェクト  |  Android Open Source Project source.android.com ちなみにオープンソースにした理由としては、特定のプレーヤーが独占して他の誰かのイノベーションを阻害することがないように、誰もがメリットを享受できるようにとの理念があるそうです。 Android オープンソース プロジェクト  |  Android Open Source Project Android が世界を一つにします。オープンソースの Android オペレーティング システムでデバイスを活用しましょう。コピー source.android.com   Android OSのビルド要件 下記の通りです。 64 ビット環境のUbuntu Long Term Support(LTS) ※ ストレージ400GB以上 16 GB 以上の使用可能な RAM(64 GB を推奨) ※Googleでは、Ubuntuで開発とテストが行われているので、ビルドにはUbuntuを使うのが無難。 要件  |  Android オープンソース プロジェクト  |  Android Open Source Project source.android.com   Codebuildのスペック 2024/1現在、東京リージョンのCodebuildで用意されているUbu ntu、環境タイプ値:LINUX_CONTAINERのタイプとその費用は下 記の通りです。 コンピューティングタイプ 環境タイプ値 メモリ vCPU ディスク容量 費用/1分あたり※ Linux Small  LINUX_CONTAINER 3 GB 2 64 GB 0.005USD (0.75円) Linux Medium  LINUX_CONTAINER 7 GB 4 128 GB 0.01USD   (1.5円) Linux Large  LINUX_CONTAINER 15 GB 8 128 GB 0.02USD   (3円) Linux 2xlarge LINUX_CONTAINER 145 GB 72 824 GB (SSD) 0.25USD   (37.5円)  ※1USD=150円換算 参照URL: ビルド環境のコンピューティングモードおよびタイプ - AWS CodeBuild CodeBuild では、CodeBuild がビルドの実行に使用するコンピューティングとランタイム環境イメージを指定できます。 コンピューティング とは、CodeBuild によって管理および保守されるコンピューティングエンジン (CPU、メモリ、およびオペレーティングシステム) を指します。 ランタイム環境イメージ... docs.aws.amazon.com ビルド環境のコンピューティングモードおよびタイプ - AWS CodeBuild CodeBuild では、CodeBuild がビルドの実行に使用するコンピューティングとランタイム環境イメージを指定できます。 コンピューティング とは、CodeBuild によって管理および保守されるコンピューティングエンジン (CPU、メモリ、およびオペレーティングシステム) を指します。 ランタイム環境イメージ... docs.aws.amazon.com   ビルド要件との比較 Android OSのビルド要件と、Codebuildが用意するコンピューティングマシンの比較は下記の通りです。 項目 要件 Linux Large  Linux 2xlarge メモリ 16GB 15GB 145GB ストレージ 400GB以上 128GB 824GB コア数 ー 8コア 72コア 費用単価(分) ー 3円 37.5円 ビルド時間/回 ー ? ? ビルド費用/回 ー ? ? 公式によるとメモリが64GBの場合、72コアでビルド40分、6コアで3時間を要しています。 要件  |  Android オープンソース プロジェクト  |  Android Open Source Project source.android.com 要件を満たすコンピューティングタイプはLinux 2xlargeのみ ですが、単価が次点のLinux Large の10倍以上あります。ビルド時間が1/10になってくれればよいのですが、実際に試してみないとわかりません。 今回は費用面の理由によりLinux Largeを選択し、要件を満たしていない点に関しては、後述のリソース拡張方法で乗り切ることにしました。   Codebuildプロジェクトの作成 ストレージの不足:Amazon EFS のマウントで対処 不足するストレージについては、Codebuildに Amazon EFS をマウントさせることで対処します。ここでEFSをマウントする理由は2つあります。 前述の通り、ビルド要件から不足しているストレージ分を補うため Android ソースツリーを事前にダウンロードしたEFSをマウントさせることで、ダウンロード時間をスキップするため 2つ目のポチに関して.. Codebuildを開始すると新規のEC2が起動します。Androidの公式手順に従い、 ソースツリーのダウンロードから初めてしまうとダウンロードの時間(約2~3時間)を要してしまいます。CodebuildのタイムアウトはMAX8時間と制限があります。そのため、事前にEFSにソースツリーをダウンロードし、それをCodebuildから利用することで、時間短縮を図ります。 EFSのマウント方法は公式手順をご確認ください。 AWS CodeBuild の Amazon Elastic File System サンプル - AWS CodeBuild ビルドコンテナで Amazon EFS を使用する方法について説明します。 docs.aws.amazon.com   メモリの不足:SWAPの設定で対処 ビルド仕様のファイル(buildspec.yaml)にて、SWAPの設定を追加します。ここでは16GBを追加しています。 version: 0.2   phases:   pre_build:     commands:       – sudo fallocate -l 16G /swapfile       – sudo chmod 600 /swapfile       – sudo mkswap /swapfile       – sudo swapon /swapfile (略)   補足:buildspec.yamlで、以前のコマンドに依存するコマンドを実行する方法 buildspec.yamlの記載に際し、一つ補足があります。 Android OSのビルドに際し、公式手順では、ダウンロードしたソースツリーにある環境設定のスクリプトを実行することで、ビルドに必要な lunchやmコマンドを実行できるようになります。 $ . build/envsetup.sh #後続のlunchやmコマンドが実行できるようになる $ lunch product_name-build_variant #ビルドターゲット product_name-build_variant を指定 $ m #ビルド開始 公式手順: Android のビルド  |  Android オープンソース プロジェクト  |  Android Open Source Project   下記のようにbuildspec.yamlを記載すると、lunchやmコマンド実行時に”command not found”と怒られ、ビルドが失敗することになります。 version: 0.2 phases:   (略)   build:     commands:       – . build/envsetup.sh       – lunch “product_name-build_variant”       – m   正しくは、c ommands フェーズで – | と指定し、 YAML のリテラルブロック構文を使用する必要があります。 version: 0.2 phases:   (略)   build:     commands:       – |          . build/envsetup.sh          lunch “product_name-build_variant”          m   公式のドキュメントを見たところ、ビルド仕様バージョン 0.1 では以前のコマンド (ディレクトリの変更や環境変数の設定など) の状態に依存する単一のコマンドを実行することはできないとのこと。 ビルド環境のシェルとコマンド - AWS CodeBuild ビルドのライフサイクル中にビルド環境で実行するための AWS CodeBuild の一連のコマンドを提供します (たとえば、ビルドの依存関係のインストール、ソースコードのテストおよびコンパイルなど)。これらのコマンドを指定する方法はいくつかあります。 docs.aws.amazon.com 今回は、上記の通りビルド仕様バージョン 0.2を指定しましたが、以前のコマンドに依存するlunchやmコマンドは実行できず、ビルドが失敗しましたので、上記YAML構文を利用して回避しました。   結果 Codebuild上で、上記のようにリソースを拡張したコンピューティングタイプでは、 ビルドが一向に進まずに失敗する形となりました。 SWAPを設定しない場合は、メモリ不足で失敗するまでは途中までビルドは順調に進みました。 SWAPの利用によりビルドが進まなかったと考えていますが、原因究明中となります.. ひとまず高額ですがビルド要件を満たすコンピューティングタイプ “Linux 2xlarge”を素直に選んだほうがよさそうです。実際に試したかったのですが、費用的観点から別の機会で考えています。 項目 要件 Linux Large  Linux 2xlarge メモリ 16GB 15GB 145GB ストレージ 400GB以上 128GB 824GB コア数 ー 8コア 72コア 費用単価(分) ー 3円 37.5円 ビルド時間/回 ー 8時間(タイムアウトでビルド終了) ? ビルド費用/回 ー 1,440円 ?   終わりに Android OSのビルドに際し、Codebuildで利用できるコンピューティングタイプのメモリについて、15 GBの上位が145 GBと開きがあり、ちょうど良いスペックのものがありませんでした。 加えて、2023年11月にCodebuildで AWS Lambdaによるサポート開始が発表されました。AWS Lambda はほぼ瞬時に起動するため、より高速なビルドが可能とうたっています。 AWS CodeBuild で AWS Lambda によるコンピューティングのサポートを開始 aws.amazon.com ただし、AWS Lambdaのメモリが最大10GBであり、Android OSのビルド要件である16GB(推奨64GB)を満たしていません。 ビルド環境のコンピューティングモードおよびタイプ - AWS CodeBuild CodeBuild では、CodeBuild がビルドの実行に使用するコンピューティングとランタイム環境イメージを指定できます。 コンピューティング とは、CodeBuild によって管理および保守されるコンピューティングエンジン (CPU、メモリ、およびオペレーティングシステム) を指します。 ランタイム環境イメージ... docs.aws.amazon.com そのため、高額であることを承知した上でCodebuildのEC2のオーバースペックのものを利用するか、Codebuildを使わず、要件を満たすEC2を利用してビルドする方法が望ましいと考えます。
新年あけましておめでとうございます。本年もどうぞよろしくお願いします。 早速ですが、Catoクラウドの担当として、 独断と偏見で選出した ゼロトラストネットワーキング(Zero Trust Networking) 、特に SASE 、 SSE に関連する 2023年の10大ニュース を、今後の注目ポイントと合わせてご紹介します。 SASE (サッシー、サーシ)は「Secure Access Service Edge」、 SSE (エス・エス・イー)は「Security Service Edge」の略称で、ともにアメリカ調査会社であるガートナー社が提唱しており、SASEは2019年、SSEは2年後の2021年に提唱されました。 SASEは、ネットワークとセキュリティと統合(融合)し、ユーザが場所を問わず企業のシステム、アプリケーション、クラウドサービス、データにアクセスできるよう、安全で信頼性が高く、最適化されたネットワーク接続を提供することがコンセプトとなっており、一方でSSEは、SASEのサブセット(一部分)で、SWG、ZTNA/SDP、CASB/DLP機能のみを指します。 1. 国内SASE導入は、海外に遅れを取るものの普及期へ 昨年(2023年)からSASEの普及期に入るとされていました。SCSKでは2021 年より SASE の主要なソリューションを一同に紹介を行うオンラインセミナー「SCSK SASE Solution Summit(通称S4:エスフォー)」をこれまで13回開催しており、2023年の6月および10月の開催では、それぞれ200名以上、これまでに延べ1,300 名以上の方々にご参加頂いております。※次回は2024年2月開催予定です。 これらのセミナーを通じて、多くの参加者からの声を集めると、SASEに関して世間で類似のアンケート調査(例えば、SASE導入済み企業が4割、導入着手企業が6割など)よりも、実際の国内の認知度や導入率が低いのではないか、実態と大きく乖離しているのではないかという仮説が上がりました。 そこで、2023年6月に外部調査企業を利用し、国内企業(n=339社)への実態調査を実施したところ、約7割の企業が、SASEについて認知していないことが判明し、SASE導入済み企業は1割であることが分かりました。 一方、SASEを認知している3割の企業の内、1割(10%)の企業は、すでにSASEを導入済みで、5%が現在導入中、15%が導入計画中であることも判明しており、キャズム理論においては 、日本国内においてもキャズム(普及に向けた深い溝)を超え、メインストリーム市場へ進んでいることが判明 し、2023年から今年(2024年)が普及期であるということが分かりました。 https://www.scsk.jp/news/2023/pdf/20230809i.pdf コロナ禍でのリモートワークや境界型防御の喫緊の課題解決で、いち早くSASEへ移行をしたお客様は一段落し、現在は、WANやリモートアクセスのライフサイクルのタイミングでの検討が多いように思えます。 2. ゼロトラストに続き、SASE、SSEがバズワードへ ガートナーが2023年7月18日に「 ゼロトラストネットワーキングのハイプサイクル (Hype Cycle for Zero Trust Networking)」公開しました。 公開理由には「ゼロトラストをめぐる顧客の関心、混乱、誇大広告を考慮して、新しいハイプ・サイクルを発表」、「測定可能なゼロトラスト・プログラムを導入することは、ノイズや誇大広告に満ちた困難な旅になる可能性がある」、「ゼロトラストは、クラウドや、Software-Defined(SD~)のような言葉に似ており、私たちが目にすることのひとつは、本当にゼロトラストの特徴を示すものと、純粋なベンダーのマーケティングとを区別するのに苦労する」とあり、「ゼロトラスト」に続いて、「SASE」「SSE」が多くの誇大広告に溢れ返ったバズワードと化し、本来の定義は無視され、曖昧な定義のまま広く世間で使われてしまっています。 今後も「ゼロトラスト~」「~SASE」「~SSE」など様々なバズワードが出現することになると思いますが、「SASE」「SSE」の正しい定義と、皆さんが求めている「ゼロトラスト」が、どのようなステップで検討・導入を進めるべきか、また、最終的ゴール(あるべき姿)はどこか?を、きちんと検討されることが重要かと思います。 3. ゼットスケーラー(Zscaler)が、SASEマジック・クアドラントから外れる ご存知の通り、ガートナーの シングルベンダーSASE (Single-Vendor SASE)の マジック・クアドラント (Magic Quadrant:MQ)から、ゼットスケーラーが外されました。 その後のフォレスターの ゼロトラストエッジ (Zero Trust Edge Solutions)の Waveレポート からも外されています。 前述の当社のSASEセミナーS4(エスフォー)でも、2021年の開始当初からゼットスケーラーの紹介を行っておりましたが、2022年度以降(2023年度)からは、ゼットスケーラーを外さざるを得ない状況となりました。 ゼットスケーラーは、このことに対し「このMQは、我々の成長速度を落とすものではない。SASEは幅広い総称です。ガートナーがこれを始めたとき、それは我々が持っているゲートウェイ製品であるSD-WANとSSEの統合でした。そして、私たちはそこにある重要なSD-WANベンダー全てとの統合を行ってきました。ゼットスケーラーは、CASB、DLP、SWG、ZTNAを統合したSSEソリューションと共に、主要なSD-WANベンダーの殆どと提携し、マルチベンダーのベストオブブリードSASEセキュリティスタックを提供しています。」 「今回のMQは、SD-WANを含む単一ベンダーのSASEのためのものです。我々はしばしばSD-WANはゼロトラストであると言ってきたが、我々はゼロトラストのSASEを提供しているが、SD-WAN SASEは提供していません。だから、我々はそのMQに入っていません。」 ゼットスケーラーは、SD-WANベンダーを中心に、様々パートナーとの協業モデル(ゼットスケーラー曰く「マルチベンダーSASE」)で成功してきていますが、利用者はマルチベンダーのベストオブブリード(マルチベンダーSASE)ではなく、よりシンプルなシングルベンダーSASEを希望する方向へ変わってきています。 ゼットスケーラーは、今後ネットワークハードウェアを展開し、SD-WANサービスの提供へ戦略転換を図るとの記事もありますが、それは同時にこれまでのSD-WANベンダーとの関係が悪化することを意味します(ゼットスケーラーの売上のかなりの部分がネットワークパートナーを介したものである)ゼットスケーラーがこれまで一緒にビジネスを牽引してきたパートナーと決別し、シングルベンダーSASEへ舵を取るのかどうかが今後注目です。 また、日本国内では長引く円安の状況もあり、契約更新の度に大幅な値上げがあるのでリプレースを検討する利用者が増えています。最初の3年契約の初回更新はなんとかクリアしても、次の契約更新を行わない(行えない)利用者も多いので、その対応についても今後注目です。 4. AI、AI、AI・・・ 最近のIT関連のニュースは、ChatGPT、Microsoft Copilot、Google BardなどAI一色です。 ゼロトラスト、SASE、SSE界隈も同じくAIの話題がつきません。 一例ですが、パロアルトネットワークス(Palo Alto Networks)は、 Strata Cloud Manager と呼ばれる人工知能(AI)を活用した管理ツールを開発しました。 このAIを活用すると「SASE全体だけでなく、ハードウェア・ファイアウォールとソフトウェア・ファイアウォール全体でも単一の統合ダッシュボードで情報を得ることができ、ネットワーク・セキュリティを 1 つの画面で確認でき、完全な可視性を得ることができます。」とのこと。 その他のベンダーも同じように次々にAIを謳っていますが、多くは管理ポータルでのセキュリティインシデントについての詳細な説明(追加の関連情報)やアドバイスが多いように思います。どの部分にAIがどのように活用されているのか?そのAIによって利用者はどのようなメリットを享受できるのか?などは、実際に利用して見ないと分かりません。 今後もAIの話題はつきないと思いますが、ゼロトラスト、SASE、SSEでの実際のメリットに注目していきたいと思います。 5. シスコ(Cisco)がSASEに本腰をいれるが、現時点では難解 シスコは、シングルベンダーSASEに選出されていますが、これまで買収した「Meraki」、「Umbrella」などが組み合わされたSASE、シスコ曰く「統合型(Unified)SASE」で、管理コンソールは全く別々のままでした。 “組み合わせされたSASE”は、「Cisco+ Secure Connect」と呼ばれ、SD-WANはMeraki、セキュリティ機能はUmbrellaにて機能が提供されていましたが、さらに”組み合わせされたSSE”として、「Cisco Secure Access」もリリースしています。 ちなみに、Umbrellaには「Umbrella DNS」「Umbrella Secure Internet Gateway(SIG)」があります。 正直なところ複雑過ぎて分かりません。 Meraki(SD-WAN)、Umbrellaに、ZTNA(VPNaaS)を付加して(言葉自体がおかしいが)「統合型SASE」として、Cisco+ Secure Connectが位置づけられています。 一方で、SSE、SD-WANについては(これも言葉自体がおかしいが)「組み立て型SASE」として”適宜”組み合わせたものをソリューションとして提供するようで、バラ売りも行うようです。 また、管理コンソールは、Umbrellaを捨てて、Merakiへ統合する方針のようです。 いずれにせよ、シスコは、統合型(Unified)SASEの名の下、 Cisco+ Secure Connect へ統合を図るようです。 シスコは、バラバラのパーツを如何にしてうまく統合できるか、また、この複雑なソリューション・ポートフォリオを利用者が理解し、支持されるかどうかに注目です。 6. マイクロソフト(Microsoft)が、SSEから本格参入 マイクロソフトが、これまでの CASBに加えて、Entra SuiteにSWG、ZTNA、FWaaSを加え、SSEへの本格参入を表明 しました。 これまでのAzure Active Directory(Azure AD)のブランド名も捨て、Entra IDへ変更するなど、かなりの本気度が垣間見えます。 マイクロソフトはすでに全世界中にAzureリージョンを保有しており、61のデータセンターと185のPoPを有し、世界最大のグローバルバックボーンネットワークを保有していることが最も大きな特徴になります。 まずは、SSE-but-the-SASE市場に参入したため、SSE市場の競争が激化することは間違いないですが、近い将来グローバルバックボーンを活用したSASE市場への参画することも間違いないと思います。 シスコと同じく、大規模な顧客基盤と、様々なパートナーとのエコシステム、強力なアイデンティ基盤であるAzure AD(Entra ID)、オペレーションシステム基盤(Windows OS)など、SASE、SSEでは最も強力なベンダーになる可能性が高いです。 一方、国内ではマイクロソフトファンの利用者も多い反面、マイクロソフト嫌いの利用者も多いため、SASE、SSEまでマイクロソフトに支配されたくないと言う方も一定数は存在すると思います。SSEからSASEへサービス範囲を広げ、利用者に支持されるかに注目です。 7. フォーティネット(Fortinet)が、Google Cloudとパートナーシップ 2023年10月に フォーティネットは、SASE PoPの拡大のためにGoogle Cloud と提携 したことを発表しました。 Google Cloudのグローバル ロケーションの広範なネットワークを利用するとのこと。Google Cloudは 、39の地域、200以上の国と地域に187のネットワークエッジロケーションがあります。 つまり、フォーティネットは、パロアルトネットワークス(Prisma Access)と同じくGoogle Cloud と提携し、全世界にPoPを持つことになりましたが、その反面、Googleが進出していない中国へのアクセスは行わない(≒行えない)ことを選択したようです。 アメリカ企業は、とかく中国を軽視しがちですが、日本国内、特に製造業を中心に、中国接続は必須の要件であるため、利用者が中国接続なしでフォーティネット(FortiSASE)を支持するか、またはフォーティネットがGoogle CloudがPoPを展開していない中国等へ独自にPoPを展開するかどうかが注目です。 8. ブロードコム(Broadcom)のヴイエムウェア(VMware)買収が完了 2023年11月にブロードコムのヴイエムウェアの買収が完了しました。 ヴイエムウェア本来の仮想サーバ(vShere)以外でこれまで買収したVeloCloud、Ananda Networks、Nyansa、Carbon Black、Air Watchなどがどうなるかが今後注目すべき事項です。 シマンテック(Symantec)と、VMware SD-WANを組み合わせてSASEを強化するのか、それともすでに話がでているように、それぞれバラバラで売却されるのか?シングルベンダーSASEで有り続けられるのか?がポイントです。 過去ブロードコムにより買収された企業、シーエー(CA Technologies)、シマンテックの動きを見る限りは、従業員のレイオフ、個々の事業売却、そして利用者に対しては、価格高騰(抱き合わせ販売)、サポートの減少、イノベーションの停滞へと進む可能性が高いのではないかと推測します。 ブロードコムがどう動くのか、各調査会社がSASE、SSEからブロードコム(ヴイエムウェア)をどう評価するのか注目です。 特に、旧ヴイエムウェアが買収したSD-WANのVeloCloudは、前述のゼットスケーラーとの協業モデルの事例が多かったため、ブロードコムが VeloCloudを、ゼットスケーラーへ売却することになれば、ゼットスケーラーがいっきにシングルベンダーSASEとなる可能性もあります。 9. 世界初SASEソリューションベンダー、ケイトネットワークス(Cato Networks) Cato Networksは、2023年9月に2億3,800 万ドル(約340億円)の資金を株式調達し、評価額が30 億ドル(約4,300億円)を超えました。 「 SASE のゴッドファーザー 」とも呼ばれる Cato Networks の CEO である シュロモ・クレイマー(Shlomo Kramer)は、「私たちは、2015年にSASEを発明しました。最初の4年間は、多くの人が私たちを”何をしているの?”という目で見ていたが、2019年ガートナーの”ネットワーク セキュリティの未来”で、新たなSASEとしてカテゴリ定義されたことで流れが変わりました。SASE エクスペリエンスを提供するソリューションとして、このプラットフォームをゼロから構築した唯一の企業になりました。」とのこと。 全世界中に85箇所以上に設置されているCato社独自のPoP(中国を含む)、ネットワーク接続性を拠点まで保証するSocketのサービス提供(責任分界点が異なる)、クラウドネイティブで実装されたアーキテクチャ(圧倒的な使いやすさ、シンプルさ)は、他のソリューションと異なる大きな差別化ポイントで、唯一のSASEソリューションとも言えます。 ちなみに、シュロモ氏は、他の競合他社に対しては「SASEが登場した後、パロアルトネットワークスのように、グーグルを活用した急ごしらえのつなぎ合わせソリューションは、持続可能性や費用対効果に問題があり、将来的にその代償は顧客が支払うことになるだろう。」「ゼットスケーラーの言う”マルチベンダーSASE”カテゴリは、本質的にはすでに消滅している。」「フォーティネットは、最近クラウドについて意識し始めたところ、まさにこれから」と、ゴッドファーザーらしいコメントをあげています。 Catoクラウドの注目すべきポイントは、ガートナーのSASE定義をすでに超え始めていること です。 2023年には「 SaaS Security API 」のセキュリティオプションをリリースし、SaaSサービスに対して、ウィルスチェックや、機密情報漏えい対策(DLP)をカバーしました。つまり、企業内のユーザは、Catoクラウドを経由するので問題はないが、社外ユーザとのデータ共有はCatoクラウドによるセキュリティ検査が行えないため、SaaSを直接検査を行うことで、カバー範囲を広げました。 「 XDR Security 」をリリースし、 EDR製品とのログ連携 もすでに開始されています。現時点では Microsoft Defender for Endpoint のみですが、主要なEDR製品との連携が予定されており、これまで「EDRはEDRのSOC、SASEはSASEのSOC」と、SOCが別々になる事が多かったのですが、SASE(Catoクラウド)へログおよびSOCを統合する動きが開始されています。 さらに、来月(2024年2月)からは、 EPP製品をリリース し、ガートナーのSASEの定義を超えて、ネットワーク層を超えエンドポイントまでカバー範囲を広げます。 10. Cato Networks社の最優秀パートナーアワードをSCSKが受賞 最後のニュースはSCSKの宣伝を兼ねていますが、2023年7月 Cato Networksが日本で初めて開催した「Partner Summit in Tokyo 2023」において、SCSKは「ビジネス貢献度」、「案件創出数」、「デジタルコンテンツ拡充」ならびに「Cato 認定技術者数」の項目で最も高いポイントを獲得し、 最優秀パートナーアワードである「Top Performing Partner」を受賞 しました。 https://www.scsk.jp/news/2023/pdf/20230726i.pdf 「ビジネス貢献度」、「案件創出数」はもちろんのことながら、SCSKのCatoクラウド認定技術者数と、特に、Catoクラウドのお客様導入事例の制作や、CatoクラウドのFAQシステム等の「デジタルコンテンツ拡充」が認められたことは、非常にありがたいことです。 2023年8月からは、さらにこのSCSK技術ブログ「TechHarmony」への記事投稿も開始しており、さらにCatoクラウドのデジタルコンテンツの拡充を図って行きたいと考えておりますので、引き続きご活用ください。 最後に 「SASE のゴッドファーザー」であるシュロモ・クレイマーが率いるSASE、Cato Networks社、Catoクラウド(Cato Cloud/Cato SASE Cloud)ですが、 知名度が圧倒的に低いのが一番の課題 です。 特に、日本国内においては「革新的なもの」「便利なもの」「費用対効果が高いもの(安いもの)」よりも、「認知度が高い(誰もが知っていている)もの」「同業(または自社と比較対象の企業)が採用しているもの」「誰もが利用していてるもの」を選択する傾向にあります。 つまり、日本では莫大なマーケティング(特に広告)コストを掛けて、認知度(知名度)をあげ、誰もが知っている有名企業が採用し、さらに導入事例化されたソリューション”のみ”が売れるのが現状です。 そのため、SCSKでは Cato Networks、Catoクラウドの知名度向上に向けた活動を推進しています。 昨年末2023年12月25日(月)から12月31日(日)の一週間、JR東日本品川駅の自由通路(品川コンコース)のデジタルサイネージでOOH(Out Of Home:屋外広告)を実施しました。また、今月2024年1月15日(月)から1月21日(日)の一週間も再度OOHを掲示する予定ですので、もし品川駅をお通りの際は、ご確認いただけると幸いです。
Catoクラウドでは、許可した端末からしかリモートアクセスをさせたくないというご要件に対応する機能として、 デバイス認証(Device Authentication)機能 があります。 これは、 指定した電子証明書(デバイス証明書、別名クライアント証明書)がインストールされている端末からのみ、Catoクラウドへの接続を許可する 機能で、Catoクライアントが対応するすべてのOS(※)にて利用可能です。 ※ Windows, macOS, iOS(iPhone/iPad), Android, Linux デバイス認証機能の詳細や活用方法については後日別記事にてご紹介予定ですが、今回は特によくお問い合わせをいただく iPhoneへの証明書導入方法 について解説します。iPhoneへの導入は他OSよりStepが多く分かりづらいため、参考にしていただけますと幸いです。 前提条件 前提として、 iPhoneでデバイス証明書認証を利用する場合は、iOSの仕様上、MDM等による構成プロファイルの作成が必須 となります。構成プロファイルを用いない設定には対応していないため、ご注意ください。 ※なお、デバイス証明書認証を利用しない場合には、構成プロファイルは必須ではありません。 また、 使用するデバイス証明書およびCA証明書を用意 する必要があります。証明書の用意方法としては、外部の電子証明書発行サービスを利用する方法や、Active DirectoryのADCS機能で発行する方法、OpenSSLを利用しプライベート認証局を構築して発行する方法などがあります。Catoクラウドではどの方法で発行したデバイス証明書でも利用可能です。 接続までの流れは以下となります。 CMAにCA証明書をアップロード MDM等を利用し構成プロファイルを作成 作成した構成プロファイルをiPhoneへ配信 iPhoneに構成プロファイルをインストール CMAで接続テスト設定 iPhoneにCatoクライアントをインストールし接続 本記事では、MDMとしてApple Configuratorを使用し、以下の環境にてテストしています。ご利用のMDMにより画面は異なりますが、設定項目はおおよそ同じですので、参考としていただければと思います。 端末: iPhone SE(第2世代) iOS 16.6.1 MDM: Apple Configurator 2.16 (macOS Ventura 13.6.3) デバイス証明書: 検証用のプライベート認証局で発行 (CMA)CA証明書をアップロード Catoの管理画面(CMA)に、デバイス証明書を検証(Verify)するCA証明書をアップロードします。 ここでは、 デバイス証明書を署名したCAの証明書 をアップロードする必要があります。つまり、デバイス証明書が中間CAから発行されている場合には中間CA証明書、そうでない場合にはルート証明書になります。ご利用の証明書の構成をご確認ください。 アップロードは、CMA の Access > Client Access > Device Authentication の箇所で行います。 「New」ボタンを押し、任意の名前を指定の上、CA証明書をアップロードします。 認証の際は、端末内のデバイス証明書がこのCA証明書で正しく検証できる必要があります。 (MDM)構成プロファイルの作成 Apple Configuratorを開き、ファイル > 新規プロファイルを選択し、構成プロファイルの作成画面を開きます。任意のプロファイル名をつけてください。 各種設定項目がありますが、Catoクライアントで利用するのは、左メニューの「証明書」と「VPN」の2つのみです。 証明書の設定 証明書を2つ設定します。 1. Catoのルート証明書 CatoでTLS Inspectionを行うために必須となる、Catoのルート証明書です。 WindowsやMacOSでは、Catoクライアントのインストール時に自動でインポートされるため特に意識しないのですが、iPhoneではクライアントとセットになっていないため、クライアントとは別にインポートが必要です。このため、この構成プロファイルであわせて配布してしまうのがおすすめです。 このCatoのルート証明書は、下記サイトの「Cato Certificate」より入手ください。 Cato Downloads Easily download the newest Client version from this portal without authenticating clientdownload.catonetworks.com 2. デバイス証明書 デバイス証明書認証で使用する証明書です。 インポートパスワードを設定した .p12形式 でご用意ください。 パスワード欄に、証明書のインポートパスワードを入力します。 VPNの設定 続いて「VPN」に移動し、各設定項目を入力します。詳細はCato Knowledge Baseに公開されていますので、あわせてご確認ください。 Distributing Certificates for Device Authentication and Device Checks 接続名 任意の名前 接続のタイプ カスタムSSL 識別子 CatoNetworks.CatoVPN サーバ vpn.catonetworks.net アカウント Catoテナント名 ※モバイルユーザアカウントではありません プロバイダバンドル識別子 CatoNetworks.CatoVPN.CatoVPNNEExtenstion プロバイダの指定要件 空欄 カスタムデータ 空欄 ユーザ認証 証明書 さらに下にスクロールします。 プロバイダタイプ パケットトンネル 資格情報 プルダウンし、証明書のところで設定した デバイス証明書の名前を選択 ※ここが間違いがちです これ以外の項目はすべてデフォルトとします。 以上で構成プロファイルの作成は完了です。プロファイルを保存します。 (MDM)構成プロファイルをiPhoneへ配信 作成した構成プロファイルを、対象のiPhoneに配信します。配信方法は、MDMからの配信、Eメール添付など、なんでも問題ありません。 今回はiPhoneをUSBケーブルでMacに接続し、Apple Configuratorから直接配信しました。 (iPhone)構成プロファイルをインストール iPhone側で、受け取った構成プロファイルをインストールします。 ※MDM等の設定で、プロファイルが自動インストールされる場合には、以下は不要です 「設定」>「ダウンロード済みのプロファイル」を選択します。 先ほど配信したプロファイルであることを確認し、「インストール」します。 完了画面が出たら、「完了」を押します。 インストールの確認 構成プロファイルが正しくインストールされたかを確認します。 「設定」>「一般」>「VPNとデバイス管理」を開き、「構成プロファイル」の欄に、先ほどインストールした構成プロファイルがあることを確認します。 次に「VPN」を開き、構成プロファイルの中で設定したVPN設定が入っていることを確認します。 これが表示されていない場合、構成プロファイルに何らかの設定誤りがあって、VPN設定が 認識されていないため、プロファイルを見直します。 続いて、配信したCatoのルート証明書を通信に利用できるようにするため、信頼設定します。 「設定」>「一般」>「情報」を最下部までスクロールし、「証明書信頼設定」を開きます。「Cato Networks CA」の横のスライダをON(緑の状態)にしてください。 (CMA)接続テスト設定 接続テストを行うにあたり、デバイス証明書認証の設定を全体に適用すると影響が大きいため、 まずは接続テストを実施するユーザのみに適用する ことをおすすめします。 CMA の Access > Users で、テストを行うユーザを選択します。 User Configuration > Device Authentication で、「Override account Device Authentication settings」にチェックを入れ、証明書認証したいOS(今回はiOS)を選択し「Save」します。 こうすることで、このユーザのみにデバイス証明書認証を有効化できます。 (iPhone)Catoクライアントをインストールし接続 Catoクライアントをインストールします。App Storeからのダウンロードでも、MDMからの配信でも問題ありません。 インストール完了後、アプリを起動し、中央のボタンを押して接続します。 認証画面に遷移します。通常どおりCatoモバイルユーザのアカウント(メールアドレス)とパスワードを入力し、「Continue」を押します。 Connectedの表示となれば成功です! CMAのEventsにも証明書認証が成功した旨のログがでます。 トラブルシュート エラーメッセージが出て接続できない例をご紹介します。 Catoクライアントの認証画面で「Device Certificate is needed」と表示され接続できない デバイス証明書が認識されていません。 以下2点をご確認ください。 配信した構成プロファイルに正しくクライアント証明書が含まれているか。 「設定」>「一般」>「VPNとデバイス管理」>「VPN」の箇所で、 VPNプロファイルが2つできていないか 。 2つできてしまっている場合、構成プロファイルに設定したVPNのパラメータのいずれかに誤りがあり、Catoクライアントがそのプロファイルを参照できていない状態です。パラメータを見直します。 Catoクライアントの認証画面で「Failed to authenticate with Certificate」と表示され接続できない デバイス証明書は認識されていますが、CMAにアップロードされたCA証明書で検証できません。 以下をご確認ください。 デバイス証明書とCA証明書の紐づきが正しいか (異なるCAをアップロードしていないか) 。 よくある例として、デバイス証明書に署名しているのは中間CAなのに、中間CA証明書ではなくルートCA証明書をアップロードしてしまっていないか。 デバイス証明書、CA証明書ともに有効期限内か。 まとめ iPhoneでのデバイス証明書認証は、MDMの利用が必須であることから、他OSより少し手間がかかります。 MDMでうまくいかない場合には、切り分けとして、シンプルなApple Configuratorでの構成プロファイル作成をお試しください。
新年明けましておめでとうございます。SCSKの池田です。 新年早々、能登での大地震があり、今この時点においても余震が続いております。 亡くなられた方々に心からお悔やみを申し上げるとともに、被災された皆様、ならびにそのご家族の皆様に心よりお見舞い申し上げます。 皆様の安全と被災地の一日も早い復興を心よりお祈り申し上げます。  さて前回は、スプリットブレインを防ぐために「Quorum/Witness」機能が有効であることをお伝えしました。2台のサーバで構成するが故に、どちらのサーバがActiveであるかを判断する機能が必要だったというお話しでした。 7回目の今回は、なんと たった1台で可用性を向上 させることができるLifeKeeperの姉妹製品 Single Server Protection をご紹介します。 Single Server Protectionとは Single Server Protection(略してSSPとも呼びます) とは、(くどいようですが) 1台のサーバで可用性を高めることができる 製品なのですが、どのようにして実現しているのでしょうか。 構成と動作の流れはこんな感じです。 前提:1台のサーバにSSPと冗長化したいミドルウェアを実装しておく (1)SSPが冗長化対象のミドルウェアの状態を定期的に監視 (2)ミドルウェアの異常を検知すると、ミドルウェアを再起動し、正常状態に戻るかを確認 (3)正常状態に戻った場合は、処理はここで終了。まだ異常事態が続いている場合はOSを再起動 (4)OS再起動後はSSPの機能により、対象のミドルウェアなど、自動起動し、正常状態に戻ったことを確認   動きとしては、とてもシンプルですね。 以前「 なぜAWS(パブリッククラウド)でLifeKeeperが有効なのか! 」の回でもお伝えしましたが、AWSですと「責任共有モデル」の考え方により、ミドルウェアレイヤーはユーザー側の責任範囲となります。SSPはLifeKeeper同様に、見落としがちなミドルウェアの可用性をシンプルな仕組みで安価に高めることのできる製品なのです。 SSPはコスパが良い! 直前で「安価」とお伝えしましたが、SSPはコスパがすごく良い製品なんです。 サイオステクノロジーが公開している定価をご覧いただきますね。 製品名 定価 Single Server Protection for Linux \200,000 Single Server Protection for Linux サポート1年 \50,000 Single Server Protection for Windows \200,000 Single Server Protection for Windows サポート1年 \50,000 桁が間違っているのではないかというレベルのお安さですよね! 1台構成ですので、 サーバの初期費用もランニングコストも1台分で済みます し、 導入する ミドルウェアのライセンス費や保守費も1台分で済みます 。 さらにこの製品には、LifeKeeperでは有償オプション製品となるARKも一部無償で同梱されているというサービスっぷり! ただしLinuxとWindowsでは同梱されているARKが異なりますのでご注意くださいね。 製品名 Red Hat Enterprise Linux Windows Apache Web Server Recovery Kit 〇 ー Microsoft IIS Recovery Kit ー 〇 DB2 Recovery Kit 〇 ー Oracle Recovery Kit 〇 〇 MySQL Recovery Kit 〇 ー PostgreSQL Recovery Kit 〇 〇 SQL Server Recovery Kit 〇 〇 Sybase ASE Recovery Kit 〇 ー NFS Server Recovery Kit 〇 ー Network Attached Storage Recovery Ki 〇 ー WebSphere MQ Recovery Kit 〇 ー それと保守についても注意が必要です。LifeKeeperの場合は、重大障害発生時に24時間365日のサポートを受けることができますが、 SSPの場合は平日日中サポートのみとなってしまいます。 GUIはLifeKeeperとほぼ同じで判りやすい LifeKeeperの管理GUIはとても判りやすいことで有名(?)ですが、SSPは、LifeKeeperの姉妹製品だけあって、GUIの判りやすさも受け継いでいます。以下の様にリソースの依存関係もツリー構造で表現されているので、視認性が高く、これまでLifeKeeperの運用をされていた方はもちろんのこと、初めてお使いになる方でも、すぐに使いこなせる様になると言っても過言ではありません。 まとめ 今回は、LifeKeeperの姉妹製品であるSingle Server Protectionについてご紹介しました。コスパがものすごく良い製品ですので、LifeKeeperほどしっかりした可用性は必要ないけど、AWSなどパブリッククラウドではカバーしないミドルウェア領域までの可用性を高めたいとお考えのシステム担当者様にはうってつけな製品ではないでしょうか? まとめますと SSPは ・たった1台で可用性を高められる ・ライセンス、保守費も安く、一部のARKも同梱されているのでコスパがとても良い ・サーバ自体の費用やミドルウェアのライセンス、保守費も1台分でOK ・LifeKeepeの管理GUIとほぼ同じなので、導入や運用移行の敷居が低い ・保守は平日日中のみなので注意が必要 次回は、第6回でお伝えした Quorum/Witness の詳細について、もう少し掘り下げてお伝えしようと思います。 乞うご期待!! SCSK LifeKeeper公式サイトはこちら
こんにちは、自称ネットワークエンジニアの貝塚です。 AWS環境において、会社間でVPC同士を接続したいということはないでしょうか? 多くの場合、以下の記事で解説されているVPCエンドポイント(PrivateLink)を用いるのが最適な手段ではないかと思います。 Amazon VPC エンドポイントについて整理してみる VPC エンドポイントの役割について説明したいと思います。 blog.usize-tech.com 2023.12.10 PrivateLinkを使用すれば互いに相手側のIPアドレスは隠蔽されるので、IPアドレス被りを心配する必要もなく、私のようにネットワーク設計を考える立場の人間からするととてもありがたいサービスです。 PrivateLinkが使えない場合どうするか? しかし、PrivateLinkはTCP通信にしか対応していないため、UDPを通したい場合には使用できません。 また、通信対象サーバが複数ある場合は、原則、サーバごとにPrivateLinkの作成が必要になりますし、逆方向の通信が発生する(A社からB社方向へコネクションを開始するだけではなく、B社からA社方向へコネクションを開始する)場合、逆方向のPrivateLinkも必要です。このように通信要件が多くなるとPrivateLinkの管理が逆に大きな負担になってきます。(PrivateLinkのエンドポイントサービス側にはELBが必要なので、料金面の負担も大きくなるかもしれません) NATして互いのIPアドレスを隠蔽できる。(ソースNATとデスティネーションNATが両方できる) UDPを通せる。 双方向通信に対応できる。(1対1NATができる) インターネットは通らないようにする。 上記条件を満たすソリューションとして 接続したいVPCの間にNAT用EC2インスタンスをデプロイした中間VPCを設け、VPC Peeringで接続する方式 を考えてみました。(下図) 今さらNATインスタンス ……非常に泥臭いですね。 EC2を1台管理する手間が増えますし、(直接聞いたことはないですが)AWSはEC2インスタンスで1対1NATすることをあまり推奨していないような感じがします。 が、必要とあらば仕方ありません。 以下、NATインスタンス以外(VPC、サブネット、ルートテーブル、VPC Peering、NATインスタンス以外のEC2インスタンス、EC2に適用するセキュリティグループ、など)は既に構築済みという前提で、NATインスタンスの構築手順を解説します。 VPC Peeringの構築やVPC Peeringした際のルートテーブルの設定などは、インターネット上にブログ記事が多数存在しますので、それらを調べてみてください。 また、インスタンスへのアクセス手段も本記事では解説しておりませんが、VPC内にエンドポイントを作成してセッションマネージャーで接続する、インターネットゲートウェイをアタッチしてインターネットからsshするなどでアクセスできるようにしてください。 EC2インスタンス作成 Linux (Amazon Linux 2023)のAMIからEC2インスタンスを作成します。 作成時に「高度なネットワーク設定」を開き、セカンダリIPを「自動で割り当てる」、IP数は今回2を指定します。 その他は特に注意事項ありません(インスタンスにアクセスできるように適切にセキュリティグループやIAMインスタンスプロファイルの指定はしてください)。 割り当てられたセカンダリIPは、EC2インスタンスの「ネットワーキング」タブから確認することができます。今回の検証では、10.33.1.145と10.33.1.151が割り当てられました。 iptablesの設定 NATインスタンスにログインしてNAT設定を行います。 今回は、NAT機能を実現するためにiptablesを使用しますが、Amazon Linux 2023にはデフォルトでインストールされていないので、yumを使用してインストールします。 sudo yum install -y iptables-services iptablesを起動します。 sudo systemctl start iptables IPパケットを中継する必要があるので、IPフォワーディングを有効にします。 sysctl コマンドで有効にしただけでは再起動で設定が消えてしまうので、/etc/sysctl.conf にも書き込んでおきます。 sudo sysctl -w net.ipv4.ip_forward=1 | sudo tee -a /etc/sysctl.conf 次に、NATの設定を入れます。 A社のIP 10.32.1.157を中間VPCの10.33.1.145にアドレス変換するようにします。 10.32.1.157が送信元の時に10.33.1.145に変換する設定(ソースNAT)と、10.33.1.145が宛先の時に10.32.1.157に変換する設定(デスティネーションNAT)の2行必要です。 sudo /sbin/iptables -t nat -A POSTROUTING -s 10.32.1.157 -j SNAT --to-source 10.33.1.145 sudo /sbin/iptables -t nat -A PREROUTING -d 10.33.1.145 -j DNAT --to-destination 10.32.1.157 同様に、B社のIP 10.34.1.125を中間VPCの10.33.1.151にアドレス変換するようにします。 sudo /sbin/iptables -t nat -A POSTROUTING -s 10.34.1.125 -j SNAT --to-source 10.33.1.151 sudo /sbin/iptables -t nat -A PREROUTING -d 10.33.1.151 -j DNAT --to-destination 10.34.1.125 念のためここまでに入れたNAT設定を確認してみます。以下のようになっているはずです。 [ec2-user@ip-10-33-1-124 ~]$ sudo iptables -vL -t nat Chain PREROUTING (policy ACCEPT 2 packets, 702 bytes)  pkts bytes target     prot opt in     out     source               destination     0     0 DNAT       all  --  any    any     anywhere             ip-10-33-1-145.ap-northeast-1.compute.internal  to:10.32.1.157     0     0 DNAT       all  --  any    any     anywhere             ip-10-33-1-151.ap-northeast-1.compute.internal  to:10.34.1.125 Chain INPUT (policy ACCEPT 0 packets, 0 bytes)  pkts bytes target     prot opt in     out     source               destination Chain OUTPUT (policy ACCEPT 422 packets, 29626 bytes)  pkts bytes target     prot opt in     out     source               destination Chain POSTROUTING (policy ACCEPT 422 packets, 29626 bytes)  pkts bytes target     prot opt in     out     source               destination     0     0 SNAT       all  --  any    any     ip-10-32-1-157.ap-northeast-1.compute.internal  anywhere             to:10.33.1.145     0     0 SNAT       all  --  any    any     ip-10-34-1-125.ap-northeast-1.compute.internal  anywhere             to:10.33.1.151 OS再起動後もiptablesを自動起動しNAT設定が反映されるようにします。 sudo systemctl enable iptables sudo service iptables save 疎通確認 A社EC2から10.33.1.151にpingを実行してみます。 B社EC2でtcpdumpを実行してみると、10.33.1.145からpingが来ているので、意図通りのNATができていることが分かります。 B社EC2から10.33.1.145にpingを実行してA社EC2でtcpdumpを実行してみると、逆方向も確かに10.33.1.151からpingが来ており、意図通りのNATができていることが分かります。 まとめ 以上、NATインスタンスの構築手順でした。 なお、ここで示したソリューションは検証用のものであり、実際にビジネスで使用する場合にはNAT以外にも例えば以下のような考慮点があります。ご注意ください。 中間VPCのIPアドレスは両社で合意しておく必要がある。 VPC間通信のセキュリティ。 NATインスタンスは誰が管理するのか。(NATインスタンスを管理している側は容易にセキュリティ侵害できてしまう点に注意)
こんにちは。SCSKの清水です。 Google Cloud のカンファレンスイベント Google Cloud Next Tokyo’23 が国内4年ぶりに東京ビックサイトにて開催されました。 Platinumスポンサーとして当社も出展をした本イベントですが、当社登壇のパートナーセッション「製造業 DX 関係者必見!Google AI を組み込み、生産プロセスを変革するまでの七転び八起き」では CSAT(顧客満足度)にて最高評価をいただくことができました。 製造業向けの内容としてご紹介をしましたが、 AIの活用に悩まれる全企業の皆様 に向けて是非知っていただきたい内容になります為、 改めて本ブログを通して多くの皆様へ有益な情報をお届けできればと思います! Google Cloud Next Tokyo ’23 セッションについて Google Cloud Next Tokyo ’23は、基調講演、セッション、ブレイクアウトセッション、ハンズオンセッション、Expoブース、Innovators Hiveと盛りだくさんの内容で構成されていました。各セッションではテーマは様々でしたが、やはりAIに関する内容が多い印象を持ちました。そんな中、SCSKもパートナーセッションでやはりAIというテーマで40分間登壇をしております。 勿論リハーサルもあったのですが、やはりその時に前に立つのと本番で前に立つのでは視界も緊張感も大違いですね…!!! 圧巻の景色を前に、お集まりいただいた観客の皆様へ一つでも情報を持ち帰りいただきたい一心で当日ご説明いたしました。 当社はExpoブースへの出展も行いました。AIサービスのデモ展示は当日非常に好評でしたのでこちらも是非ご確認ください! 【GCP】【AIML】Google Cloud Next Tokyo ’23に出展しました!!!!! Google Cloud のカンファレンスイベントGoogle Cloud Next Tokyo'23が東京ビックサイトにて開催されました。 2日間に及んだGoogle Cloud Next Tokyo'23での当社の出展内容をご紹介します。 blog.usize-tech.com 2023.11.24   SCSKセッションの中身をご紹介 製造業の某社様に向けて行った実際の導入事例を通して、 Google AIを組み込み生産プロセスを変革するために考えるべきポイントや、リアルな躓きや起き上がりを語りました。 大きく5つの章立てに分かれており、全量を文字ベースで見るのは大変だと思いますのでそれぞれ簡潔にご紹介いたします。 なお、当日の内容はオンデマンド配信としてGoogle Cloud Next Tokyo ’23の公式HPに掲載されておりますので、 フルバージョンはこちらからDay2のパートナーセッションをご確認ください。 Google Cloud Next Tokyo ’23 【Google Cloud Next Tokyo ’23】2023 年 11 月 15 - 16 日に東京ビッグサイトで開催 cloudonair.withgoogle.com ※登録がお済でない方は、招待コード:FY23nx_P030 をご入力の上ご登録ください。 本セッションでお伝えしたかった事 当社セッションで何をお伝えしたかったのか、ずばり結論から申し上げます。 「生産プロセスが抱える課題に対して、省人化・コスト削減・生産性向上を当社と共に実現する方法 」 です。 はい、ピンと来ていない方も大丈夫です。順を追って紐解いていきましょう! 私たちが考える製造業の課題 まずは、製造業界を取り巻いている課題を整理していきます。製造業様向けのセッションでしたので、「製造業の課題」と書いてありますが、内容はその他業界の皆様にも通ずる課題と思っています。 上図はGoogleのGenAI「Bard」にも聞いた結果となっています。 少子化の影響で労働力人口の減少は不可避(総務省のデータでは2020年~2040年にかけて20%減少)である事、労働力人口減少に拍車をかけるように熟練工や技能人材が退職する等の影響で技術継承が難しくなってきている、さらにその熟練工や技能人材を抱えるために人件費がかかる といった、労働力に関わる問題が顕在化してきています。これらの課題にさらされている企業では、 労働力人口減少に対しての対策を考え続けなければならない 属人化する業務の置き換わりを検討する余地が残っている 本当に人がやるべきことか業務の仕分けを行う必要がある という状態になっていると思っています。 では、どう解決していくか。弊社では一例として下記のような業界動向も踏まえて、AIの活用にヒントがあると考えています。 DX推進というキーワードでIT投資が進んできた ⇒ クラウドに投資をしている企業も多数存在 ⇒ クラウドではAIに必要なデータを蓄積する基盤も用意しやすい ⇒ 昨今のGenAI登場によりクラウドAIサービスの拡充も進んできた ⇒ 今まで高かったAIへの参入障壁が下がって上記の課題解決を図りやすくなった!   労働力に関わる問題はクラウド利用が進んできた今こそ、AIによる解決を図ることができそう   AIサービスによる自動化の可能性 AIで解決を図れそうだと言っても実際、「AIで具体的にどんなことができるの??」と思われる方が大半かと思います。GoogleのAIでは幅広いタスクに対して、それぞれ処理を行ってくれるAIサービスは既にかなり出てきている状態です。ここではそのうちの一つ、製造業の外観検査工程を手助けする精度の高いAIを紹介いたします。 製造業のお客様に多い、「不良品を保管していないので、AIに使う画像も用意できない…」、「工場環境はインターネットに繋がっていないのでクラウドAIサービスを使うことができない」等の課題を解決しながら高い性能を誇るという、これだけあれば良いじゃん!となりかねない優れものになります。弊社も自信をもって数々の検証を実施して参りました。 しかし、実際は本番化まで至らないパターンが多かったということでたくさん転んできました。 AI処理以外に画像をアップロードする手間が残ってしまう 検査対象が細かいので、画像処理が必要 目検よりも費用対効果が見込めない etc… これらは一例にすぎませんが、なぜ本番化につながらないのか弊社なりに学んできました。 結局優れたAIだけでは、課題解決ができない AI単体で課題解決できるケースはかなり少なく、実際にAIを業務に活用する際には3つのポイントが重要です。 AIがどの工程のどの作業を担うのかを決めないといけない(AI処理) AIに使用するインプットデータを整えることが必要(AI処理の前工程) インプットデータや処理したデータを蓄積して活用する(AI処理の後工程) これらを全て見据えることで、予算化も含めてAIの導入検討ができるようになると学んできました。 AIによる課題解決を図る場合は、AI処理・AI処理の前工程・後工程 これらすべてを見据えて進めることが重要   導入事例のご紹介 ご紹介した事例は「某製造業様へ行った外観検査ソリューション導入プロジェクト」となります。 お客様は製品の外観検査工程において、こんな背景と課題を抱えていらっしゃいました。 製造パーツのワレ検査を目検で実施している 技能人材、個人の検査スキルに頼って検査している 上記に伴い製品を撮影・データを蓄積する環境は無い状態 これらの背景・課題に対して実施した内容はシンプルです。 外観検査工程にAIを組み込み省人化 データドリブンな工場運営の実現 これにより原価削減・品質向上・AIを利用したマネタイズまで見据え、課題解決を図ることができそうという事で進めて参りました。 では実際どのような解決策となったのか。下図をご覧ください。 前章の学びをしっかりと活かして、「外観検査のクラウドAI部分に留まらない、Input/Outputデータを意識した製造工程の確立」を図ることで成功へと繋げました。弊社としてもこれまで持っていなかった知見の獲得につながった部分もあり、「製造現場へのAI導入」のケイパビリティを獲得することに成功しました。これからもより一層、皆様へAI導入のご支援をして参ります。 AI処理前後も検討/導入する事で課題解決に成功。SCSKはAI導入の新たな知見を獲得し全体の企画立案と推進を行うことが可能に! ただ、 この図もいきなりポンと出てきたわけではありません 。 お客様のご協力はもちろん、Google Cloud サービスの活用や協業企業とも協力しながら 文字通り七転び八起き、「転んで起き上がる」を繰り返して この全体像に辿りつきました。 ここで詳細はお伝えしませんが、セッション当日は一つ一つどうやって実現に至り、 最終的にお客様へどのような結果をもたらすことに成功したか紹介しています。是非オンデマンド配信にてご覧ください。 Google Cloud Next Tokyo ’23 検索 SCSKを選ぶ理由 前章で、SCSKはAI導入に関するケイパビリティを獲得したという内容をお伝えしました。 ここで一つ、こんな疑問が浮かぶ方もいらっしゃるかもしれません。 「導入を支援してくれるのは分かったけど、結局どこまで支援してくれるのSCSK?」 ご安心ください!!弊社ではクラウドAI体験から、運用保守までサポートさせていただく事が可能です。 使い始めから使いこなすまで、サポートいたします! 勿論ですが、既に取り組まれている範囲もお伺いした上で、お客様毎に必要なものを必要なだけご提案させていただきます。 AIというのはビジネスへの活用、業務への組み込み・適用が難しいサービスの一つだと弊社では考えておりますし、実際悩まれている企業の方々も多くいると存じます。課題解決を図ることができそうなベンダー様、あるいは弊社へご相談いただくことで、今お抱えのお悩みが解決されることを願っております。 USiZEパブリッククラウドモデル(Google Cloud)│SCSK株式会社|サービス|クラウド移行だけでは描けない、理想のDXを実現する Google Cloud の導入支援から保守運用・最適化まで、ワンストップでご提供するサービスです。 SCSKのノウハウや体制を有効活用してお客様のビジネスに合わせてお届けし、お客様と一緒にDX推進を行います。 www.scsk.jp   おわりに いかがでしたしょうか? 製造業の企業の皆様だけでなく、 AIを活用したいと考えているすべての企業様にお伝えしたい内容 でした。 当日ご参加いただいた企業の皆様には満足をいただけた結果となり、非常に嬉しく思います。 オンデマンド配信が公開されたことをきっかけに、より多くの方々に情報が届けばと思いこのブログを執筆いたしましたので、 是非、同様のお悩みをお抱えの方々にご紹介いただくと共に、この内容が皆様のAI活用の成功への一助となれば幸いです。 最後まで読んでいただきありがとうございました!
こんにちは、SCSKでAWSの内製化支援『 テクニカルエスコートサービス 』を担当している貝塚です。よろしくお願いします。 東京リージョンのNetwork Firewallでアウトバウンド(Egress) TLS インスペクションが使えるようになりましたね。 AWS Network Firewall egress TLS inspection is now available in all regions aws.amazon.com TLSインスペクションとは SSL/TLSで暗号化された通信内容をチェックする機能です。 HTTPSなどのSSL/TLSで保護された通信は、クライアント-サーバ間で通信内容が暗号化されているため、通常、中継するネットワークデバイスで通信内容をチェックすることができません。SSLサーバ証明書をうまく使って中継デバイスで通信内容をチェックできるようにしたのがTLSインスペクションです。   インバウンド(Ingress) TLSインスペクション これまで、AWS Network Firewallは、インバウンド(AWSのドキュメントではIngressと呼ばれる)のTLSインスペクションにのみ対応していました。Ingress TLSインスペクションは、自サイトのウェブサーバ等を保護するために使用されます。たとえば自サイトでwww.example.comというサーバ証明書をインストールしたサイトを運営しているとしたら、Network Firewallにも同じwww.example.comの証明書をインストールしてやります。Network Firewallはウェブサーバに向かう通信を、そのサーバ証明書を用いて復号化し、検査した後に再びサーバ証明書を用いて暗号化して、何食わぬ顔でウェブサーバに転送します。 検査したい対象サーバのサーバ証明書を入手しなければ検査ができないので、必然的に自身の管理下にあるサーバしか検査対象にできませんでした。   アウトバウンド(Egress) TLSインスペクション 今回、新たに対応したのは、アウトバウンド(AWSのドキュメントではEgressと呼ばれる)方向、つまり、自分たちの管理下にあるクライアントPCが、自分たちの管理下にないSSLサーバ証明書をインストールした外部のウェブサーバと通信するときに通信内容を検査できるようになりました。 方式としては、Network FirewallがクライアントPCに代わって外部のウェブサーバwww.example.comとTLS接続を行い、Network Firewallは自身でwww.example.comのサーバ証明書を発行してクライアントPCとの間にTLS接続を確立します。Network FirewallがクライアントPCとのTLS接続、サーバとのTLS接続、両方を終端するため、Network Firewallで通信内容が検査できるということになります。 動的にサーバ証明書を発行するためにNetwork Firewallには認証局(CA)証明書をインストールする必要があります。 以下、Egress TLS インスペクション機能を検証したときの設定手順と動作確認について説明しますが、Network Firewall自体は既に作成したことがあるか、他のドキュメントを参考にして新規作成できることを前提に、キモとなる部分のみを解説します。 AWS Network Firewallについて学んでみた! AWS Network Firewallについて、学んだことをアウトプットしたいと思います。 blog.usize-tech.com 2023.12.24   Egress TLSインスペクション設定の流れ Egress TLSインスペクション機能検証のために実施した設定は以下の通りです。Network Firewall自体は既にデプロイされている前提で、TLSインスペクションの設定手順のみを記載しています。 プライベート認証局のルート証明書を作成する ACMに、作成したルート証明書をインポートする Network FirewallのTLS検査設定を作成する Network Firewallのファイアウォールポリシーを作成する Network Firewallにファイアウォールポリシーを関連付ける   動作確認の流れ Egress TLSインスペクションの動作確認で実施した内容は以下の通りです。 クライアントPCにルート証明書をインストールする クライアントPCからHTTPSアクセスして証明書を確認する Network FirewallのルールグループにHTTPの内容をチェックするルールを追加する HTTPの内容をチェックできていることを確認する   Egress TLSインスペクション設定 プライベート認証局のルート証明書を作成する Egress TLS インスペクションには、プライベート認証局(CA)のルート証明書が必要になります。 作成は、こちらの記事を参考にさせていただきました。 プライベート認証局によるサーバー証明書の発行 プライベート認証局を構築して、Webサーバー向けのサーバー証明書を発行する手順について紹介します。認証局の証明書をWebブラウザやOSの証明書ストアに読み込むことで、自己署名証明書を使ったサーバーに、警告なしにアクセスすることができます。 pvision.jp 「4.2 認証局の証明書の作成」まで実行し、証明書と秘密鍵を作成します。 ACMに、作成したルート証明書をインポートする AWSマネジメントコンソールからACM(AWS Certificate Manager)を起動して「インポート」をクリック、「証明書本文」と「証明書のプライベートキー」に作成した証明書、秘密鍵を張り付けてインポートを完了させます。   インポートした証明書は以下のようになりました。 Network FirewallのTLS検査設定を作成する AWSマネジメントコンソール、ネットワークファイアウォールのTLS検査設定から「TLS検査設定を作成」をクリックします。 「アウトバウンド SSL/TLS インスペクション用の CA 証明書」で、インポートしたCA証明書を選択します。 「TLS 検査設定の詳細」を埋めた後、スコープ設定で検査対象とする送信元/送信先IPとポートを指定します。検査対象としたいトラフィックの範囲をきっちり定義してあげましょう。ここでTLS以外のトラフィックも含めてしまうと、それらは正常に通信できなくなってしまいます。基本的には送信先ポートを443番のみに限定しておくのがよいでしょう。 以降の設定項目も適切に入力して、TLS検査設定を作成します。 Network Firewallのファイアウォールポリシーを作成する ファイアウォールポリシー作成時にTLS検査設定を指定します。既に作成済みのファイアウォールポリシーにTLS検査設定を追加することはできないので、使用中のファイアウォールポリシーがある場合はあきらめてファイアウォールポリシーを作り直します。 作成途中で「TLS検査設定を追加」というステップがありますので、先ほど作成したTLS検査設定を指定します。それ以外は通常のファイアウォールポリシー作成と同様の手順で、ファイアウォールポリシーの作成を完了させます。 Network Firewallにファイアウォールポリシーを関連付ける 作成したファイアウォールポリシーをNetwork Firewallにひもづけます。 手順はNetwork Firewallのドキュメントなどをご参照ください。   動作確認 クライアントPCにルート証明書をインストールする プライベートCAの発行したサーバ証明書が提示されると、クライアントPCのウェブブラウザで警告が出てしまうので、クライアントPCにはルート証明書をインストールします。 下記サイトを参考にして、「プライベート認証局のルート証明書を作成する」のところで作成したルート証明書を、動作確認に使用するクライアントPCにインストールしました。 Windows環境にルート証明書をインストールする方法 knowledge.digicert.com クライアントPCからHTTPSアクセスして証明書を確認する クライアントPCからウェブサーバにHTTPSアクセスします。 今回は、自前で立てたウェブサーバの前にELBを置き、ACMで発行した証明書をELBにインストールしてHTTPS化しています。 まずはTLSインスペクション設定前の状態を確認しておきます。クライアントPCのウェブブラウザからこのウェブサーバにアクセスして証明書を確認してみると、たしかにAmazon(ACM)が発行した証明書です。 次に、TLSインスペクション設定後にアクセスし証明書を確認します。発行者(Issued By)が先ほど作成したCAになっているのが分かります。うまくいっているようですね。クライアントPCにCAのルート証明書をインストールしているので、証明書の警告も表示されません。 Network FirewallのルールグループにHTTPの内容をチェックするルールを追加する Network FirewallのHTTPチェックのルールで、HTTPSの通信をチェックできるようになっているはずです。今回の検証では、URIをチェックしてindex.htmlへのアクセスはドロップし、scsk.htmlへのアクセスは許可するルールにしてみます。 ルールグループのルールに、以下のSuricata互換ルールを追加しました。TLSは終端しているのでプロトコルにはtlsではなくhttpを、ポート番号はhttps通信のデフォルトでTCP 443を使っているので443を指定しています。 drop http $HOME_NET any -> $EXTERNAL_NET 443 (msg:"Detected access to tcp port 443 /index.html"; http.uri; content:"index.html"; sid:1000102; rev:1;) alert http $HOME_NET any -> $EXTERNAL_NET 443 (msg:"Detected access to tcp port 443 /scsk.html"; http.uri; content:"scsk.html"; sid:1000111; rev:1;) pass http $HOME_NET any -> $EXTERNAL_NET 443 (http.uri; content:"scsk.html"; sid:1000112; rev:1;) HTTPの内容をチェックできていることを確認する /index.htmlにアクセスしてみます。以下の通りコンテンツは表示されません。 /scsk.htmlにアクセスしてみます。こちらは問題なくコンテンツを表示できました。 Network Firewallのアラートログを確認したところ、以下のログが確認できました。意図通りにHTTPの内容をチェックし、URIに基づいて通信を制御できていることが分かります。   まとめ Network FirewallのEgress TLS Inspectionについて、簡単な検証の結果をまとめてみました。 AWSのマネージドサービスを使って高度なネットワークセキュリティを確保したいというニーズはわりとあるのではないかと感じているので、Network Firewallが今後さらに機能を充実させていくことを期待しています。
こんにちは、SCSK 池田です。 早いもので2023年も終わりを告げようとしています。皆さんにとってはどのような1年でしたか? 私は、このTech HarmonyでLifeKeeperに関するブログを投稿し始めた思い出深い1年となりました。 さて前回は、前田さんより、AWS環境におけるLifeKeeperで対応可能ないくつかの接続方法についてお伝えしました。 6回目の今回は、HAクラスター構成の敵とも言える「 スプリットブレイン 」についてLifeKeeperでどのよぅな対策がなされているのかについてお伝えします。 スプリットブレインとは? 「スプリットブレイン?」「脳が分かれる?」。またまた聞きなれない用語が出てきました。「 スプリットブレイン 」とはどのような状態なのでしょうか? HA クラスターシステムは、多くの場合において、2台のサーバでアクティブ-スタンバイの構成となり、2台のうちのどちらか一方だけのサービスが起動している状態です。ところがある条件下において、2台ともがサービスを起動しようとしてしまい、正しくサービスが提供できなくなることがあります。 この状態のことを「 スプリットブレイン 」もしくは「 スプリットブレイン シンドローム 」と呼びます。 本来1台だけでサービス提供するところ、 誤って2台が提供しようとして障害になってしまうのは問題だね ではどんな時にスプリットブレインが起きてしまうのでしょうか? まず2台のサーバでクラスタを構成している前提とします。2台はお互いの死活状態を確認しています。 この動作をハートビートと言いますが、ネットワークの障害など何らかの原因によって、お互いの死活状態を確認できなくなった場合に、それぞれのサーバは、相手のサーバが停止しサービス提供ができなくなったと判断し、自らが稼働系になろうとします。これによってスプリットブレイン状態になってしまうのです。 スプリットブレイン状態となった時に一番怖いのが、両方のサーバから共有ディスクに書き込んだ場合です。これが起きてしますと最悪共有ディスク上のデータで不整合が発生して、データ破損に繋がってしまいます。 せっかくのHAクラスタ構成なのに データの不整合が起きてしまうのは避けたいわ LifeKeeper では、この様なスプリットブレインを発生させないために、Quorum/Witness(クォーラム/ウィットネスと呼びます) をいう機能を利用することが出来ます。 Quorum/Witnessとはなに? また新しい言葉が出てきましたが「 Quorum/Witness 」とは、スプリットブレインが発生した場合に、どちらのサーバが稼働系になるべきかを判断する為の機能となります。 「Quorum」の主な機能は、多数決の仕組みを使って稼働系となるべきサーバを決定する機能です。「Witness」は障害が発生したノードのステータスについて「セカンドオピニオン」を取る機能です。「Quorum」による多数決だけでは、本当に稼働すべきサーバか判断が付きかねる場面において、障害が発生していると思われるサーバについて、Witnessサーバの「セカンドオピニオン」を取ることで、より確実な判断をすることができるようになります。 まずは一般的な障害シナリオを見てみましょう。 シナリオ1 サーバAと他の全ノードとの間の通信に障害発生(サーバAに障害発生) シナリオ2 サーバAとサーバBの間の通信で障害発生 次に、サーバ間の通信で障害が発生したものの、Quorum/Witnessサーバがいるお陰で、不要なフェイルオーバを抑止するパターンをご紹介します。 シナリオ2の場合では、もしもQuorum/Witnessサーバが存在しなかった場合は、サーバAで継続してサービス提供可能にも関わらず、フェイルオーバが発生してしまい、一時的ではありますが、サービスが利用できない時間帯ができてしまいます。 Quorum/Witness機能を実装するために必要な費用及び維持していく費用と、要求する可用性レベルとの天秤になるポイントとなりますので、お客様との十分なすり合わせが必要となります。 まとめ 今回は、Quorum/Witness機能についてご説明しましたがいかがでしたでしょうか? システムとしてデータの整合性や一貫性が損なわれてしまうのは一大事ですよね。 非常に重要な機能ではありますが、LifeKeeperではQuorum/Witnessがオプションとして用意されているので、簡単に組み込むことができます。 まとめますと Quorum/Witnessは、スプリットブレイン対策として有効な機能 Quorumは、多数決により、どのサーバでサービス提供すべきかを判断する機能 Witnessは、第三者を介して相手ノードの状態についてセカンドオピニオンを取る機能 次回は、「たった1台で可用性を高められる!? ~ Single Server Protection ~」についてお伝えします。お楽しみに!! 良いお年を!!
こんにちは、SCSK株式会社の大石です。 Zabbixにはディスカバリ機能があり、指定のネットワーク内から監視対象を見つけてホスト登録したり、テンプレートをリンクさせることもできますが、指定の時間で更新をかけることができなかったりホストを削除したい場合、すぐに消す場合はIPアドレスを除外→ホスト削除の操作が必要だったり、ちょっとだけ操作が必要になっています。 個人的にはホストだけ消して、IPアドレス除外を忘れて、後々復活。。。なんてことをやりそうです。 hostsファイルと同期取っておけば楽なのでは?と思いhostsファイルと同期とれるようにしてみました。 環境準備 以下のサーバを構築しておきます。 ZabbixServer6.0 (Redhat9)  監視対象: WindowsServer 2019 x 1 監視対象: Redhat9 x 2(うち1台はAgent無) 今回はpythonを使用するため、ZabbixServerにはpython3をインストールしておきます。 python3では以下のライブラリを使用します。 pyzabbix(zabbixのAPI使用する) pandas(hostsファイル加工用) subprocess(OSコマンド実行用) pyzabbixとpandasはインストールが必要なので、以下のコマンドでインストールしておきます。 ※あらかじめpipのインストールが必要です。 pip install pandas pyzabbix 実装 pythonでスクリプトを書いていきます。 まず、使用するライブラリをインポートしておきます。 import pandas as pd import pyzabbix import subprocess pyzabbixには、ZabbixWebコンソールのURLとログイン情報を指定します。 # Zabbixログイン情報 zapi = pyzabbix.ZabbixAPI("http://172.23.32.191/zabbix") zapi.login('Admin','zabbix') hostsファイルを取得し、Zabbixのホストには使用できない特殊文字を”_”に変換します。 # /etc/hostsファイル取得 df = pd.read_table("/etc/hosts",sep="\s+",header=None, index_col=None) # ホスト名の列に特殊文字(ドット、ハイフン、アンダーバーを除く)がある場合、アンダーバーに置換 df[1]=df[1].replace(r'[^a-zA-Z0-9_.-]','_',regex=True) hostsfile=df.iloc[:,[0,1]] ZabbixServerのホスト登録する関数です。 # ZabbixServer登録 def zabbix_regist(hostname,ipaddr,templateid): zapi.host.create( host=hostname, interfaces=[ { "type":1, "main":1, "useip":1, "ip":ipaddr, "dns":"", "port":"10050" } ], groups=[ { "groupid":"23" } ], templates=[ { "templateid":templateid } ] ) hostsファイルから、IPアドレスとホスト情報を取り出し、接続可否、OSの種類(WIndowsかLinux)などで振り分けて、登録します。 接続可能で、ZabbixAgentが使用できれば、WindowsとLinuxで分岐させて各Windows用Linux用でテンプレートを登録し、Agentが使用できない場合は、Pingテンプレートを割り当てます。 def main(): # hostsファイルから、1行ずつ2列目(ホスト名)を引数に、ZabbixServerからホスト情報を取得 for index,row in hostsfile.iterrows(): hosts=zapi.host.get( filter={ "host":[row[1]] } ) # ホスト情報がZabbixに登録されていない場合、対象のマシンの情報を取得する if not hosts: # fpingで接続状況を確認 ping_result=subprocess.run(["fping","-r","1",row[0]],capture_output=True,text=True).stdout # 接続できる場合、ZabbixAgentの有無を確認 if ping_result.find("alive"): zabbixagent_ping=subprocess.run(["zabbix_get","-s",row[0],"-p","10050","-k","agent.ping","-t","1"],capture_output=True,text=True).stdout # ZabbixAgentが起動されている場合、LinuxかWindowsか確認し、それぞれのOS事のテンプレートを指定し、ZabbixServerに登録 if zabbixagent_ping: #監視退場のOS情報を取得 os_info=subprocess.run(["zabbix_get","-s",row[0],"-p","10050","-k","system.uname","-t","1"],capture_output=True,text=True).stdout if os_info.startswith("Linux"): # 100001がWindos用の監視テンプレートのID zabbix_regist(row[1],row[0],10001) elif os_info.startswith("Windows"): # 100081がWindos用の監視テンプレートのID zabbix_regist(row[1],row[0],10081) # ZabbixAgentが起動されていない、またはインストールされていない場合、Ping監視テンプレートのみ登録する。 else: # 10186がPing監視テンプレートのID zabbix_regist(row[1],row[0],10186) ZabbixServerから登録されているホスト情報を取得し、hostsファイルに登録されていないホストは削除します。 # /etc/hostsファイルに登録されていないホストをZabbixServerから削除する # すべてのホスト情報を取得 allhosts=zapi.host.get() for host in allhosts: # /etc/hostsファイル内に、取得したホスト情報が含まれていないのか確認 # 含まれていない場合、該当するホストを削除する。 if not (hostsfile[1] == host["host"]).any(): zapi.host.delete(host["hostid"]) スクリプト実行 hostsファイルは以下の様に記述しておきます。 127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6 172.23.32.191 ZabbixServer 172.23.32.187 testLinux-Agent 172.23.32.232 testLinux-Agentless 172.23.32.190 TestWIN,SCSK Zabbixのホスト登録状況は以下の様にしておきます。 Zabbix Server(ホスト名: ZabbixServer)のみ残しておきます。 実装したファイル名は何でもいいですが、今回は「zabbix_autoregistration.py」としました。 以下のコマンドで実行します。 python3 zabbix_autoregistration.py 実行すると以下の様に登録されます。 では、hostsファイルから、ホストを削除、ホスト名の変更をして、再実行します。 hostsファイルは以下のようにします。 127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6 172.23.32.191 ZabbixServer 172.23.32.187 testLinux-Agent 172.23.32.190 TestWIN,SCSKTEST 「TestWIN,SCSK」→「TestWIN,SCSKTEST」に変更しました。また、「testLinux-Agentless」を削除してみました。 この状態で再実行すると、以下の様になります。 「TestWIN,SCSKTEST」にホスト名が変更され、「testLinux-Agentless」が削除されました。 あとは、cronなどで、深夜帯に実行仕掛けておけば、指定の時間で同期取れるようになります。 課題 ホスト名変更は出来ているのですが、一回ホスト追加→削除で実現しているため、変更処理が必要です。 また、ZabbixServerを除外する処理はできていないので、この辺りを追加する必要があると考えています。 ネットワーク機器も対応できるようにしていきたいです。 今後の活動 課題の対処はもちろんですが、適用するテンプレートの選択をOSだけではなくて、ミドルウェアや物理・仮想等…サーバ環境によってテンプレートにできるようにしたいです。とはいえ、千差万別とある中、そのあたりを人が介すると難しいと思うので、もう少しやり方を考えて実装をしていきたいと思います。 SCSK Plus サポート for Zabbix SCSK Plus サポート for Zabbix 世界で最も人気のあるオープンソース統合監視ツール「Zabbix」の導入構築から運用保守までSCSKが強力にサポートします www.scsk.jp ★YouTubeに、SCSK Zabbixチャンネルを開設しました!★ SCSK Zabbixチャンネル 本チャンネルでは、SCSK株式会社でのZabbixに関するトレンド/事例紹介などを動画にまとめて取り上げております。 最新のトピックについては、以下の弊社HPもしくはツイッターアカウントをぜひ参照ください。 ツイッターアカウント: www.youtube.com ★Twitterに、SCSK Zabbixアカウントを開設しました!★ 【公式】SCSK Zabbix (@SCSK_Zabbix) / Twitter SCSKが提供するZabbixサービスのオフィシャルアカウントです。 #Zabbix #SCSKPlusサポートforZabbix #監視 #SCSK twitter.com
Catoクラウドの2024年2月に実施される価格改定について解説します(ただし、記事内で実際の価格については記載していません) 当社とご契約のお客様については、すでに本記事の内容および新価格体系を含む価格表のご提示をしております。 月例報告書サービスをご契約いただいているお客様については、すでに報告会でのご説明も実施しております。 当社とご契約のお客様で、ご説明がご希望の場合は、サービス窓口または当社担当者までご連絡ください。 はじめに 今回の価格改定については、Cato Networks社から2023年11月3日に Pricing Update として全世界のパートナーに対して一斉に通知が行われました。 後で紹介するリージョンの統廃合や、SiteライセンスのPoP接続帯域の統廃合、セキュリティオプションの統廃合、新サービスとして、XDR Security Pro、Endpoint Security(EPP)、Socket X1600 LTEモデル、そして、新しい価格体系および価格について発表が行われました。 日本国内においては、ディストリビュータ制度がとられているため、日本円での定価(メーカ希望小売価格)の提示があったのが、12月に入ってからです。 ちなみに、以前の記事にも記載しましたが、Catoクラウドの”定価”については、Cato Networks社の公式サイトでは価格を公開しておらず(”参考小売価格”は存在しません)、あくまでも”メーカ希望小売価格”となります。 まず、 価格は残念ながら 値上げ になっています 。 SCSKでは、2019年からCatoクラウドの取り扱いを開始しておりますが、2019年当時から、SiteライセンスのPoP接続帯域25Mbps(最低)は月額40,000円でしたが、2013年の今現在も同じ価格です。 2019年当時の円相場は1ドル110円前後でしたが、最近では、1ドル140~150円となっており、ドルに対して30~40%程度 円の価値が下がってしまっています。 直接ドルをベースに課金請求されるAWSやAzure、GCPなどのクラウドについては、ここ数年はリソースの利用が変わらないのに関わらず30~50%程度の値上げがありますので、Catoクラウドが2019年から4年間価格変更がなかったので頑張った方なのかも知れません。 今後もし円高に進めば、元の価格に戻るかと思いますが、少なくともいち早くSASE、Catoクラウドをご採用されていたお客様については、まさに先行者利益を得られたと言えます。   価格改定概要 それでは、今回の価格改定(Pricing Update)のアナウンスについて解説を行います。 Pricing Update アナウンスの主な概要は以下となります。 1. リージョンの統廃合 2. PoP接続帯域の統廃合 3. セキュリティオプションの統廃合 4. 新サービスのリリース   ・XDR Security Pro   ・Endpoint Security(EPP)   ・Socket X1700 LTEモデル リージョンの統廃合 現行は、11のリージョンでそれぞれ価格設定がされていましたが、2024年2月以降は、 3つのグループ ( Group1 、 Group2 、 Stand-alone Countries )となり、Stand-alone Countries(単独国)には、 中国 、 ベトナム 、 モロッコ の3ヵ国が含まれており、それぞれの国毎に価格設定がされているため、 5つの価格体系へ統廃合 されます。 Group1、Group2、Stand-alone Countriesの国(世界地図)は以下の通りです。 価格としては、(安価)Group1 < Group2 < Stand-alone Countries (高額)となっています。 Group1、2は、より大きなグループになったことで、Pooledライセンスの分配がしやすくなりました。 Pooledライセンスは、これまでリージョン単位(APJ、NAM、EUROPE等)で購入し、同一リージョン内でしか分配できませんでしたが、Group1、Group2で購入し、グループ内で分配を行うことが可能となりましたので、例えば、Group1でPooledライセンスを購入した場合、アメリカとヨーロッパで分配することが可能となりました。 ちなみに、Stand-alone Countries(中国、ベトナム、モロッコ)には、Pooledライセンスはございません。 PoP接続帯域の統廃合 Stand-alone Countriesを除く、Group1、Group2においては、現状の17の帯域契約メニューから、 9つの帯域契約メニューへ統廃合 されます。 Stand-alone Countries(中国、ベトナム、モロッコ)は、従来のGlobal/Regional毎の1Mbps単位での契約メニューです。 75Mbpsや、200M、300M、400M等の帯域メニューが無くなりました。500Mの次は、1,000Mbpsとなります。 既存のお客様については契約更新時に、新しい帯域での契約更新を行う必要がありますので、例えば、現在300Mをご契約の場合は、250M、または500Mのいずれかを選択いただき契約更新を行うことになります。 また、クラウドとの専用線接続であるCross-Connectについては、501Mbps以上の契約が前提となりますが、これまでの600Mのメニューが廃止されたため、1,000Mbpsでの契約を行う必要があります。 セキュリティオプションの統廃合 セキュリティオプション「NGAM」と「IPS」が「 Threat Prevention 」に統廃合されます。 以前、別々のセキュリティオプションだった「AM(Anti Malware)」「NGAM(Next Generation Anti Malware)」が「NGAM」に統合されましたが、今回は、さらに「NGAM」と「IPS」が統合されました。 IPSは、次々と機能拡張されおり、DNS Protectionや、Suspicious Activity(不審な活動)などの機能がリリースされていますが、今回Threat Intelligence(脅威インテリジェンス)、インライン AI/ML、アンチフィッシング機能も含めて、「Threat Prevention」となります。 また、セキュリティオプションについては、Group1、Group2で同じ価格体系(同じ価格)となっております。 既存のお客様については、「NGAM」と「IPS」が購入できなくなりますので、「Threat Prevention」の購入をご判断いただく必要があります。 ただし、契約期間中のお客様については、契約満了までは「NGAM」、「IPS」を個別に購入することは可能です。 セキュリティオプションには幾つかの前提条件があります。 ・DLPは、CASB契約が前提となります。 ・SaaS Security APIはDLP契約が前提となります。 ・SaaS Security APIでマルウェア検査をする場合は、Threat Preventionの契約が前提となります。 ・SaaS Security APIのシングルコネクターは同じベンダーのアプリケーションはすべてで機能します。例えば、Microsoft app connectorは、Microsoft 365アプリケーション(One Drive、Sharepoint等)すべてで利用できます。 新サービスのリリース XDR Security Pro XDR Securityには、 Core と Pro の2種類があります。 XDR Security Coreについては、Catoクラウドをご利用のすべてのお客様が無料でご利用可能です。 Cato Management Application(CMA)の[Monitoring] > [Stories Workbench]にてストーリ(=セキュリティインシデント)を確認することができます。 ただし、XDR Security Coreは、セキュリティオプションであるIPSのログを元に分析をしていますので、IPS(2024年2月以降は、Threat Prevention)の契約が必須となります。 XDR Security Proは、セキュリティインシデントに対する対応(SOC通知の対応)が可能なお客様向けに提供される機能で、AIベースの脅威ハンティング(Threat Hunting)、ユーザー行動分析(User Behavioral Analysis)、インシデントライフサイクル管理を追加したセキュリティオプションとなります。 すでに、既存のお客様向けに早期提供プログラムが開始されています。 CatoのマネージドサービスであるMDR(Managed Detection and Response)は、2024年2月以降は、XDR Security Proの契約が前提になります。 Endpoint Security(EPP) ついに、エンドポイントセキュリティ(EPP)がリリースされます。 これまでの SASEプラットフォームのカバレッジ範囲を、ネットワーク層を超えてエンドポイントにまで拡張する新しい製品 となります。 Cato EPPは、現行CMAに完全に統合管理され、クラウドネイティブな他のセキュリティスタックと連携して動作します。 EPPは、CatoのSDPユーザの利用デバイス数上限と同様に、3デバイスが上限となります。 すでに、既存のお客様向けに早期提供プログラムが開始されています。 SCSKでも早期提供プログラムで検証を実施しておりますので、追ってご案内ができるものと思います。 最後に、XDR Security Pro、Endpoint Security(EPP)、MDRについては、新たに Knowledge Users課金 と言うものが適用されることになります。 Knowledge Usersとは、企業内のM365やG-Suite契約ユーザ数のことで、同ユーザ数での契約が前提となります。 Socket X1600 LTEモデル これまでのSocket X1600(ベーシックモデル)に、LTE接続用のセルラーモジュールを組み込んだ新しいX1600がリリースされます。 モジュールは、現在全世界中で承認作業が行われており、2024年第2四半期(2024年4~6月)に発売を予定しています。 これまでSocket利用時に、メイン回線は有線(フレッツ等)を利用し、バックアップ回線は、無線(LTE)をご利用されているお客様が比較的多くいらっしゃいます。 無線(LTE)には、SIMが搭載可能なルータを別途手配されていましたが、これがSocket X1600(LTEモデル)では不要となります。 価格適用スケジュール 新価格は、2024年2月より適用されます。 契約期間中のお客様についても、2024年2月以降のライセンス追加時(拠点追加・拠点の帯域増速・モバイルユーザ追加)は、すべて新価格が適用されます。 現行価格については、2024年1月末までのお見積り提示分(ご注文が2月末まで)が最終 となります。 なお、ご利用開始月(課金開始月)については、最長で2024年5月まで延長することが可能ですので、例えば、1月末見積り提示、2月末までにご注文の場合、5月利用開始(課金開始)が可能です。 また、これから新規にCatoクラウドをご契約するお客様は、契約期間(最低契約期間は1年)を伸ばすことも可能です。   まとめ 今回は、価格改定の変更部分のみをピックアップして解説しましたが、2024年2月までには、新サービス体系を改めて記事にする予定です。 現行のサービス体系の解説記事 Catoクラウドのサービス体系について Catoクラウドのサービス料金を含むサービス体系、オプションやマネージドサービスについて紹介します。 blog.usize-tech.com 2023.08.17 Catoクラウドは他のSASEソリューションと比較し、安価でコストパフォーマンスが非常に高かったのですが、今回の価格改定で、そのメリットが少なくなったかも知れません。 それでも、全世界中に85箇所以上に設置されている独自PoP(中国を含む)、ネットワーク接続性を拠点まで保証するSocketのサービス提供(責任分界点の差)、クラウドネイティブで実装されたアーキテクチャ(圧倒的な使いやすさ・シンプルさ)は、他のソリューションとは異なる大きな差別化ポイントです。 SASEの普及期となり、SASEの知名度が上がるにつれ、最近では、誤ったマーケティングが横行しています。 「SASEはそもそもマルチベンダーでしか実現できない」 → × 「統合型SASEソリューション」 → × 「(SSEなのに)SASEソリューション」 → × SASEを提唱したガートナーも「 SASEは単一のベンダーから導入すべきである」 と提言しており、2019年のSASEを提唱した後、組み合わせのSASEが多く登場したことから、2022年には「 シングルベンダーSASE 」を改めて提唱しています。 SASEは、ネットワーク・セキュリティが融合・統合された統合型ソリューションであるため、”統合型SASE”自体が本来誤ったマーケティングです。 SSEでは、ゼロトラストは実現できません。(境界型防御の”境界”のクラウドリフト) 立場上、ソリューションを名指しして誤りを指摘することはできませんが、シングルベンダーSASE、世界初のSASEソリューションであるCatoクラウドについて、是非一度ご紹介の機会をいただれば幸いです。
本記事は TechHarmony Advent Calendar 12/25付の記事です。 こんにちは、SCSKの木澤です。 今年初めて企画した TechHarmony Advent Calendar も、本日で完走となりました。 TechHarmony寄稿者から広く協力いただき、本企画を完遂できたことは感激ひとしおです。 各記事をご覧頂いた頂いた皆様も、ありがとうございました。 さて 今年の話題と言えば、最後としては何と言っても生成AIのブーム でしょう。 昨年11月のChatGPT発表以降一世を風靡し、AWSとしても今年4月に Amazon Bedrock を発表、プレビュー期間を経て9月にGAされました。 Amazon Bedrockの特徴としては、 多数の生成AIモデルから選択できる こと、 データセキュリティに強く配慮している こと、 他のAWSサービスと統合が容易なこと が挙げられます。 生成AIモデルの性能としては後塵を拝しているとの評価もありますが、用途によっては十分に使えるため、既にAWSを活用しているユーザーにとっては有力な選択肢になると思われます。 私は昨年、AWSブログの更新を検出しTeamsに通知するという記事を発信しました。 そこで今回はこれに生成AIの要素を追加し、記事を要約して通知することにチャレンジしてみたいと思います。 AWSアップデート情報を見落とさない!Microsoft Teamsへの通知方法 AWSでは毎日のようにアップデートがありますが、効率的に確認できるようにするため社内のMicrosoft Teamsに通知するようにしました。 その仕組みをご紹介したいと思います。 blog.usize-tech.com 2022.05.18 アーキティクチャ・生成AIモデルの選択 アーキティクチャとしてはこんな感じ。 前回の記事から、翻訳に用いていたAmazon TranslateをAmazon Bedrockに取り替えているだけです。 Amazon SNS経由メール通知 Amazon SMS経由Teams通知(HTMLメール) Webhook経由Slack など幅広く対応可能です。 生成AIモデルには Amazon Titan Text G1 – Express を利用しました。 こちらは 今年のre:Inventで発表があったAmazon Bedrockの言語モデル です。英語以外にも100を超える言語に対応しますが、2023年12月時点で英語以外はプレビューの扱いとなっています。 Amazon Titan Text モデル (Express と Lite) が Amazon Bedrock で一般提供されるようになりました aws.amazon.com 今回はTitan Textの日本語性能をチェックしてみたかったことや、コストの観点での選択した次第です。 もしやAWS情報の要約であるためAmazon謹製の生成AIモデルでも期待できるのでは?という思いもありました。 価格は Claudeの1/8~1/10程度、Claude Instantの2/3~1/2程度の費用となります。 もし実用に耐えるのであれば有力な選択肢になるでしょう。 基盤モデルを使用した生成系 AI アプリケーションの構築 – Amazon Bedrock の料金表 – AWS オンデマンドやプロビジョニングスループットなどの Amazon Bedrock の料金モデルの詳細情報と、AI21 labs、Amazon、Anthropic、Cohere、Stability AI などのモデルプロバイダーの料金内訳をご覧ください。 aws.amazon.com   設定手順 以下の手順を実施しました。 なお、当方では東京リージョン(ap-northeast-1)で実装しました。 パラメータストアの作成 後述のLambda関数では取得元RSSフィード情報をAWS Systems Managerのパラメータストアから取得するように設計してありますので、下記のようなJSON形式でパラメータストアを作成します。 タイトルとURL、言語のみしているシンプルなものです。 [ { "TITLE" : "AWS What's New(英語版)" , "URL" : "https://aws.amazon.com/about-aws/whats-new/recent/feed/" , "LANG" : "en" }, { "TITLE" : "AWS What's New(日本語版)" , "URL" : "https://aws.amazon.com/jp/about-aws/whats-new/recent/feed/" , "LANG" : "ja" }, { "TITLE" : "AWS News Blog(英語版)" , "URL" : "https://aws.amazon.com/blogs/aws/feed/" , "LANG" : "en" }, { "TITLE" : "Amazon Web Servicesブログ(日本語版)" , "URL" : "https://aws.amazon.com/jp/blogs/news/feed/" , "LANG" : "ja" }, { "TITLE" : "AWS JAPAN APN ブログ" , "URL" : "https://aws.amazon.com/jp/blogs/psa/feed/" , "LANG" : "ja" } ] Amazon SESへのメールアドレス登録 今回はAmazon SES経由で通知を行いますので、メールの「From」になるメールアドレスと、宛先となるTeamsのメールアドレスを登録し認証しておきます。 Amazon Bedrock 生成AIモデルのリクエスト Amazon Bedrockのコンソールに接続し、Model AccessからTitan Text G1 – Expressを有効化します。 Access grantedと緑で表示されていることを確認します。 Lambda関数の作成 IAMロールの事前準備 以下のアクションを許可したポリシーを作成し、これらをアタッチしたロールを作成します。 英語版ブログのタイトルの翻訳を含むため、Translateの権限も残してあります。 AWS Systems Manager(Parameter Store)からの値の取得 ssm:GetParameterHistory ssm:GetParametersByPath ssm:GetParameters ssm:GetParameter Amazon Translateでの翻訳実行 translate:TranslateText Amazon Bedrockでの推論実行 bedrock:InvokeModel SESでのメール送信 ses:SendEmail CloudWatch Logsへのログ送信 logs:CreateLogGroup logs:CreateLogStream logs:PutLogEvent Bedrockのモデル呼び出しはbedrock:InvokeModelのみで良いようです。ポリシーはこちら。 { "Version": "2012-10-17", "Statement": [ { "Action": "bedrock:InvokeModel", "Resource": "*", "Effect": "Allow" } ] } Lambda関数の作成 2023年12月にLambdaで Python 3.12ランタイムがリリースされました。 内包されているbotoのバージョンは1.28.72 となっており、 boto3をアップデートするためにLambdaレイヤーの作成もしくは関数内への埋め込みは不要になりました。 そこで、前回同様組み込みが必要なライブラリはfeedparserのみとなります。 AWS Cloudshellにログインし、適当なフォルダを生成し以下のようなコマンドで生成→S3バケットにプッシュします。 $ pip3 install feedparser -t . $ touch lambda_function.py $ zip -r func.zip ./* $ aws s3 cp ./func.zip s3: / /(S3バケット名)/ 関数のひな形をデプロイ後、ソースコードは以下のように改修しました(ダウンロードしご確認ください) AWSアップデート通知Python Lambdaコード(Bedrock-Titan要約版) Download Now! 2 Downloads   なお、botoにてAmazon Titan Textを呼び出すためのパラメータはこちらで確認できます。 Amazon Titan text models - Amazon Bedrock The Amazon Titan models support the following inference parameters for text models. docs.aws.amazon.com 一般設定・環境変数の設定 元々本Lambda関数はRSSのパース及び外部の呼び出しに少々時間がかかりますが、Bedrockの呼び出しで更に時間が掛かります。タイムアウト時間は3分程度まで延ばしておいた方がよいと思われます。 また環境変数として以下を指定します。 MAIL_FROM 送信するメールの発信元 MAIL_DEST_EN 英語版ブログの通知先メールアドレス(Teams) MAIL_DEST_JA 日本語版ブログの通知先メールアドレス(Teams) PARAMETER_STORE 作成したAWS Systems Managerパラメータストアの名前 EventBridgeルールの設定 最後に、Amazon EventBridgeのルールを追加し、作成したLambda関数を定期実行するように設定します。 動作確認 以上、AWSアップデートの要約チャレンジでした。 Lambdaを実行すると、Bedrock(Titan)で記事が要約された通知が行われます。 本サンプルはSNS経由メール通知で届いたものを掲載しています。 日本語版ブログを要約させたもの 概ね想定通りの結果が得られました。 英語版ブログをTitanで直接日本語解説させたもの 下記は比較的良い結果を載せましたが、出力結果が不安定な印象があります。   まとめ&今後の展望 LambdaからBedrockを呼び出して、アプリケーションに生成AIモデルを組み込むことが非常に簡単なことが解りました 。 今回の検証の結果では、英語版ブログの翻訳まで組み込んだ形で要約するにはまだ不安定であるといった印象でしたが、Amazon Translateと組み合わせることで実用に耐えうるレベルに達するのでは無いかという印象です。 また今回は時間切れのため検証できませんでしたが、プロンプトの調整で改善される可能性もあるかと思います。 実際にはRSSで配布される記事の要約文(Description)もあるため、今後の本番運用に関しては引き続き検証し判断していきたいと思います。 今後ともAmazon Bedrockを用いて色々なサーバレスアプリに生成AI要素を組み込んでいきたいですね。 では。
本記事は TechHarmony Advent Calendar 12/24付の記事です。 こんにちは、SCSK齋藤でございます。 今回は、最近業務で調べる機会が多かったAWS Network Firewallについて、学んだことをアウトプットしたいと思います。 AWS Network Firewallとは? AWSから提供される、VPC全体に適用されるファイアウォール型マネージドサービスです。 数クリックでファイアウォール自体は作成でき、ステートフルやステートレスのアクセス制御、Webフィルタリング、IPS/IDSといった幅広い機能が使えます。 VPCの前面に配置することで、インターネットからVPCに入ってくる通信に対してチェックを行うファイアウォールということです。 ファイアウォールとのことなので、個人的にはセキュリティグループやネットワークACLとの違いが最初よくわからなかったのですが、検証を踏まえて使ってみたことで、違いが見えてきました。 構成要素 AWS Network Firewallには主に3つの構成要素がございます。 ・Firewall その名の通り、ファイアウォールそのものです。数クリックで作成することができ、それをVPCやサブネットにアタッチします。 インターネットからVPCに入ってくる通信をチェックするので、パブリックサブネットに配置する必要がございます。 ファイアウォールそのものですが、これ単体ではパケットのチェックなどは実施しないので、後述する2つが必要となります。 ・ファイアウォールポリシー ファイアウォールの動作を定義したものです。後述するルールグループを紐づけることで、ステートレスもしくはステートフルなチェックを実施します。 ・ルールグループ ネットワークトラフィックのルールの集合体です。1つのルールグループに複数のルールを追加することができ、優先順位づけを実施することができます。 5つの項目 (送信元IP、送信元ポート番号、宛先IP、宛先ポート番号、プロトコル番号)を細かく定義することができ、またその項目に対する挙動(通信をパスするか、ドロップするか、別のルールに分岐するかなど)も定義することができます。 ハンズオン 構成 今回は下記のような構成で通信を行い、インスタンスにSSHをしてみたいと思います。 パブリックサブネットにAWS Network Firewallを配置し、専用のサブネットとします。 その背後のプライベートサブネットにEC2を配置することで、外部からの通信は必ずAWS Network Firewallを通って、EC2のあるサブネットに疎通するようにします。 なお、今回のハンズオンではネットワークの設定や、EC2の立ち上げは省略いたします。 Firewallの作成 まずは、前述したFirewallを作成します。 基本的にマネジメントコンソールの内容に沿って設定を実施します。 VPC単位で適用されるサービスであるのと、Firewallを設置するサブネットの選択が必須になります。 また、ファイアウォールポリシーについてはこの段階で作成を行います。 ファイアウォールポリシーを作成する際に注意すべきは、デフォルトのアクションをどうするかです。 この後作成する、ルールグループでの評価に何もマッチしなかった場合に、通信を許可するか、拒否するかなどを設定することができます。 通常、セキュリティのことを考えたら、ルール評価にマッチしない場合は通信を拒否するのが普通かなと考えたので、今回はデフォルトで拒否するようにします。 下記のように準備が整ったら、「ファイアウォールを作成」を押下して作成します。作成には結構時間がかかるので、待ちましょう。   ルールグループの作成 ファイアウォールポリシーに、具体的なルールを設定するための、ルールグループを作成します。 ルールグループには2種類があり、「ステートレスルールグループ」と「ステートフルルールグループ」があります。 評価の順序については、下記ドキュメントに記載されている通り、「ステートレスルールグループ」→「ステートフルルールグループ」の順番となります。「ステートフルルールグループ」を作成しない場合は、「ステートレスルールグループ」のみの評価となります。 Network Firewall stateless and stateful rules engines - AWS Network Firewall Learn about the Network Firewall stateless and stateful rules engines. docs.aws.amazon.com ルールグループは複数作成してアタッチし、評価順序を設定できるので、より柔軟に設定が可能です。 今回は1つだけのルールグループを作成しました。 今回は上記のようなルールで、特定のインスタンスに、自宅のネットワークからのみSSHを許可するアクションを追加しました。 ステートレスで作成したので、行きの通信と戻りの通信それぞれのルールを設定する必要がありますね。 前述したようにファイアウォールポリシーのデフォルトのアクションが、拒否という設定をしたので、今回のルールグループの評価にマッチしない場合は、通信が全部拒否されます。 ファイアウォールポリシーとの関連付け 作成したルールグループをファイアウォールポリシーにアタッチします。 私はこれを忘れたまま、SSHの接続を試みて、全然アクセスができないという事象に陥りました。。。 ファイアウォールポリシーの画面に遷移し、ステートレスルールグループの「アクション」から、「アンマネージドステートレスルールグループを追加」をクリックします。 事前作成したルールグループを選択し、「ステートレスルールグループを追加する」を押下します。 これで、ルールグループの内容をもとに、ファイアウォールがパケットを評価する準備が整いました。   動作検証 SSH通信が許可されるかどうか では早速、インスタンスにSSHをしてみましょう。 問題なく、SSH接続をすることができました。 私が前述した通り、最初はルールグループをファイアウォールポリシーにアタッチするのを忘れていたのですが、ルールグループなしでSSH接続してみたらどうなるかを再度試してみましたところ、、 接続できませんでした。これは、ファイアウォールポリシーのデフォルトのアクションが拒否になっているので、通信が拒否されたものとなります。   セキュリティグループとの関係性はどうなのか? ひとつ気になることとして、セキュリティグループとの関係性はどういうものなのか気になりました。 試しに、EC2のセキュリティグループで外部からのアクセスを許可する設定を入れなかった場合にどうなるか試してみたところ、SSH接続できませんでした。 これは、AWS Network FirewallがVPC単位でのファイアウォールなのに対して、セキュリティグループはインスタンス単位でのファイアウォールになるためです。 なので、AWS Network FirewallでVPC内への通信を許可しても、インスタンスの直前に立つセキュリティグループがブロックすれば、通信はできないということですね。   まとめ 今回は、AWS Network Firewallが何をできるのか知るために検証してみました。 ファイアウォールということで、セキュリティグループなどとはどう違うのかが1番気になっていたので、VPC単位での設定や、複数のルールグループをアタッチし順番に評価することが可能な点がわかり、より柔軟なアクセスコントロールができるのだと感じました。