TECH PLAY

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

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

1268

こんにちは、広野です。 先日、React アプリに Amazon Bedrock に問い合わせる画面をつくってみた系の記事を公開いたしました。 React アプリに Amazon Bedrock への問い合わせ画面を組み込む [レスポンスストリーミング対応] React アプリに Amazon Bedrock に問い合わせる画面をつくってみたので React と AWS Lambda 関数のコードを紹介します。 blog.usize-tech.com 2024.01.16 今回は、Agents for Amazon Bedrock に問い合わせる画面をつくってみましたので紹介します。前回の記事の内容と似ていますが、一部アーキテクチャと API の仕様が異なります。 Agents for Amazon Bedrock についてはこちら。簡単に説明しますと、複数のデータソースの情報をもとにユーザからの問い合わせに自然言語で回答してくれるオーケストレーションサービス?のようなものです。今流行りの RAG 構築にも使われます。 Agents for Amazon Bedrock - Amazon Bedrock Learn about how to set up conversational agents using Amazon Bedrock docs.aws.amazon.com それでは、目次です。 つくったもの 一般的な質問はテキスト生成系 AI モデルから、当社 (SCSK 株式会社) に関する質問は別途用意したナレッジベースから情報を取得し、自然言語で返してくれます。最小構成の RAG という感じです。 一般的な質問(京都のお勧め観光地) 当社に関する質問 ※ 実は 当社に関する質問 を一般的な質問としてテキスト生成系 AI に投げると、残念なことに 誤った回答を返します 。(ハルシネーションと言われる現象)そのため、当社に関する質問は独自データベース (Knowledge Base) から情報を取得し回答するよう作り込んでいます。それが RAG と呼ばれる機能です。 ※ 上記画像は問い合わせから返事までの待ち時間をカットしています。実際には、1分近い待ち時間が発生しています。 アーキテクチャ RAG 用の Knowledge Base (ベクトルデータ) には、Agents for Amazon Bedrock が自動作成してくれる Amazon OpenSearch Service Serverless を使用しています。別途 Amazon S3 バケットを作成し、そこに当社公式ホームページの情報を PDF 化したファイルを格納し、OpenSearch に Sync させます。 一般的な回答をするために使用する生成系 AI の基盤モデルには、Amazon Bedrock の Anthropic Claude 2.1 を使用しています。 ユーザからの問い合わせ内容が当社 (SCSK 株式会社) に関連するものであれば Agents for Amazon Bedrock が自動的に OpenSearch 内の情報を取得します。それ以外の内容であれば AWS Lambda 関数経由で Claude 2.1 モデルに問い合わせます。 Agents for Amazon Bedrock に問い合わせるのは AWS Lambda 関数 (Node.js 20) です。関数 URL を持たせており、React アプリから直接呼び出します。 Lambda 関数を介さずに Agents for Amazon Bedrock の API に直接問い合わせることもできましたが、レスポンスのデータ構造がわからずあきらめました。 その AWS Lambda 関数からのレスポンスはレスポンスストリーミング対応にしています。それにより、Agents for Amazon Bedrock が回答を作成しつつ、レスポンスを画面に表示できるようにしています。ただ、実際に出来上がった画面を見てみると流れるようなテキスト表示はされていないので引き続き経験を積んで確認していきたいと思います。Agents for Amazon Bedrock を呼び出す API はレスポンスストリーミング対応の InvokeAgentCommand を使用しています。 補足ですが、React アプリから AWS Lambda 関数 URL を認証付きで呼び出す構成は以下参考記事の構成にしています。本記事では説明を割愛します。 やってみたら面倒くさい、React アプリからの Amazon Cognito 認証付き AWS Lambda 関数 URL 呼出 Amazon Cognito 認証を施した React アプリから、認証済みユーザのみ AWS Lambda 関数を呼び出せるようにする React コードを紹介します。 blog.usize-tech.com 2024.01.15 また、Agents for Amazon Bedrock により RAG 用の Knowledge Base を作成する方法については、以下の記事が参考になります。マネジメントコンソールで簡単につくれます。 生成AI初心者がAmazon BedrockのKnowledge baseを使ってRAGを試してみた AWS re:Invent2023にて、Amazon BedrockのKnowledge baseとAgentsがGAされたと発表がありました。今回はこのうちKnowledge baseを利用して、RAG(Retrieval Augment Generation)を試してみたいと思います。 blog.usize-tech.com 2023.12.07 図で表すと以下の赤枠部分のことです。ここについては今後の別記事でもう少し踏み込んで解説したいと思います。 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 InvokeAgentCommand の API が Agents for Amazon Bedrock からのレスポンスを chunk 分割された状態で受け取るので、chunk ごとに React アプリへのレスポンス用ストリーム responseStream に放り込んでいます。レスポンスは Blob なので、途中で人が読み取れるテキストデータに変換する処理が入っています。 const { BedrockAgentRuntimeClient, InvokeAgentCommand } = require("@aws-sdk/client-bedrock-agent-runtime"); const bedrockagent = new BedrockAgentRuntimeClient({region: "${AWS::Region}"}); exports.handler = awslambda.streamifyResponse(async (event, responseStream, _context) => { try { const args = JSON.parse(event.body); if (args.prompt == '') { responseStream.write("No prompt"); responseStream.end(); } const agentInput = { "agentId": " BedrockAgentId ", //BedrockのエージェントIDが入る "agentAliasId": " BedrockAgentAliasId ", //BedrockのエージェントエイリアスIDが入る "sessionId": args.jobid, //セッションIDを入れる "enableTrace": false, "endSession": false, "inputText": args.prompt, //プロンプトを入れる "sessionState": { "promptSessionAttributes": { //任意で情報を入れることが可能 "serviceid": args.serviceid, "user": args.username, "datetime": args.datetime } } }; const command = new InvokeAgentCommand(agentInput); const res = await bedrockagent.send(command); const actualStream = res.completion.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 { chunks.push(decodedString); responseStream.write(decodedString); } catch (error) { console.error(error); responseStream.write(null); responseStream.end(); } } responseStream.end(); } catch (error) { console.error(error); responseStream.write('error'); responseStream.end(); } }); Python を採用していない理由は、AWS 公式ドキュメントにもありますが AWS Lambda 関数がレスポンスストリーミングをネイティブにサポートしているランタイムが Node.js のみだからです。※執筆時点 sessionId というパラメータを Agents for Amazon Bedrock に送信しています。UUID など一意の ID を生成して入れることで、2回目以降の問い合わせも同じ sessionId であれば過去の問い合わせ内容を自動的に関連付けて回答してくれます。便利! 私のケースでは sessionId はアプリ側でも必要な情報なので、アプリ側で生成した ID を Lambda 関数に渡しています。 React コード React アプリ側は、Lambda 関数 URL を呼び出すために fetch を使用します。 AWS Lambda 関数 URL から chunk 分割されたレスポンスが送られてくるので、それを順次、直前の chunk と繋げて state に突っ込むだけの、非常に原始的なループのコードです。もっと簡単かつ効率的な処理になる SDK を AWS が開発してくれることを期待しております。 //レスポンス表示用、セッションID用state const [response, setResponse] = useState(""); const [jobid, setJobid] = useState(); //date、セッションID(jobid)とか const dt = new Date(); const datetime = dt.toISOString(); setJobid(uuidv4()); //送信するデータ const body = { prompt: prompt, jobid: jobid, serviceid: serviceid, user: username, datetime: datetime }; //Lambda関数URL呼出 try { const res = await window.fetch( "https://xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.lambda-url.us-west-2.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 のミリ秒数を調整することで、受け取ったレスポンス文章表示の流暢さを調整できます。 すみません、チャットボット画面の UI についてはややこしくなるので割愛させて頂きます。考え方としては、上記コード内にある response ステートをユーザのプロンプト prompt と交互に並べて表示することになります。 セッション ID はコード内では jobid という state に格納していますが、過去の問い合わせとの関係性をクリアするときには jobid を取得し直す処理が必要です。 まとめ いかがでしたでしょうか。 Amazon Bedrock のモデルを呼び出すコードと Agents for Amazon Bedrock とではレスポンスの仕様が異なるため全く同じというわけにはいきませんでした。AI/ML 領域は技術革新が激しいので、本記事の陳腐化も早いと思います。引き続きキャッチアップしていきたいと思います。 本記事が皆様のお役に立てれば幸いです。
こんにちは。今回は Amazon Redshift のクラスターを作成する時に遭遇したプチトラブルに対して、ブラウザの開発者ツールを使ったごく簡単なトラブルシュート方法について書いてみます。 今回の趣旨は、インフラ系技術者の方でWEBブラウザでのトラブルはあまり対応したことがない、という方に向けて、漠然と色々試すのではなく、トラブルの原因を探る一つの方法をお伝えすることです。この記事では Amazon Redshift のクラスター作成時のトラブルについて取り上げていますが、やり方自体は他のサービスでも使えるものです。 想定するトラブル AWSマネジメントコンソールでRedshiftクラスターを作成する際に、諸々の設定をして「クラスターを作成」をクリックしたが、何も反応がない、という状況を想定します。※実話です。 多くのケースでは、設定に問題があった時には画面上部に赤背景でエラーメッセージが出るので、それに応じて対処をすればよいのですが、しばしば今回のケースのように、何もエラーメッセージは出ていないのにクリックしても無反応で手掛かりがない、という状態に遭遇することがあります。 ブラウザの開発者ツールを使ったトラブルシュートの流れ こんな状況で、トラブルシュートの手がかりになり得るのが開発者ツールです。これはWEBブラウザに付属のツールで、ブラウザが裏でどのような通信をしたかやそのレイテンシ、どんなスクリプトを実行してどこで問題があったのか、等を表示してくれるもので、WEBアプリを作る際にはすぐ使える便利なツールとして一般に使用されています。Google Chrome、Edge等、有名なブラウザであれば大体実装されていますが、今回は私が普段使っているGoogle Chromeを例にお話します。 まず、「クラスターを作成」を押そうとした画面で、F12キーを押せば開発者ツールが起動します。 デフォルトでは、右下にコンソールがあり、エラー等のログはここから確認できます。 ここで、「クラスターを作成」をクリックした時に何か手がかりになるエラーが出力されていないか、試してみます。開発者ツールを起動した状態で、再度「クラスターを作成」をクリックします。 コンソールに1件エラーが出力されています。ログの内容は以下です。 Uncaught TypeError: Cannot read properties of undefined (reading 'keySource’) at t.createSnapshotCopyGrantMessage (main.js:2167:915175) at n.onCreateButtonClick (main.js:2167:898441) at l (main.js:27:153561) at onClick (main.js:27:567037) at Object.<anonymous> (main.js:2087:1410) at S (main.js:2087:1448) at main.js:2087:1594 at T (main.js:2087:1680) at O (main.js:2087:2129) at N (main.js:2087:1941) エラーのスタックトレースが出力されています。スタックトレースでは、処理のネスト構造がある場合は下から上に向かってネスト構造を深堀りしていく順に出力されますので、一番直近の(直接的な)エラーの原因は「at t.createSnapshotCopyGrantMessage」の行です。その前の「at n.onCreateButtonClick」という名称と、エラーの原因の直前に出力されていることから想像すると、「クラスターを作成」ボタンを押した時に流れる処理の中で、「t.createSnapshotCopyGrantMessage」という処理があり、ここでエラーが発生したのだろう、と予想がつきます。 さて、この「createSnapshotCopyGrantMessage」、名称上、すごく関係がありそうな入力項目がコンソールにあります。 怪しげですね。クロスリージョンスナップショットを設定する場合、スナップショットコピー権限の設定は必須なので、クロスリージョンスナップショットは一旦Disableで作っておいて、構築後にEnableする作戦で回避できないか試します。 無事作成が始まりました。これで問題としては解決しました。(後でクロスリージョンスナップショットをEnableするところは省略)。しかし、何がいけなかったのか気になるので、もう少しだけ調べてみます。 開発者ツールに戻って、直近の問題になっていた、「t.createSnapshotCopyGrantMessage」というのはどんな処理なのか確認します。コンソールには、エラーメッセージそのものの他、スクリプトのどこでその問題が起こったのか、ソースコードへのリンクが張られています。 ここをクリックすると、こんな感じのソースコードが見れます。 このソースコードを全て読み解くのは骨なので、ざっと見てわかることがないか考えます。 バツ印で具体的にどの行で問題があったのかを示してくれています。読んでみると、「KMS_KEY_SOURCE_AWS_OWNED」という文言があります。Redshiftに詳しい方ならピンとくるかもしれませんが、今回暗号化設定を入れており、AWS KMSの使用かつデフォルトのRedshiftキーを使用する、という選択にしていました。 後で実際に試してみたら、この暗号化を無効にすることで、クロスリージョンスナップショットをEnableにしていてもクラスターは作成できました。要はクラスター作成のワークアラウンドとしては、暗号化をDisableにするか、クロスリージョンスナップショットをDisableにするかどちらかを選択することになります。どちらでも問題はないと思いますが、まあ感覚的に言えば、クロスリージョンスナップショットの設定の方が暗号化と比べれば軽微な変更なので、クロスリージョンスナップショットをDisableにする方でいいかな、と思います。 まとめ 今回はAWSマネジメントコンソールでの操作が無反応だった時のトラブルシュートの方法として、ブラウザの開発者ツールを使う方法をお伝えしました。この方法では、AWSマネジメントコンソールのスクリプトまでは必ずしも理解する必要はなく、今回の例でもトレースしていたのはあくまで名前から怪しいコンポーネントを類推する方法でした。 それでもわからなければマニュアルを漁ったり設定を一つ一つ変更して切り分けを進めたりすることになりますが、ある程度の精度で素早く原因の当たりをつける、という意味で、ぜひ開発者ツールを活用してみてください。
こんにちは。SCSKのふくちーぬです。 皆さんは、AWS内の疎通テストをどのように実施していますでしょうか。pingコマンドやTest-NetConnectionコマンドを利用しているでしょうか。 今回は、VPC Reachability Analyzerを用いた疎通テストの手法をご紹介します。 VPC Reachability Analyzer AWS内のリソース間の接続性を擬似的にテストし、どの経路地点で問題があるか分析する機能です。 新機能 – VPC Reachability Analyzer | Amazon Web Services Amazon Virtual Private Cloud (VPC) を使用すると、お客様は、論理的に分離され aws.amazon.com Reachability Analyzerを利用することで、ルートテーブルやセキュリティグループのどこに設定不備があるか表示され、どこのネットワークに問題があるか容易に切り分けすることができます。到達不能箇所を特定することで、通信の到達性に関する問題の解決を手助けしてくれます。 How Reachability Analyzer works - Amazon Virtual Private Cloud Learn more about how Reachability Analyzer works. docs.aws.amazon.com 気になる料金は、一律で1回の分析あたり0.10 USDとなります。 アーキテクチャ EC2・VPCエンドポイントは、プライベートサブネットに配置する EC2からVPCエンドポイントに向けて、Reachability Analyzerを用いてTCP:443の疎通を実施する 検証① EC2インスタンスから、各VPCエンドポイントの疎通テストを実施し到達不能箇所を特定する CloudFormationテンプレート(ネットワークスタック) 下記のリソースを作成するCloudFormationテンプレートです。 VPC プライベートサブネット ルートテーブル セキュリティグループ VPCエンドポイント EC2 IAMロール 以下のテンプレートをデプロイしてください。 AWSTemplateFormatVersion: 2010-09-09 Description: cfn private EC2 Parameters: ResourceName: Type: String Resources: # ------------------------------------------------------------# # VPC # ------------------------------------------------------------# VPC: Type: AWS::EC2::VPC Properties: CidrBlock: 10.0.0.0/16 EnableDnsSupport: true EnableDnsHostnames: true Tags: - Key: Name Value: !Sub "${ResourceName}-VPC" # ------------------------------------------------------------# # Subnet # ------------------------------------------------------------# PrivateSubnet1a: Type: AWS::EC2::Subnet Properties: VpcId: !Ref VPC CidrBlock: 10.0.2.0/24 AvailabilityZone: ap-northeast-1a MapPublicIpOnLaunch: false Tags: - Key: Name Value: !Sub "${ResourceName}-PrivateSubnet-1a" PrivateSubnet1c: Type: AWS::EC2::Subnet Properties: VpcId: !Ref VPC CidrBlock: 10.0.3.0/24 AvailabilityZone: ap-northeast-1c MapPublicIpOnLaunch: false Tags: - Key: Name Value: !Sub "${ResourceName}-PrivateSubnet-1c" # ------------------------------------------------------------# # RouteTable # ------------------------------------------------------------# PrivateRouteTable: Type: AWS::EC2::RouteTable Properties: VpcId: !Ref VPC Tags: - Key: Name Value: !Sub "${ResourceName}-PrivateRouteTable" PrivateSubnet1aAssociation: Type: AWS::EC2::SubnetRouteTableAssociation Properties: SubnetId: !Ref PrivateSubnet1a RouteTableId: !Ref PrivateRouteTable PrivateSubnet1cAssociation: Type: AWS::EC2::SubnetRouteTableAssociation Properties: SubnetId: !Ref PrivateSubnet1c RouteTableId: !Ref PrivateRouteTable # ------------------------------------------------------------# # EC2 # ------------------------------------------------------------# EC2: Type: AWS::EC2::Instance Properties: ImageId: ami-0b193da66bc27147b InstanceType: t2.micro NetworkInterfaces: - AssociatePublicIpAddress: "true" DeviceIndex: "0" SubnetId: !Ref PrivateSubnet1a GroupSet: - !Ref EC2SecurityGroup Tags: - Key: Name Value: !Sub "${ResourceName}-ec2" EC2SecurityGroup: Type: "AWS::EC2::SecurityGroup" Properties: VpcId: !Ref VPC SecurityGroupIngress: - IpProtocol: tcp FromPort: 80 ToPort: 80 CidrIp: 10.0.0.0/16 GroupName: !Sub "${ResourceName}-ec2-sg" GroupDescription: !Sub "${ResourceName}-ec2-sg" Tags: - Key: "Name" Value: !Sub "${ResourceName}-ec2-sg" # ------------------------------------------------------------# # IAM Role # ------------------------------------------------------------# EC2Role: Type: AWS::IAM::Role Properties: Path: / RoleName: !Sub "${ResourceName}-ec2-Role" AssumeRolePolicyDocument: Version: 2012-10-17 Statement: - Effect: Allow Principal: Service: - ec2.amazonaws.com Action: - sts:AssumeRole MaxSessionDuration: 3600 ManagedPolicyArns: - arn:aws:iam::aws:policy/service-role/AmazonEC2RoleforSSM InstanceProfile: Type: AWS::IAM::InstanceProfile Properties: Path: / Roles: - !Ref EC2Role # ------------------------------------------------------------# # VPCEndpoint # ------------------------------------------------------------# SSMEndpoint: Type: AWS::EC2::VPCEndpoint Properties: ServiceName: !Sub "com.amazonaws.${AWS::Region}.ssm" SubnetIds: - !Ref PrivateSubnet1a - !Ref PrivateSubnet1c VpcId: !Ref VPC VpcEndpointType: Interface SecurityGroupIds: - !Ref EndpointSecurityGroup PrivateDnsEnabled: true EC2MessageEndpoint: Type: AWS::EC2::VPCEndpoint Properties: ServiceName: !Sub "com.amazonaws.${AWS::Region}.ec2messages" SubnetIds: - !Ref PrivateSubnet1a - !Ref PrivateSubnet1c VpcId: !Ref VPC VpcEndpointType: Interface SecurityGroupIds: - !Ref EndpointSecurityGroup PrivateDnsEnabled: true ssmmessagesEndpoint: Type: AWS::EC2::VPCEndpoint Properties: ServiceName: !Sub "com.amazonaws.${AWS::Region}.ssmmessages" SubnetIds: - !Ref PrivateSubnet1a - !Ref PrivateSubnet1c VpcId: !Ref VPC VpcEndpointType: Interface SecurityGroupIds: - !Ref EndpointSecurityGroup PrivateDnsEnabled: true EndpointSecurityGroup: Type: "AWS::EC2::SecurityGroup" Properties: VpcId: !Ref VPC GroupName: !Sub "${ResourceName}-endpoint-sg" GroupDescription: !Sub "${ResourceName}-endpoint-sg" Tags: - Key: "Name" Value: !Sub "${ResourceName}-ec2-sg"   CloudFormationテンプレート(分析スタック) 下記のリソースを作成するCloudFormationテンプレートです。 パスと分析 以下のテンプレートをデプロイしてください。 AWSTemplateFormatVersion: 2010-09-09 Description: Rechability Analyzer Test Parameters: ResourceName: Type: String InstanceId: Type: String VPCeIdForSSM: Type: String VPCeIdForSSMMesssages: Type: String VPCeIdForEC2Messsages: Type: String Resources: # ------------------------------------------------------------# # Rechability Analyzer Test01 # ------------------------------------------------------------# EC2NetworkInsightsPathForSSM01: Type: "AWS::EC2::NetworkInsightsPath" Properties: Destination: !Ref VPCeIdForSSM FilterAtSource: DestinationPortRange: ToPort: 443 FromPort: 443 Protocol: "tcp" Source: !Ref InstanceId Tags: - Key: Name Value: !Sub ${ResourceName}-test01-ssm EC2NetworkInsightsPathForSSMMessages01: Type: "AWS::EC2::NetworkInsightsPath" Properties: Destination: !Ref VPCeIdForSSMMesssages FilterAtSource: DestinationPortRange: ToPort: 443 FromPort: 443 Protocol: "tcp" Source: !Ref InstanceId Tags: - Key: Name Value: !Sub ${ResourceName}-test01-ssmmessages EC2NetworkInsightsPathForEC2Messages01: Type: "AWS::EC2::NetworkInsightsPath" Properties: Destination: !Ref VPCeIdForEC2Messsages FilterAtSource: DestinationPortRange: ToPort: 443 FromPort: 443 Protocol: "tcp" Source: !Ref InstanceId Tags: - Key: Name Value: !Sub ${ResourceName}-test01-ec2messages EC2NetworkInsightsAnalysisForSSM01: Type: AWS::EC2::NetworkInsightsAnalysis Properties: NetworkInsightsPathId: !Ref EC2NetworkInsightsPathForSSM01 EC2NetworkInsightsAnalysisForSSMMessages: Type: AWS::EC2::NetworkInsightsAnalysis Properties: NetworkInsightsPathId: !Ref EC2NetworkInsightsPathForSSMMessages01 EC2NetworkInsightsAnalysisForEC2Message: Type: AWS::EC2::NetworkInsightsAnalysis Properties: NetworkInsightsPathId: !Ref EC2NetworkInsightsPathForEC2Messages01  分析結果の確認 以下のように、VPCエンドポイントにアタッチしているセキュリティグループに適切なインバウンドルールがないことが判明しました。 検証② 各VPCエンドポイントのセキュリティグループのインバウンドルール(インバウンドルールに、HTTPS:443を許可する)を修正する 再度疎通テストを実施し到達可能を確認する CloudFormationテンプレート(ネットワークスタック) VPCエンドポイントにアタッチ済みのセキュリティグループを修正を行います。 以下のテンプレートをデプロイして、スタックの更新をします。 AWSTemplateFormatVersion: 2010-09-09 Description: cfn private EC2 Parameters: ResourceName: Type: String Resources: # ------------------------------------------------------------# # VPC # ------------------------------------------------------------# VPC: Type: AWS::EC2::VPC Properties: CidrBlock: 10.0.0.0/16 EnableDnsSupport: true EnableDnsHostnames: true Tags: - Key: Name Value: !Sub "${ResourceName}-VPC" # ------------------------------------------------------------# # Subnet # ------------------------------------------------------------# PrivateSubnet1a: Type: AWS::EC2::Subnet Properties: VpcId: !Ref VPC CidrBlock: 10.0.2.0/24 AvailabilityZone: ap-northeast-1a MapPublicIpOnLaunch: false Tags: - Key: Name Value: !Sub "${ResourceName}-PrivateSubnet-1a" PrivateSubnet1c: Type: AWS::EC2::Subnet Properties: VpcId: !Ref VPC CidrBlock: 10.0.3.0/24 AvailabilityZone: ap-northeast-1c MapPublicIpOnLaunch: false Tags: - Key: Name Value: !Sub "${ResourceName}-PrivateSubnet-1c" # ------------------------------------------------------------# # RouteTable # ------------------------------------------------------------# PrivateRouteTable: Type: AWS::EC2::RouteTable Properties: VpcId: !Ref VPC Tags: - Key: Name Value: !Sub "${ResourceName}-PrivateRouteTable" PrivateSubnet1aAssociation: Type: AWS::EC2::SubnetRouteTableAssociation Properties: SubnetId: !Ref PrivateSubnet1a RouteTableId: !Ref PrivateRouteTable PrivateSubnet1cAssociation: Type: AWS::EC2::SubnetRouteTableAssociation Properties: SubnetId: !Ref PrivateSubnet1c RouteTableId: !Ref PrivateRouteTable # ------------------------------------------------------------# # EC2 # ------------------------------------------------------------# EC2: Type: AWS::EC2::Instance Properties: ImageId: ami-0b193da66bc27147b InstanceType: t2.micro NetworkInterfaces: - AssociatePublicIpAddress: "true" DeviceIndex: "0" SubnetId: !Ref PrivateSubnet1a GroupSet: - !Ref EC2SecurityGroup Tags: - Key: Name Value: !Sub "${ResourceName}-ec2" EC2SecurityGroup: Type: "AWS::EC2::SecurityGroup" Properties: VpcId: !Ref VPC SecurityGroupIngress: - IpProtocol: tcp FromPort: 80 ToPort: 80 CidrIp: 10.0.0.0/16 GroupName: !Sub "${ResourceName}-ec2-sg" GroupDescription: !Sub "${ResourceName}-ec2-sg" Tags: - Key: "Name" Value: !Sub "${ResourceName}-ec2-sg" # ------------------------------------------------------------# # IAM Role # ------------------------------------------------------------# EC2Role: Type: AWS::IAM::Role Properties: Path: / RoleName: !Sub "${ResourceName}-ec2-Role" AssumeRolePolicyDocument: Version: 2012-10-17 Statement: - Effect: Allow Principal: Service: - ec2.amazonaws.com Action: - sts:AssumeRole MaxSessionDuration: 3600 ManagedPolicyArns: - arn:aws:iam::aws:policy/service-role/AmazonEC2RoleforSSM InstanceProfile: Type: AWS::IAM::InstanceProfile Properties: Path: / Roles: - !Ref EC2Role # ------------------------------------------------------------# # VPCEndpoint # ------------------------------------------------------------# SSMEndpoint: Type: AWS::EC2::VPCEndpoint Properties: ServiceName: !Sub "com.amazonaws.${AWS::Region}.ssm" SubnetIds: - !Ref PrivateSubnet1a - !Ref PrivateSubnet1c VpcId: !Ref VPC VpcEndpointType: Interface SecurityGroupIds: - !Ref EndpointSecurityGroup PrivateDnsEnabled: true EC2MessageEndpoint: Type: AWS::EC2::VPCEndpoint Properties: ServiceName: !Sub "com.amazonaws.${AWS::Region}.ec2messages" SubnetIds: - !Ref PrivateSubnet1a - !Ref PrivateSubnet1c VpcId: !Ref VPC VpcEndpointType: Interface SecurityGroupIds: - !Ref EndpointSecurityGroup PrivateDnsEnabled: true ssmmessagesEndpoint: Type: AWS::EC2::VPCEndpoint Properties: ServiceName: !Sub "com.amazonaws.${AWS::Region}.ssmmessages" SubnetIds: - !Ref PrivateSubnet1a - !Ref PrivateSubnet1c VpcId: !Ref VPC VpcEndpointType: Interface SecurityGroupIds: - !Ref EndpointSecurityGroup PrivateDnsEnabled: true EndpointSecurityGroup: Type: "AWS::EC2::SecurityGroup" Properties: VpcId: !Ref VPC SecurityGroupIngress: - IpProtocol: tcp FromPort: 443 ToPort: 443 CidrIp: 10.0.0.0/16 GroupName: !Sub "${ResourceName}-endpoint-sg" GroupDescription: !Sub "${ResourceName}-endpoint-sg" Tags: - Key: "Name" Value: !Sub "${ResourceName}-ec2-sg"   CloudFormationテンプレート(分析スタック) 再度パスの分析を実行します。 以下のテンプレートをデプロイして、スタックの更新をします。  AWSTemplateFormatVersion: 2010-09-09 Description: Rechability Analyzer Test Parameters: ResourceName: Type: String InstanceId: Type: String VPCeIdForSSM: Type: String VPCeIdForSSMMesssages: Type: String VPCeIdForEC2Messsages: Type: String Resources: # ------------------------------------------------------------# # Rechability Analyzer Test01 # ------------------------------------------------------------# EC2NetworkInsightsPathForSSM01: Type: "AWS::EC2::NetworkInsightsPath" Properties: Destination: !Ref VPCeIdForSSM FilterAtSource: DestinationPortRange: ToPort: 443 FromPort: 443 Protocol: "tcp" Source: !Ref InstanceId Tags: - Key: Name Value: !Sub ${ResourceName}-test01-ssm EC2NetworkInsightsPathForSSMMessages01: Type: "AWS::EC2::NetworkInsightsPath" Properties: Destination: !Ref VPCeIdForSSMMesssages FilterAtSource: DestinationPortRange: ToPort: 443 FromPort: 443 Protocol: "tcp" Source: !Ref InstanceId Tags: - Key: Name Value: !Sub ${ResourceName}-test01-ssmmessages EC2NetworkInsightsPathForEC2Messages01: Type: "AWS::EC2::NetworkInsightsPath" Properties: Destination: !Ref VPCeIdForEC2Messsages FilterAtSource: DestinationPortRange: ToPort: 443 FromPort: 443 Protocol: "tcp" Source: !Ref InstanceId Tags: - Key: Name Value: !Sub ${ResourceName}-test01-ec2messages EC2NetworkInsightsAnalysisForSSM01: Type: AWS::EC2::NetworkInsightsAnalysis Properties: NetworkInsightsPathId: !Ref EC2NetworkInsightsPathForSSM01 EC2NetworkInsightsAnalysisForSSMMessages01: Type: AWS::EC2::NetworkInsightsAnalysis Properties: NetworkInsightsPathId: !Ref EC2NetworkInsightsPathForSSMMessages01 EC2NetworkInsightsAnalysisForEC2Message01: Type: AWS::EC2::NetworkInsightsAnalysis Properties: NetworkInsightsPathId: !Ref EC2NetworkInsightsPathForEC2Messages01 # ------------------------------------------------------------# # Rechability Analyzer Test02 # ------------------------------------------------------------# EC2NetworkInsightsPathForSSM02: Type: "AWS::EC2::NetworkInsightsPath" Properties: Destination: !Ref VPCeIdForSSM FilterAtSource: DestinationPortRange: ToPort: 443 FromPort: 443 Protocol: "tcp" Source: !Ref InstanceId Tags: - Key: Name Value: !Sub ${ResourceName}-test02-ssm EC2NetworkInsightsPathForSSMMessages02: Type: "AWS::EC2::NetworkInsightsPath" Properties: Destination: !Ref VPCeIdForSSMMesssages FilterAtSource: DestinationPortRange: ToPort: 443 FromPort: 443 Protocol: "tcp" Source: !Ref InstanceId Tags: - Key: Name Value: !Sub ${ResourceName}-test02-ssmmessages EC2NetworkInsightsPathForEC2Messages02: Type: "AWS::EC2::NetworkInsightsPath" Properties: Destination: !Ref VPCeIdForEC2Messsages FilterAtSource: DestinationPortRange: ToPort: 443 FromPort: 443 Protocol: "tcp" Source: !Ref InstanceId Tags: - Key: Name Value: !Sub ${ResourceName}-test02-ec2messages EC2NetworkInsightsAnalysisForSSM02: Type: AWS::EC2::NetworkInsightsAnalysis Properties: NetworkInsightsPathId: !Ref EC2NetworkInsightsPathForSSM02 EC2NetworkInsightsAnalysisForSSMMessages02: Type: AWS::EC2::NetworkInsightsAnalysis Properties: NetworkInsightsPathId: !Ref EC2NetworkInsightsPathForSSMMessages02 EC2NetworkInsightsAnalysisForEC2Message02: Type: AWS::EC2::NetworkInsightsAnalysis Properties: NetworkInsightsPathId: !Ref EC2NetworkInsightsPathForEC2Messages02 分析結果の確認 VPCエンドポイントへの擬似的な疎通テストが成功していることを確認しました。 この後の作業としては、実際に各エンドポイントのAPIを叩くことにより適切なレスポンスが返却されるかテストしていただく流れになるかと思います。その際に、例えばアクセスエラーが出ればIAMロールの権限不足である可能性が濃厚となります。 最後に いかがだったでしょうか。 VPC Reachability Analyzerを用いて、容易に疎通テストを実行することができました。 検証作業等でネットワーク疎通不可事象が発生することが多いかと思います。その際には、AWSサポートへ問い合わせする前にご自身で疎通テストを実施し到達不能箇所を特定した上で調査していただければ幸いです。 本記事が皆様のお役にたてば幸いです。 ではサウナラ~🔥
こんにちは、SCSK株式会社の盛です。 今回は皆様にお知らせしたいことがあり、TechHarmonyに初寄稿しました。それは… SCSK株式会社は、 JAWS DAYS 2024   へ協賛します! ランチセッション他、計3セッションに登壇します! ご来場お待ちしております! JAWS DAYS とは JAWS-UG ( J apan AWS U ser G roup) 主催、アマゾン ウェブ サービス ジャパン合同会社後援で開催される JAWS-UG 最大の エンジニアコミュニティイベント です。 JAWS-UGは日本全国に60以上の支部を持つ Amazon Web Services(以下AWS)のユーザーグループで、全国の各支部では、AWSに関する技術交流や人材交流が毎週のように行われ、AWSユーザーの技術力向上およびビジネスの拡大に寄与しています。 JAWS DAYS 2024 のテーマは 「 LEAP BEYOND 」 リアルなイベント会場で 「ビジネスとテクノロジー」「地方と都市」「学生と社会人」 など、さまざまなバックグラウンドを持つ人が同じ空間を共有します。この空間の中で、異なる価値観の人たちが、自分たちのコミュニティを飛び越えて偶然に出会う場を提供することで、新しい可能性を探っていく主旨となっています。 AWS初心者から上級者までのエンジニア、経営者や人事、マーケティング、エンタープライズからスタートアップ、中小企業など職種や業態・会社規模を問わず、たくさんの方に参加いただけるイベントです。   イベント概要 開催日時: 2024年3月2日(土)  – セッション:10:00〜17:00  – 懇親会:17:30〜19:30(予定) 場所:池袋サンシャインシティ 展示ホールA  – 住所:〒170-8630 東京都豊島区東池袋3-1   弊社からの登壇について それでは、弊社登壇者のセッション内容について、簡単にご紹介させていただきます。 CIer・SIer集まれ!! クライアントワークな私たちとAWSの良い関係を考えよう! 講演時間 : 11:00~11:50 講演場所 : セッションE SCSK登壇者 : 木澤 朋隆 (AWS Ambassador) 受託開発経験者3名のCIer・SIerによる、よもやまパネルディスカッションに弊社木澤がパネリストとして参加します。 クライアントワークならではの苦労話や成功事例を知って、共に考え、楽しく学べるセッションです。 セッション詳細 エンジニアブログ「TechHarmony」注目記事のご紹介 講演時間:12:45~13:00(ランチセッション) 講演場所:セッションE SCSK登壇者: 齋藤 友宏 (AWS Jr.Champions) ・ 木澤 朋隆   本エンジニアブログTechHarmony から、選りすぐりの記事に触れ、解説するセッションです。 皆様のお役に立とうと日々のAWSアップデートをキャッチアップするKawarimonoたちが、業務中にふと得られた気付きであったり、ふと閃いたことなどについて執筆している本ブログですが、その中から選りすぐりの記事をご紹介します。 皆様にとって、偶発的なshi AW a S eを手繰り寄せる何かが見つかれば幸いです。 セッション詳細 子育てエンジニアパネルディスカッション ~コーディングとおむつ替えの狭間で~ 講演時間:16:10~17:00 講演場所:セッションC SCSK登壇者: 中村 朋世 SCSKは ダイバーシティ&インクルージョン(D&I)の施策 を全社で推進しており、多様な人材が活躍しています。特に ワーク・ライフ・バランス の推進は業界に先駆けて行われており、多数の社員にて育児との両立が行われています。 本パネルディスカッションには弊社からパネリストとして中村が登壇し、子育てと日進月歩で進化する技術のキャッチアップ、両面を追いかけるコツについて語り合います。 セッション詳細 他にもセッションが多数! JAWS DAYS 2024では、その他にも素敵なセッションが多数あります。 詳細は イベントサイト(セッション一覧) をご覧下さい。   お申込み 本イベントへの申込はイベント公式サイトからどうぞ。 (人数制限がございます。早めの登録がオススメです) Click Here ! 👇🖱 JAWS DAYS 2024 JAWS DAYS 2024 Official HP jawsdays2024.jaws-ug.jp 当日は池袋サンシャインシティにてお待ちしております。 是非ご来場下さい!
こんにちは、SCSK 浦野です。 1月があっという間に過ぎてしまい、すでに2月の中旬であることに焦りを覚えている筆者です。 昨年は自分の中では生成AIに驚かされ続けた1年でした。興味がある分野でもありましたので、自宅でRVCでボイスチェンジをしてみたり、Stable Diffusion で絵を生成してみたりしていましたが、ここのところはあまり触れていませんでした。 そんななか、AWSのブログを見ていたところ「 Amazon Bedrock を利用して、画像生成アプリケーションを開発してみた! 」という記事を見つけました。 昨年 Amazon Titan Image Generator G1 が発表されておりましたが、こちらも触れられていなかったので、モデルを Amazon Titan Image Generator G1 に変更して試してみました。その際に少し追加の手順が必要になりましたので、共有できればと思います。 前提など 手順は「 Amazon Bedrock を利用して、画像生成アプリケーションを開発してみた! 」を参考に実施致します。 但し、Amazon Titan Image Generator G1 を使ってみたいので、モデルの選択で Amazon Titan Image Generator G1 を選択、呼び出し等はそれに合わせて変更します。 Amazon BedrockでTitan Image Generator G1を利用可能にする Amazon Bedrock を開き、左ペインの「モデルアクセス」をクリック、右上の「モデルのアクセスを管理」をクリックします。 表示された画面でTitan Image Generator G1のチェックボックスにチェックを入れて、「変更を保存」をクリックします。 変更後、アクセスのステータスが「アクセスが付与されました」となっていることを確認します。  S3バケット作成 生成された画像を保存するバケットを作成します。 コンソールでS3に移動し、「バケットを作成」から適当な名前を付けえたバケットを作成します。バケットの設定は全てデフォルトで作成します。  Lambda関数作成 コンソールでLambdaに移動し、 「関数の作成」をクリック 適当な関数名を指定、ランタイムで「Python 3.12」を選択し、その他はデフォルトで「関数の作成」をクリックします。 コードを書きたいところですが、先に Lambda の IAM ロールを変更します。 この際に Titan Image Generator G1を利用するので、Resource の部分で amazon.titan-image-generator-v1 を指定します。  { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "bedrock:InvokeModel" ], "Resource": [ "arn:aws:bedrock:us-east-1::foundation-model/ amazon.titan-image-generator-v1 " ] }, { "Effect": "Allow", "Action": [ "s3:GetObject", "s3:PutObject" ], "Resource": [ "arn:aws:s3:::{作成したバケット名}/*" ] } ] }   コードを記述します。Titan Image Generator G1を利用するため、Titan Image Generator G1に合わせた設定で記述します。 コードを保存後に、「設定」からタイムアウトを3分程度に変更します。(筆者が試した範囲では1枚生成されるのに30秒前後かかっていました) import json import boto3 from io import BytesIO import base64 from PIL import Image from botocore.config import Config import uuid def lambda_handler(event, context): bedrock_runtime = boto3.client('bedrock-runtime') my_config = Config(region_name="us-east-1", signature_version="s3v4") s3 = boto3.client("s3", config=my_config) bucket_name = '{作成したバケット名}' text = event['input_text'] image_num = 1 body = json.dumps({ "taskType": "TEXT_IMAGE", "textToImageParams": { "text": text, }, "imageGenerationConfig": { "numberOfImages": image_num, "quality": "premium", "height": 768, "width": 1280, "cfgScale": 7.5, "seed": 0 } }) response = bedrock_runtime.invoke_model( body=body, modelId="amazon.titan-image-generator-v1", accept="application/json", contentType="application/json" ) response_body = json.loads(response['body'].read()) images = [Image.open(BytesIO(base64.b64decode(base64_image))) for base64_image in response_body.get("images")] presigned_urls = [] for img in images: img_data = BytesIO() img.save(img_data, format='PNG') img_data.seek(0) random_uuid = uuid.uuid4().hex s3_key = f"{random_uuid}.png" s3.upload_fileobj(img_data, bucket_name, s3_key, ExtraArgs={'ContentType': 'image/png'}) presigned_url = s3.generate_presigned_url( 'get_object', Params={'Bucket': bucket_name, 'Key': s3_key}, ExpiresIn=3600 ) presigned_urls.append(presigned_url) return { 'statusCode': 200, 'body': json.dumps({'presigned_urls': presigned_urls}) } Lambda Layerの登録 記載したコードでは画像処理ライブラリのPillowを利用していますが、デフォルトのランタイムには含まれていない為、Lambda Layerの登録を行う必要があります。 python 3.12の環境でライブラリをインストールし(Cloud9等で環境を準備できます)、zipファイルに圧縮してレイヤーにアップロードして登録後、Lambda関数側の「レイヤー」から登録したレイヤーを追加してください。   テスト実行 Lambdaの画面にある「Test」ボタンを押し、テストイベントを設定します。イベントJSONには、以下のような形で生成を希望するテキストを記述します。「保存」を押して保存後に、「テスト」を押すと生成が実行されます。 { "input_text": "Mt Fuji" } 実行し、成功するとレスポンスとしてURLが返されますので、ブラウザにURLを入れると生成された画像を見ることができました。 参考元では、APIの設定やフロントの作成もありますが、同様の手順で実装できますので本記事ではスキップさせて頂きます。
本記事の内容は、以下のCato Networks社の記事を元に日本語へ意訳し、再構成したものとなります。 Cato Endpoint Protection (EPP) Endpoint Protection (EPP) Cato Endpoint Protection (EPP) is the industry’s first SASE-managed EPP solution protecting endpoints against advanced malware, evasive attacks and zero-day thr... www.catonetworks.com Cato Extended Detection and Response (XDR) Extended Detection and Response (XDR) Cato XDR is the industry’s first SASE-based detection and response solution empowering security teams with granular and efficient threat investigation and remed... www.catonetworks.com Cato Networks社 は、2024年2月5日に、端末のマルウェア対策である Endpoint Protection (EPP) と、SASEのネットワークのログだけでなく、エンドポイント(EPP/EDR)も含めた様々なログを統合し、総合的に分析し、インシデント対応を一元化する Extended Detection and Response (XDR) をリリースしました。 Cato EPPは、これまでのSASEとしてのネットワーク層を超え、エンドポイントにまでセキュリティ範囲を拡張する製品 となり、Cato管理アプリケーション(Cato Management Application、以下、CMA)に完全に統合され、クラウドネイティブな他のセキュリティスタックと連携して動作します。 Cato XDRは、世界初のSASEベースのXDR(Extended Detection and Response) です。Catoクラウドのセキュリティ機能である NGFW、SWG、IPS、NGAM、DNS Security、CASB、DLP、RBIの各種データを始め、Cato EPP、さらに、Microsoft Defender、CrowdStrike、SentinelOne などの主要EDRソリューションと連携により、エンドポイントからネットワークにまたがる豊富なネイティブセンサーから収集される上質なデータから、脅威の探索・検出・対応に単一の共有コンテキストを提供することが可能になります。 それでは、CatoクラウドのEPPとXDRについてご紹介します。 Cato EPPについて Cato エンドポイントプロテクション(EPP)は、高度なマルウェア、回避型攻撃、ゼロデイ脅威からエンドポイントを保護する世界初のSASE管理型EPPソリューションです。 Cato EPPは、CatoのマルチレイヤーSASEアーキテクチャにエンドポイント保護と検出機能を追加し、管理オーバーヘッドを削減し、セキュリティチームの効率を高め、企業のセキュリティ体制を改善します。 ファイル実行前とランタイムでマルウェアを阻止 Cato EPPは、アーカイブやパックされたファイルを含む300以上のファイルタイプをスキャンします。高度なルールベースの分析と機械学習アルゴリズムを使用し、ファイルの特性分析に基づいて、既知のマルウェア、ポリモーフィック、ゼロデイマルウェアを識別します。Cato EPPは、ヒューリスティックとプロセス行動分析を使用して、疑わしい悪意のあるアクティビティをリアルタイムで検出します。この機能により、システムメモリ内で直接動作するファイルレス・マルウェア、回避型エクスプロイトやゼロデイ攻撃、正規のツールを悪意のある目的に活用する Living Off The Land (※) 攻撃の検出と防止が可能になります。攻撃対象領域をさらに最小化するために、Catoはデバイス制御によってUSBドライブの使用をブロックすることができます。 (※)Living Off The Land(環境寄生型)とは、対策側の監視や調査を回避することを目的として、持ち込んだ正規ツールの悪用や被害者の環境にあるシステムを悪用する、痕跡を残さない攻撃手法。 侵害されたエンドポイントに対する柔軟な封じ込めオプション マルウェアによる潜在的な被害を最小限に抑えるには、脅威へのリアルタイムな対応が不可欠です。しかし、自動化されたレスポンスとユーザの生産性の間には、微妙なバランスが必要です。Catoは、脅威のブロック、ファイルの隔離、プロセスの終了など、組織のセキュリティ要件に合わせて封じ込めポリシーを調整できる柔軟性を管理者に提供します。 EPPをSASEに統合し、セキュリティ管理を合理化 Cato EPPは、Cato管理アプリケーション(CMA)を通じて完全に管理され、他のすべてのCatoクラウドのプラットフォーム機能とシームレスに統合されています。管理者は、ユーザーデータ、ネットワーク情報、およびセキュリティポリシーが統合された統一コンソールから、保護されたエンドポイントを監視できるという利点があります。Cato EPPにより、管理者はスタンドアロンのエンドポイント保護ソリューションを統合、維持、管理する必要がなくなります。すべてのEPPイベントとアラートがCatoクラウドプラットフォームのネイティブな一部となったため、手動によるSIEM統合も不要になりました。 迅速な導入とユーザー影響のない即時保護 Cato EPPは、Cato管理アプリケーション(CMA)またはお客様が選択したモバイルデバイス管理ツール(MDM)を介してプロビジョニングすることができます。管理者は、数分で数千のエンドポイントの保護を開始できます。インストール後、Cato EPPエージェントはバックグラウンドで実行され、エンドユーザーには完全に透過的です。ログイン不要で、エンドポイントでセキュリティイベントが発生すると、ユーザーは即座に保護され、アラートが表示されます。アドホックなマルウェアスキャン活動は、ユーザーまたは管理者がCato管理アプリケーション(CMA)から直接開始できます。 ネットワークとエンドポイントが同じデータレイクを使用することで検出とレスポンスをより速く(XDR対応) Cato EPPのイベントは、Catoクラウドプラットフォームの各種エンジンによって生成された他のすべてのイベントと同じデータレイクに保存されます。Cato XDRは、AI/ML脅威の検知と調査を最適化するために、ネットワークベースのセンサーとともに、高品質のエンドポイントデータを活用します。管理者は、1つの画面でエンドポイントとネットワークのすべてのセキュリティイベントの統一されたリストを見ながら、ユーザーやデバイスごとにイベントを簡単にフィルタリングすることができ、効率的なインシデント調査と対応が可能になります。   Cato XDRについて Cato XDRは、世界初のSASEベースのXDRソリューションであり、セキュリティチームにきめ細かく効率的な脅威調査・修復ツールを提供します。Cato XDRのAIとMLアルゴリズムは、膨大なデータレイクから脅威を特定し、Cato管理アプリケーション(CMA)内で分析と解決のために管理可能な方法で浮上させます。 脅威防御エンジンのアラート疲れを見抜く Cato XDRは、Catoのリアルタイムセキュリティエンジンによって生成されたブロックイベントを集約し、単一の脅威防御インシデントにグループ化します。これらのインシデントは、セキュリティチームがアラート疲れを克服し、侵害されたデバイスを迅速に検出し、適切な封じ込めと修復のアクションを取るのに役立ちます。 回避的なセキュリティ脅威の検出と修復 Cato XDR 脅威ハンティング( Threat Hunting )インシデントは、CatoのAI/MLエンジンによって作成されます。脅威ハンティングエンジンは、データレイクを継続的にスキャンし、防御レイヤーでブロックされなかった常駐脅威の異常な指標を探します。脅威ハンティングエンジンは、さまざまなシグナルを1つのインシデントにグループ化し、セキュリティ・アナリストがさらに調査を行います。さらに、MLアルゴリズムは各インシデントにリスクスコアを提案し、セキュリティチームが脅威の調査に優先順位をつけられるようにします。 異常検知で不審なユーザー行動を調査 Cato XDRは、悪意を示す可能性のある異常な行動を特定するために、 エンドユーザー行動分析(EUBA) 機能を統合しています。異常検知AI/MLエンジンは、ユーザーのネットワークアクティビティを事前に計算されたベースラインと比較し、異常検知インシデントの作成を通じて、疑わしい逸脱について警告します。セキュリティ・チームは、報告されたインシデントが悪意あるものか良性かを効率的に調査・判断し、それに応じて行動を起こすための詳細な情報と洞察を得ることができます。 生成AIとMITRE ATT&CKマッピングでインシデント調査をスピードアップ Cato XDRは、セキュリティチームの効率的な運用を可能にするため、複数のAI技術を使用している。生成AIは、Cato XDRのインシデント「ストーリーテラー」に使用されており、インシデントのデータポイントを脅威のストーリーにシームレスに結び付け、理解しやすく伝わりやすい要約を作成します。 脅威とリスクの分析をさらに支援するために、Cato XDRのインシデントは特定の MITRE ATT&CK TTPs(Tactics Techniques and Procedures) にマッピングされ、セキュリティチームが攻撃のキルチェーンにおける攻撃者の進捗状況を正確に理解するのに役立ちます。 エンド・ツー・エンドの可視性と迅速な修復を実現 XDRソリューションの一般的な課題は、修復アクションが異なるプラットフォーム上で実行されることです。 Cato XDRは、Catoクラウドプラットフォームのネイティブ機能であり、セキュリティチームが同じソリューション内でアクティブな脅威を修復することを可能にします。エンドポイントと攻撃封じ込めのためのファイアウォールルールは数分で設定でき、インターネットとの悪意のあるトラフィックをブロックし、WANを介したマルウェアのさらなる拡散を防止します。EPPスキャンは即座にトリガーされ、感染や侵害の可能性があるエンドポイントをプロアクティブにクリーニングします。 高度に訓練された実証済みAI/MLを搭載したオープンなXDR Cato XDRは、Catoクラウドプラットフォームのネイティブセンサーからの生のデータと、サードパーティのEDRソリューションなどの外部センサーからのイベントを、単一のデータレイクに収集するオープンなXDRソリューションです。Cato XDRは、脅威ハンティングと異常検知のために高度なAIとMLアルゴリズムを使用しています。このアルゴリズムは、元軍人のセキュリティ・アナリストとデータ・アナリストによって開発され、ペタバイトのデータと数兆件のイベントで訓練され、すでに数万件の確認されたセキュリティ・インシデントで実証されています。Cato XDRは、SOCチームが脅威の滞留時間を短縮し、セキュリティ・インシデントを迅速に修復することを可能にします。 脅威の検知、調査、対応(TDIR)のための単一コンソール Cato XDRは、脅威の検知、調査、対応( Threat Detection , Investigation and Response:TDIR )を行い、インシデントのライフサイクル全体を管理する単一のコンソールをSOCチームに提供します。Cato管理アプリケーション(CMA)内のXDRダッシュボードは、すべてのインシデント、そのステータス、MLで計算されたリスクと優先度を表示します。個々のインシデントの調査は、ワンクリックで完了し、AIを活用した洞察と推奨によって強化された、さらなる分析のための共通のデータ表示構造を備えています。SOCチームは、管理コンソールを切り替える手間を省き、効率を高め、ヒューマンエラーの可能性を減らすことができます。 業界で最も広範なネイティブセンサーが、より優れた検知と迅速なレスポンスを実現 Cato XDRは、Catoクラウドプラットフォームのセキュリティ機能をネイティブセンサーとして使用します。Catoクラウドの NGFW、SWG、IPS、NGAM、DNS Security、CASB、DLP、RBIからのデータは、Catoデータレイクに保存され、Cato XDRへの高品質なインプットとして機能します。ネイティブセンサーのデータはソースで削減されないため、Cato XDRのAI/MLアルゴリズムは、外部ソースからのデータを処理するAI/MLに比べて、重要なシグナルを見逃す可能性が大幅に低くなります。SOCチームは、比類のないレベルのインシデント精度と豊富な調査用データから利益を得ることができます。 MLを活用したクラウド規模の脅威インテリジェンスにより、有効性を向上し、誤検知を削減 Cato XDRは、250以上の脅威インテリジェンスソースによって強化されており、500万件以上の有効なIoCレコードを生成します。Catoは、専用に構築されたクラウドスケールのMLプラットフォームを使用して、何百ものソースから脅威インテリジェンスフィードを取り込み、その中の各IoCレコードを処理して検査し、正確で最新のブラックリストとホワイトリストを維持します。 Catoは、セキュリティチームに最新の脅威インテリジェンスデータを提供し、誤検知をほぼゼロに抑えた効率的な運用を実現します。 まとめ CatoクラウドのSASEから少し離れて、EPP、XDRの記事をご紹介させていただきました。 Catoクラウドに少しでも興味をお持ちになられた方は、遠慮なくSCSKまでお問い合わせください。 SASE、Cato Networks社、Catoクラウド(Cato Cloud/Cato SASE Cloud)自体の知名度もまだまだ低い状況です。 SCSKでは、2021年からSASEの主要ソリューションを一同に紹介を行うオンラインセミナー「SCSK SASE Solution Summit(通称:S4 エスフォー)」を定期的に開催しております。これまで13回開催し、1,600名以上の方にご参加いただいております。 次回は、2024年2月15日に開催いたしますので、ご興味のある方は是非ご参加ください(2024年2月時点) さらに、2024年3月14日には、Catoクラウドの主要機能を2時間・デモ形式でご覧いただけるセミナーを開催しますので、ご興味のある方は是非ご参加ください。 【好評につき追加開催決定!】SCSK SASE Solution Summit (S4)ー主要4製品の違いや強みを横並びでご紹介!ー 弊社グループにて取り扱っている4つのSASE製品の気になるポイントをギュッと凝縮しており、製品比較や選定行っていくための情報を一度に収集できるため、「SASEの関する情報収集中の方」だけでなく、「自社の課題解決に最適なSASEを知りたい方」、「他社の導入成功事例を聞きたい方」のご参加を心よりお待ちしております! www.scsk.jp Catoクラウドデモセミナー~Catoクラウドの主要機能を2時間で網羅~ 本セミナーでは、世界初のSASEである「Catoクラウド」の概要をたっぷり2時間、デモ形式でご覧いただきます。 また、ご希望の方(先着10名様)は、デモ環境に対して、お手元の環境からハンズオン形式でCatoクラウドに触れて頂くことが可能な参加型セミナーです。 www.scsk.jp SASE、Catoクラウドのセミナー以外に、Catoクラウドのお客様導入事例の制作、FAQサイト運営、この TechHarmony(技術ブログ)で、皆様のお役に立て、Catoクラウドの知名度アップに少しでも貢献できればと考えております。
こんにちは、広野です。 2024 年 4 月から正式リリースされる AWS 認定の新試験、Data Engineer – Associate のベータ版試験を 2023 年 12 月に受験しておりまして、先日合格通知が届きました。その受験記や対策っぽい情報を紹介したいと思います。 Data Engineer – Associate 試験って? 冒頭にも書きましたが、新たに新設される AWS 認定試験です。近年のデータ活用、AI/ML 技術の注目度合いから、従来のソリューションアーキテクト、ディベロッパー系に次ぐ新たな体系をつくったものと想像します。 公式情報はこちらをご覧下さい。 AWS Certified Data Engineer - Associate 認定 | AWS 認定 AWS テクノロジーを使用して分析や実用的なインサイトを得るためにデータを変換することにご関心がおありの場合、このベータ試験は、この新しい認定の最初の取得者となる機会を提供します。AWS は、試験ガイド、テスト問題のサンプル、トレーニングリソースを提供しています。詳細をご覧ください。 aws.amazon.com ベータ版試験って? AWS が試験を新設する場合、正式リリース前にベータ版試験をリリースします。実際の受験者のフィードバックを受けて、正式リリースまでに改修を入れるのが目的と思います。 ベータ版試験には、以下の特徴があります。 期間限定 英語でしか受けられない 費用は半額で受けられる(バウチャーの併用は不可) 合格発表は受験から数か月後 合格すれば正式資格として認定される デフォルトで半額で受けられるメリットはありますが、日本人的には英語でしか受けられないというのがデメリットでしょう。 試験対策は? 今後の正式リリースのために、執筆時点での対策を残しておきます。ベータ版試験からの個人的な見解なので、正式リリースされた試験とは若干違いがあると思いますが、そこはご了承ください。 そもそも新試験なので、今時点、受験対策本などはありません。公式情報に頼るしかありません。 まずは公式「試験ガイド」で試験範囲を押さえる 前述、公式サイトのリンクに試験ガイドの PDF 資料があります。これで、ある程度どんなことが問われるのかは想像できます。わかりやすく言いますと、今後廃止予定ではありますが Data Analytics – Specialty (DAS) と同じ領域ですので、内容はほぼ同じと思ってよいと思います。試験対策も DAS の対策をすれば半分以上は取れるかな、と思います。 出題イメージを押さえる AWS Skill Builder という AWS 公式の e-Learning サイトに 20 問だけですが公式練習問題が掲載されています。日本語もあります。こちらを見れば、どんな出題がされるのかイメージは湧くと思います。 出題されるサービスを理解しておく 全てを理解する必要はないのですが、各サービスで何ができるのか、他のサービスと組み合わせるとどのようなユースケースに対応できるのか、を理解するとよいと思います。次の章で特に理解しておくべきサービスを紹介します。 絶対に理解しておくべき AWS サービス 以下 5 つ。データ活用の中核となる AWS サービスです。 Amazon Redshift Amazon QuickSight Amazon Athena AWS Glue Amazon RDS これらは、AWS の Blackbelt 等でまんべんなく理解しておく必要があります。RDS に関しては、SAA や DBS 試験の知識で兼ねることができます。その他、SAA, DVA, SOA の知識で賄える部分があるので、それらを合格している状態で受験されることをお勧めします。 AWS Glue は特に Glue XXXXX といった Glue 系のいくつかのサービスに分かれているので、それらのユースケースを全て理解しておきましょう。 Amazon Redshift には Redshift Spectrum というサービスがあります。Redshift との違いはしっかり押さえておきましょう。 あまり深入りすると試験規約上よろしくないので、この程度にとどめておきます。 その他学習しておいた方がよいこと 以下、勉強しておいて良かったな、と感じたことです。 データレイクの考え方。Amazon S3 にあらゆるデータを集約させ、Glue で ETL、Athena でクエリー、QuickSight で可視化、という王道の設計パターンの理解は必須です。加えて、Lake Formation でできること、たとえばアクセス制御はどんなことができるかは押さえておきましょう。 データ活用の過程で、データを処理するパイプラインを作成するユースケースがあります。このとき、パイプラインを作成するソリューションとして以下 3 つが挙げられます。使い分けを理解しておくとよいでしょう。 AWS Step Functions AWS Glue Workflow Amazon Managed Workflows for Apache Airflow ETL ジョブのスケジュールも、以下 3 つの違いは押さえておきましょう。 Amazon EventBridge AWS Batch AWS Glue Workflow オンプレミスからの大量データ移行も押さえておきましょう。AWS DMS や AWS DataSync が一般的です。 こうして見ると、結構幅広いですね。 まとめ いかがでしたでしょうか。情報少なくて申し訳ないです。 DEA はアソシエイトレベルとは言え、かなり難易度高かった印象です。記事内で申しておりましたが、DAS と同じレベルと思ってもらえればと思います。今後は SAA、DVA、SOA と並ぶ試験になりますし、データ活用も今後必要な知識になりますので、是非皆様もチャレンジ頂けたらと思います。 本記事が皆様のお役に立てれば幸いです。
こんにちは。SCSKのふくちーぬです。 Amazon CloudWatch AlarmのターゲットにAmazon Simple Notification Service (Amazon SNS) だけではなく、AWS Lambdaを指定できるようになったことを知っていますでしょうか。 今回は、Amazon CloudWatch Alarm のターゲットに AWS Lambda をターゲットとしたメトリクス監視をご紹介します。またリソースの構築には、AWS CloudFormation を利用します。 CloudWatch AlarmのターゲットにLambdaがサポートされた件 以前までは、CloudWatch Alarmはアラームアクションとして、SNSやAutoacalingの増減やEC2インスタンスの起動/停止、Systems Manager Incident Manager でインシデントの起票が可能でした。 Amazon CloudWatch でのアラームの使用 - Amazon CloudWatch アラームの状態が変わったときに Amazon SNS メッセージを送信するか、アクションを実行する Amazon CloudWatch のアラームを作成します。 docs.aws.amazon.com カスタムアクションを実施する際には、一度SNSトピックに送信した後にLambdaでサブスクライブする必要がありました。 2023/12/22に発表されたアップデートにより、直接Lambdaをターゲットとすることが可能になりました。 Amazon CloudWatch アラームにアラーム状態変更アクションとして AWS Lambda が追加 aws.amazon.com 使いどころ 今回のアップデートによりSNSを経由することなく、カスタムアクションを容易に実施することができます。SNSを挟む必要がなくなったため、その分のリソースを構築する必要がなくなったことは大きなメリットとなります。CloudWatch Alarmのアラート内容をLambdaにて加工し、その後にSNSへ送信する処理をLambda内で完結して実行できます。 SNSを挟むパターンとしては、他の複数のサービス(Lambda・SQS・E-Mail等)へ送信する要件があったり、リトライ処理を入れ込むこと等が対象となってくると思います。 検証 実際に、CloudWatch AlarmのターゲットにLambdaを指定してアラート内容の出力結果を確認します。 アーキテクチャー LambdaのConcurrenExecutions(同時実行数)メトリクスの監視をする アラーム状態の場合、Lambdaをターゲットとして起動する Lambdaの処理では、アラート内容を専用のロググループに出力する CloudFormationテンプレート 下記のリソースを作成するCloudFormationテンプレートです。 CloudWatch アラーム Lambda Lambda リソースポリシー ロググループ IAMロール 以下のテンプレートをデプロイしてください。 AWSTemplateFormatVersion: 2010-09-09 Description: To trigger Lambda with a CloudWatch Alarm Parameters: ResourceName: Type: String Resources: # ------------------------------------------------------------# # CloudWatch Alarm # ------------------------------------------------------------# CloudWatchAlarm: Type: 'AWS::CloudWatch::Alarm' Properties: Namespace : AWS/Lambda AlarmName : !Sub ${ResourceName}-Lambda-ConcurrentExecutions-Alarm AlarmActions : - !GetAtt Function.Arn MetricName : ConcurrentExecutions ComparisonOperator : GreaterThanThreshold # 以上を表す EvaluationPeriods : 5 DatapointsToAlarm: 1 Period : 60 Statistic : Maximum Threshold : 100 # ------------------------------------------------------------# # Lambda # ------------------------------------------------------------# Function: Type: AWS::Lambda::Function Properties: FunctionName: !Sub ${ResourceName}-lambda-function Role: !GetAtt LambdaRole.Arn Runtime: python3.12 Handler: index.lambda_handler Environment: Variables: LOGGROUPNAME: Alarm-Lambda-ConcurrentExecutions Code: ZipFile: !Sub | import boto3 import os import time import datetime import json s3_client = boto3.client('s3') cwlogs_client = boto3.client('logs') def lambda_handler(event, context): message = event['alarmData'] LOG_GROUP_NAME = os.environ['LOGGROUPNAME'] localtime = datetime.datetime.now() + datetime.timedelta(hours=9) LOG_STREAM_NAME = localtime.strftime("%Y%m%d%H%M") try: cwlogs_client.create_log_stream( logGroupName = LOG_GROUP_NAME, logStreamName = LOG_STREAM_NAME, ) response = cwlogs_client.put_log_events( logGroupName = LOG_GROUP_NAME, logStreamName = LOG_STREAM_NAME, logEvents = [ { 'timestamp': int(round(time.time() * 1000 )), 'message' : json.dumps(message) } ] ) except cwlogs_client.exceptions.ResourceAlreadyExistsException: pass except Exception as e: print("error",e) raise return response LambdaInvokePermission: Type: 'AWS::Lambda::Permission' Properties: FunctionName: !GetAtt Function.Arn Action: 'lambda:InvokeFunction' Principal: lambda.alarms.cloudwatch.amazonaws.com SourceAccount: !Ref 'AWS::AccountId' SourceArn: !GetAtt CloudWatchAlarm.Arn # ------------------------------------------------------------# # Log Group # ------------------------------------------------------------# FunctionLogGroup: Type: AWS::Logs::LogGroup Properties: LogGroupName: !Sub "/aws/lambda/${Function}" CloudWatchAlarmLogGroup: Type: AWS::Logs::LogGroup Properties: LogGroupName: Alarm-Lambda-ConcurrentExecutions # ------------------------------------------------------------# # IAM Role # ------------------------------------------------------------# LambdaRole: Type: AWS::IAM::Role Properties: RoleName: !Sub ${ResourceName}-lambda-role AssumeRolePolicyDocument: Version: '2012-10-17' Statement: - Effect: Allow Action: sts:AssumeRole Principal: Service: - lambda.amazonaws.com ManagedPolicyArns: - arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole  アラームの発砲テスト 任意の端末(Cloud9やCloudShell等)から、以下のコマンドを実行してアラートを発砲させます。<ResourceName>には、スタックデプロイ時に入力したパラメータを挿入します。 aws cloudwatch set-alarm-state --alarm-name <ResourceName>-Lambda-ConcurrentExecutions-Alarm --state-value ALARM --state-reason "alarm test"  アラート内容が正常に出力されていることが確認できました。 容易にCloudWatch AlarmとLambdaを連携することができましたね。 最後に いかがだったでしょうか。CloudWatch AlarmのターゲットにLambdaを指定して、カスタムアクションを実行しました。 既存の構成でSNSを利用している場合は、SNSを省くことができるかどうか検討をすることをお勧めします。 本記事が皆様のお役にたてば幸いです。 ではサウナラ~🔥
こんにちは。SCSKのふくちーぬです。 皆さんは、プライベート(閉域網)環境下での AWS Lambda や Amazon API Gateway を利用したことありますでしょうか。VPC Lambdaに関する詳細な解説や設計ポイントを知りたい方は、以下の記事から先にご覧いただければ幸いです。 VPC Lambdaを実現しているAWS内の裏側と設計の心得三箇条 インターネットに接していないVPC Lambdaの設計ポイントとVPC Lambdaを実現しているAWS内の裏側を紹介します。 blog.usize-tech.com 2023.12.22 今回は、Amazon API Gateway の VPC エンドポイントを利用する際の落とし穴について解説します。 AWSサービスエンドポイントの種類 AWSでは、各種サービスにおいてサービスへのリクエストを受け付けるエンドポイントを用意しています。以下のように、大きく2種類に分かれています。 ・全ての機能を有するサービスエンドポイント 例:Lambda, CloudWatch, CloudFormation …etc ・機能を分割したサービスエンドポイント 例:API Gateway, App Sync, Bedrock …etc サービスエンドポイントとクォータ - AWS 全般のリファレンス AWS のサービスのサービスエンドポイントとデフォルトクォータ (以前は制限と呼ばれていました) を参照してください。 docs.aws.amazon.com API Gatewayのサービスエンドポイントの提供体系 API Gatewayではサービスエンドポイントとしてコントロールプレーン/データプレーンの2種を用意しています。 Amazon API Gateway エンドポイントとクォータ - AWS 全般のリファレンス このサービスのサービスエンドポイントおよび Service Quotas を以下に示します。AWS のサービスにプログラムで接続するには、エンドポイントを使用します。標準の AWS エンドポイントに加えて、一部の AWS のサービスは選択されたリージョンで FIPS エンドポイントを提供します。詳細については、「 」を... docs.aws.amazon.com API Gatewayにおいては、APIの呼び出し機能を有するデータプレーンのみVPCエンドポイントとして提供されます。 ・com.amazonaws.<リージョン>.execute-api AWS PrivateLink と統合する AWS のサービス - Amazon Virtual Private Cloud AWS PrivateLink と統合する AWS のサービス について説明します。サービスコンシューマーは、AWS のサービス に接続するためのインターフェイス VPC エンドポイントを作成できます。 docs.aws.amazon.com つまり、API の作成・管理機能を有するコントロールプレーンはインターネット経由の通信ではないと利用できません。 ・apigateway.<リージョン>.amazonaws.com 結論 API GatewayのVPCエンドポイントでは、APIの呼び出し機能のみ利用可能である プライベート(閉域網)環境にてAWSサービスを利用する際は、各種AWSサービスエンドポイントが、VPCエンドポイントとして提供されているか確認すること 検証 今回は、VPC LambdaにてNAT Gateway経由でAPI Gatewayのエンドポイント一覧を取得します。 アーキテクチャ VPC Lambdaは、プライベートサブネットに配置します。 VPC Lambdaは、NAT Gateway経由でAPI Gatewayのコントールプレーンにアクセスします。 CloudFormationテンプレート 下記のリソースを作成するCloudFormationテンプレートです。 VPC インターネットゲートウェイ NATゲートウェイ パブリックサブネット、プライベートサブネット ルートテーブル セキュリティグループ Lambda IAMロール 以下のテンプレートをデプロイしてください。 AWSTemplateFormatVersion: 2010-09-09 Description: cfn vpc lambda Parameters: ResourceName: Type: String Resources: # ------------------------------------------------------------# # VPC # ------------------------------------------------------------# VPC: Type: AWS::EC2::VPC Properties: CidrBlock: 10.0.0.0/16 EnableDnsSupport: true EnableDnsHostnames: true Tags: - Key: Name Value: !Sub "${ResourceName}-VPC" # ------------------------------------------------------------# # Subnet # ------------------------------------------------------------# PublicSubnet1a: Type: AWS::EC2::Subnet Properties: VpcId: !Ref VPC CidrBlock: 10.0.0.0/24 AvailabilityZone: ap-northeast-1a MapPublicIpOnLaunch: false Tags: - Key: Name Value: !Sub "${ResourceName}-PublicSubnet-1a" PublicSubnet1c: Type: AWS::EC2::Subnet Properties: VpcId: !Ref VPC CidrBlock: 10.0.1.0/24 AvailabilityZone: ap-northeast-1a MapPublicIpOnLaunch: false Tags: - Key: Name Value: !Sub "${ResourceName}-PublicSubnet-1c" PrivateSubnet1a: Type: AWS::EC2::Subnet Properties: VpcId: !Ref VPC CidrBlock: 10.0.2.0/24 AvailabilityZone: ap-northeast-1a MapPublicIpOnLaunch: false Tags: - Key: Name Value: !Sub "${ResourceName}-PrivateSubnet-1a" PrivateSubnet1c: Type: AWS::EC2::Subnet Properties: VpcId: !Ref VPC CidrBlock: 10.0.3.0/24 AvailabilityZone: ap-northeast-1c MapPublicIpOnLaunch: false Tags: - Key: Name Value: !Sub "${ResourceName}-PrivateSubnet-1c" # ------------------------------------------------------------# # InternetGateway # ------------------------------------------------------------# InternetGateway: Type: "AWS::EC2::InternetGateway" Properties: Tags: - Key: Name Value: !Sub "${ResourceName}-igw" InternetGatewayAttachment: Type: "AWS::EC2::VPCGatewayAttachment" Properties: InternetGatewayId: !Ref InternetGateway VpcId: !Ref VPC # ------------------------------------------------------------# # NATGateway # ------------------------------------------------------------# EIP: Type: "AWS::EC2::EIP" Properties: Domain: vpc NATGateway: Type: "AWS::EC2::NatGateway" Properties: AllocationId: !GetAtt EIP.AllocationId SubnetId: !Ref PublicSubnet1a Tags: - Key: Name Value: !Sub "${ResourceName}-natgw" # ------------------------------------------------------------# # RouteTable # ------------------------------------------------------------# PublicRouteTable: Type: AWS::EC2::RouteTable Properties: VpcId: !Ref VPC Tags: - Key: Name Value: !Sub "${ResourceName}-PublicRouteTable" PublicRoute: Type: "AWS::EC2::Route" Properties: RouteTableId: !Ref PublicRouteTable DestinationCidrBlock: "0.0.0.0/0" GatewayId: !Ref InternetGateway PublicSubnet1aAssociation: Type: AWS::EC2::SubnetRouteTableAssociation Properties: SubnetId: !Ref PublicSubnet1a RouteTableId: !Ref PublicRouteTable PublicSubnet1cAssociation: Type: AWS::EC2::SubnetRouteTableAssociation Properties: SubnetId: !Ref PublicSubnet1c RouteTableId: !Ref PublicRouteTable PrivateRouteTable: Type: AWS::EC2::RouteTable Properties: VpcId: !Ref VPC Tags: - Key: Name Value: !Sub "${ResourceName}-PrivateRouteTable" PrivateRoute: Type: "AWS::EC2::Route" Properties: RouteTableId: !Ref PrivateRouteTable DestinationCidrBlock: "0.0.0.0/0" NatGatewayId: !Ref NATGateway PrivateSubnet1aAssociation: Type: AWS::EC2::SubnetRouteTableAssociation Properties: SubnetId: !Ref PrivateSubnet1a RouteTableId: !Ref PrivateRouteTable PrivateSubnet1cAssociation: Type: AWS::EC2::SubnetRouteTableAssociation Properties: SubnetId: !Ref PrivateSubnet1c RouteTableId: !Ref PrivateRouteTable # ------------------------------------------------------------# # Security Group # ------------------------------------------------------------# LambdaSecurityGrouptoFull: Type: AWS::EC2::SecurityGroup Properties: GroupName: !Sub "${ResourceName}-outbound-full-sg" GroupDescription: Security Group for Lambda to full VpcId: !Ref VPC SecurityGroupEgress: - IpProtocol: -1 CidrIp: 0.0.0.0/0 # ------------------------------------------------------------# # Lambda # ------------------------------------------------------------# LambdaFunction: Type: 'AWS::Lambda::Function' Properties: Handler: index.lambda_handler Role: !GetAtt LambdaExecutionRole.Arn FunctionName: !Sub "${ResourceName}-get-api" Runtime: python3.12 Timeout: 3 MemorySize: 128 Code: ZipFile: | import boto3 import json from datetime import date, datetime client_api = boto3.client('apigateway') def json_serial(obj): # 日付型の場合には、文字列に変換します if isinstance(obj, (datetime, date)): return obj.isoformat() # 上記以外はサポート対象外 raise TypeError("Type %s not serializable" % type(obj)) def lambda_handler(event, context): response = client_api.get_rest_apis() response_serial = json.dumps(response, default=json_serial) print(response_serial) return response_serial VpcConfig: SecurityGroupIds: - !Ref LambdaSecurityGrouptoFull SubnetIds: - !Ref PrivateSubnet1a - !Ref PrivateSubnet1c FunctionLogGroup: Type: AWS::Logs::LogGroup Properties: LogGroupName: !Sub "/aws/lambda/${LambdaFunction}" # ------------------------------------------------------------# # IAM Role # ------------------------------------------------------------# LambdaExecutionRole: Type: AWS::IAM::Role Properties: RoleName: !Sub "${ResourceName}-IRL-LAMBDA" AssumeRolePolicyDocument: Version: '2012-10-17' Statement: - Effect: 'Allow' Principal: Service: 'lambda.amazonaws.com' Action: 'sts:AssumeRole' ManagedPolicyArns: - arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole - arn:aws:iam::aws:policy/service-role/AWSLambdaVPCAccessExecutionRole - !GetAtt LambdaPolicy.PolicyArn LambdaPolicy: Type: AWS::IAM::ManagedPolicy Properties: ManagedPolicyName: !Sub ${ResourceName}-lambda-policy Description: IAM Managed Policy with APIGateway GET Access PolicyDocument: Version: '2012-10-17' Statement: - Effect: 'Allow' Action: - 'apigateway:GET' Resource: - '*'  API情報取得の確認 Lambdaにて、テストイベントを発行します。 以下のように、ロググループ内にてAPI情報が取得できていれば成功です。 最後に いかがだったでしょうか。 各種AWSサービスがどのような形でサービスエンドポイントを提供しているか解説しました。API GatewayのVPCエンドポイントの利用用途としては、プライベート型API Gatewayの呼び出しに使用できることをご留意ください。 閉域網環境でAWSを利用する際は、各種AWSサービスがVPCエンドポイントをサポートしているか確認していただければ幸いです。 本記事が皆様のお役にたてば幸いです。 ではサウナラ~🔥
こんにちは。SCSK株式会社の上田です。 今年の1月から、OSSの統合監視ツールである「 Zabbix 」の構築部署に配属になりました。 今回は、無料でありながらも豊富な機能を有し、導入が手軽なZabbixのインストール手順をご紹介します。 はじめに Zabbixは、ネットワークやサーバー、アプリケーションをリアルタイムで監視するためのオープンソースソフトウェアです。無料でありながらマルチプラットフォームに対応しており、死活監視からリソース監視まで様々な監視が行えます。 Zabbixの詳細情報については、下記リンクよりご確認ください。 Zabbix :: The Enterprise-Class Open Source Network Monitoring Solution www.zabbix.com 今回は、社内に仮想サーバー(RHEL8.3)を立てて、その中にZabbix(Ver.6.0)をインストールしてみました。 導入手順 環境設定 導入前の準備として、firewallの設定を行います。firewallは、不要な通信をブロックするためのセキュリティ機能です。Zabbix導入環境においては、WEBコンソールへの接続やエージェントとの通信に必要なポートを開放します。 # httpとhttpsを許可 firewall-cmd --add-service={http,https} --permanent # Zabbixの通信に必要なポートを開放 firewall-cmd --add-port={10051/tcp,10050/tcp} --permanent # firewallの再起動 firewall-cmd --reload 関連パッケージインストール ZabbixのWebインターフェースを構築するためにhttpdとphpを、DBを構築するためにMySQLをインストールします。 # パッケージのインストール dnf -y install httpd php mysql # サービスの起動 systemctl start httpd php mysqld # 自動起動の有効化 systemctl enable httpd php mysqld MySQLセットアップ Zabbixの情報を格納するDBを作成します。 mysql -uroot -p create database zabbix character set utf8 collate utf8_bin; create user zabbix@localhost identified with mysql_native_password by '任意のパスワード'; grant all privileges on zabbix.* to zabbix@localhost; set global log_bin_trust_function_creators = 1; quit; Zabbixのインストール いよいよZabbixのインストールに入っていきます。Zabbixをインストールする前に、専用のリポジトリを追加してください。 # 専用リポジトリのインストール dnf -y install https://repo.zabbix.com/zabbix/6.0/rhel/8/x86_64/zabbix-release-6.0-1.el8.noarch.rpm # キャッシュのクリア dnf clean all # Zabbixサーバーのインストール dnf -y install zabbix-server-mysql zabbix-web-mysql zabbix-apache-conf zabbix-sql-scripts zabbix-selinux-policy インストール後は、先ほど作成したZabbix用DBに設定を流し込み、コンフィグファイルにDBのパスワードを設定してサービスを起動します。 # DBに設定を流し込む zcat /usr/share/zabbix-sql-scripts/mysql/server.sql.gz | mysql -uzabbix -p # DBパスワードの設定 /etc/zabbix/zabbix_server.conf DBPassword=先ほど設定したパスワード # サービスの起動 systemctl start zabbix-server # 自動起動の有効化 systemctl enable zabbix-server Zabbix WEBコンソールへのアクセス ここまでの手順でインストールが完了しましたので、WEBからアクセスしてみましょう。 ブラウザを立ち上げて、以下にアクセスします http://XX.XX.XX.XX/zabbix XXには、今回構築したIPアドレスを入れてください。例えば、もしZabbixサーバーのIPアドレスが192.168.0.1なら、アドレスバーには”http://192.168.0.1/zabbix”と入力します。 以下のような画面が表示されると思います。 言語を【日本語(ja_JP)】に変更して、【次のステップ】をクリックします。 すべての項目が「OK」になっていることを確認し、【次のステップ】をクリックします。 パスワード欄に先ほど設定したZabbixDBのパスワードを入力し、【次のステップ】をクリックします。 タイムゾーン欄で【(UTC+9:00) Asia/Tokyo】を選択し、【次のステップ】をクリックします。 設定内容に問題がなければ、【次のステップ】をクリックします。 【終了】をクリックします。すると、以下のようなログイン画面が表示されます。 初期状態でユーザーが登録されているので、以下のユーザー名・パスワードでログインします。 ユーザ名:Admin パスワード:zabbix ログインすると、WEBコンソール画面が表示されます! このWEBコンソールから監視対象や監視項目を設定し、監視を行うことができます。   まとめ 今回は、Zabbixのインストール手順をご紹介しました。ITインフラの健全な運用管理には欠かせない監視ツールであるZabbixは、その多機能性と柔軟性で多くの企業様から高い評価を受けています。弊社はZabbixのプレミアムパートナーとして、導入から運用まで幅広いサポートを行っています。本ブログで紹介したインストールはもちろん、要件定義・パラメータ設計・運用サポートなど、様々なサービスを取り揃えております。 Zabbixの導入をご検討の方、または既にご導入いただいていてさらなる運用効率化をお求めの方は、ぜひSCSK株式会社までお気軽にお問い合わせください! ★SCSK Plus サポート for Zabbix★ SCSK Plus サポート for Zabbix 世界で最も人気のあるオープンソース統合監視ツール「Zabbix」の導入構築から運用保守までSCSKが強力にサポートします www.scsk.jp ★YouTubeに、SCSK Zabbixチャンネルを開設しました!★ SCSK Zabbixチャンネル 本チャンネルでは、SCSK株式会社でのZabbixに関するトレンド/事例紹介などを動画にまとめて取り上げております。 最新のトピックについては、以下の弊社HPもしくはツイッターアカウントをぜひ参照ください。 ツイッターアカウント: www.youtube.com ★X(旧Twitter)に、SCSK Zabbixアカウントを開設しました!★ 【公式】SCSK Zabbix (@SCSK_Zabbix) / Twitter SCSKが提供するZabbixサービスのオフィシャルアカウントです。 #Zabbix #SCSKPlusサポートforZabbix #監視 #SCSK twitter.com
こんにちは。SCSKの堀口です。 本記事では、バックアップシステムを導入する上で考慮すべきポイントを記載しています。 バックアップに関する技術記事は多く見かけますが、 実際にバックアップシステムを導入する際にどのような観点で考えればいいか迷った経験はないでしょうか。 筆者は、オンプレミスのバックアップから自社クラウドのバックアップサービス開発など 多くのバックアップシステム導入に携わってきました。 その経験・ノウハウの中で得たバックアップ導入の勘所をお伝えします。 記事内での用語 バックアップに関連する用語について文脈・読者によって解釈が変わる場合があります。 本記事内での用語の意味は以下の通りです。 用語 意味 バックアップ 特に断らない限り、サーバ全体のバックアップを意味します。 本記事ではシステムバックアップとデータバックアップを区別しません。 リストア 特に断らない限り、バックアップデータからサーバを復旧させること全般を意味します。 DRシステム DRは、Disaster Recovery(ディザスタリカバリ)の略称。直訳で「災害復旧」です。 DRシステムは、DR対策用のシステムを意味します。 メインサイト DRシステムにおいて、通常時にシステムが稼働する環境を意味します。 DRサイト DRシステムにおいて、災害時にシステムが稼働する環境を意味します。 それぞれ特定の意味で用いる場合、説明を入れますのでご留意ください。 バックアップシステム導入の全体像 一般的なシステム開発と同様ですが、以下のようなステップでバックアップシステムの導入を検討するのが望ましいです。 ※ 概要および一例なので、各ステップは細分化されたり一部前後・反復して実施される場合があります。 No. ステップ 内容 1 アセスメント システム全体およびバックアップ対象の情報を調査・整理、評価する。 CPU/メモリ/ディスク/ネットワーク構成などのスペックや稼働するアプリケーション、サーバの役割などの情報を明確にする。 2 要件定義 バックアップシステムに求められる要件を決定する。 バックアップシステム導入の 「目的」 と 「目標」 を明確にする。 3 製品選定 要件を満たすバックアップ製品を調査・選定する。 4 基本設計 バックアップシステムの構成、利用機能などを決定する。 各システム、サーバーに対して保存世代数やスケジュールなどのバックアップ設定を決定する。 運用設計もここに含む 5 詳細設計 基本設計の内容をもとにバックアップシステムのパラメーターシートを作成する バックアップジョブの設定値を決める 6 構築 パラメーターシートをもとにバックアップシステムを構築する バックアップジョブを作成する 7 テスト バックアップシステムおよびバックアップジョブに問題ないかテストする 以下、アセスメント、要件定義を中心に各工程を考えるヒントになることを書いていきます。 アセスメントのポイント アセスメントのポイントは、バックアップ対象のスコープ(範囲)と各対象の情報を洗い出し、整理することです。 まずは、システム全体の中でバックアップシステムの対象となる範囲を明確にします。 環境情報(ベアメタル環境、 仮想環境、クラウド環境 )やロケーション、設定ファイルなども対象になるかを洗い出してください。 次にスコープ内のバックアップ対象については以下の情報を最低限収集してください。 バージョン情報:ハイパーバイザーのバージョン、OS種別 スペック情報:CPU、メモリ ディスク情報:ディスク構成、ディスクサイズ、ディスク種別 NW情報:NIC構成、IPアドレス システムの役割とシステム間の依存関係 既存のバックアップシステムがある場合、既存のバックアップシステムの構成や取得方法、バックアップジョブの情報も取得してください。 また、既知の問題や課題が発生している場合は洗い出し、原因や解決策を明確にするのが望ましいです。 これらの情報は、要件定義や製品選定時の適合性、バックアップシステム全体の設計、バックアップジョブの設計などに利用します。 要件定義のポイント アセスメントによりバックアップ対象の全体像を把握した後は、バックアップ要件を決定していきます。 その上で重要となるのが、バックアップの 目的 を明確にし、 目標 を定めることです。 目的は、どのようなインシデントを最も脅威と考えて対策するかを意味します。 目標は、その目的を実現するためにどのような状態を目指すかを意味します。 「広域災害対策」 を目的とした場合には、 普段システムが稼働する地域とは別に、遠隔地に災害時用の環境を準備する、いわゆるDRシステムの検討が必要です。 「ランサムウェア対策」 を目的とした場合には、 保存したバックアップデータ自体をランサムウェアに書き換えられないようにする仕組みの検討が必要です。 なお、このようにバックアップデータを書換不可にする仕組みを「イミュータブルバックアップ」と呼びます。 ※ ランサムウェアとは マルウェアの一種で、感染したサーバーやデータを暗号化し、復号するために身代金を要求する攻撃です。 バックアップデータ自体を暗号化する攻撃も登場しており、より復旧が困難になる場合があります。 マルウェアについてより詳しく知りたい方は以下のコラムをご参照ください ランサムウェアに気をつけろ!基礎知識と安全対策のポイント このように、目的に応じて必要となる機能や構成が変わってくることがわかります。 複数の事象に対応しようとすると、様々な機能を利用し、構成が複雑になりがちで、コストが肥大化したり、運用負担が大きくなってしまう場合があります。 要件定義をする際にあれこれと要件を詰め込みそうになったり、記載内容に迷ったら、目的・目標を見返しましょう。 全てのシステムに対して同じレベルで対策するのではなく、 重要度やシステムの特性に応じてバックアップシステムを設計・導入することがカギになります。 では、どのように整理していくのか、重要な3つの指標を説明します。 RTO、RPO、RLOについて 一般的にバックアップやDRからの復旧時に利用される指標に以下の3つがあります。 指標 説明 RTO  (Recovery Time Objective) 「 目標復旧時間 」と呼びます。 何時間(秒、分、時間、日)を目標にシステムを復旧させるのかの指標です。 RPO  (Recovery Point Objective) 「 目標復旧時点 」と呼びます。 何時間前(秒、分、時間、日)のデータ/状態に復旧させるかの指標です。 RLO  (Recovery Level Objective) 「 目標復旧レベル 」と呼びます。 平常時の稼働状態を100%としたとき、どのレベルでシステムを復旧させるかの指標です。 RTOについて RTOは対象のシステムを復旧させるまでの時間の指標です。指標の幅は数分、数時間、数日と様々です。 RTOを短く設定し、実現できるほど、より迅速にシステムやビジネスを復旧させることを意味します。 復旧時間は、復旧対象の規模やパフォーマンス、復旧方法に依存します。 以下、代表的な復旧方法の違いによるRTOの違いについて整理しました。 なお、RTOは復旧対象のサイズ、バックアップ環境や本番環境の構成・パフォーマンスにも影響されるため、参考程度に考えてください。 バックアップデータのマウント方式 項目 説明 RTO 数秒~数分 特徴 バックアップデータを直接サーバーとして復旧させる方式です。 短いRTOを実現することができます。 バックアップ環境で動作するため本番環境とパフォーマンスが異なる可能性があります。 バックアップデータのリストア方式(保存先と復旧先が同一リージョン) 項目 説明 RTO 数分~数時間 特徴 バックアップデータを本番環境に書き戻して復旧させる方式です。 バックアップデータの保存先と復旧先である本番環境が同一のリージョン(地域)の場合です。 バックアップデータのリストア方式(保存先と復旧先が異なるリージョン) 項目 説明 RTO 数時間~数日 特徴 バックアップデータを本番環境に書き戻して復旧させる方式です。 バックアップデータの保存先と復旧先である本番環境が異なるリージョン(地域)の場合です。 なお、RTOは以下のバックアップの仕組みにも左右されます。ご留意ください。 バックアップ取得時の方式:フル、増分、差分、永久増分バックアップ バックアップメディア・保存先:ストレージ、バックアップテープ、クラウドストレージ RPOについて RPOは対象のシステムをどの時間に復旧させるかの指標です。指標の幅は数分、数時間、数日と様々です。 RPOは必ずしも短ければいいというものではないため注意が必要です。 例えば、RPOを1時間と定義し、以下の設定でバックアップジョブを作成・実行したとします。 実行周期:1時間ごとに実行 保存世代数:24世代 この場合、もしウイルスに感染して気づくまでに2日かかってしまうと、 バックアップデータもすべてウイルスに感染した状態のデータになってしまいます。 これを回避するためには、世代数を増やすか、バックアップの周期を長くする必要があります。 (もちろん、早期にウイルス感染を検知することも有用です) RPOを達成するためには、基本的にバックアップジョブの実行周期を調整します。 RPOを1日とする場合は、毎日バックアップジョブを実行するようにします。 もしくは、より短い実行周期で世代数を多く保持する方法でも達成可能です。 このとき注意するポイントは、バックアップジョブが設定した周期で終わるように設計することです。 バックアップ対象のサイズや前回のバックアップ実行から差分が大きい場合、次回のバックアップ実行までに完了しない場合があります。 また、より短いRPOを達成する必要がある場合は「レプリケーション」方式のソフトウェアも検討されます。 レプリケーションは、常にレプリケーション対象(バックアップ対象)のデータをレプリケーション先の環境に転送する方式です。 これにより、数秒のRPOを実現することが可能になっています。 レプリケーション利用時は、データの変更量がレプリケーションの処理速度を超える場合、データが滞留してしまうため注意が必要です。 RLOについて RLOはどのレベルでシステムを復旧させるかの指標です。 レベルを決める観点は「システムの優先度」、「スペック」、「可用性」などがあげられます。 例えば、災害発生により全システムが停止し、DRサイトでシステム復旧できる状態になったとします。 このとき、すべてのシステムを通常時と同じように復旧させようとするとリストアや動作確認に時間がかかり、結果的にRTOが満たせなくなる可能性があります。 そのため、あらかじめ復旧させるシステムに優先度を決め、優先度の高いシステムから復旧する準備が有用です。 また、DRサイトにメインサイト同様のリソースを準備できないこともあるため、 災害時には、スペックを落とした縮退運転や、冗長構成のものを単体で動作させることも検討が必要です。 実際の設計時には、復旧対象のグルーピングや復旧作業のフェーズ分けの明文化をお勧めします。 まとめ 要件定義する際には以下を明確にすることを説明させていただきました。 アセスメントでバックアップ対象の情報を洗い出すこと バックアップの目的と目標を明確にすること RTO、RPO、RLOを定義すること これらの情報を製品選定時に条件を満たしているか、設計フェーズでは抜け漏れがないか判断材料に活用してみてください。 USiZEシェアードモデルの紹介 当社のプライベートクラウド「USiZEシェアードモデル」では複数のバックアップサービスを提供しています。 要件に合わせてバックアップおよびDRシステムを複雑な設計不要で導入できます。 USiZEシェアードモデルの概要については以下のページも参照してください。 運用付きの国産クラウドサービス USiZEシェアードモデル SCSKのプライベートクラウド「USiZEシェアードモデル」とは?
本記事の内容は、Cato Networks社の以下の記事を元に日本語へ意訳し、再構成したものとなります。 Use Cases(ユースケース) Cato SASE Use Cases www.catonetworks.com Catoクラウドは、お客様がデジタルビジネス向けにネットワークとセキュリティのインフラを徐々に変革(Transformation)することを可能にします。以下にご紹介するユースケース(活用事例)については、1つまたは複数を、お客様のペースで取り組むことが可能です。 そして、どこから始めても、Catoクラウドはあなたの旅(Journey)の全体をサポートします。   ネットワークの変革(Network Transformation) MPLS(キャリア網)からSD-WANへの移行 Catoクラウドは、高価で柔軟性がなくキャパシティなどに制約のあるMPLSから、大容量で弾力性のある最新のネットワークへの移行を可能にします。Cato Edge SD-WANと複数のインターネットリンクを使用することで、お客様はMbpsあたりのコストを抑えながらキャパシティを増強し、回復力を向上させることができます。グローバルに拠点を展開しているお客様は、Catoクラウドの手頃な価格のグローバルプライベートバックボーンを活用して、グローバルなMPLSサービスを置き換え、コストを削減し、サービスレベルを満たし、パフォーマンスを向上させ、あらゆる場所にセキュリティを提供します。最終的に、ほとんどのお客様は同じネットワーク費用で、キャパシティと回復力を高め、全体的なネットワーク・パフォーマンスとセキュリティを向上させることができます。 最適なグローバル・アプリケーション・アクセス Catoクラウドでは、トラフィックの高速化と最適化が組み込まれたグローバルなプライベートバックボーンを活用し、SLAに裏付けされた予測可能で高性能なアプリケーションアクセスをあらゆる場所で提供します。Catoクラウドは、さらにSaaSアプリケーションへのアクセスを最適化する「スマート・エグレス(Smart Egress)」機能により、特定のアプリケーション・トラフィックを、組織にサービスを提供するロケーションに最も近い指定PoPを出口とするアプリケーション・レベルのルールを定義できます。全体として、遠隔地やユーザーのアプリケーション・アクセスの悪さに悩まされているお客様は、Catoクラウドのグローバル・アクセス最適化を利用することで、オンプレミスとクラウドの両方のアプリケーションのアクセス・エクスペリエンスを向上させることができます。 ハイブリッドクラウドとマルチクラウド Catoクラウドは、物理データセンターとパブリッククラウドのデータセンターをCatoクラウドのプラットフォームに簡単に接続し、パブリッククラウドアプリへのアクセスを最適化します。トラフィックはCatoクラウドによってセキュリティ検査され、「ミドルマイル」を横断するCatoのグローバル・プライベート・バックボーンを使用して最適化されます。Catoを利用することで、AWS DirectConnectや、Microsoft ExpressRouteのような高価なクラウド接続ソリューションを排除することができます。   セキュリティの変革(Security Transformation) セキュアなハイブリッドワーク Catoクラウドは、グローバルネットワーキングとセキュリティ機能を、1人のユーザーのPC、スマートフォン、タブレットにまで拡張し、ユーザーを識別します。CatoクライアントのZTNA機能を使用することで、ユーザーはCatoクラウドのプラットフォームを通じて、オンプレミスまたはクラウド上のあらゆるアプリケーションへのセキュアで最適化された接続を確立できます。 Catoクラウドは、リスクベースのアプリケーションアクセスポリシーを継続的に実施し、すべてのトラフィックを脅威から保護し、機密データの損失を防ぎます。Catoクライアントには、次世代マルウェア対策エンジンを使用したエンドポイント保護機能が含まれており、マルウェア感染を防止し、インシデントの検出と対応のためにエンドポイントの異常な挙動データを共有します。Catoクラウドのスケールアーキテクチャは、どこからでも働くすべてのユーザーを確実にサポートします。 セキュアなダイレクト・インターネット・アクセス Catoクラウドは、Catoクラウドプラットフォームに統合されたクラウドネイティブなセキュリティサービスエッジ、「Cato SSE 360」を提供します。CatoのエッジSD-WANデバイスとCatoクライアントを通じてすべての拠点とユーザーをCatoに接続することで、すべてのWAN、クラウド、インターネットのトラフィックは、脅威や機密データの損失から完全に保護されます。Catoクラウドを使用することで、お客様は拠点のファイアウォールとSD-WANアプライアンス、インターネットアクセス用のポイントクラウド配信ソリューションの混合環境のコストと複雑さを排除または回避することができます。 セキュアなアプリケーションとデータアクセス CatoクラウドのCASBとDLP機能は、クラウドアプリケーションと機密データへのアクセスの完全な可視化と制御を可能にします。Catoは、「シャドーIT」を含むすべてのクラウドアプリケーションアクセスをリスクベースで即座に可視化し、企業やBYODデバイスからの機密データアクセスに対してインラインできめ細かなポリシーを適用します。Catoは、SaaSアプリケーションAPIを活用して、ポリシーをBYODデバイスやアプリケーション間のデータ共有に拡張します。Catoクラウドを使用することで、お客様は機密データ損失のリスクを低減し、規制要件へのコンプライアンスを向上させることができます。 インシデントの検出とレスポンス(Detection and Response) Catoクラウドは、ネットワーク(NDR)とエンドポイント(EDR)のドメインにわたって、Cato クラウドのPlatformに組み込まれた完全な拡張検知と応答(XDR)機能を提供します。Catoクラウドのライブトラフィックとサードパーティデータから作成されたきめ細かくコンテキスト豊富なデータレイク、実績のあるAI/ML駆動型脅威ハンティング、AI支援型アナリストワークベンチ、インシデント対応プレイブックを組み合わせています。CatoのXDRは、当社のMDR(Managed Detection and Response)アナリストによって広範にテストされ、パートナーや顧客が社内でSOC機能を構築するために使用できるようになりました。   ビジネスの変革(Business Transformation) ベンダーの統合 Catoクラウドは、複数のネットワークおよびセキュリティ製品を、単一のクラウドプラットフォームに統合することを可能にします。お客様は、複数の製品の統合、保守、トラブルシューティング、複数の契約更新や請求サイクルを行う必要がなくなります。Catoを利用することで、IT部門・情報システム部門は一貫性のある自律的なITインフラ機能の提供を活用し、ビジネスのサポートとユーザー・エクスペリエンスの最適化に集中することができます。 コストの最適化 Catoクラウドは、MPLS、ファイアウォール・アプライアンス、VPNソリューション、クラウドベースのセキュリティ・サービスなど、複数のネットワーキングおよびセキュリティ・ポイント・ソリューションのキャッシュ・ニュートラル(=予算の見極めが難しい状況)からポジティブへの置き換えを可能にします。同様の支出で、これらのポイント・ソリューションを単一のプラットフォームに置き換え、サービスの回復力、拡張性、セキュリティ体制を完全に自動化し、ユーザー・エクスペリエンスを最適化して、IT部門・情報システム部門が戦略的なビジネス・イニシアチブに集中できるようにします。 M&Aと地域拡大 Catoクラウドは、M&Aや新規地域へのシームレスな事業拡大を可能にします。Catoクラウドのファーストアーキテクチャは、一貫したセキュリティポリシーとグローバルなトラフィック最適化を、あらゆる場所、あらゆるユーザー、企業リソースから実現します。Catoクラウドのゼロタッチおよびセルフサービスプロビジョニングによる「シン・エッジ(Thin Edge)」(Cato SD-WANまたはCato Client)を使用することで、お客様は新しい拠点やユーザーを迅速にCatoに導入し、オンプレミスまたはクラウド上のあらゆるアプリケーションへのセキュアで最適化されたアクセスを提供することができます。   展開モデル(Deployment Models) ローカル企業(Regional Enterprises) Catoクラウドは、単一のクラウドサービスを通じて、企業ネットワーク全体を接続し、保護します。CatoクラウドのSASEプラットフォームにより、ITチームはセキュアなネットワークを簡単に構築できます。Catoは、クラウド上で自動的にWANフルメッシュを構築し、アプリケーションとユーザーの認識に基づいてQoSとパス選択を実施し、クラウドリソースへのアクセスを最適化し、リモートユーザーをネットワークの重要な一部にし、すべての場所、ユーザー、アプリケーションに同じエンタープライズグレードのセキュリティを適用することで、インターネットのラストワンマイルを最大限に活用できるようにします。Catoは、ITチームまたはマネージド・サービス・プロバイダーが、ユーザーフレンドリーな単一の管理アプリケーションを介して管理することができます。 グローバル企業(Global Enterprises) Catoクラウドは、手頃な価格で信頼性が高く、俊敏なグローバル接続を実現します。SLAに裏付けされたグローバルなプライベートバックボーンは、レガシーMPLSの数分の一のコストで一貫したユーザーエクスペリエンスを提供し、パブリッククラウドのデータセンター、クラウドアプリケーション、リモートユーザーにネイティブに拡張します。中国を含む80を超えるグローバルな接続拠点により、お客様のビジネスニーズを満たすセキュアで最適なグローバル接続を数分で実現できます。Catoのセキュリティ・スタックは、すべての拠点、ユーザー、アプリケーションに対して、どこでも同じエンタープライズ・グレードのセキュリティが適用されることを保証します。 自分でできる(DIY) Catoクラウドは、Cato管理アプリケーションを通じて、企業のIT部門が詳細なリアルタイムおよび過去に遡って、ネットワーク分析とセキュリティ・イベントにアクセスできるようにします。セキュリティ、ルーティング、サービス品質など、すべてのポリシーはお客様が直接設定できます。クラウドサービスであるCatoクラウドは、基盤となるインフラストラクチャの更新やアップグレードにお客様が関与する必要がないため、これまでネットワーク・ポイント・ソリューションの保守に必要だったITチームの貴重なリソースを節約できます。 マネージドサービス ハンズオフ(Hands Off:手離し)のマネージドサービスをご希望のお客様は、Catoクラウドのパートナーをご利用いただくか、特定のCato Networks社が提供するマネージドサービスにご利用ください。お客様は、サイトの展開、ラスト・マイル・リンクの監視、Cato管理アプリケーション内での必要なポリシー設定の実行、または広範なセキュリティ脅威に対するネットワークの監視などの支援が必要かどうかを選択することができます。クラウド・サービスとして、Catoクラウドのプラットフォームとそのすべてのコンポーネントを保守するため、ITチームやMSPは、これまで複数のポイント・ソリューションの保守に必要だった貴重なリソースを節約することができます。   真のSASEプラットフォームがもたらす戦略的メリット Catoクラウドは、真のクラウドネイティブSASEプラットフォームとしてゼロから構築されています。Catoクラウドのセキュリティ機能は、現在および将来にわたって、Catoプラットフォームのグローバルな分散、大規模なスケーラビリティ、高度な回復力、自律的なライフサイクル管理、一貫した管理モデルを活用しています。 一貫したポリシー実施 Catoクラウドは、すべてのセキュリティ機能をグローバルに拡張し、最大規模のデータセンターから単一のユーザーデバイスに至るまで、あらゆる場所であらゆる人に一貫したポリシーの適用を実現します。 拡張性と回復力のある保護 Catoクラウドは、完全なTLS復号化とすべてのセキュリティ機能を備えた数ギガのトラフィック・ストリームを検査できるように拡張し、サービス・コンポーネントの障害から自動的に回復して、継続的なセキュリティ保護を保証します。 自律的なライフサイクル管理 Catoクラウドは、SASEクラウドプラットフォームが最適なセキュリティ態勢、99.999%のサービス可用性、低レイテンシのセキュリティ処理を維持することを保証します。 一枚のガラス(SPOG:Single Pane of Glass) Catoクラウドは、設定、分析、トラブルシューティング、インシデントの検出と対応など、すべてのセキュリティとネットワーク機能を一貫して管理するための一枚のガラス(SPOG)を提供します。統一された管理モデルにより、IT部門とビジネス部門による新機能の導入が容易になります。   まとめ Catoクラウドのユースケース(活用事例)の記事をご紹介させていただきました。もし、Catoクラウドに興味がお持ちの方は、当社までお問い合わせください。 “SASE”自体の知名度も低く、”Cato Networks社”、”Catoクラウド(Cato Cloud/Cato SASE Cloud)”の知名度もはまだまだ低い状況です。SCSKでは、2021年からSASEの主要ソリューションを一同に紹介を行うオンラインセミナー「SCSK SASE Solution Summit(通称 S4 エスフォー)」を定期的に開催しております。これまで13回開催し、1,600名以上の方にご参加いただいております。 S4は、2024年2月15日に開催いたしますので、是非ご興味のある方はご参加ください。また、2024年3月14日にはCatoクラウドの主要機能を2時間でデモ形式でご覧いただけるセミナーを開催しますので、是非ご参加ください。 【好評につき追加開催決定!】SCSK SASE Solution Summit (S4)ー主要4製品の違いや強みを横並びでご紹介!ー 弊社グループにて取り扱っている4つのSASE製品の気になるポイントをギュッと凝縮しており、製品比較や選定行っていくための情報を一度に収集できるため、「SASEの関する情報収集中の方」だけでなく、「自社の課題解決に最適なSASEを知りたい方」、「他社の導入成功事例を聞きたい方」のご参加を心よりお待ちしております! www.scsk.jp Catoクラウドデモセミナー~Catoクラウドの主要機能を2時間で網羅~ 本セミナーでは、世界初のSASEである「Catoクラウド」の概要をたっぷり2時間、デモ形式でご覧いただきます。 また、ご希望の方(先着10名様)は、デモ環境に対して、お手元の環境からハンズオン形式でCatoクラウドに触れて頂くことが可能な参加型セミナーです。 www.scsk.jp SASEやCatoのセミナー以外に、Catoクラウドのお客様導入事例の制作、FAQサイト運営、この TechHarmony(技術ブログ)で、皆様のお役に立て、Catoクラウドの知名度アップに少しでも貢献できればと考えております。
こんにちは。SCSKのふくちーぬです。 少し前の話ですが、2023 Japan AWS All Certifications Engineersに選出していただきました。 AWS 12冠の証として、先日受賞景品もいただきました。 今回は、AWS認定試験を受験される方に向けて全資格に通ずる合格するための必勝法や感想をお話します。 弊社石原も受賞しており、以下の記事で細かく各試験の対策法を紹介しているのでぜひ参考にしてください。 AWS12冠をノーミスでクリアできた学習法と感想 2023年1月にAWS PASに合格してAWS12冠となりました。全ての試験に一発合格できましたので学習法を記事にします。 これからAWS認定試験を受験される方、今年度に追い込みをかける方、来年度に全冠を目指す方の参考になれば幸いです。 blog.usize-tech.com 2023.01.27   学習スタイル 全認定試験共通の勉強法をご紹介します。下記の学習手順を実施しました。 試験ガイドに目を通す、ウェビナーを視聴する(必須) AWSに限らずどの試験を受験する場合でも、試験で何が問われるのか・何が出題されないのかを知ることは重要です。試験要領をしっかり確認しておきましょう。 https://d1.awsstatic.com/ja_JP/training-and-certification/docs-sa-assoc/AWS-Certified-Solutions-Architect-Associate_Exam-Guide.pdf Skill BuilderというAWS公式が用意している学習サイトにて、各試験のポイントがまとまったものが無料のウェビナーとして提供されています。試験ガイドを読むのが面倒だという人は、動画で視聴して試験の概要を掴むのもありです。 無料トレーニングと認定イベント | ライブおよびオンデマンドのウェビナー | AWS 無料の AWS トレーニングと認定ライブウェビナー、仮想トレーニングイベント、オンデマンドウェビナーに登録します。これらのイベントは、幅広いロールとトピックについてさまざまなレベルの技術的な専門知識を取り扱うことを目的としており、AWS 認定の取得を目指す方向けの試験対策ウェビナーなどが含まれます。 aws.amazon.com サンプル問題を解く(必須) AWS認定試験では過去問というものが存在しないですが、AWS公式が作成した実際の問題に触れることが大切です。試験の難易度や言い回しもほとんど同じレベルです。 https://d1.awsstatic.com/ja_JP/training-and-certification/docs-sa-assoc/AWS-Certified-Solutions-Architect-Associate_Sample-Questions.pdf 書籍での学習 最近は資格試験に特化した書籍も多く販売されているので、お金に余裕のある人は購入してもよいかと思います。特に、AWS認定試験を始めて受ける方は1冊は手に取ることをお勧めします。試験の概要や各種AWSサービスの概要が分かりやすく解説されています。 ハンズオン(必須) AWS公式で提供されている初心者向けハンズオンに取り組むことを推奨します。AWS テクニカルソリューションアーキテクトの方が、初めてAWSを触る人に向けて丁寧に分かりやすく説明してくれます。AWSを利用するにあたり超重要サービスを扱っており、マネジメントコンソール上での操作がメインとなっています。AWSアカウントを所有していない方でも、動画を視聴していただくだけで操作感等も掴めるのでお勧めです。 ハンズオン資料 | AWS クラウドサービス活用資料集 aws.amazon.com 時間に余裕のある方は、Udemy等のオンライン講座を受講していただくのも良いかと思います。 デジタルトレーニングの視聴(必須) Skill Builderにて各試験のデジタルトレーニングが無料で提供されています(Exam Readinessシリーズ)。各種AWSサービスの概要だけではなく、設計ポイント等アーキテクチャ図を含めて解説してくれます。学習の中心となるので、必ず視聴しましょう。 Self-paced digital training on AWS - AWS Skill Builder Your learning center to build in-demand cloud skills. explore.skillbuilder.aws BlackBeltオンラインセミナーの視聴 Black Belt Online Seminarでは各種AWSサービスについて概要だけではなく、詳細まで紹介をしてくれます。各資格の試験ガイドに記載されたAWSサービスを視聴します。空き時間等で視聴するのが効率がよいです。 サービス別資料 | AWS クラウドサービス活用資料集 アマゾン ウェブ サービス (AWS) は安全なクラウドサービスプラットフォームで、ビジネスのスケールと成長をサポートする処理能力、データベースストレージ、およびその他多種多様な機能を提供します。それらを活用するために役立つ日本語資料、動画コンテンツを多数ご提供しております。 aws.amazon.com ナレッジセンターの利用(必須) ナレッジセンターは、各種AWSサービスのFAQとなっています。実務で困った際に、サポートへの問い合わせをする前に確認する方もいるかと思います。認定資格においても十分に活用することができます。 各資格の試験ガイドに記載されたAWSサービスについて、トラブルシューティングやどんな考慮点が必要なのか等を身に付けていきます。 情報センター Learn about some of the most frequent questions and requests that we receive from AWS Customers including best practices, guidance, and troubleshooting tips. repost.aws 例えばAWS Certified Advanced Networking – Specialty (ANS-C01)では、Direct Connectに関する以下のような問題が 出題されます 出題されるかもしれません。 ※1 「VIF(Virtual Interface)がDownしています。ネットワーク管理者のあなたは、どのような項目を確認すればよいですか?」 ナレッジセンターに目を通しているここのあなたなら答えられますよね。こんな感じに利用していきます。 仮想インターフェイスの BGP ステータスが「ダウン」状態 AWS Direct Connect 用の仮想インターフェイスの BGP ステータスが AWS コンソールでダウンしています。この問題をトラブルシューティングするにはどうすればよいですか? repost.aws ※1 AWS認定試験には「試験問題を公開しない」という規約がありますので、このような文言としています。 模擬試験を解く(必須) 認定試験対策の最後の仕上げを行います。AWS公式が作成した無料の20問の模擬試験をBenchPrepというサイト経由で解きます。 この模擬試験で8割以上の点数を取得できていれば、合格に限りなく近いので自信を持ってテストセンターに足を運んでください。 Self-paced digital training on AWS - AWS Skill Builder Your learning center to build in-demand cloud skills. explore.skillbuilder.aws   おすすめ受験順序 各試験を受験してきた感想として、下記の受験順序をお勧めします。ポイントは下記のとおりです。 DBS→DAS→MLSはデータを扱うという点で試験範囲が重複するので、近い日程で受験する PASはAWSというよりかはSAP(ERP)の色が強いので、一番最後に受験する SCSはどの認定資格にも出題される内容でありセキュリティは重要分野となるので、なるべく早く受験しておく ANSは対策時間を十分に取った上で受験する 「AWS案件にアサインされて監視系のサービスに触れている」や「オンプレミスにて仮想基盤のネットワーク設計をやってきた」等の経験に応じて、順番を柔軟に変更していただければと思います。 AWS12冠までの道 受験日と各試験のスコアは下記の通りです。受験スケジュールの参考にしてください。試験のスコアはあまり高くないため大きな口はきけませんが、ノーミスで費用を最小限に抑えられたのでよかったかなと思います。 個人的な難易度の列については、完全な主観になります。 試験コード 試験名 スコア 受験日 個人的な難易度(5段階評価) SAA-C02 AWS Certified Solutions Architect – Associate 794 2021-12-18 ★★ SAP-C01 AWS Certified Solutions Architect – Professional  812 2022-02-26 ★★★★★ DVA-C01 AWS Certified Developer – Associate 828 2022-08-28 ★★★ DBS-C01 AWS Certified Database – Specialty 849 2022-09-10 ★★★ SOA-C02 AWS Certified SysOps Administrator – Associate 785 2022-10-22 ★★★ SCS-C01 AWS Certified Security – Specialty 878 2022-11-03 ★★ DAS-C01 AWS Certified Data Analytics – Specialty 861 2022-11-12 ★★★ MLS-C01 AWS Certified Machine Learning – Specialty 842 2022-11-26 ★★★★ DOP-C01 AWS Certified DevOps Engineer – Professional 869 2022-12-04 ★★★★ CLF-C01 AWS Certified Cloud Practitioner 813 2022-12-18 ★ ANS-C01 AWS Certified Advanced Networking – Specialty 792 2023-01-27 ★★★★★ PAS-C01 AWS Certified: SAP on AWS – Specialty 895 2023-02-08 ★★★★   最後に いかがだったでしょうか。私としてはJapan AWS All Certifications Engineersになってからが、本当のスタートだなとつくづく感じています。 AWS認定試験は体系的にAWSを学ぶことができる良い機会でもあるので、ぜひ一歩を踏み出していただければと思います。 本記事が皆様のお役にたてば幸いです。 ではサウナラ~🔥
こんにちは。SCSKのふくちーぬです。 皆さんは、Network Load Balancer(NLB)に対してセキュリティグループをアタッチして利用していますでしょうか。 今回は、セキュリティグループがアタッチされていないNetwork Load Balancer(NLB)をIPアドレスを保持したまま、セキュリティグループがアタッチできるNetwork Load Balancer(NLB)へ移行する手法をご紹介します。 Network Load Balancer(NLB)がセキュリティグループをサポートした件 2023/8/11にNetwork Load Balancer(NLB)に対して、Application Load Balancer(ALB)と同様にセキュリティグループをアタッチできるようになりました。多くの方が待ち望んでいたアップデートだったのではないでしょうか。 セキュリティグループがアタッチできるようになるまでの以前の状況は、IPアドレス制御を行うためにはAWS Network FirewallやネットワークACLを利用する必要がありました。サブネットレベルまで考慮する必要があるため、大変面倒でした。 Network Load Balancer でセキュリティグループのサポートを開始 aws.amazon.com 注意事項としては、Network Load Balancer(NLB)にセキュリティグループをアタッチできるタイミングは作成時のみということです。一度セキュリティグループをアタッチできるタイプとしてNetwork Load Balancer(NLB)を作成さえすれば、セキュリティグループの付け替えは任意のタイミングで実施できます。 Network Load Balancer を作成するときに、セキュリティグループを Network Load Balancer に関連付けることができます。セキュリティグループを関連付けずに Network Load Balancer を作成した場合、後でセキュリティグループをロードバランサーに関連付けることはできません。ロードバランサーを作成するときに、セキュリティグループをロードバランサーに関連付けることをお勧めします。 Network Load Balancer のセキュリティグループ - Elastic Load Balancing セキュリティ グループを Network Load Balancer に関連付ける方法について説明します。 docs.aws.amazon.com   アーキテクチャ 内部向けNetwork Load Balancer(NLB)では、TCP:80をリスナーとして受付し、ターゲットグループとしてEC2を指定しています。 移行前のNetwork Load Balancer(NLB)には、セキュリティグループがアタッチされていないため、フルオープンのアクセスを許可しています。 移行後のNetwork Load Balancer(NLB)には、セキュリティグループをアタッチします。   移行シナリオとポイント 下記を実現するためには、旧Network Load Balancer(NLB)を削除後に新Network Load Balancer(NLB)を再作成する必要があります。AWSサポートに問い合わせた結果、現時点でプライベートIPアドレスを確保しておく技術やサービスはありません。 静的プライベートIPアドレスを維持すること Network Load Balancer(NLB)にセキュリティグループがアタッチできるタイプへ変更すること Network Load Balancer(NLB)のセキュリティグループのインバウンドルールには、指定されたIPアドレスからのみ通信を許可すること EC2のセキュリティグループのインバウンドルールには、Network Load Balancer(NLB)にアタッチされたセキュリティグループからの許可をすること Network Load Balancer(NLB)をIPアドレスを保持したまま移行するためには、以下のポイントを念頭に置いて実施することが重要です。 プライベートIPアドレスが他のサービス(EC2,VPC Lambda,RDS等)に奪われないように移行時間帯を設けて、関係者へAWSアカウントの利用時間帯を周知すること 旧Network Load Balancer(NLB)の削除、新Network Load Balancer(NLB)の再作成を短期間で実施すること このポイントを押さえておかないと、例えばNetwork Load Balancer(NLB)の移行タイミングと他のIAMユーザによるEC2作成等が重なってしまうことにより、プライベートIPアドレスを奪われてしまう可能性があります。   移行の検証 事前準備 VPC、サブネット、インターネットゲートウェイ、NATゲートウェイ、ネットワークACL、ルートテーブルが作成済みであることを確認してください。 初期構築(旧Network Load Balancerの作成) 以下のテンプレートを使用して、デプロイします。 AWSTemplateFormatVersion: 2010-09-09 Description: NLB Create Parameters: ResourceName: Type: String VpcId: Type: String PrivateSubnetA: Type: String PrivateSubnetC: Type: String PrivateIPAddressA: Type: String PrivateIPAddressC: Type: String Resources: # ------------------------------------------------------------# # Network Load Balancer # ------------------------------------------------------------# LoadBalancer: Type: AWS::ElasticLoadBalancingV2::LoadBalancer Properties: Name: !Sub ${ResourceName}-NLB SubnetMappings: - SubnetId: !Ref PrivateSubnetA PrivateIPv4Address: !Ref PrivateIPAddressA - SubnetId: !Ref PrivateSubnetC PrivateIPv4Address: !Ref PrivateIPAddressC Scheme: internal Type: network LoadBalancerListener: Type: AWS::ElasticLoadBalancingV2::Listener Properties: LoadBalancerArn: !Ref LoadBalancer Port: 80 Protocol: TCP DefaultActions: - Type: forward TargetGroupArn: !Ref TargetGroup TargetGroup: Type: AWS::ElasticLoadBalancingV2::TargetGroup Properties: Name: !Sub ${ResourceName}-targetgroup VpcId: !Ref VpcId Port: 80 Protocol: TCP TargetType: instance Targets: - Id: !Ref EC2 Port: 80 # ------------------------------------------------------------# # EC2 # ------------------------------------------------------------# EC2: Type: AWS::EC2::Instance Properties: ImageId: ami-0b193da66bc27147b InstanceType: t2.micro NetworkInterfaces: - AssociatePublicIpAddress: "true" DeviceIndex: "0" SubnetId: !Ref PrivateSubnetA GroupSet: - !Ref EC2SecurityGroup UserData: !Base64 | #!/bin/bash yum update -y yum install httpd -y systemctl start httpd systemctl enable httpd touch /var/www/html/index.html echo "Hello,World!" | tee -a /var/www/html/index.html Tags: - Key: Name Value: !Sub "${ResourceName}-ec2" EC2SecurityGroup: Type: "AWS::EC2::SecurityGroup" Properties: VpcId: !Ref VpcId SecurityGroupIngress: - IpProtocol: tcp FromPort: 80 ToPort: 80 CidrIp: !Sub "${PrivateIPAddressA}/32" - IpProtocol: tcp FromPort: 80 ToPort: 80 CidrIp: !Sub "${PrivateIPAddressC}/32" GroupName: !Sub "${ResourceName}-ec2-sg" GroupDescription: !Sub "${ResourceName}-ec2-sg" Tags: - Key: "Name" Value: !Sub "${ResourceName}-ec2-sg"  セキュリティグループがアタッチされていないNetwork Load Balancer(NLB)が作成されたことを確認します。 併せてプライベートIPアドレスの値も確認しておきます。 移行中(旧Network Load Balancerの削除) セキュリティグループがアタッチされていないNetwork Load Balancer(NLB)に対して、セキュリティグループをアタッチするためには、一度”AWS::ElasticLoadBalancingV2::LoadBalancer”及び”AWS::ElasticLoadBalancingV2::Listener”を削除する必要があります。 理由としては、AWSドキュメント記載の通り、”AWS::ElasticLoadBalancingV2::LoadBalancer”の”SecurityGroups”プロパティを変更しても置換が発生しないためとなります。 AWS::ElasticLoadBalancingV2::LoadBalancer - AWS CloudFormation Specifies an Application Load Balancer, a Network Load Balancer, or a Gateway Load Balancer. docs.aws.amazon.com “AWS::ElasticLoadBalancingV2::LoadBalancer”及び”AWS::ElasticLoadBalancingV2::Listener”に対してコメントアウトすることで、削除することができます。以下のテンプレートを使用して、スタックを更新します。 AWSTemplateFormatVersion: 2010-09-09 Description: NLB Delete Parameters: ResourceName: Type: String VpcId: Type: String PrivateSubnetA: Type: String PrivateSubnetC: Type: String PrivateIPAddressA: Type: String PrivateIPAddressC: Type: String Resources: # ------------------------------------------------------------# # Network Load Balancer # ------------------------------------------------------------# # LoadBalancer: # Type: AWS::ElasticLoadBalancingV2::LoadBalancer # Properties: # Name: !Sub ${ResourceName}-NLB # SubnetMappings: # - SubnetId: # !Ref PrivateSubnetA # PrivateIPv4Address: !Ref PrivateIPAddressA # - SubnetId: # !Ref PrivateSubnetC # PrivateIPv4Address: !Ref PrivateIPAddressC # Scheme: internal # Type: network # SecurityGroups: # - !Ref NLBSecurityGroup # LoadBalancerListener: # Type: AWS::ElasticLoadBalancingV2::Listener # Properties: # LoadBalancerArn: !Ref LoadBalancer # Port: 80 # Protocol: TCP # DefaultActions: # - Type: forward # TargetGroupArn: !Ref TargetGroup TargetGroup: Type: AWS::ElasticLoadBalancingV2::TargetGroup Properties: Name: !Sub ${ResourceName}-targetgroup VpcId: !Ref VpcId Port: 80 Protocol: TCP TargetType: instance Targets: - Id: !Ref EC2 Port: 80 # ------------------------------------------------------------# # EC2 # ------------------------------------------------------------# EC2: Type: AWS::EC2::Instance Properties: ImageId: ami-0b193da66bc27147b InstanceType: t2.micro NetworkInterfaces: - AssociatePublicIpAddress: "true" DeviceIndex: "0" SubnetId: !Ref PrivateSubnetA GroupSet: - !Ref EC2SecurityGroup UserData: !Base64 | #!/bin/bash yum update -y yum install httpd -y systemctl start httpd systemctl enable httpd touch /var/www/html/index.html echo "Hello,World!" | tee -a /var/www/html/index.html Tags: - Key: Name Value: !Sub "${ResourceName}-ec2" EC2SecurityGroup: Type: "AWS::EC2::SecurityGroup" Properties: VpcId: !Ref VpcId SecurityGroupIngress: - IpProtocol: tcp FromPort: 80 ToPort: 80 CidrIp: !Sub "${PrivateIPAddressA}/32" - IpProtocol: tcp FromPort: 80 ToPort: 80 CidrIp: !Sub "${PrivateIPAddressC}/32" GroupName: !Sub "${ResourceName}-ec2-sg" GroupDescription: !Sub "${ResourceName}-ec2-sg" Tags: - Key: "Name" Value: !Sub "${ResourceName}-ec2-sg" 変更セットにて”AWS::ElasticLoadBalancingV2::LoadBalancer”及び”AWS::ElasticLoadBalancingV2::Listener”が削除予定であることを確認後、”送信”を押下します。 Network Load Balancer(NLB)が削除されていることを確認します。 移行完了(新Network Load Balancerの作成) 以下のテンプレートを使用して、スタックを更新します。 AWSTemplateFormatVersion: 2010-09-09 Description: NLB Recreate Parameters: ResourceName: Type: String VpcId: Type: String VpcAddress: Type: String PrivateSubnetA: Type: String PrivateSubnetC: Type: String PrivateIPAddressA: Type: String PrivateIPAddressC: Type: String Resources: # ------------------------------------------------------------# # Network Load Balancer # ------------------------------------------------------------# LoadBalancer: Type: AWS::ElasticLoadBalancingV2::LoadBalancer Properties: Name: !Sub ${ResourceName}-NLB SubnetMappings: - SubnetId: !Ref PrivateSubnetA PrivateIPv4Address: !Ref PrivateIPAddressA - SubnetId: !Ref PrivateSubnetC PrivateIPv4Address: !Ref PrivateIPAddressC Scheme: internal Type: network SecurityGroups: - !Ref NLBSecurityGroup LoadBalancerListener: Type: AWS::ElasticLoadBalancingV2::Listener Properties: LoadBalancerArn: !Ref LoadBalancer Port: 80 Protocol: TCP DefaultActions: - Type: forward TargetGroupArn: !Ref TargetGroup TargetGroup: Type: AWS::ElasticLoadBalancingV2::TargetGroup Properties: Name: !Sub ${ResourceName}-targetgroup VpcId: !Ref VpcId Port: 80 Protocol: TCP TargetType: instance Targets: - Id: !Ref EC2 Port: 80 NLBSecurityGroup: Type: "AWS::EC2::SecurityGroup" Properties: VpcId: !Ref VpcId SecurityGroupIngress: - IpProtocol: tcp FromPort: 80 ToPort: 80 CidrIp: !Ref VpcAddress GroupName: !Sub "${ResourceName}-nlb-sg" GroupDescription: !Sub "${ResourceName}-nlb-sg" Tags: - Key: "Name" Value: !Sub "${ResourceName}-nlb-sg" # ------------------------------------------------------------# # EC2 # ------------------------------------------------------------# EC2: Type: AWS::EC2::Instance Properties: ImageId: ami-0b193da66bc27147b InstanceType: t2.micro NetworkInterfaces: - AssociatePublicIpAddress: "true" DeviceIndex: "0" SubnetId: !Ref PrivateSubnetA GroupSet: - !Ref EC2SecurityGroup UserData: !Base64 | #!/bin/bash yum update -y yum install httpd -y systemctl start httpd systemctl enable httpd touch /var/www/html/index.html echo "Hello,World!" | tee -a /var/www/html/index.html Tags: - Key: Name Value: !Sub "${ResourceName}-ec2" EC2SecurityGroup: Type: "AWS::EC2::SecurityGroup" Properties: VpcId: !Ref VpcId SecurityGroupIngress: - IpProtocol: tcp FromPort: 80 ToPort: 80 SourceSecurityGroupId: !Ref NLBSecurityGroup GroupName: !Sub "${ResourceName}-ec2-sg" GroupDescription: !Sub "${ResourceName}-ec2-sg" Tags: - Key: "Name" Value: !Sub "${ResourceName}-ec2-sg"   Network Load Balancer(NLB)が新規に作成されました。 セキュリティグループがアタッチされていることを確認します。 プライベートIPアドレスが変更されていないことを確認します。 正常にNetwork Load Balancer(NLB)経由で疎通できていることも確認できました。   最後に いかがだったでしょうか。AWSのベストプラクティスとしても、Network Load Balancer(NLB)にはセキュリティグループをアタッチしておくことを推奨しています。これを機に、移行を検討していただくと幸いです。 実際のプロジェクトでも、Network Load Balancer(NLB)の移行を無事成功させることができました。稼働中のシステムの場合には、必ず検証を実施の上、ユーザーとの合意及び移行期間を設けてください。 本記事が皆様のお役にたてば幸いです。 ではサウナラ~🔥
こんにちは。SCSKのふくちーぬです。 皆さんは、西谷さんが2月に主催した『第一回AWSコスト削減天下一武道会』に参加されましたでしょうか。 大変盛り上がっていて、技術はもちろんのことコスト削減に対する楽しさや根性を感じることができました。大きいものから、小さいものまで様々なコスト削減法が紹介されていました。”Elephant in the room”に向き合うことが大切でしたね🐘 第1回AWSコスト削減天下一武道会を終えて - Sweet Escape 昨日、2024年2月1日に自身が企画・運営をした『第一回AWSコスト削減天下一武道会』というイベントを終えました。申し込み人数としては最終的には3692人の人がConnpass上で申し込んでくれました。 この数は個人が企画して開催するIT関連の勉強会としては類を見ない規模だったのではないかと自負しております。 もちろん... www.keisuke69.net 今回は、弊社環境でも稼働しているElastic IPの自動削除の仕組みについてご紹介します。 2024/2の料金体系の変更により、パブリックIP(Elastic IPを含む)について料金が発生するようになりましたので、”コスト削減”ではなく”AWS環境のお掃除”ということはご了承ください。 Elastic IPの料金体系について 以前までの料金体系は、ざっくり以下の通りでした。 僅かとは言えども、Elastic IPを作成後放置しておくと料金がかかってしまいます。 状態 料金 Elastic IPをEC2にアタッチ済みで、インスタンスを実行中 0.0$/1h Elastic IPがどのリソースにもアタッチされていない 0.005$/1h 新しい料金体系が、2024/2から適用されており以下の通りです。 EIPがEC2にアタッチされているか否かに関わらず、料金が発生するようになりました。 新着情報 – パブリック IPv4 アドレスの利用に対する新しい料金体系を発表 / Amazon VPC IP Address Manager が Public IP Insights の提供を開始 | Amazon Web Services AWS は、パブリック IPv4 アドレスの利用に対して新しい料金体系を導入します。2024年2月1日より、特定のサービスに割り当てられているかどうかに関わらず、すべてのパブリック IPv4 アドレスの利用に対して1 IP アドレスあたり 0.005 USD/時間 が課金されます。 aws.amazon.com 状態 料金 パブリックIP(Elastic IPを含む)の数 (アタッチ済みかどうかを問わない) 0.005$/1h 料金に関する詳細は、以下をご確認ください。 料金 - Amazon VPC | AWS 定義した論理的に分離された仮想ネットワークで AWS リソースを起動できるようにするサービスである Amazon VPC の料金についてご紹介します。 aws.amazon.com   アーキテクチャー Configルールである、”eip-attached”を利用して検査します。 Configの修復オプションで自動削除を実施します。 “AWS-ReleaseElasticIP”を利用して非準拠(Elastic IPが利用中のEC2及びENIにアタッチされていない)の場合、Elastic IPが解放されるようSSM-Automationを実行させます。   完成したCloudFormationテンプレート 以下のテンプレートを使用して、デプロイします。 AWSTemplateFormatVersion: "2010-09-09" Description: Create Config (Delete EIP System) Resources: # ------------------------------------------------------------# # Config # ------------------------------------------------------------# ConfigRule: Type: AWS::Config::ConfigRule Properties: ConfigRuleName: eip-attached Description: Checks whether all EIP addresses allocated to a VPC are attached to EC2 instances or in-use ENIs. Scope: ComplianceResourceTypes: - "AWS::EC2::EIP" Source: Owner: "AWS" SourceIdentifier: EIP_ATTACHED ConfigRemediationConfiguration: Type: AWS::Config::RemediationConfiguration Properties: ConfigRuleName: !Ref ConfigRule Automatic: "true" #自動修復再試行回数と秒数は,自動修復の修復の場合のみ MaximumAutomaticAttempts: 5 RetryAttemptSeconds: 60 Parameters: AllocationId: ResourceValue: Value: "RESOURCE_ID" AutomationAssumeRole: StaticValue: Values: - !GetAtt IAMRoleForSSM.Arn TargetId: AWS-ReleaseElasticIP TargetType: "SSM_DOCUMENT" TargetVersion: "1" # ------------------------------------------------------------# # IAM Role,IAM Policy # ------------------------------------------------------------# IAMRoleForSSM: Type: AWS::IAM::Role Properties: RoleName: !Sub ${AWS::Region}-ssm-AutomationRole-DeleteEIP AssumeRolePolicyDocument: Version: "2012-10-17" Statement: - Effect: "Allow" Principal: Service: - "ssm.amazonaws.com" Action: - "sts:AssumeRole" ManagedPolicyArns: - 'arn:aws:iam::aws:policy/service-role/AmazonSSMAutomationRole' Path: "/" iamPolicy: Type: AWS::IAM::ManagedPolicy Properties: ManagedPolicyName: !Sub ${AWS::Region}-iam-policy-ReleaseEIP PolicyDocument: Version: "2012-10-17" Statement: - Effect: Allow Action: - ec2:ReleaseAddress Resource: "*" Roles: - !Ref IAMRoleForSSM     検証 Elastic IPの作成 EC2のマネジメントコンソールから、”Elastic IP”ペインを選択します。”Elastic IPアドレスを割り当てる”を押下します。 “割り当て”を押下してください。 Elastic IPが作成されたことが確認できます。 自動削除の確認 Configのマネジメントコンソールを開きます。”ルール”ペインを選択すると、作成したルールが確認できます。 今回作成した”eip-attached”が存在しています。 “eip-attached”を押下します。 Elastic IPをアタッチせずに放置して待っていると、非準拠のEIPが検出されます。 ちなみに準拠しているElastic IPの場合は、以下のように表示されます。 しばらくすると、対象のEIPが自動削除されましたね。   最後に いかがだったでしょうか。 Configを利用することで、Elastic IPの自動削除を実現できました。AWS環境を綺麗に維持しておくためにも、是非導入を検討ください。 今後は、他のConfigルールについてもご紹介したいと思います。 本記事が皆様のお役にたてば幸いです。 ではサウナラ~🔥
こんにちは。SCSKのふくちーぬです。 皆さんは、DLP(Data Loss Prevension)サービスの一つであるAmazon Macieを利用したことはありますでしょうか。 今回は、クレジットカード番号を用いて正常に検出されるかを検証していきます。 DLPとは DLPとは、企業内で保護すべき機密情報(個人情報や取引先・自社製品に関わる情報等)の漏洩を防止するためのソリューションです。機密情報の持ち出し(クラウドへのアップロード)を防ぐために、「Digital Guardian」等のソフトウェアを社内で導入している企業も多いかと思います。 Enterprise IP & DLP Software The first and only solution to unify Data Loss Prevention and Endpoint Detection and Response. The DG Data Protection Platform provides a single product suite t... www.digitalguardian.com AWSではAmazon Macieが提供されており、AzureではAzure Information Protectionが提供されています。GoogleではCloud DLPが提供されています。 Amazon Macie(機械学習による機密データの検出、分類、保護)| AWS Amazon Macie では、機械学習とパターンマッチングを利用して機密データを発見し、データセキュリティのリスクを可視化して、そのリスクに対する自動的な防御を行います。 aws.amazon.com Azure Information Protection (AIP) とは Azure Information Protection (AIP) は Microsoft Purview Information Protection フレームワークを拡張し、Microsoft 365 で提供されるラベル付けと分類の機能がそれによって拡張されます。 learn.microsoft.com Cloud Data Loss Prevention | Google Cloud Cloud DLP を使用すると、特に機密性の高いデータ要素を自動的に検出、分類、保護できます。 cloud.google.com   Amazon Macieとは S3バケットに保管されたオブジェクトを探索して、機密性の高い情報が含まれていないか機械学習やパターンマッチング手法を利用して検出するサービスです。 検出結果のタイプ 内容 Policy S3バケット自体が高いセキュリティレベルを満たしているかチェック 例:暗号化設定、パブリックアクセスブロック設定、バケットポリシー Sensitive Data S3バケット内のオブジェクトに機密性の高い情報が含まれていないかチェック 例:AWSシークレットアクセスキー、クレジットカード番号、氏名、運転免許証識別番号 つまりS3内のオブジェクト(データ)の検査だけでなく、S3バケット自体のチェックも行うことができます。   検証(クレジットカード番号を用いた機密情報の検出) Amazon Macieを始めるための設定 Macieのマネジメントコンソールに移動する。 “ご利用開始にあたって”を押下する。 “Macieを有効化”を押下する。 検出結果をS3に保存する必要があるので、検出結果格納用のS3を作成する必要があります。 “今すぐ設定”を押下します。 S3バケットの作成 S3バケット名を入力して新規作成します。既存のバケットを利用いただいても問題ありません。 KMSキーの作成 検出結果を暗号化して保存するために、KMSキーを作成します。キーポリシーさえ設定すれば、既存のKMSキーを利用いただいても問題ありません。 “新しいキーを作成”を押下します。 “次へ”を押下します。 エイリアスを入力します。ここでは、”kms-macie-<名前>”としています。 “次へ”を押下します。 キー管理者として、自身のIAMユーザーを指定します。 “次へ”を押下します。 “次へ”を押下します。 キーポリシーに以下の内容を追記して、”完了”を押下します。 Amazon Macie での機密データ検出結果の保存と保持 - Amazon Macie Amazon S3 オブジェクトの機密データを検査するときに実行する分析の詳細なレコードを保存するように Amazon Macie を設定する方法について説明します。 docs.aws.amazon.com { "Sid": "Allow Macie to use the key", "Effect": "Allow", "Principal": { "Service": "macie.amazonaws.com" }, "Action": [ "kms:GenerateDataKey", "kms:Encrypt" ], "Resource": "*", "Condition": { "StringEquals": { "aws:SourceAccount": "<AWSアカウントID>" }, "ArnLike": { "aws:SourceArn": [ "arn:aws:macie2:<リージョン>:<AWSアカウントID>:export-configuration:*", "arn:aws:macie2:<リージョン>:<AWSアカウントID>:classification-job/*" ] } } }  “保存”を押下します。 以下のように設定されていれば、Macieを利用するための準備は完了です。 テストデータの作成 以下の架空のテストデータ(csvファイル)を利用することとします。 name,birthday,creditcardnumber Taro Sumitomo,1998/10/10,4710753616400187 新規のS3として先ほどのバケットとは別に作成して、上記のテストデータをアップロードします。 ジョブの作成 “ジョブを作成”を押下します。 今回は、1つのバケットを対象にします。”s3b-<AWSアカウントID>-financial-data”を選択します。 “次へ”を押下します。 “次へ”を押下します。 今回は、1度限りのジョブを作成するため”ワンタイムジョブ”を選択します。”次へ”を押下します。 ジョブが利用する識別子を選択することで、機密データの検出をカスタマイズすることができます。 今回は、全てのマネージドデータ識別子を使用して分析させたいため、”カスタム”を選択後に、全ての識別子を選択します。 “次へ”を押下します。 カスタムデータ識別子は、今回利用しません。この機能を利用すると、ユーザーが独自にパターンを定義することができます。 “次へ”を押下します。 “次へ”を押下します。 ジョブ名として、”macie-test”を入力します。”次へ”を押下します。 設定確認後に、”送信”を押下します。 これにて、ジョブの作成は完了です。 Amazon Macieでの検出結果の確認 10分ほど待つと分析が終わり、検出結果が表示されます。 1件の重要度Highの検出がされました。 Macie内で簡単に検出結果を確認することができます。 今回は検出結果のタイプとして、 SensitiveData:S3Object/Multiple が検出されています。 オブジェクトには、1 つ以上のカテゴリの機密データ (1 つ以上のカスタムデータ識別子の検出基準に一致する認証情報データ、財務情報、個人情報、またはテキストの任意の組み合わせ) が含まれます。 Amazon Macie の調査結果のタイプ - Amazon Macie Amazon S3 で機密データを検出、モニタリング、保護できるようにするために Amazon Macie が提供するさまざまなカテゴリとタイプの調査結果について説明します。 docs.aws.amazon.com 今回は、3件の機密データが検出されています。 個人情報として、Date of Birth(誕生日)、Name(名前)が検出 財務情報として、Credit card number no keyword(クレジットカード番号)が検出 個人を特定できる情報 (PII) のマネージドデータ識別子 - Amazon Macie Amazon Macie が組み込み型の基準と手法を使用してAmazon S3 オブジェクト内で検出できる個人を特定できる情報 (PII) 機密データのタイプを説明します。 docs.aws.amazon.com 個人を特定できる情報 (PII) のマネージドデータ識別子 - Amazon Macie Amazon Macie が組み込み型の基準と手法を使用してAmazon S3 オブジェクト内で検出できる個人を特定できる情報 (PII) 機密データのタイプを説明します。 docs.aws.amazon.com 財務情報のマネージドデータ識別子 - Amazon Macie Amazon Macie が組み込み型の基準と手法を使用して Amazon S3 オブジェクト内で検出できる機密の財務情報のタイプについて説明します。 docs.aws.amazon.com 正常に検出することができましたね。架空データではありますが、念のため機密ファイルはS3から削除しておきましょう。 最後に いかがだったでしょうか。 Macieを利用した機密情報の検出を検証してみました。検出結果の集約先としてAWS Security Hubとの統合が可能のため、機会があれば試してみたいと思います。 本記事が皆様のお役にたてば幸いです。 ではサウナラ~🔥
どうも、Catoクラウドを担当している佐々木です。 今回は、2024年2月5日に発表された ユーザー通信可視化の新機能 「 Experience Monitoring」 を紹介します。   画⾯は2024年2⽉時点のものです。機能アップデート等で変わる場合がありますので、あらかじめご了承ください。 2024年2月5日に発表された新機能ですが、実環境への適用まで数日~数週間程度かかる可能性があります。   Experience Monitoringとは 「Experience Monitoring」とは、Catoユーザーの通信を可視化する新機能です。 これまでも「Monitoring」機能で、サイト/ユーザートラフィック、アプリケーション単位のトラフィック、接続状態、パケットロス、 レイテンシーなどの可視化が提供されていました。 「Experience Monitoring」では  快適に業務アプリを使えて いるか という モニタリング機能を 新たに提供します。   Experience Monitoringのイメージ 「Experience Monitoring」のトップ画面です。 左のグラフは日時毎の通信状況を、右のグラフはアプリケーション単位の通信状況を、 「Good(良い)」「Fair(普通)」「Poor(悪い)」 の3段階で評価。 そして、ここからユーザー単位、サイト単位、アプリケーション単位の詳細な情報にドリルダウン可能です。   Experience Monitoringで出来ること(2024/2時点) 「Experience Monitoring」では、 2024年2月時点で以下の機能を提供しています。 User monitoring Application monitoring Network monitoring KBを見るといろいろ書いてありますが端的に言うと、ユーザーデータを収集・分析して、ネットワーク状況がアプリのパフォーマンスや ユーザー・エクスペリエンスにどのような影響を及ぼしているかを可視化することができる機能です。   例えば、とあるユーザーから特定のアプリケーション通信が遅いと申告があった場合、以下のようなことを簡単に確認できます。 特定のアプリケーションだけに影響が出ているのか(ISPトラブルなどが原因でユーザー通信全般に影響が出ていないか) 他のユーザーにも影響が出ていないか(アプリケーション起因の通信トラブルの可能性がないか) 原因究明するための情報(TTFB、HTTP/S Latency、HTTP/S Error Rate情報など)   「Experience Monitoring」は今後も機能拡張を予定しており、以下機能の実装を検討しているようです。  ・Synthetic Probing:ユーザー操作をシミュレートし、システムの潜在的な問題を発生前に特定する機能  ・Endpoint Performance:端末の負荷状況(CPUやメモリなど)の監視機能   Experience Monitoringの利用方法 2024年2月の時点では、 本機能を利用するにあたって特別な設定やライセンス購入、準備は必要ありません。 Monitoring>Experience Monitoringを選択すると上記トップ画面が表示されます。   KBやアップデート情報だと「A free trial of Experience Monitoring is available(=無料トライアルが利用可能)」と 記載がありますので、今後利用にあたって何らかの変更が発生する可能性があります。 ※CMA上にも以下のように表示されます。   各ステータスの見方、説明 基本的には他のMonitoring機能と同じ操作方法になります。 No 項目名 説明 1 Filterバー フィルターがページに適用されます。選択したフィルターは、ページ上のすべてのウィジェットに適用されます。クラウド アプリケーション用のフィルターがデフォルトで適用されます。 2 時間範囲 ページに適用される時間範囲です。最大期間は標準で 3か月です。 3 Account Experience すべてのアプリケーションの平均スコアが表示されます。 4 Top Applications ネットワーク内で最もよく使用されるアプリケーション毎のスコアが表示されます。 「View More」をクリックするとすべてのアプリケーションのスコアが表示されます。 5 Experience Type Tabs 画面下部の各タブには、ネットワーク内の Site、Users/Host、Applicationsのデータが表示されます。この表内の項目​​をクリックすると選択した項目ごとの詳細データが確認できます。   Site、Users/Host、Application、各項目ごとのモニタリングについて 「Experience Type Tabs」で特定のSite、Users/Host、Applicationsをクリックすると以下のような画面が表示され、 Site/User/Application単位の通信状況やスコアなどが確認できます。   ▼Site Experience Monitoring ▼User Experience Monitoring ▼Application Experience Monitoring   また、同じ画面の下部には本機能で収集している以下情報を確認できます。   ▼グラフで表示される情報一覧 項目 内容 グラフ表示の有無 Time to first Byte サーバーからデータの最初の1バイトを受け取るまでにかかる時間 すべてで表示 HTTP/S Latency HTTPリクエストとレスポンスの間の時間 すべてで表示 TCP Connect TCP 接続の確立にかかる時間 すべてで表示 TLS Connect TLS 接続の確立にかかる時間 すべてで表示 HTTP/S Error Rate HTTP エラーの割合 すべてで表示 Packet Loss Upstream/Downstream Last Mileパケットロスの割合 Site/Userのみグラフ表示 Discard Packets Upstream/Downstream Last Mileで破棄されたパケットの割合 Siteのみグラフ表示 Distance SiteからCatoCloudまでのDistance(距離) Site/Userのみグラフ表示 Tunnel Age SocketとPoP間の現在のDTLSトンネルが接続されている合計時間 Site/Userのみグラフ表示 Jitter Upstream/Downstream 遅延時間 Siteのみグラフ表示   活用イメージ 例えば、「ユーザーからMicrosoft365通信が遅い」と申告があった場合、以下のような切り分けが可能です。 特定のアプリケーションだけに影響が出ているのか(ISPトラブルなどが原因でユーザー通信全般に影響が出ていないか) ⇒「User Experience Monitoring」各アプリケーションの通信状況を確認します。 ⇒Microsoft365(Office365)以外も通信状況が悪い(Poor)場合:インターネット回線やNW機器のステータスを確認します。       他のユーザーにも影響が出ていないか(アプリケーション起因の通信トラブルの可能性がないか) ⇒トップ画面の「Applications」タブから「Office365」をクリックし、他のユーザーの通信状況を確認します。 ⇒複数のユーザーでMicrosoft365(Office365)の通信状況が悪い(Poor)場合:アプリケーション起因の可能性があります。 ⇒Microsoft365(Office365)で障害が発生していないかインターネットなどで確認します。 現状ではまだこのくらいの切り分けツールになりますが、今後も機能拡張を予定しているということですので、 「今後に乞うご期待!」 といったところでしょうか。   気になる点 評価基準は? どのような基準で「Good」や「Poor」と評価しているのでしょうか。 KBによると、次のアプリケーション パフォーマンス メトリックに基づいたスコアを元に総合的に判断しており、 各項目ごとに、Cato AI によって学習された異なる閾値があるようです。 ※閾値の値は公表されていませんでした。 Time to First byte TCP Connect TLS Connect HTTP Latency HTTP/S error スコアが「Poor」だったら問題か? ケースバイケースなので、Catoの公式見解は当然ありません。 1日Catoを接続して業務をしてみたところ、「Poor」な接続状況のアプリがそこそこあったり、TTFBが3秒近くかかっているアプリも ありましたが、実際、業務をするうえで遅さや不便さは感じませんでした。 「Poor」=「問題」と考えるのではなく、利用者から申告があった場合のトラブル切り分けツールとして活用するのがいいかなと、 個人的には思っています。   注意事項 2024年2月時点では、アプリケーションのパフォーマンス メトリックは、TCP トラフィックについてのみ計算されます。 音声通話やオンラインミーティングの場合、UDPを利用することが多いです。 今の段階では、 音声通話やオンラインミーティングの通信状況を完全に把握できない可能性があります。   将来的には、他のプロトコルのメトリクスもサポートされる予定です。   まとめ 今回のポイントです。   ・「Experience Monitoring」では、ユーザが快適に業務アプリを使えているかモニタリングできる ・「○○さんの△△アプリが遅い」といった時の切り分けが容易にできる ・2024年2月時点では、TCPトラフィックにしか対応していない ・ただし、今後も様々な機能拡張を予定している   上記以外の情報についても弊社の 「Catoに関するFAQサイト」 に多数情報ございますのでご参考にください。 よくあるご質問 | Cato Cloud ケイトクラウド - SCSK Cato SASE Cloud Platform. powered by SCSK cato-scsk.dga.jp   最後に、SCSKではPoCから導入、運用まで幅広くCatoに関する支援を行っております。 本番構成への移行を見据えたPoC構成や、PoCでつまづきやすい点のサポートなど、豊富な導入実績を基にご支援いたします。 ぜひお声がけください!
はじめに こんにちは。SCSKのふくちーぬです。 今回は、NLBアクセスログをCloudWatch Logsに自動転送する方法をご紹介します。 NLBのアクセスログは、リスナーがTLSの時のみS3を宛先としてログ保管することができます。一方他の多くのサービスではCloudWatch Logsへの転送をサポートしているため、CloudWatch Logsへログの集約をしている方が多いかと考えます。 そこで今回は、NLBのアクセスログもCloudWatch Logsに転送することでログの一元的な集約・分析を可能にしていきます。 事前準備 VPC、サブネット、インターネットゲートウェイ、ネットワークACL、ACM、ドメインが作成済みであることを確認してください。 アーキテクチャー ユーザーは、NLBを経由でWebサイトにアクセスします。 NLBのアクセスログをS3に保存します。 アクセスログがS3に置かれることをトリガーとして、Lambdaが実行されてCloudWatch Logsに転送します。 本記事ではNLB等の作成をしていますが、ご自身の用途に併せてLambdaとS3のみ利用する等適宜調整してください。 完成したCloudFormationテンプレート 以下のテンプレートを使用して、デプロイします。 AWSTemplateFormatVersion: 2010-09-09 Description: NLB Accesslog push to CWlogs Parameters: ResourceName: Type: String VpcId: Type: String PublicSubnetA: Type: String PublicSubnetC: Type: String AcmArn: Type: String Resources: # ------------------------------------------------------------# # Network Load Balancer # ------------------------------------------------------------# LoadBalancer: Type: AWS::ElasticLoadBalancingV2::LoadBalancer Properties: Name: !Sub ${ResourceName}-NLB Subnets: - !Ref PublicSubnetA - !Ref PublicSubnetC Scheme: internet-facing Type: network SecurityGroups: - !Ref NLBSecurityGroup LoadBalancerAttributes: - Key: access_logs.s3.enabled Value: true - Key: access_logs.s3.bucket Value: !Ref MyS3Bucket LoadBalancerListener: Type: AWS::ElasticLoadBalancingV2::Listener Properties: LoadBalancerArn: !Ref LoadBalancer Port: 443 Protocol: TLS DefaultActions: - Type: forward TargetGroupArn: !Ref TargetGroup Certificates: - CertificateArn: !Ref AcmArn TargetGroup: Type: AWS::ElasticLoadBalancingV2::TargetGroup Properties: Name: !Sub ${ResourceName}-targetgroup VpcId: !Ref VpcId Port: 80 Protocol: TCP TargetType: instance Targets: - Id: !Ref EC2 Port: 80 NLBSecurityGroup: Type: "AWS::EC2::SecurityGroup" Properties: VpcId: !Ref VpcId SecurityGroupIngress: - IpProtocol: tcp FromPort: 443 ToPort: 443 CidrIp: "0.0.0.0/0" GroupName: !Sub "${ResourceName}-nlb-sg" GroupDescription: !Sub "${ResourceName}-nlb-sg" Tags: - Key: "Name" Value: !Sub "${ResourceName}-nlb-sg" # ------------------------------------------------------------# # EC2 # ------------------------------------------------------------# EC2: Type: AWS::EC2::Instance Properties: ImageId: ami-0b193da66bc27147b InstanceType: t2.micro NetworkInterfaces: - AssociatePublicIpAddress: "true" DeviceIndex: "0" SubnetId: !Ref PublicSubnetA GroupSet: - !Ref EC2SecurityGroup UserData: !Base64 | #!/bin/bash yum update -y yum install httpd -y systemctl start httpd systemctl enable httpd touch /var/www/html/index.html echo "Hello,World!" | tee -a /var/www/html/index.html Tags: - Key: Name Value: !Sub "${ResourceName}-ec2" EC2SecurityGroup: Type: "AWS::EC2::SecurityGroup" Properties: VpcId: !Ref VpcId SecurityGroupIngress: - IpProtocol: tcp FromPort: 80 ToPort: 80 SourceSecurityGroupId: !Ref NLBSecurityGroup GroupName: !Sub "${ResourceName}-ec2-sg" GroupDescription: !Sub "${ResourceName}-ec2-sg" Tags: - Key: "Name" Value: !Sub "${ResourceName}-ec2-sg" # ------------------------------------------------------------# # IAM Policy IAM Role # ------------------------------------------------------------# LambdaPolicy: Type: AWS::IAM::ManagedPolicy Properties: ManagedPolicyName: !Sub ${ResourceName}-lambda-policy Description: IAM Managed Policy with S3 PUT and APIGateway GET Access PolicyDocument: Version: '2012-10-17' Statement: - Effect: 'Allow' Action: - 's3:GetObject' Resource: - !Sub "arn:aws:s3:::${ResourceName}-${AWS::AccountId}-bucket/*" LambdaRole: Type: AWS::IAM::Role Properties: RoleName: !Sub ${ResourceName}-lambda-role AssumeRolePolicyDocument: Version: '2012-10-17' Statement: - Effect: Allow Action: sts:AssumeRole Principal: Service: - lambda.amazonaws.com ManagedPolicyArns: - arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole - !GetAtt LambdaPolicy.PolicyArn # ------------------------------------------------------------# # S3 # ------------------------------------------------------------# MyS3Bucket: Type: AWS::S3::Bucket DeletionPolicy: Retain Properties: BucketName: !Sub ${ResourceName}-${AWS::AccountId}-bucket NotificationConfiguration: LambdaConfigurations: - Event: 's3:ObjectCreated:*' Function: !GetAtt PushtoCWlogsFunction.Arn BucketPolicy: Type: AWS::S3::BucketPolicy Properties: Bucket: !Ref MyS3Bucket PolicyDocument: Version: "2012-10-17" Statement: - Sid: AWSLogDeliveryAclCheck Effect: Allow Principal: Service: delivery.logs.amazonaws.com Action: s3:GetBucketAcl Resource: !Sub "arn:aws:s3:::${ResourceName}-${AWS::AccountId}-bucket" Condition: StringEquals: "aws:SourceAccount": - !Sub ${AWS::AccountId} ArnLike: "aws:SourceArn": - !Sub "arn:aws:logs:${AWS::Region}:${AWS::AccountId}:*" - Sid: AWSLogDeliveryWrite Effect: Allow Principal: Service: delivery.logs.amazonaws.com Action: s3:PutObject Resource: !Sub "arn:aws:s3:::${ResourceName}-${AWS::AccountId}-bucket/AWSLogs/${AWS::AccountId}/*" Condition: StringEquals: "s3:x-amz-acl": "bucket-owner-full-control" "aws:SourceAccount": - !Sub ${AWS::AccountId} ArnLike: "aws:SourceArn": - !Sub "arn:aws:logs:${AWS::Region}:${AWS::AccountId}:*" # ------------------------------------------------------------# # Lambda # ------------------------------------------------------------# PushtoCWlogsFunction: Type: AWS::Lambda::Function Properties: FunctionName: !Sub ${ResourceName}-lambda-function Role: !GetAtt LambdaRole.Arn Runtime: python3.12 Handler: index.lambda_handler Environment: Variables: LOGGROUPNAME: LGR-NLB-Access-Logs Code: ZipFile: !Sub | import boto3 import time import json import io import gzip import os s3_client = boto3.client('s3') cwlogs_client = boto3.client('logs') #ロググループの指定 LOG_GROUP_NAME = os.environ['LOGGROUPNAME'] #ログフォーマットの変数の指定 fields = ["type","version","time","elb","listener","client:port","destination:port","connection_time","tls_handshake_time", "received_bytes","sent_bytes","incoming_tls_alert","chosen_cert_arn","chosen_cert_serial","tls_cipher","tls_protocol_version", "tls_named_group","domain_name","alpn_fe_protocol","alpn_be_protocol","alpn_client_preference_list","tls_connection_creation_time"] #s3の情報を取得 def parse_event(event): return { "bucket_name": event['Records'][0]['s3']['bucket']['name'], "bucket_key": event['Records'][0]['s3']['object']['key'] } #ログファイルをgzip解凍する def convert_response(response): body = response['Body'].read() body_unzip = gzip.open(io.BytesIO(body)) return body_unzip.read().decode('utf-8') #CWLogsにログを書き込む def put_log(log, LOG_STREAM_NAME): try: response = cwlogs_client.put_log_events( logGroupName = LOG_GROUP_NAME, logStreamName = LOG_STREAM_NAME, logEvents = [ { 'timestamp': int(time.time()) * 1000, 'message' : log }, ] ) return response except cwlogs_client.exceptions.ResourceNotFoundException as e: cwlogs_client.create_log_stream( logGroupName = LOG_GROUP_NAME, logStreamName = LOG_STREAM_NAME) response = put_log(log, LOG_STREAM_NAME) return response except Exception as e: print("error",e) raise #ログをjsonに変換する def transform_json(log_list): data = {} json_data = [] for log_line in log_list: field_item = log_line.split() for field, value in zip(fields, field_item): data[field] = value json_data.append(json.dumps(data)) return json_data def lambda_handler(event, context): bucket_info = parse_event(event) response = s3_client.get_object( Bucket = bucket_info['bucket_name'], Key = bucket_info['bucket_key']) LOG_STREAM_NAME = bucket_info['bucket_key'].split("_")[4] log_text = convert_response(response) log_list = log_text.splitlines() log_data = transform_json(log_list) for log in log_data: response = put_log(log, LOG_STREAM_NAME) return { 'statusCode': 200, } LambdaInvokePermission: Type: 'AWS::Lambda::Permission' Properties: FunctionName: !GetAtt PushtoCWlogsFunction.Arn Action: 'lambda:InvokeFunction' Principal: s3.amazonaws.com SourceAccount: !Ref 'AWS::AccountId' SourceArn: !Sub 'arn:aws:s3:::${ResourceName}-${AWS::AccountId}-bucket' PushtoCWlogsFunctionLogGroup: Type: AWS::Logs::LogGroup Properties: LogGroupName: !Sub "/aws/lambda/${PushtoCWlogsFunction}" NLBAccessLogGroup: Type: AWS::Logs::LogGroup Properties: LogGroupName: LGR-NLB-Access-Logs Lambdaのコード NLBのアクセスログを転送する処理についてPythonファイルを用意しておりますので、ご自身の環境で検証の上ご利用ください。 今回では、CloudFormationテンプレート内にベタ書きしているので特に気にする必要はありません。 import boto3 import time import json import io import gzip import os s3_client = boto3.client('s3') cwlogs_client = boto3.client('logs') #ロググループの指定 LOG_GROUP_NAME = os.environ['LOGGROUPNAME'] #ログフォーマットの変数の指定 fields = ["type","version","time","elb","listener","client:port","destination:port","connection_time","tls_handshake_time", "received_bytes","sent_bytes","incoming_tls_alert","chosen_cert_arn","chosen_cert_serial","tls_cipher","tls_protocol_version", "tls_named_group","domain_name","alpn_fe_protocol","alpn_be_protocol","alpn_client_preference_list","tls_connection_creation_time"] #s3の情報を取得 def parse_event(event): return { "bucket_name": event['Records'][0]['s3']['bucket']['name'], "bucket_key": event['Records'][0]['s3']['object']['key'] } #ログファイルをgzip解凍する def convert_response(response): body = response['Body'].read() body_unzip = gzip.open(io.BytesIO(body)) return body_unzip.read().decode('utf-8') #CWLogsにログを書き込む def put_log(log, LOG_STREAM_NAME): try: response = cwlogs_client.put_log_events( logGroupName = LOG_GROUP_NAME, logStreamName = LOG_STREAM_NAME, logEvents = [ { 'timestamp': int(time.time()) * 1000, 'message' : log }, ] ) return response except cwlogs_client.exceptions.ResourceNotFoundException as e: cwlogs_client.create_log_stream( logGroupName = LOG_GROUP_NAME, logStreamName = LOG_STREAM_NAME) response = put_log(log, LOG_STREAM_NAME) return response except Exception as e: print("error",e) raise #ログをjsonに変換する def transform_json(log_list): data = {} json_data = [] for log_line in log_list: field_item = log_line.split() for field, value in zip(fields, field_item): data[field] = value json_data.append(json.dumps(data)) return json_data def lambda_handler(event, context): bucket_info = parse_event(event) response = s3_client.get_object( Bucket = bucket_info['bucket_name'], Key = bucket_info['bucket_key']) LOG_STREAM_NAME = bucket_info['bucket_key'].split("_")[4] log_text = convert_response(response) log_list = log_text.splitlines() log_data = transform_json(log_list) for log in log_data: response = put_log(log, LOG_STREAM_NAME) return { 'statusCode': 200, }  動作検証 NLBのDNS名を登録する カスタムドメインでアクセスできるように、Route53ホストゾーンにてNLBのDNS名のAliasレコードを追加してください。 ELB ロードバランサーへのトラフィックのルーティング - Amazon Route 53 Route 53 を使用して、ELB Classic、Application、または Network Load Balancer にクエリをルーティングします。 docs.aws.amazon.com カスタムドメインでのアクセス 作成されたNLBに向けて、カスタムドメインでアクセスしてください。アクセスを試行することで、アクセスログがS3に保管されます。 そして、S3にオブジェクトがアップロードされたことをトリガーとしてLambdaが起動します。 CloudWatch Logsの確認 NLBのアクセスログが、JSON形式で格納されていることが分かります。これで、他のサービスと同様の方法でCloudWatch Logs内で分析できます。 最後に いかがだったでしょうか。 既存のログ監視基盤を利用する等の理由で、AWSサービスのログをCloudWatch Logs内に集約・分析するといった事象が稀に発生します。その際はCloudWatchLogsに転送処理を実施し、引き継ぎCloudWatch Logsをご利用いただければと思います。 本記事が皆様のお役にたてば幸いです。 ではサウナラ~🔥
本記事の内容は、The Hacker News に投稿された以下のCato Networksの記事を元に日本語へ翻訳(意訳)し、再構成したものとなります。 Hands-On Review: SASE-based XDR from Cato Networks (ハンズオンレビュー: Cato NetworksのSASEベースのXDR) Hands-On Review: SASE-based XDR from Cato Networks Discover how Cato Networks is revolutionizing cybersecurity with their SASE-based XDR platform! Learn how they simplify threat detection and response. thehackernews.com はじめに サイバーセキュリティとサイバー脅威に関して、企業は終わりの見えない駆け引きを繰り広げている。組織が次々と防御ブロックを築き上げると、悪意のある攻撃者はそのブロックを回避するために、さらに一段上の攻撃を仕掛けてくる。企業のリソースは限られており、熟練したサイバーセキュリティ専門家も少ない中、課題の1つは、異種のセキュリティ・ツールの防御能力を調整することである。 XDR(Extended Detection and Response) は、この課題に対処するものである。XDRプラットフォームは、セキュリティ・ドメイン全体からの指標を相関させて脅威を検出し、インシデントを修復するためのツールを提供します。 XDRには多くの利点がありますが、これまでのレガシーなアプローチは良質なデータの欠如によって妨げられてきました。EPP/EDRシステムによって生成されたイベントから脅威について非常に優れた見解が得られるかもしれませんが、ネットワークの観点に関するイベントが不足しています(またはその逆もしかり)。XDR製品はサードパーティのセンサーからデータをインポートしますが、データは異なるフォーマットで提供されます。XDRプラットフォームはデータを正規化する必要があり、その結果品質が低下します。その結果、脅威が正しく認識されなかったり、見逃してしまったり、インシデント・レポートが迅速な調査と修復に必要な情報を欠いてしまったりする可能性があります。 複雑さを軽減するCatoのユニークなアプローチについて Cato NetworksのXDRへのアプローチは特に興味をそそられる。1月に発表されたCato XDRは、Cato Networksが言うように、 初の「SASEベース」のXDR製品 である。SASE(Secure Access Service Edge)は、セキュリティとネットワーキングをクラウドに統合するアプローチだ。SASEプラットフォームにはすでに多くのネイティブセンサーが搭載されているため、SASEはXDRに自然にフィットするように思われる。2019年にSASEを定義したガートナーは、SASEプラットフォームには「SD-WAN、SWG、CASB、NGFW、ZTNA」が含まれると話しているが、これらは必要な機能に過ぎない。SASEには、リモートブラウザ隔離(RBI)、ネットワークサンドボックス、DNS保護などの高度なセキュリティ機能も含まれる可能性がある。SASEプラットフォームには既に多くのネイティブセンサーが組み込まれているため、XDRの最大の問題点である「良いデータがない」という問題を回避することができます。 Catoクラウドは、ガートナーの提唱するSASEの典型的な例であり、少なくとも机上では、Cato XDRは、SASEが提供する機能をフルパワーで利用することができる。 Catoクラウドには、NGFW、高度な脅威防御(IPS、NGAM、DNS Security)、SWG、CASB、DLP、ZTNA、RBI、EPP/EDRなど、ネットワークとエンドポイントにまたがる豊富なネイティブ・センサーが搭載されている 。後者のEPP/EDRは、Cato XDRと同じくらい新しい。 Cato EPPは、Bitdefenderのマルウェア防御技術に基づいて構築され、顧客とエンドポイントのデータを、Cato SASEの他のネットワークデータと同じデータレイクに保存します 。XDRユーザーは、多くのネイティブセンサーから収集された詳細なデータにより、インシデントの信じられないほどリッチな「サラウンドサウンド(”surround sound”)」ビューを手に入れることができます。Catoの機能は即座に稼働し、常に利用可能なスケールで、脅威の探索、検出、対応に単一の共有コンテキストを提供します。独自のEPP/EDRソリューションを導入している企業にとっても、Catoは有効です。 Cato XDRは、Microsoft Defender、CrowdStrike、SentinelOneなどの主要なEDRプロバイダーと統合されています 。 Catoクラウドのアーキテクチャ。Cato XDR (1)は、Cato SASEクラウドに組み込まれた多数のネイティブセンサー (2)を利用して、豊富で詳細な脅威分析を提供します。すべてのセンサーは、Catoのグローバル・プライベート・バックボーン(3)によって相互接続された世界中の85以上のCato PoPすべてで稼働します。拠点からCatoクラウドへのアクセスは、CatoのエッジSD-WANデバイスであるCato Socket (4)、リモートユーザはCato Clientまたはクライアントレスアクセス (5)、マルチクラウドデプロイメントとクラウドデータセンターはCato vSocket、Cross ConnectまたはIPsec (6)、SaaSアプリケーションはCatoのSaaS Optimization (7)を介して行われます。 テスト環境 このレビューでは、Cato XDR を使用するセキュリティ・アナリストの一日に焦点を当てます。アナリストがネットワーク上のセキュリティ脅威のスナップショットをどのように見ることができるか、また、それらを調査し、修復するプロセスを学びます。このシナリオでは、午後10時59分にマルウェアの存在を知らされました。そのインシデントを調査し、修復を行います。 Cato XDRはスタンドアロン製品としてではなく、Catoクラウドの一部として販売されていることを理解することが重要です。Cato XDRは、Catoクラウドのセンサー、アナリティクス、UIなど、すべての機能を活用しています。従って、Cato XDRを十分に理解するためには、Catoプラットフォームのシンプルさと、Catoが言うところの「エレガンス」を最もよく理解するために、Catoプラットフォームの他の部分をよく知る必要がある。しかし、そうすると、Cato XDRをレビューする余裕を持つことは、不可能ではないにせよ、難しくなる。私たちは、Cato全体をざっと見てから、Cato XDRに焦点を当てることにした(このプラットフォームについては、2017年の古いレビューではあるが、より完全なレビューを見ることができる)。 Cato XDRの使い方 Catoクラウドプラットフォーム(管理ポータル)に入ると、企業ネットワークのカスタマイズされたビューが迎えてくれる。セキュリティ、アクセス、ネットワーク機能は、上部のプルダウンメニューから利用でき、ダッシュボードや調査、検知、対応、プラクティス評価のための特定の機能は、縦方向にあります。Cato XDRへのアクセスは、検知と対応(Detection & Response)のセクションにあります。Cato XDRの機能については、Cato XDRをご覧ください。 Cato XDRは画面左側(赤枠)からアクセスできる。 注:表示されているトポロジーは、当社のテスト環境を反映したものではありません。 Cato XDRのテスト Cato XDRのストーリー・ダッシュボード(Stories Dashboard)をクリックすると、企業内のストーリー(≒セキュリティインシデント)の全体像を見ることができる(下図)。Catoにとっての「ストーリー」とは、1つまたは複数のセンサーによって生成されたイベントの相関関係である。ストーリーは、脅威の発生から解決までのストーリーを物語る。私たちが最初に気づいたのは、ストーリー・ダッシュボードが直感的で使いやすいインターフェイスを備えており、さまざまなスキルレベルのセキュリティアナリストが簡単に操作して理解できることです。これは、効率的な調査と意思決定を行う上で非常に重要だと感じています。 アカウントの全体的なリスクスコアを素早く理解するために、AIを搭載したアカウントリスクスコアウィジェットを見ました。この場合、総合リスクスコアは75で、かなり高い。このことから、何がこのような高スコアにつながっているのかを掘り下げて確認する必要があることがわかる。インシデント・ストーリーは全部で55件あり、そのうち24件はオープン、30件はクローズしている。 Cato XDR ストーリー・ダッシュボードは、企業全体のストーリーの状態を要約します。上部には、AI を使用して、さまざまなストーリーのステータスと垂直方向の追加カウンタ (2) を使用して、アカウントの全体的なリスク (1) を評価します。 全体のサマリーラインの下には、さまざまな観点からストーリーを理解するのに役立つウィジェットがある。最も優先度の高いストーリーは、AIを搭載したクリティカリティストアによってソートされる(1)。このスコアは、選択した時間範囲のすべてのストーリーのリスクスコアに基づいており、Catoの研究開発チームによって開発された数式を使用して計算されます。これは、どのストーリーに最初に対処すべきかを教えてくれるのに役立つ。また、最も多くのストーリー(2)に関与しているホスト(Top 5 Hosts)とサイト(Top 5 Sites)もすぐに確認できる。下にスクロールすると、重要度(3)、マルウェアアクティビティ、ドメイン生成アルゴリズム(DGA)、不審なネットワークアクティビティ(4)などの攻撃指標(IoA)、アプリケーションレイヤープロトコル、C2 チャネル経由の流出、自動流出緩和(5)などの MITRE ATT&CK テクニックの内訳を示すグラフが表示されます。 ウィジェットは、重要度(1)、最も多くのストーリーに関与しているホストとサイト(2)、重要度によるストーリーの内訳(3)、IoA(4)、Mitre ATT&CK テクニック(5)など、さまざまな観点から脅威のストーリーを伝えるのに役立ちます。 アナリストとしては、どのストーリーがオープンになっているかを確認したい。ストーリー・ダッシュボードのサマリー行にある24のオープンストーリーをクリックすると、ストーリーズ・ワークベンチページ(Stories Workbench)(画面左側のナビゲーションからもアクセス可能)に移動し、すべてのストーリーの優先順位付けされたリストが表示され、効率的なトリアージと集中力の向上が図れる。CatoはAIを活用したCriticalityスコアでストーリーをランク付けする(1)。また、フィルタを追加してリストをさらに絞り込み、フィルタ行でよりフォーカスできるようにすることもできる(2)。グループ化オプションも分析を容易にする(3)。 ストーリーズ・ワークベンチには、利用可能なストーリーズがリストアップされ、この場合はフィルタリングされ、重要度(1)でランク付けされたオープンストーリーが表示されます。さらにフィルタリング(2)とグループ化(3)オプションにより、効率的なトリアージと調査が可能です。 私たちは、ストーリーズ・ワークベンチ画面の脅威の分布を、そのユニークな兆候によって脅威をグループ化することで調べることにしました。これで、マルウェア活動、不審なネットワーク活動、ドメイン生成アルゴリズム(DGA)などのカテゴリ別に脅威を確認できるようになりました。DGAは、マルウェア作成者が多数のドメイン名を動的に生成するために使用する手法です。これは、ボットネットやその他の悪意のあるソフトウェアなど、ある種のマルウェアがC&Cサーバーとの通信を確立するために一般的に採用しています。我々は午後10時59分に最終的なストーリーに行き、調査のためにそれを開いた。 ドメイン生成アルゴリズム(DGA)を持つストーリーを示す、表示別にグループ化されたストーリーズワークベンチの画面。最後のDGAストーリーを調査した。 調査画面では、脅威をトップダウンで分析し、状況を大まかに把握し、さらに深く掘り下げていくためのツールを使った方法論が示されている。まず、ストーリーのサマリーラインである(1)。検出された攻撃の種類がドメイン生成アルゴリズムであること、脅威ハンティングのストーリーであること、ストーリーを構成するネットワークフローである関連シグナルの数が 26 であることがわかる。脅威ハンティング・ストーリーには、相関するセキュリティ・イベントとネットワーク・フローが含まれ、AI/ML と脅威ハンティング・ヒューリスティックを使用して、防御ツールではブロックできないシグネチャのないとらえどころのない脅威やゼロデイ脅威を検出します。 ストーリーの期間が 9 日間であることから、9 日間の間に関連するシグナルを発見したことがわかります。次に、ストーリーのアクションを記録するステータス行が表示される(2)。現在のステータスは “作成 “である。今後、このストーリーを作成するにつれて、アクションが追加される予定である。詳細に進むと、ドメイン生成アルゴリズム(DGA)が”Robin’s Host 7″で発見されたことがすぐにわかる。攻撃の方向はアウトバウンドで、AIによるクリティカリティ・スコアは5である。 調査画面は、アナリストがストーリーを調査するために必要なすべての詳細を提供する。ここでは、画面の冒頭部分と、その下にさらなる詳細を示している。ストーリーの詳細は上(1)に要約され、インシデントを修復するために取られたアクションは下(2)に表示されます。この行は調査が進むにつれて更新される。 ストーリーを読みやすく理解するには、「サマリーを見る(”See Summary”)」ボタンをクリックすればいい。Catoの生成AIエンジンは、画面の結果を読みやすいテキストで要約する。詳細には、通信の種類、IPソース、ターゲット、ストーリーが検出された理由、トラフィックをブロックするなどのアクションが自動的に取られたかどうかなどが含まれる。 ストーリー要約(”Story Summary”)ボタン(1)をクリックすると、Catoの生成AIエンジンを使って画面の要約がテキストで生成される。 ストーリー・サマリーを閉じ、捜査画面にとどまることで、ストーリーに関するさらなる洞察を得ることができる。Catoの機械学習を利用したPredicted Verdictは、ストーリーの様々な指標を分析し、過去の知識に基づいて予想される評決を提供する(1)。もう一つのスマートな洞察は「類似ストーリー」で、これもAIを搭載しており、関連性がある場合、類似した特徴を持つストーリーにリンクする。Playbook Knowledge Base(強調表示)もあり、悪意のあるターゲットとのコミュニケーションに関するストーリーを調査する方法を教えてくれる。 画面の右側には、ソースの詳細(2):IP、OS、クライアントが表示されます。これはTorブラウザであることがわかります。Torはプライバシーと匿名性のために特別に設計されたウェブ・ブラウザであり、攻撃者はしばしばオンラインで自分の身元と活動を隠すためにこれを使用します。 攻撃者のジオロケーション・ソース(3)を見ることができる。これも疑わしい。次に、「ターゲットの行動」ボックス(4)を見ると、このストーリーに関係するすべてのターゲットに関連する行動を見ることができる。これは脅威狩りのストーリーであるため、広範なシグナルの間に相関関係を見ることができる。 調査画面では、ストーリーの詳細が表示されます。類似ストーリー(1)は、アカウント内の関連ストーリーを示す(今回は該当なし)。攻撃元に関する詳細が表示され(2)、ジオロケーションも表示されます(3)。ターゲットに関連するアクションも表示されます(4)。 下にスクロールすると、攻撃配信のタイムラインが表示される。ターゲットへの通信が9日間続いていることがわかる。 攻撃分布のタイムラインは、様々なターゲットへの攻撃を時系列に一覧表示します。ターゲットをクリックすると、アナリストはグラフィックからターゲットを追加または削除して、攻撃パターンを見やすくすることができます。 ターゲットの一部をフィルタリングすることで、容易に観察可能な通信のパターンを見ることができます。ボットまたはスクリプトが開始した通信を示す周期的なアクティビティが明 確に確認できます。攻撃タイムラインの下にあるターゲットテーブル(1)には、IP、ドメイン名、関連する脅威インテリジェンスなど、ターゲットの詳細が表示されます。ターゲットは悪意のあるスコアでソートされます。これはAIとMLを活用したスマートスコアで、Catoの脅威インテリジェンスソース(独自ソースとサードパーティの両方)をすべて取り込み、ゼロから1の間でスコアを計算し、そのIPが悪質性が高いと考えられるかどうかを示します。 4つのターゲットを除くすべてのターゲットを削除すると、ボットまたはスクリプトを示す定期的な通信パターンが示されます。攻撃分布のタイムラインの下には、調査対象のターゲットに関する広範な情報が記載されたターゲットの表があります。 人気の列は、Catoの内部データに従って、IPまたはドメインがどのくらいの頻度で訪問されているかを測定するCato独自のアルゴリズムによって決定されたIPが「人気(”popular”)」か「不人気(”unpopular” )」かを示しています。人気のないIPやドメインは、しばしば疑わしいIPやドメインを示しています。VirusTotal、WhoIs、AbusePDBなどのサードパーティの脅威インテリジェンスリンクをクリックすることで、ターゲットに関する外部の脅威インテリジェンス情報を得ることができます。 外部の脅威インテリジェンス・ソースは、「ターゲット」テーブル内でクリックするだけでアクセスできます。 攻撃関連フロー表(Attack Related Flows table)までスクロールダウンすると、トラフィックの開始時間やソース・ポートおよび宛先ポートなど、ストーリーを構成する生のネットワーク・フローについて、より詳細な詳細を表示できます。この特定のケースでは、宛先ポートが異常に高く(9001)、一般的でないため、赤信号が灯っています。 Catoで発見したことを文書化する テストケースから得られた知見をまとめてみよう。Torクライアントを使用するドメイン生成アルゴリズムに関連する不審なネットワーク活動を発見した。このIPは人気が低く、悪意のあるスコアが高く、通信は明確な時間帯に特定のパターンに従っています。これで結論が出ました。ソースエンドポイントである”Robin’s Host 7″にマルウェアがインストールされており、Torインフラを使って外部と通信しようとしている疑いがあります。 では、以下の画面で判定を設定してみよう。このストーリーを悪意のあるものとして分類します。アナリストの重大度は中程度でしょう。タイプはアノニマイザーです。下の画像で詳細を見ることができる。分類はDGAです。そして、このインシデント・ストーリーの評決を保存します。 セキュリティ・アナリストは、他の人が脅威を理解するのを助けるために、評決を文書化することができる。 保存すると、冒頭の脅威検索画面が更新されていることがわかる。2行目には、アナリストが深刻度を「中」(”Medium”)に設定し、判定を「悪意あり」(”Malicious”)に設定していることが示されている。この場合、ファイアウォールルールを設定することで、脅威を軽減する必要がある。 更新された「検知と対応」のストーリーには、アナリストがアクションを起こしたことが反映されています。深刻度は「中」(”Medium”)、評決は 「悪意がある」(”Malicious”)に設定され、タイプは 「匿名化」(”Anonymizer”)に変更されている。以下では、ストーリーが作成されたこと(1)だけでなく、アナリストが重大度を「中」(2)に設定し、評決が「悪意がある」(”Malicious”)に設定されていることがわかる。 Catoで脅威を軽減 通常、アナリストは対策を講じるために別のプラットフォームに移動する必要がありますが、Catoの場合はXDRプラットフォームですべて行うことができます。マルウェアの拡散を防ぐために、Catoのインターネットファイアウォールにブロックルールを簡単に作成することができます。攻撃ネットワークフローに表示されるターゲットドメインをコピーし、ファイアウォールルールのApp/Categoryセクションにドメインを追加し、適用をクリックします。世界中のDGAドメインがブロックされました。 DGAが生成したドメインへのアクセスをブロックするルールが更新されたCatoファイアウォール画面。 結論(まとめ) CatoクラウドのSASE ベースの XDR の導入により、Cato Networks は脅威の検知、インシデント対応、エンドポイント保護を大幅に簡素化することを約束した。彼らはその約束を守っているようだ。私たちが上記で実行したテスト・ケースのシナリオでは、経験豊富なセキュリティ・アナリストであれば、開始からミティゲーションまで20分もかからないはずです。しかも、セットアップや実装、データ収集の作業は一切必要ない。データはすでに SASE プラットフォームのデータレイクに存在していました。 Cato Networks は、XDR と関連機能によって、統合ネットワーキングとセキュリティ・プラットフォームのセキュリティ・サービスを拡張することに成功しました。これは、脅威の検出と対応に関して、自社のゲームを向上させようと決意している顧客にとって、大きなメリットとなる。Cato XDRについてもっと知りたいですか? Cato XDRのページをご覧ください。 Extended Detection and Response (XDR) Cato XDR is the industry’s first SASE-based detection and response solution empowering security teams with granular and efficient threat investigation and remed... www.catonetworks.com
こんにちは。SCSKのふくちーぬです。 みなさんは、Terraformを利用してAWSやAzureのリソースを作成したことはありますでしょうか。 本記事では、Terraform Associate認定試験に合格するためのポイントをご紹介します。 Terraformとは Terraformとは、AWSやAzure,GCP等のマルチクラウドに対応したIaCツールとなります。 またTerraformは、オープンソースであり開発が非常に速いため、Terrafom CLIのバージョンアップも頻繁に行われます。バージョンアップにより使用できるコマンドや機能等も増えています。そして、Terraform Associate(003)が2023/4/5から受験可能になりました。 本記事の内容は、2023/2/16にてTerraform Associate(002)試験を合格した際の記録となります。最新の情報は、ぜひTerraform Associate(003)試験に合格されたkakkuさんや公式サイトの情報をご確認ください。 Terraform の認定試験「HashiCorp Certified: Terraform Associate (003)」に合格した - kakakakakku blog Terraform の理解を証明できる HashiCorp 公式の認定試験「HashiCorp Certified: Terraform Associate (003)」に合格した❗️やったー👏 試験問題に関係する内容は NDA を厳守するため書かず,今回は「試験紹介(普及のため!)」と「勉強方法」をまとめたいと思う.... kakakakakku.hatenablog.com HashiCorp Cloud Engineer Certification - Terraform Associate 003 Cloud engineers will be able to use either version of the Terraform Associate certification to verify their basic infrastructure automation skills. www.hashicorp.com 試験概要 以下が試験概要です。 受験費用 USD 77.5 試験会場 オンライン試験のみ(※AWSやAzureのようにテストセンターでは、受験できないのでご注意ください。) 言語 英語のみ 試験形式 57問(選択式、一部コマンドの記述) 試験時間 60分 合格得点率 不明/100%(おそらく70%程度だと思われます。) Terraform Associate(002) vs Terraform Associate(003) 試験自体は新しくなったようですが、内容に大きな変化等はありません。具体的には、非推奨のコマンドに関する問題が出題されなくなり、Terraform Cloudに関する問題をさらに理解しておく必要があります。 既にTerraform Associate(002)を保有している方も、わざわざ再受験する必要はなく、胸を張って資格を持っていることをアピールして問題ありません。 HashiCorp Cloud Engineer Certification - Terraform Associate Cloud engineers can use the Terraform Associate exam from HashiCorp to verify their basic infrastructure automation skills. www.hashicorp.com local-exec,remote-execコマンドの出題がなくなった terraform taintコマンドが非推奨になったため、terraform apply -replace等のオプションを利用すること Terraformロックファイルの内容と更新方法の理解 sensitive値を含む機密情報の扱い方 Terraform Cloudの仕組みと記述方法及びチーム間連携の方法 出題分野 コードとしてのインフラストラクチャ (IaC) の概念を理解する Terraform の目的を理解する (他の IaCツール(主にCloudformation)と比較して) Terraform の基本を理解する Terraform CLI を使用する Terraform モジュールとやり取りする Terraform ワークフローをナビゲートする stateの実装と維持 構成ファイルの読み取り、生成、および変更 Terraform Cloud と Enterprise の機能を理解する 学習教材 Udemy講座 1つ目が、以下のUdemyの講座を受講して、Terraformを使用したAWSリソース構築に取り組みました。 Terraform Associate試験用の講座ではないものの、Terraformで使用する基本コマンドやtfstateファイルについて分かりやすく説明しているのでおすすめです。 AWS と Terraformで実現するInfrastructure as Code インフラの手運用なんてもうイヤだ!そんなあなたに贈る Infrastracture as Code の大本命!AWS上の環境構築をコーディングしよう! www.udemy.com HashicCorp公式チュートリアル 2つ目が、HashiCorpが提供している公式チュートリアルに取り組みました。 試験範囲をすべて網羅しているので、Terraformの仕様について詳しく学ぶことができます。試験で実際に問われた内容も、チュートリアル内にあったかと思います。 Associate Tutorials | Terraform | HashiCorp Developer Study for the Terraform Associate exam by following these tutorials. Login to Learn and bookmark them to track your progress. Study the complete list of study m... developer.hashicorp.com 勉強方法と勉強時間 20時間ほど勉強時間を割きました。 Udemy講座を通して、Terraformを使用してテンプレートを記述,リソース構築,削除の流れを理解し、コマンドを体に染みこませる。⇒14時間 公式チュートリアルを通して、Terraformコマンドの仕様やTerraform Cloudの使い方を理解。⇒4時間 上記で不明な点等あれば、公式ドキュメントを読む Documentation | Terraform | HashiCorp Developer Documentation for Terraform, including Terraform CLI, Terraform Cloud, and Terraform Enterprise. developer.hashicorp.com 少々バージョンが古いですが、Kindle unlimitedに加入している方は無料なので、こちらも参照してみてください。 はじめての人のための Terraform for AWS AWSの環境構築をTerraformで行う、初心者向けの解説本です。はじめての方でもわかりやすく理解できるよう、チュートリアル形式で紹介しています。 www.amazon.co.jp 当日の試験会場・試験内容 試験会場 以下のサイトから、試験を予約できます。申し込みが完了すると、試験サイトへの案内リンクが含んだメールが届きます。 Just a moment... hashicorp-certifications.zendesk.com 試験には、GitHubのアカウントが必要なため、アカウントを持っていない方は、事前に作成しておきましょう。 Build software better, together GitHub is where people build software. More than 100 million people use GitHub to discover, fork, and contribute to over 420 million projects. github.com 試験会場は、自宅の廊下で受験しました。 私の部屋のリビングは散らかっており、片づけるのが面倒であったため、自宅廊下にて受験しました。 試験会場 受験開始までの流れ メールアドレス内の案内リンクをクリックすると、PSIの試験サイトに飛ばされます。試験の30分前からアクセス可能なため、なるべく早くアクセスしましょう。 カンニング防止やオンライン監視を実現するために必要な、PSI専用のセキュリティソフトをダウンロードします。 セキュリティソフトを立ち上げると、音声チェックと他アプリの起動確認が自動で実施されます。どちらもチェック済みにならないと、試験が開始されないので注意してください。 基本的には、タスクマネージャーで起動しているプロセスを選択して”タスクの終了”すれば問題ないはずです。 ※自分の場合は、タスクマネージャーで対処しても、バックグランドで”vmwep.exe”が起動し続けていたため、一向に試験が始まりませんでした😢 拙い英語ですが、 “I Couldn’t terminate process(vmwep.exe). Would you take care of it?” とチャット入力しました。。 すぐにはチェック済みにはなりませんでしたが、しばらくするとチェック済みになりました!(チャットでは返事はなかったので、誰がどのように対処したのかは不明ですが、裏で上手く対応してくれたのかなあ?) やっとここから試験会場の撮影となります。部屋の上下左右、自身の腕、眼鏡、耳、机の上下等を5回ほどに分けて撮影します。最後に、スマホを自身の後ろに置いた様子を撮影します。 全ての撮影においてゆっくりカメラを動かさないと、試験官のチェックが通らず再撮影を求められるのでご注意ください。 ここまでの内容が全て問題なければ、チャットで試験開始のアナウンスがされるので、やっと試験スタートになります。 認定試験のポイントと結果 認定試験のポイント 出題分野に沿って、ポイントをまとめます。 コードとしてのインフラストラクチャ (IaC) の概念を理解する IaCの原則 Terraform の目的を理解する (他の IaCツール(主にCloudformation)と比較して) Terraformを利用することの利点(Terraformを利用することで、AWS及びAzureに、同様の記述方法でデプロイが可能となる) Terraform の基本を理解する providerのバージョン指定方法 Terraform CLI を使用する terraform taintコマンドの意味と使いどころ terraform importコマンドの使い方(既存リソースのterraformファイルへの取り込み方) Terraform モジュールとやり取りする 親モジュールと子モジュールの呼び出し方 Terraform ワークフローをナビゲートする 右記の一連の流れをそれぞれ理解する(terraform init(初期化)  → terraform fmt(フォーマット) → terraform validate(構文チェック)  → terraform plan(実行計画)  → terraform apply(デプロイ) → terraform destroy(削除)) stateの実装と維持 tfstateファイルと実際のインフラリソースとの差異について tfstateファイルの管理方法(s3+DynamoDB,Terraform Cloud) 構成ファイルの読み取り、生成、および変更 Dynamicブロックを使用した、動的記述方法 Terraform Cloud と Enterprise の機能を理解する Terraform Cloudを利用したチーム開発,ワークスペースの使用方法 sentinelを使用したポリシー制限 試験結果 84%/100%で合格でした。 IaCの基本的なところで、点数を落としていたのがショックでした。。 自分では理解しているつもりでしたが、英語のニュアンスを読み取ることが難しかったような気がします。IaCの基本から復習する良い機会になったのかもですね。 最後に いかがだったでしょうか。上記の学習教材を学習することで、合格に近づくことができます。 試験を受けてみて、Terraformを使用して、AWSへのリソースをデプロイすることができるようになりました。次は、他クラウドやKubernatesへのデプロイも実践してみようと思います。 本記事が皆様のお役にたてば幸いです。 ではサウナラ~🔥