こんにちは。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へのデプロイも実践してみようと思います。 本記事が皆様のお役にたてば幸いです。 ではサウナラ～🔥

Catoクラウドでは、現在のサービス状態や定期メンテナンスなどの情報を確認できるステータスサイトのページがあります。 今回はステータスページについて、見方や使用方法を確認していきたいと思います。 Loading... status.catonetworks.com Catoステータスページとは Catoステータス ページでは、Catoクラウド のステータス（サービスの状態）と、計画されたメンテナンスやアップグレードに関する情報が表示されています。 Catoクラウド内のPoPに関するリアルタイム情報と、Cato管理アプリケーションが稼働するサーバーに関する情報などが表示されます。 Catoに接続できない等といった際の障害の一次切り分けとしても活用できますので、ぜひご参照ください。 メンテナンスについてですが、PoPメンテナンス期間中は、ユーザー側で何か特別なことをする必要はありませんが、メンテナンスを行っている間は、約30秒間サービスが使えなくなることがあります。 定期メンテナンスについては、事前にステータスページを通じてアナウンスされます。 どのサービスがメンテナンスで影響を受けるのかの範囲や詳細、予想されるサービス停止時間などの情報が含まれておりますので、事前に確認できるとよいですね。   サイト内容 まず、ステータスページにどのような項目が記載されているか、全体的な内容についてみていきましょう。 掲載されている内容は以下となります。 PoP稼働状況 メンテナンスカレンダー サービス稼働状況 Uptime PoP稼働状況 サイトを開くと、このような画面が表示されます。 PoPのUP/DOWNなどの現在の稼働状況やメンテナンス情報、障害発生時にどのPoPでなにが起こっているか等の確認ができます。   メンテナンスカレンダー 稼働状況の下には、「Notifications」と「Maintenance」の項目があります。 「Notifications」では、PoPステータスが AFFECTED状態のもの に関する情報（発生日時や現在対処している内容）が表示されています。 「Maintenance」では、カレンダーに今後予定されているメンテナンスや、すでに実施されたメンテナンス履歴が記載されています。対象の日付を選択するとメンテナンス内容の確認ができます。 試しに、2024/1/24の箇所を選択してみますと、以下のようにメンテナンス実施時間や対象のサービス範囲、ダウンタイムの推定時間などが記載されており、今後予定されているメンテナンス情報について確認することができます。   サービス稼働状況 Service HistoryのListの表示ではEvents Cato APIやCMAなどのManagement機能、PoP接続のネットワークサービス全体についてのGlobal、各PoPのサービス稼働状況についての表示があります。 正常に稼働しているか、メンテナンスや障害の有無についての履歴が確認できます。 緑色 正常に稼働している 黄色 パフォーマンスに影響あり 赤色 サービスダウンあり 障害があった際は赤丸にて表示され、障害内容や対象時間、対処内容の記載があります。   また、Carendarを選択すると、1か月の履歴が確認できます。 確認したい内容があれば、該当日付の記載をクリックしますと、詳細内容が説明されたページへ移動されます。 試しに、1月4日の項目をクリックしてみますと、以下のように課題がいつ発見されたかや現在対処中である旨、課題がいつ解決されたかについての内容が確認できました。   Uptime Management機能の各サービスや各PoPのUptimeを、1日・1週間・1か月・1年単位で確認することが可能です。 CMAにログインできないや、ログが反映されないといった際はこちらの項目にてDOWNしている可能性があるか確認してみましょう。 サイトに記載されている内容については以上となります。   機能紹介 ステータスサイトで使用できる機能についても確認していきます。 SUBSCRIBE  例えば、拠点のCatoクラウド接続が切れてしまい、障害影響であるか確認したいや、東京・大阪PoPの今後のメンテナンス予定の通知を受領したい、などといった際に使用できる機能がございます。 それが以下の「SUBSCRIBE」です。 こちらをクリックすると以下の表示がされ、通知を受領したい項目を選択することができます。 通知設定について、試しにEmailにて設定を行ってみたいと思います。 「Email」を選択すると、メールアドレスの設定に移ります。 アドレスを入力し、同意にチェックを入れましたら通知してほしい内容のカスタマイズを行います。 ※All serviceを選択した場合、すべてのPoP障害・メンテナンス等の通知が来ることになります。 選択できる内容としては、Management機能のサービスと、各地域のPoPを選択することができます。 東京、大阪のPoP情報のみ通知が欲しいといった際には、「Tokyo,Japan」「Tokyo_DC2,Japan」「Osaka,Japan」「Osaka_DC2,Japan」にチェックをいれSaveボタンを押しますと、完了となります。   実際の通知メールは以下のようなものが送付されてきます。   対象PoP・サービスの選択 特定のPoPやサービス、例えば東京PoPだけのメンテナンス履歴や今後のメンテナンス予定を知りたいなどの際は、Service History ＞LIST　下付近にある検索欄の箇所で対象のPoP名・サービス名を入力いただくと該当のもののみ表示されるようになります。 他にもPoP名だけでなく、「JAPAN」など国名を入力することで対象国のPoP情報を確認することもできます。 また、ページ右上のタイムゾーンを「UTC」⇒「JST」に変更することで、メンテナンスカレンダーの表記時間が日本時間の表記に変更されるため見やすくなります。 機能紹介は以上となります。   他サービスとの比較 AWS AWSでは AWSサービスヘルスダッシュボード という機能にて各種サービスが正常稼働しているかどうかを公開しているサイトがあります。 こちらのサイトにてAWSステータスを確認し、各リージョンのサービス稼働状況が確認できるため、AWSにて利用してるサービスに何か問題が起きた場合は、チェックすることが可能です。過去に起きた問題等も時系列で閲覧することが可能となっています。 AWSサービスでも通知機能も備わっているため、外部ツールなどで指定した対象リージョンのサービスの通知を受け取ることも可能です。 Catoのステータスページとの比較してみると、AWSでは他のAWSサービスと統合・組み合わせをすることが可能になっています。例えば、AWS CloudWatchやAWS Lambda関数と組み合わせて、問題発生時の改善措置を自動化し、運用の負担減らすなどのことが可能となっております。AWSのサービスの豊富さを活用していると思います。   Azure Azure では「 Azure の状態 」ページにて、Azure の全サービスおよび全リージョンの稼働状況や障害情報の確認が可能となります。 また、よりパーソナルな情報を確認できる「Azure Service Health」というページもございます。 お客様ごとに利用しているサービスとリージョンごとに確認ができるページとなり、Service Health 内では、顧客が影響を受ける軽微なサービス停止から、計画メンテナンスの実施を始めとする正常性に関する通知まで、さまざまな情報を参照できます。 Catoとの違いでは、ダッシュボードの情報がパーソナライズされているため、お客様が利用中のサービスやリージョンが反映されるようになっております。お客様毎のページがあり、トラブルシューティングに役立つよう、各イベントによって影響を受ける可能性のあるリソースのリストを提示してくれております。 他のステータスページと比較し、Catoクラウドのステータスページの特徴としては、詳細な確認以外は1ページで完結している見やすさが特徴であると感じました。   まとめ 今回はCatoクラウドのサービス状況の確認ができるサイトステータスページのご紹介をしました。 Catoクラウドに接続できないといった事象が発生しましたら、障害が発生していないか、メンテナンスに該当していないかのご確認をしていただき、切り分け対応の切り分けにご活用いただければ幸いです。 ご覧いただきありがとうございました。

本記事の内容は、Cato Networks社の Avishay Zawoznik氏が投稿した以下のブログを元に日本語へ翻訳（意訳）し、再構成したものとなります。 Busting the App Count Myth （アプリ数神話を打ち破る） Busting the App Count Myth  Many security vendors offer automated detection of cloud applications and services, classifying them into categories and exposing attributes such as security ri... www.catonetworks.com はじめに SSE、特にCASBを中心としたセキュリティソリューションで「約50,000以上のクラウドアプリケーションの検出が可能です」と謳われている事がよくありますが、本記事では、クラウドアプリケーションのセキュリティにおける”アプリケーション数”の重要性に対する疑問を呈し、アプリケーションの実際のトラフィックに焦点を当てた包括的なアプローチを提言するものとなります。 つまり、 アプリケーション数だけでなく、トラフィックから見たアプリケーションのカバレッジ（Coverage＝網羅率）に注目すべき であり、数が増えても必ずしもセキュリティ向上につながらないことを示唆しています。 CatoクラウドのCASBについては、以下の記事を参照ください。 CatoクラウドのCASBについて Catoクラウドのセキュリティオプション CASB について解説します。 blog.usize-tech.com 2023.09.12 各セキュリティベンダーは、クラウドアプリケーションやサービスを自動検出し、カテゴリ分類して、セキュリティリスク、コンプライアンス、サービス提供企業のステータスなどの属性を公開しています。 ユーザーは、アプリケーションのカテゴリと属性に基づいて、ファイアウォール、CASB、DLPポリシーの設定など、さまざまなセキュリティ対策を適用することができます。 そのため、アプリケーションの分類数、登録されているアプリケーション数が多ければ多いほど良いという結論はとても理にかなっているように思えます。 ちなみに、Catoクラウドでは、独自のACE（Application Credibility Engine）を用いてアプリケーション分類が行われています。 ACEのアプリケーションカタログ（App Catalog）には、 2024年2月5日時点で10,352のアプリケーションが登録 されています。 アプリケーションを数えるのをやめてカバレッジを考えるべき まず、アプリケーションの数を数えるのをやめて、アプリケーションのカバレッジを考えるべきであるということです。 セキュリティベンダーが分類したアプリケーション数を議論しても、実際のトラフィックを考慮しなければ意味がありません。 10万のアプリケーションカタログを提供するベンダーと、一方で2千のアプリケーションカタログを提供するベンダーにおいて、両方のベンダーがカバーするのがともに同じ1千のアプリケーションであれば、提供している機能としては全く同じことです。 上の図で、左の円はセキュリティベンダーによって署名され、分類されたアプリケーションを表し、右の円は、顧客のネットワーク上の実際のアプリケーショントラフィックを表しています。 両方の交わった部分が、ユーザのアプリケーション適用（検出）数を表しています。 つまり、顧客のトラフィックに適用されるアプリケーションカタログです。 Catoは、一部のベンダーのようにカタログのアプリケーション数に重点を置くのではなくカバレッジを最大化することに重点を置いています。 クラウドベンダーとしてのデータ可視性により、Catoの調査チームは顧客ベース全体、または要求に応じて特定の顧客カテゴリー（地域、業種など）に対してアプリケーションのカバレッジを最適化することに力を入れています。 アプリケーション数とカバレッジの考察 アプリケーションのカバレッジに注目すると、やはり「 より多くのアプリケーションを登録すれば、カバレッジはどんどん向上するのは？ 」という疑問が生じます。 アプリケーション数とカバレッジの関係を理解するために、Catoクラウド全体のトラフィックを1週間分収集し、分類されたトラフィックと分類されていないトラフィックを分析しました。 ※アプリケーションカタログの観点から主な関心事であるクラウドアプリケーション保護のシナリオに焦点を当てるため、Catoのデータレイクから収集したHTTPのアウトバウンド・フローのトラフィックに基づいています。 その結果、 10 のアプリケーションが、トラフィックの 45.42%をカバー 100 のアプリケーションが、トラフィックの 81.6%をカバー 1000 のアプリケーションが、トラフィックの 95.58%をカバー 2000 のアプリケーションが、トラフィックの 96.41%をカバー 4000 のアプリケーションが、トラフィックの 96.72%をカバー 9000 のアプリケーションが、トラフィックの 96.78%をカバー Catoのアプリケーションカタログに最後（4000→9000）に追加された5000のアプリケーションは、総カバレッジの+0.06%しか貢献していないことが判明しました。 つまり、アプリケーション数の増加は、カバレッジという点では収穫逓増（しゅうかくていぞう）※となっています。 ※アプリケーションを追加していくとカバレッジは増えるが、カバレッジの伸び率は次第に低下していくこと。 Catoクラウドが、9000 のアプリケーションだけで 96.78%という高いカバレッジとなってい るのは、実際の顧客トラフィックで見られたアプリケーションを、カバレッジへの貢献度に応じて優先的に分類する体系的なアプローチを行っている結果です。 ※2024年2月5日時点では10,352のアプリケーションが登録されています。 次に、Catoクラウドの総カバレッジよりもさらに踏み込んで、同様の手法でアカウントごとのカバレッジも調査しています。 Catoの顧客アカウントにおいて、 91%のアカウントが、90%（またはそれ以上）のカバレッジ 82%のアカウントが、95%（またはそれ以上）のカバレッジ 77%のアカウントが、96％（またはそれ以上）のカバレッジ カバレッジは、Catoクラウドのカバレッジに過ぎませんが、顧客設定とは無関係です。 Catoの新規顧客であれば、トラフィックの90％が分類される確率は91％という結論になります。図に表すと、次のようになります。 アプリケーション数は、マーケットにとって非常に分りやすい簡単な指標ですが、アプリケーションのカバレッジこそが真の価値です。 ピカピカのアプリケーションカタログを見せびらかしてもらった後、実際にそのベンダにアプリケーションのトラフィックの何パーセントを分類できているか聞いてみてはどうでしょうか？（96.78%以上でしょうか？） ちなみに、Catoクラウドでは、CASBをご契約のお客様のカバレッジが93%以上（未分類7%未満）になるように管理されています。 カバレッジ100％はあり得るか 次の疑問は「100%のアプリケーションのカバレッジは可能か？」です。 Catoクラウド上の1週間のトラフィックを注意深く調査し、現在Catoのアプリやカテゴリーに分類されていないトラフィックに焦点を当てました。アプリケーションを分類するために何が必要かを知るために、このトラフィックを（完全なサブドメインではなく）セカンドレベルドメインで分類しました。 つまり、Catoクラウドの96.78%カバー率の残り3.22%について、さらに詳細な分析を行った結果、 トラフィックの0.88%はドメイン名を示していないこ とがわかりました。これはIPアドレスからの直接アクセスが原因です。 3.22%の 残りの2.34%については、318万個の異なるセカンドレベルドメインにまたがっており、そのうち312万個は、5個未満のクライアントIP、または単一のCatoアカウントで発見 されました。 このことから、未分類のトラフィックには、常にロングテールが存在することがわかりました。 セキュリティベンダーとして、このことが「100%のカバレッジ率」を達成することを不可能にしていることが分かりました。 つまり、カバレッジを100%にすることは不可能ということになります。 未分類（Unclassified）への対応について ごくわずかなカバレッジを得るために、より多くのアプリケーションを分類することは、セキュリティの観点でも意味がありません。 ベンダーと顧客の両方に対して、未分類のトラフィックを追いかけるのではなく、未署名のアプリのロングテールを適切なセキュリティ緩和策で処理する必要があることをCatoクラウドでは提案します。 悪意のあるトラフィック（Malicious traffic）からの保護 C&Cサーバーとの通信、フィッシングサイトへのアクセス、マルウェア配信サイトなどの悪意のあるトラフィックの保護は、アプリケーションの分類がなくても保護を行う必要があります。 Catoでは、マルウェア保護とIPSは、アプリケーション分類から完全に独立しているため、ターゲットサイトが既知のアプリとして分類されていなくても保護されます。 シャドーITアプリ（認可されていないアプリケーション）への不正アクセスには、以下のような対策が必要です。 完全な可視性の確保 アプリケーション分類の有無にかかわらず、すべてのトラフィックを可視化することができます。 Catoのユーザーは、トラフィックがアプリ/カテゴリに分類されているかどうかにかかわらず、あらゆるアクティビティを監視するように選択できます。 データ損失防止（DLP） 未認可のクラウドストレージやファイル共有サービスを使用すると、機密データが社外に流出する可能性があります。 Catoは、アプリの分類に関係なく、すべてのHTTPトラフィックをDLPスキャンする機能を導入しました。 一般的には、未知のクラウドサービスに対してより制限的なポリシーを設定するためにこの機能を使用することをお勧めします。 カスタムアプリ検出 この機能は、Catoによって分類されていないアプリケーションの追跡を改善するために、トラフィックを追跡し、顧客ごとにアプリケーション分類する機能を導入しています。 リモートブラウザ分離（RBI） アプリ/カテゴリに分類されていない「Uncategorized(未分類)」および「Unknown(不明)」となるサイトは、エンドユーザのデバイスで直接アクセスさせるのではなく、Catoクラウド上の仮想マシンからアクセスを行い、その画面情報をエンドユーザへストリーミングするRBI機能があります。 まとめ クラウドアプリケーションのセキュリティ強度の指標として、アプリ・カタログのアプリケーション数に固執することが無意味であることを解説しました。 アプリケーション数の増加によるリターンの減少は、多ければ多いほど良いという一般的な考え方に疑問を投げかけるものです。 クラウドアプリケーションセキュリティを評価し、最適化するための重要な軸として、より意味のある指標であるカバレッジの採用がトレンドになっています。 効果的なセキュリティ戦略は、アプリの分類にとどまらず、完全な100%のカバレッジは実現不可能であることを認識する必要があります。 つまり、アプリケーション分類だけではなく、IPSやDLP、RBIなどの他のソリューションを適切に組み合わせることでセキュリティリスクを軽減し、アプリケーションのロングテールをカバーするギャップに対処する必要があります。 クラウドアプリケーションセキュリティの複雑な状況をナビゲートするには、適切なメトリクスと適切なセキュリティコントロールを組み合わせた微妙なアプローチが、包括的で適応性のある保護を確保するために最も重要になります。

こんにちは。SCSKのふくちーぬです。 みなさんは、コンテナ関連のサービスを利用したことありますでしょうか。 本記事では、ECSタスク定義をCloudFormationで管理・デプロイするときのちょっとしたテクニックをご紹介します。 ECSタスク定義をCFNで管理するとリビジョン保持することができない？ ECSタスク定義をCloudFormationで管理すると、以前のリビジョン(バージョン)を保持することができない問題があります。つまり、CloudFomrationでデプロイすると、以前のリビジョン(バージョン)が削除されて、最新のリビジョン(バージョン)のみ保持する仕様になっています。 ECSタスク定義のCloudFormationドキュメントを確認すると、各プロパティを更新すると”置換”が発生してしまうことが記載されています。これがリビジョン保持することを妨げる原因となります。 AWS::ECS::TaskDefinition - AWS CloudFormation Use the AWS CloudFormation AWS::ECS::TaskDefinition resource for ECS. docs.aws.amazon.com 解決策：UpdateReplacePolicyを利用する “UpdateReplacePolicy”属性を利用して、”Retain”を指定しましょう。 UpdateReplacePolicy 属性 - AWS CloudFormation UpdateReplacePolicy 属性を使用して、AWS CloudFormation によるスタック更新オペレーション時にリソースの置き換えを処理する方法を指定します。 docs.aws.amazon.com 解決方法は、たったこれだけです。思ったより簡単ですね。 完成したCloudFromationテンプレート 以下のテンプレートを使用して、デプロイします。 AWSTemplateFormatVersion: 2010-09-09 Parameters: Env: Type: String AllowedValues: - TEST - STG - PROD Resources: # ================================ # ECS (Task Difinition) # ================================ ECSTaskDefinition: Type: "AWS::ECS::TaskDefinition" UpdateReplacePolicy: Retain #この記述を追加 Properties: Cpu: 256 ExecutionRoleArn: !Sub "arn:aws:iam::${AWS::AccountId}:role/ecsTaskExecutionRole" Family: !Sub "ECS-${Env}-helloworld-taskdef" Memory: 512 NetworkMode: awsvpc RequiresCompatibilities: - FARGATE ContainerDefinitions: - Name: helloworld Image: !Sub "${AWS::AccountId}.dkr.ecr.${AWS::Region}.amazonaws.com/helloworld-appliction:v1.0" LogConfiguration: LogDriver: awslogs Options: awslogs-group: !Sub "/ecs/ECS-${Env}-helloworld-service" awslogs-region: !Ref AWS::Region awslogs-stream-prefix: v1.0 PortMappings: - AppProtocol: http HostPort: 80 Protocol: tcp ContainerPort: 80 Name: helloworld-80-tcp ReadonlyRootFilesystem: false RuntimePlatform: CpuArchitecture: X86_64 OperatingSystemFamily: LINUX Tags: - Key: Name Value: !Sub "ECS-${Env}-helloworld-taskdef" ECSタスク定義の更新 上記でデプロイしたタスク定義を更新して、リビジョン2を作成することにします。 以下のテンプレートを使用して、スタックを更新します。 AWSTemplateFormatVersion: 2010-09-09 Parameters: Env: Type: String AllowedValues: - TEST - STG - PROD Resources: # ================================ # ECS (Task Difinition) # ================================ ECSTaskDefinition: Type: "AWS::ECS::TaskDefinition" UpdateReplacePolicy: Retain Properties: Cpu: 256 ExecutionRoleArn: !Sub "arn:aws:iam::${AWS::AccountId}:role/ecsTaskExecutionRole" Family: !Sub "ECS-${Env}-helloworld-taskdef" Memory: 512 NetworkMode: awsvpc RequiresCompatibilities: - FARGATE ContainerDefinitions: - Name: helloworld Image: !Sub "${AWS::AccountId}.dkr.ecr.${AWS::Region}.amazonaws.com/helloworld-appliction:v1.1" #コンテナイメージの更新 LogConfiguration: LogDriver: awslogs Options: awslogs-group: !Sub "/ecs/ECS-${Env}-helloworld-service" awslogs-region: !Ref AWS::Region awslogs-stream-prefix: v1.1 #ロググループの更新 PortMappings: - AppProtocol: http HostPort: 80 Protocol: tcp ContainerPort: 80 Name: helloworld-80-tcp ReadonlyRootFilesystem: false RuntimePlatform: CpuArchitecture: X86_64 OperatingSystemFamily: LINUX Tags: - Key: Name Value: !Sub "ECS-${Env}-helloworld-taskdef" タスク定義のリビジョン2が作成され、以前のバージョンも保持されていることが分かります。 注意事項 ・タスク定義のファミリー名は、慎重に名前付けを決定した後にデプロイすること タスク定義のリビジョンは、ファミリー名に基づいています。タスク定義を削除したとしても、内部でファミリー名が記録されているため、リビジョンを以前のものから引き継ぎます。リビジョンを”1″から採番したい場合は、異なるファミリー名で再作成することが必要です。 まとめ いかがだったでしょうか。以前のリビジョンのタスク定義をCloudFromationでも保持することができました。いざという時に、以前のリビジョンのタスク定義からコンテナを起動したいという要件も満たすことができます。 本記事が皆様のお役にたてば幸いです。 ではサウナラ～🔥

Catoクラウドにお客様拠点を接続する際、通常は専用機器であるCato Socketのご利用をおすすめしておりますが、別の方法として、お手持ちの物理ルータやファイアウォール機器からIPsecで接続することも可能です。 IPsecでの接続は、Socketに比べると機能が劣るのですが、既存の機器で接続できることから一時的な利用には有用です。IPsec接続時の機能制限については、以下の記事の「Socket/vSocketとIPsecの比較」にて紹介しておりますのでご参照ください。 Cato SSE 360 について Catoクラウドの「Cato SSE 360」「SSEライセンス」について説明します。 blog.usize-tech.com 2023.09.05 今回、テストとしてYAMAHAルータでのIPsec接続を行いましたので、設定内容や注意点をご紹介します。 接続前の事前確認 設定を行う前に、以下の情報を確認しておきます。 機器で使えるIPsecのパラメータを確認する Catoに限らず、異なる機器間でのIPsecの接続は難しいです。その理由は、IPsecでは暗号化方式をはじめ多数の設定項目があり、パラメータが両機器で完全に一致していないと接続に失敗するためです。機器によって項目の名前や実装が微妙に違ったりすることも原因のひとつです。 このため、CatoのIPsec接続時にも、まずは利用する機器の仕様を把握しておく必要があります。 CatoはIPsec IKEv1/v2の両方に対応しており、今回は一般的なv2の接続仕様をご紹介します。ご利用の機器がこれらのパラメータに対応しているかどうかと、各項目の設定コマンドを事前にご確認ください。 設定項目 Catoの対応パラメータ 認証方式 事前共有鍵 (Pre-shared key, PSK) のみ 暗号アルゴリズム (Encryption Algorithm) AES-CBC 128 / AES-CBC 256 / AES 128 GCM-16 / AES 256 GCM-16 ※AES-CBC 128および256は100Mbps未満の接続にのみ対応します。100M以上の場合はAES 128 GCM-16 または AES 256 GCM-16を使用してください。 ハッシュアルゴリズム (PRF Algorithm, Integrity Algorithm) SHA1 / SHA2 256 / SHA2 384 / SHA2 512 DHグループ (Diffie-Hellman Group) 2(1024bit) /  5(1536bit) / 14(2048bit) / 15(3072bit) / 16(4096bit) / 21(521bit ECP) 認証ID (Authentication Identifier) 原則IPv4。他にFQDN, Email, KEY_ID にも対応。 IKE SA(Phase1)のライフタイム 19,800 秒 Child SA(Phase2)のライフタイム 3,600 秒 ※2024年1月現在の仕様です。最新の情報はCato Knowledge Baseをご確認ください。 ※ライフタイムは2024年1月現在は変更不可ですが、近日中にCMAから値の指定ができるようになる予定です。 IPsecの冗長化構成を考える IPsec接続では、特定のPoPに対して接続するため、そのPoPで障害が発生すると接続不可となってしまいます。このため、 ロケーションの異なるPoPにSecondaryのIPsecを張っておくことが推奨 となっています。 今回は以下の構成でテストしました。PPPoE接続の回線1本を使い、東京とロンドンにIPsecを張ります。 それでは、実際に設定を行っていきます。 まずはPoP IPアドレスの取得 IPsecの接続先はCatoのPoPとなりますが、このPoPにて接続用の固定IPアドレスを取得する必要があります。PrimaryのPoPとSecondaryのPoPでそれぞれ取得します。 なお、Catoの推奨は、1つのSiteに対しに1つの固定IPを取得することですが、設定上は1つのIPアドレスに複数のSiteからIPsecを張ることも可能です。 IPアドレスの取得は、CMA(Cato管理画面)の Network > IP Allocation から行います。標準で3つまで取得可能で、4つめ以降は別途費用となります。 Siteの作成 続いて、IPsec用のSiteを作成します。Network > Site の「New」から作成します。 IPsec Siteの場合は、Connection Typeの選択で、「IPsec IKEv1」または「IPsec IKEv2」を選択します。どちらを利用するかはご利用の機器によりますが、今回利用するYAMAHA RTXシリーズはv1/v2両方対応のため、一般的なIKEv2とします。 Siteを作成すると、以下のように「IPsec」という設定項目がありますので、ここでIPsecの設定を行っていきます。 General 上記スクリーンショット、Generalのセクションでは、接続の基本設定を行います。 Connection Mode は、Cato側からIPsecを張りに行くかどうかの設定で、 通常は高速に接続するために「Bidirectional」とします 。「Responder Only」にした場合には、Catoは接続を受け付けるのみで、自分からは接続に行きません。 また、 Authentication Identifier は、接続相手をどの情報で識別するかの設定です。 通常はIPv4 です。Connection ModeをResponder Onlyにした場合には、他の選択肢も選べます。 Primary / Secondary 続いて、IPアドレス等の設定です。Primary/Secondaryともに設定項目は同じです。   Public IPの Cato IPに、PoPのアドレス をプルダウン選択します。今回はTokyoとLondonです。 Site IPは、拠点側のグローバルIPアドレス です。今回は回線が1本なので、Primary/Secondaryとも同じアドレスになります。 Private IPsは、BGPによるDynamic Routingを行う場合にPeer IPとして使用します。今回は使用しませんので空欄です。 Last-mile Bandwidthは、Siteの契約帯域 を指定します。 最後に、 Primary PSK, Secondary PSK を設定します。IPsec接続のパスワードとなるものです。8～64文字で、アルファベットの大文字小文字を区別します。機器によっては記号に対応していないことがあるため、アルファベットと数字での指定が無難です。 Init Message Parameters / Auth Message Parameters 暗号アルゴリズム等の設定です。 もっとも厄介な箇所ですが、 まずはすべてAuto設定とすることが推奨 となっています。ルータ側で方式を固定し、Cato側はAutoとすることで、設定をルータ側に合わせる意図です。Autoでうまく行かない場合には、エラーメッセージを見ながら調整していきます。エラーについては後述します。 なお、 Init MessageのDiffie-Hellman Groupだけは、AutoやNoneが設定できないため、利用する機器が対応している方式を選択し、設定します。 Routing 最後がRoutingのセクションです。 Initiate connection by Cato は、Cato側から接続を開始するかどうかです。 通常はONが推奨 です。 Network Ranges は、利用機器側の設定がポリシーベースのIPsecで、SAにNetwork Rangeが定義されている場合に、そのレンジを指定します。空欄の場合には、暗黙的にルートベースとして認識されます。 今回は空欄としています。 以上で、Cato側の設定は一旦完了です。 YAMAHAルータの設定 今回は以下の機器で動作を確認しています。先日EoLとなった機器ですが、Configは他のRTXシリーズもほぼ同じです。 ハードウェア YAMAHA RTX810 ファームウェア Rev.11.01.34 古い機器のため、以下の古めなパラメータを使用しました。最近の機種はより多くのアルゴリズムに対応していますので、Catoの対応範囲内でできるだけセキュリティの高い(数値の大きい)ものを選んでください。 設定項目 パラメータ 暗号アルゴリズム (Encryption Algorithm) AES-CBC 256 ハッシュアルゴリズム (PRF Algorithm, Integrity Algorithm) SHA2 256 DHグループ (Diffie-Hellman Group) 2(1024bit) IPsecサンプルConfig PPPoE等の設定を行い、Internetへ通信できることを確認の上、IPsec関連の設定を入れていきます。 tunnel select 1 tunnel name <ルータ上での表示名> ipsec tunnel 1 ipsec ike version 1 2 # IKEv2を利用すると明示的に指定する設定 ipsec ike group 1 modp1024 # DHグループ ipsec ike encryption 1 aes256-cbc # Phase1の暗号アルゴリズム ipsec ike hash 1 sha256 # Phase1のハッシュアルゴリズム ipsec sa policy 1 1 esp aes256-cbc sha256-hmac # Phase2の暗号・ハッシュアルゴリズム ipsec ike duration ike-sa 1 19800 # Phase1のライフタイム ipsec ike duration child-sa 1 3600 # Phase2のライフタイム ipsec ike keepalive use 1 on # Keepaliveを行う設定 ipsec ike keepalive log 1 off # Keepaliveのログを表示しない設定(大量に出るため) ipsec ike local address 1 <ルータのGlobal IPアドレス> ipsec ike local name 1 <ルータのGlobal IPアドレス> ipv4-addr ipsec ike remote address 1 <CatoPoPの固定グローバルIPアドレス> ipsec ike remote name 1 <CatoPoPの固定グローバルIPアドレス> ipv4-addr ipsec ike pre-shared-key 1 text <Pre-Shaerd Key文字列> ipsec ike proposal-limitation 1 on # 指定したアルゴリズム以外ではネゴシエーションしない設定 ip tunnel tcp mss limit auto tunnel enable 1 ipsec auto refresh on 上記でPrimary分の設定です。同様にtunnel2としてSecondaryの設定も投入します。 設定を忘れやすいのは「 ipsec ike proposal-limitation <tunnel番号> on 」です。 YAMAHAルータの仕様として、デフォルトではIPsecの設定不一致を解消するために、宣言したアルゴリズム以外も含め使えるアルゴリズムすべてを相手に提案します。その結果、Cato側が「想定と違うアルゴリズムが来た」とエラーを返してしまい、SAが確立しません。このコマンドを on に明示することで問題が解消します。 また、WANインターフェイス(今回はPPPoE接続を行うPPインターフェイスです)にて以下のフィルタを設定してください。IPsecの通信にて利用するプロトコル(ESP, UDP/500)の許可です。 ip filter <フィルタ番号> pass <CatoPoPの固定グローバルIPアドレス> <ルータのGlobal IPアドレス> esp * * ip filter <フィルタ番号> pass <CatoPoPの固定グローバルIPアドレス> <ルータのGlobal IPアドレス> udp * 500 ルーティングの設定にも注意点があります。 まず、以下のIPアドレスは必ずtunnelに向ける(Cato網へルーティングさせる)必要があります。 Catoの設備IPアドレス 10.254.254.1 / .5 / .253 Cato網内の他拠点のIPアドレスレンジ、モバイルユーザのIPアドレスレンジ 拠点のルーティング要件にもよりますが、通常は拠点内のすべての通信についてCato網を通すのが推奨ですので、以下のようなルーティングになるかと思います。 PrimaryのPoPに障害が発生した場合に備え、tunnel1がdownしてもtunnel2で通信継続できるように設定しておきましょう。 ip route default gateway tunnel 1 hide gateway tunnel 2 weight 0 # 基本的にすべての通信はtunnel1に向け、tunnel1のdown時はtunnel2を使う ip route <PrimaryのCatoPoPの固定グローバルIPアドレス> gateway pp 1 # CatoPoPとのIPsec確立にはpp1(PPPoEインターフェイス)を使う ip route <SecondaryのCatoPoPの固定グローバルIPアドレス> gateway pp 1 以上を設定したら、YAMAHAルータをInternetに接続し、接続できるかを確認します。 接続確認 IPsecが正常に張れているかどうかは、以下の方法で確認します。 YAMAHAルータでの状態確認 # show status tunnel <トンネル番号> 「トンネルインターフェースは接続されています」と出ていれば、正常にUPしています。 # show status tunnel 1 TUNNEL[1]: 説明: インタフェースの種類: IPsec トンネルインタフェースは接続されています 開始: 2024/01/29 18:38:23 通信時間: 21分6秒 受信: (IPv4) 105 パケット [9660 オクテット] (IPv6) 0 パケット [0 オクテット] 送信: (IPv4) 134 パケット [10872 オクテット] (IPv6) 0 パケット [0 オクテット] IKEキープアライブ: [タイプ]: rfc4306 [状態]: OK [次の送信]: 5 秒後 異常な場合には、「トンネルインタフェースは一度も接続されていません」と出たり、何も表示されなかったりします。 CMAでの状態確認 MonitoringのTopologyにて、Site Statusが Connected となっていることを確認します。 また、IPSEC DETAILS にて、PrimaryとSecondaryそれぞれの接続状況も確認できます。 接続できていない場合は、拠点が赤い表示となり、Site StatusはDisconnectedとなります。 また、IPsecの設定画面にて「Connection Status」ボタンを押すと、数秒した後、現在の接続情報が表示されます。待っても何も表示されない場合は、接続できていません。 正常に接続できたら、ルータのLAN側の端末から、他Siteやインターネットへの通信をご確認ください。 繋がらない場合のトラブルシュート 続いて、IPsecが繋がらないときの切り分け方法をご紹介します。 切り分けは時間がかかり、心が折れることもありますが、単純に鍵交換に一時的に失敗しているだけということも多いので、まずはトンネルのリセットをおすすめします。 トンネルのリセット YAMAHAルータ側からのトンネルリセット # ipsec sa delete all   コマンド入力後何も出ませんが、すぐにSAが作り直しされます。allではなく特定のSAのみ作り直したいときは、show ipsec sa で SA番号を特定し、allの代わりに番号を指定します。 Cato側からのトンネルリセット Primary/Secondaryそれぞれ、IPsecの設定画面にある「Reset Tunnel」ボタンからResetが可能です。 リセットし、数分待っても接続されない場合、一時的な問題ではないと考えられるため、トラブルシュートに進みます。 Cato側ログの確認 まずはCato側のログを確認してみます。接続できない方のtunnelで「Timeline」をクリックすると、Cato側のログがcsv形式でダウンロードされます。 もしここで 「File not found」とエラーが出てファイルがダウンロードされない場合、ログが存在しません。 接続が全く到達していないということになりますので、以下の点を確認します。 ルータがInternetに接続できているか ルータのipsec ike remote address で指定したCato PoPのグローバルアドレスが間違っていないか ルータのフィルタで、PoPとのesp, udp500の通信が破棄されていないか ルータからCato PoPのグローバルIPアドレスに対してPingが通るか CMAに設定した、ルータのグローバルIPアドレスが間違っていないか ログがダウンロードできた場合は、直近のエラー内容を確認します。 基本的にはルータとCatoのパラメータ不一致が原因となるため、何が不一致なのかを調べ、修正していく作業となります。 一例として、当社の検証にて確認したCato側のエラーメッセージをご紹介します。 認証情報の不一致 Auth payload doesn't match the calculated one - wrong psk? Auth payload doesn't match dropping this sa 認証情報が一致しないというエラーです。PSKやnameの設定が双方で異なっている場合に発生しますので、以下を確認します。 PSK(パスワード)がCatoとルータとで一致しているか、再設定してみて改善するか ルータ側のipsec ike local name, ipsec ike remote name に相手と自分のグローバルIPアドレスが正しく設定されているか、コマンド末尾の「ipv4-addr」が抜けていないか DHグループの不一致 DH group number in the KE property doesn't match the selected proposal [selected: 14, in KE payload: 5] ルータが最初に宣言したDHグループと、実際に通信してきたDHグループが違うというエラーです。 DH group GROUP_5_MODP1536 (5) in our proposal does not match DH group GROUP_14_MODP2048 (14) in peer's proposal 1 Catoが提案したDHグループと、ルータが提案してきたDHグループが違うというエラーです。 いずれの場合も以下を確認します。 Cato側とルータ側のDHグループ設定(ipsec ike group)が一致しているか YAMAHAルータに ipsec ike proposal-limitation <tunnel番号> on が設定されているか ※この設定が抜けていると、指定していないDHグループで通信してしまいます その他各種アルゴリズムの不一致 Encryption algorithm length AES_256 (256) in our proposal does not match encryption algorithm length AES_128 (128) in peer's proposal 1 PRF algorithm HMAC_SHA2_256 (5) in our proposal does not match PRF algorithm HMAC_SHA1 (2) in peer's proposal 1 Integrity algorithm HMAC_SHA2_256_128 (12) in our proposal does not match integrity algorithm HMAC_SHA1_96 (2) in peer's proposal 1 Catoが提案した各種通信方式と、ルータが提案してきたアルゴリズムが違うというエラーです。いずれの場合も、以下を確認します。 YAMAHAルータに ipsec ike proposal-limitation <tunnel番号> on が設定されているか ※この設定が抜けていると、指定していないアルゴリズムで通信してしまいます エラーが出ている設定項目について、Catoのアルゴリズム設定をAutoにして改善するか エラーが出ている設定項目について、Catoのアルゴリズム設定をルータと同じ値で固定指定にして改善するか エラーが出ている設定項目について、Cato・ルータ双方のアルゴリズム方式を他の方式に変えて改善するか すべて確認してもエラーが解消されない場合、Cato PoP側の問題であるかどうかの切り分けとして、他のロケーションのCato PoPのIPアドレスを取得し、そちらとtunnelが張れるかご確認ください。 (ご参考)YAMAHAルータ側確認方法 問題切り分けの際は、Cato側のログとあわせて、YAMAHAルータ側でも状況をご確認ください。 確認コマンドの例 show ipsec sa SAが確立できているかどうかを確認できます。以下はtunnelを2本張った場合の正常例です。1つのtunnelに対し、phase1で1つ、phase2で2つのSAが確立されます。 このコマンドを見ることで、phase1の確立で失敗しているのか、またはphase2で失敗しているのかの切り分けができます。 # show ipsec sa Total: isakmp:2 send:2 recv:2 sa sgw isakmp connection dir life[s] remote-id ----------------------------------------------------------------------------- 1 1 - ike - 17106 <東京PoPのグローバルIPアドレス> 2 2 - ike - 18598 <ロンドンPoPのグローバルIPアドレス> 3 2 2 tun[002]esp send 2398 <ロンドンPoPのグローバルIPアドレス> 4 2 2 tun[002]esp recv 2398 <ロンドンPoPのグローバルIPアドレス> 5 1 1 tun[001]esp send 906 <東京PoPのグローバルIPアドレス> 6 1 1 tun[001]esp recv 906 <東京PoPのグローバルIPアドレス> show ipsec sa gateway <tunnel番号> detail さらにSAの詳細情報を見るコマンドです。以下は正常例です。 正常に表示されていない箇所や、意図しない設定になっている箇所がないか確認します。 # show ipsec sa gateway 1 detail SA[1] 状態: 確立済 寿命: 15014秒 プロトコル: IKEv2 ローカルホスト: <ルータのグローバルIPアドレス>:<ポート> リモートホスト: <東京PoPのグローバルIPアドレス>:<ポート> 暗号アルゴリズム: AES256_CBC PRF : HMAC_SHA2_256 認証アルゴリズム: HMAC_SHA2_256_128 DHグループ: MODP_1024 SPI: <SPI文字列> 鍵 : <鍵文字列> ---------------------------------------------------- SA[5] 状態: 確立済 寿命: 1522秒 送受信方向: 送信 プロトコル: ESP (モード: tunnel) ローカルID: <ルータのグローバルIPアドレス> (IPv4_ADDR) リモートID: <東京PoPのグローバルIPアドレス> (IPv4_ADDR) 暗号アルゴリズム: AES256_CBC 認証アルゴリズム: HMAC_SHA2_256_128 ESN: DISABLE 始点トラフィック セレクタ (タイプ / プロトコル / ポート / アドレス) IPv4-range / any / 0-65535 / 0.0.0.0-255.255.255.255 終点トラフィック セレクタ (タイプ / プロトコル / ポート / アドレス) IPv4-range / any / 0-65535 / 0.0.0.0-255.255.255.255 SPI: <SPI文字列> 鍵 : <鍵文字列> ---------------------------------------------------- SA[6] 状態: 確立済 寿命: 1522秒 送受信方向: 受信 プロトコル: ESP (モード: tunnel) ローカルID: <ルータのグローバルIPアドレス> (IPv4_ADDR) リモートID: <東京PoPのグローバルIPアドレス> (IPv4_ADDR) 暗号アルゴリズム: AES256_CBC 認証アルゴリズム: HMAC_SHA2_256_128 ESN: DISABLE SPI: <SPI文字列> 鍵 : <鍵文字列> ---------------------------------------------------- show log 通常のログにもSA確立成功・失敗等のログが出ますので、エラー内容や、どこで失敗しているのかを確認します。 なお、以下の設定をしておくことで、より詳細なログ・デバッグ情報が表示されるようになります。 ipsec ike log 1 key-info message-info payload-info syslog debug on ※ログが大量になるため、正常に接続できた後はOFFが推奨です まとめ 以上、長くなりましたが、YAMAHAルータでのIPsec接続のご紹介でした。 検証時、パラメータを正しく一致させているつもりなのに不一致のエラーで繋がらず、かなり悩まされましたが、ほとんどがYAMAHA側の設定の不足や相違が原因でした。今回ご紹介したサンプルConfigは正常に接続できた後のものですので、どなたかの参考になりましたら幸いです。 感想として、PoPとの接続やルーティング、障害切り替わりをすべて自動で行ってくれる Cato Socketの楽さが身にしみました…。 何らかの事情でSocketが利用できずIPsec接続を行われる際には、なかなか苦労しますので、準備・検証に十分な時間を取ることをおすすめします。

最近健康診断から人間ドックにランクアップした、潮です。 普段AWSのデータベース系サービス、特にAmazon RDSやAmazon Aurora等のRDB系のサービスを中心に検証や構築、チューニング等々しています。 今回はちょっと変わったDBとして、Oracle社がAWS上で動かすDBとして提供している「MySQL HeatWave on AWS」をご紹介します。 MySQL HeatWave on AWSとは？ MySQL HeatWave on AWSは、OLTP系の処理はMySQLで捌き、OLAP系の処理は分析用にデザインされたHeatWaveノードにオフロードして捌く、という、OLTPとOLAPの両利きを目指したデータベースです。名前の通りAWS上で稼働するため、会社全体でAWSを基盤インフラとして全面採用している場合や、アプリはじめフロントエンドがAWS上にある場合に、レイテンシや通信セキュリティ上のメリットがあります。また、最近のアップデートで、MySQL HeatWave on AWS外からのインバウンドレプリケーションができるようになったことで、今あるMySQLに格納されているデータを分析にかけてみたい、という要望に対して、単にスレーブを追加する感覚で分析用DBを追加できるようになりました。 このMySQL HeatWaveは、元々はOracle Cloud Infrastructure（OCI）上で提供されているサービスでしたが、これがAWS上でも使えるようになりました、というのがMySQL HeatWave on AWSです。なお、on Azureも存在します。 アーキテクチャは以下の通りで、Oracle社管理のAWSアカウント上で稼働しているMySQL/HeatWaveノードに対して、カスタマーAWSアカウント（別にそれ以外でもいいですが）からアカウント越しにアクセスすることになります。 MySQLノードは通常のMySQL同様データを永続化ディスクに持ちますが、HeatWaveノードではインメモリです。全てのデータをHeatWaveノードに持たせる必要はなく、OLAP系処理が見込まれるテーブルのみHeatWaveノードにロードする、ということもできます。 全てのクエリは一度MySQLノードで受けるのですが、ここでオプティマイザがHeatWaveよりもMySQLで実行した方が早いと判断した場合は、たとえ対象テーブルがHeatWaveにロードされていてもMySQLノードで処理してくれます。 分析処理の高速化確認 MySQL HeatWave on AWSで分析処理がどの程度早くなるか、確認します。今回は、伝票処理でデータが大きく育ってしまってMySQLでは時間がかかるようになってきてしまった、という状況を想定します。クエリは実際にソフトウェア上で動いているものをベースにしており、処理の概要とレコードの概数は以下の通りです。 処理概要 対象テーブル内レコード数 特定条件ごとの仕訳伝票数出力 30,000,000 特定条件ごとの仕訳明細数出力 200,000,000 特定条件ごとの仕訳明細数出力＋除外条件 200,000,000 特定条件ごとの台帳残高出力 90,000,000 これらクエリを、MySQLとHeatWaveそれぞれで処理させた場合の処理時間は以下でした。 処理概要 MySQL（InnoDB） HeatWave 特定条件ごとの仕訳伝票数出力 9 s 0.2 s 特定条件ごとの仕訳明細数出力 44 s 0.4 s 特定条件ごとの仕訳明細数出力＋除外条件 55 s 0.4 s 特定条件ごとの台帳残高出力 210 s 0.2 s 処理時間は劇的に改善しており、クエリによっては1000倍以上のレスポンスです。これならほとんどの性能要求は満たしてくれそうです。 とはいえ、このくらいのレスポンス速度は、データウェアハウス系の製品であればそれほど特筆して早いというものでもありません。MySQL HeatWave on AWSのいいところは、この性能がOLTP用途で使っているDBそのもので出せること、フロントにMySQLがいるため従来のMySQL用に書かれたアプリでもアプリに大きな変更なく使えること、AWS上で動いているため他コンポーネントがAWS上にあるシステムでの性能上・セキュリティ上のメリットがあること、などです。 まとめ AWSではAmazon Athenaをはじめとして、MySQL中にあるデータを分析ツールからクエリできるようにするサービスもあります。しかしながら、既成のMySQL互換アプリがあって変更が困難な場合、Amazon Athena等の分析サービスでは十分な性能水準に達しない場合等、これまで分析を諦めざるを得なかったユースケースに対して、新たな選択肢として考えられそうです。

前回は、CSPMについて解説しましたが、今回はCWPPについて解説を行います。 CSPMをご存知ない方は、先に前回のCSPMの記事をご覧ください。 2024年最新版 CSPM（Cloud Security Posture Management）とは？ クラウドセキュリティ CSPM（Cloud Security Posture Management）について、2024年の最新情報を解説しています。 blog.usize-tech.com 2024.01.09 CWPPとは？ CWPPとは、 Cloud Workload Protection Platform （クラウドワークロードプロテクションプラットフォーム）で、日本語訳は「 クラウドワークロード保護プラットフォーム 」と訳されています。 クラウドワークロードとは、クラウドサービス上で実行される業務処理や作業（タスク）を意味し、具体的には、仮想マシン（IaaS）や、PaaS、コンテナ、サーバレス環境などで実行される処理やタスクのことです。 つまり、CWPPは、 クラウドサービス上の仮想マシン（VM）などのIaaS、データベースなどのPaaS、コンテナ、サーバレスなどに対して、セキュリティパッチ適用や脆弱性対策に不備がないかの監視を行い、リスクを検出した場合に、設定変更のアドバイスや、実際の設定変更を行うソリューション となります。 CWPPは、CSPMとクラウドセキュリティのツールとしては同じですが、CSPMはクラウドサービスの利用環境全体の保護を目的に、IaaS/PaaS環境におけるアカウントやサービスを対象にしていますが、CWPPは、クラウドワークロード保護を目的として、仮想マシン（VM）、コンテナ、サーバレスなど、IaaS/PaaSに限定せずに、様々なワークロードを対象にしています。 また、CSPMはクラウドサービスの提供するAPIを用いて設定情報やログを取得し、設定の確認をするのに対して、CWPPは、仮想マシンやコンテナなどにエージェントを導入し、セキュリティの監視をする場合が多いです。 セキュリティ設定不備や、OSのセキュリティパッチ適用状況、ミドルウェアの脆弱性有無、アンチマルウェアソフトのパターンファイル更新状況やスキャン状況をチェックします。 CWPPの背景 これまでのモノリシック（一枚岩）なサービス開発ではなく、最近のマイクロサービスアーキテクチャでは、複数の小規模かつ軽量で、互いに独立したサービスを組み合わせて実装する手法となっており、アプリケーションは、仮想マシンではなく、より利用するリソースが少ないコンテナ上で稼働する事例が増えてきています。 そのため、これまでのオンプレミスのサーバや、仮想マシンとは比較にならないほど多くのコンテナが稼働するようになっています。 コンテナは、パッケージ化が容易で、実行場所を選ばず、1台の仮想マシン上に、複数のコンテナを展開できることも可能となっており、仮想マシンから準備することも可能ですが、 CaaS（Container as a Serice） としてクラウドサービスとして提供されています。 次に、サーバレスアーキテクチャも増えています。サーバレスは、 FaaS（Function as a Service） とも言われますが、AWSの「Lambda（ラムダ）」、Azureの「Azure Functions」、GCPの「Google Cloud Functions」に代表されるこれまでの仮想マシンを利用せずに、アプリケーション開発を行う手法となります。 通常は、プログラムを実行するサーバが常に稼働し続けている必要がありますが、サーバレスでは、サーバを必要としないため、サーバ自体のコストが掛からず、運用や保守、利用のための準備期間の短縮が行えます。 サーバレスは、実際に仮想マシンを使っていない訳ではなく、クラウドサービスプロバイダー側が準備する仮想マシンを一時的に利用する形態となります。 このような マイクロサービスのような開発手法の変化や、クラウドサービスの進化により、コンテナやサーバレスの利用が増加しています 。 コンテナやサーバレスは、仮想マシンと大きくアーキテクチャが異なり、コンテナは常に稼働している訳ではなく、次々と新たに作成され、不要になるとすぐに削除されます。また、サーバレスはクラウドサービスプロバイダが準備する仮想マシンのため、利用者が管理することができないため、これまでのIT運用担当者の運用方法で対応が難しい場合が多いです。 IT運用者が管理ができず、脅威が見えなくなっても、セキュリティリスクは変わりません 。 コンテナやサーバレスについても、責任は、前回CSPMで記載したように「責任共有モデル」改め「責任分担モデル」にて、きちんと責任分界点が設定されており、殆どの責任については、利用者側が負うことになっています。 攻撃者により悪意のあるコンテナイメージがパブリックなレポジトリに登録され、それに気づかずに利用し、攻撃者が容易に不正侵入を許してしまう、コンテナの脆弱性をついて、ホストOSへアクセスされ不正プログラムを実行されることもあります。 コンテナ環境のKubernetesの設定ミスからホストOSを乗っ取られた事例もあります。 サーバレスでは、AWS Lambdaで提供されている脆弱性のあるWebサイトにて、URLに特定文字列を入れAWS Lambdaの情報を取得、さらにAWS Lambdaの環境変数を見るスクリプトでクレデンシャル情報（認証ID/パスワード、アクセスキー）を取得し、そのクレデンシャル情報を利用して管理者権限を付与すれば、AWS S3の情報を閲覧する可能となります。 AWS Lambdaは、これまでのように仮想マシンに、従来のセキュリティ対策ソフトウェアをインストールして仮想マシンごと守る方法は行えません。なぜなら責任分担モデルに則り、利用者は、クラウドサービスプロバイダーのAWS Lambdaの提供する仮想マシン（サーバレイヤ）にソフトウェアをインストールできないからです。 CWPPの5つの特徴 クラウドサービスのセキュリティ不備によるリスクを低減させるCWPPの主な機能としては、以下の5つとなります。 1. マルチクラウド対応 AWSだけではなく、Azure、GCPなどの複数のクラウドサービスプロバイダーをサポートしています。 マルチクラウド環境のクラウドワークロード（仮想マシン、コンテナ、サーバレス等）をサポートしており、管理コンソールか統一したポリシーにより一元的に管理することが可能です。 2.脆弱性管理 クラウドワークロードに存在する脆弱性を定期的に監視し、特定のセキュリティホールや問題を検出し、分析・管理を行う。 ソリューションによっては問題を修復する機能も含まれます。 3.侵入検知とランタイム防御 クラウドワークロードに対する不正アクセスや攻撃、疑わしい動作や、悪意のある動作・トラフィックを検出し、適切な対策、防御を行う。 4.コンプライアンス管理 様々な法規制や企業のセキュリティポリシーに従ってワークロードが運用されているかを監視し、ポリシー違反がないかを監視・管理します。また、今後新しく施行されるルールにもいち早く対応を行うことが可能になります。 5. 自動化とオーケストレーション セキュリティプロセスや対応策の自動化が組み込まれており、人手の対応を最小限に抑えつつ、効率的なセキュリティの実現が可能です。 イベントの自動対応やセキュリティタスクのオーケストレーションにより、迅速な対応が実現されます。 参考）クラウドセキュリティにおいて、CSPMを合わせてよく出現する言葉 CWPPと合わせてよく使われる言葉としては以下があります。CWPP、CIEM、CNAPPについては、別途改めて記事にする予定です。 ・ CSPM （Cloud Security Posture Manabement）：クラウドサービスの態勢（状態）の管理 ・ CIEM (Cloud Infrastructure Entitlement Management) ：クラウドサービスのアクセス権限の監視/管理 ・ CNAPP （Cloud Native Application Protection Platform）：CSPM/CIEM/CWPPを含むプラットフォーム。シーナップと呼ばれます。 ・ CASB （Cloud Access Security Broker）：クラウドサービスの利用を可視化/監視/適切なアクセス制限を実施。キャスビーと呼ばれます。 まとめ 前回CSPMについては、導入をいきなり検討するのではなく、脆弱性診断のようにまずはCSPMを利用したサービスを一度スポットでご利用されるのが良いのではないかと考えており、SCSKでは、 Palo Alto Networks（パロアルトネットワークス）社 のCSPM「 Prisma Cloud 」を採用したマネージドサービスを提供しておりますとお伝えしました。 CWPPについては、エージェント導入が必要なこともあり、現時点では残念ながらスポットでの診断サービス提供はしておりませんが、同じく「Prisma Cloud」がCWPPもサポートしておりますので、マネージドサービスを提供しております。 「Smart One Cloud Security」として、常時監視（Monitoring）するマネージドサービスをご提供しておりますので、ご興味をもたれた方は是非、お問い合わせください。 Smart One Cloud Security® パブリッククラウドのセキュリティ設定を診断/監視するマネージドCSPMサービスです。Palo Alto Networks社Prisma Cloud（CSPM機能）を使い易く、簡単に導入いただけます。 www.scsk.jp 前回の繰り返しですが、CSPMについては「 マルチクラウド設定診断サービス with CSPM 」として、スポットでの診断サービス（30万円～）を提供しておりますので、まずは自社のクラウドサービスの脆弱性診断（＝クラウド設定診断）を実施されてみるのが良いと思います。 定期的（半年や四半期毎）にスポット診断を実施することも可能ですし、もちろん常時監視するサービスもご提供しており、以下のサービス紹介ページに当社オリジナルの日本語での診断レポートサンプルもございますので、ご興味を持たれた方は、是非ダウンロードをお願いします。 マルチクラウド設定診断サービス with CSPM｜ SCSK株式会社 マルチクラウド環境のセキュリティ設定リスクを手軽に確認可能なスポット診断サービスです。独自の診断レポートが、運用上の設定ミスや設計不備、クラウド環境の仕様変更などで発生し得る問題を可視化し、セキュリティインシデントの早期発見に役立ちます。 www.scsk.jp また、CSPM、CWPPなどクラウドセキュリティをご紹介するセミナーを随時開催しておりますので、是非ご参画ください。 以下は、「情報セキュリティマネジメントフォーラム2024」にて『DX推進にかかせないクラウド利用、そのセキュリティ対策とは？ ～事例で学ぶ、ガバナンス強化手法と運用のポイント！～』で講演を行います。 情報セキュリティマネジメントフォーラム2024 実践事例と考えるセキュリティマネジメントの最前線伊勢丹ホールディングス。一般財団法人杏仁会、東亜建設工業株式会社、株式会社三越伊勢丹ホールディングスご登壇。情報セキュリティマネジメントフォーラム2024 r-management.jp

どうも、Catoクラウドを担当している佐々木です。 CatoユーザからPoP切替タイミングを制御したい、という問い合わせを多くいただきますので、 今回は PoPの切替に関する動作説明（仕様）と切替タイミングの変更  について紹介します。 ※画⾯は2024年1⽉時点のものです。機能アップデート等で変わる場合がありますので、あらかじめご了承ください。 PoP選択について 通常Catoクラウドへ接続を開始すると、自動的にユーザのロケーションに最も近い最寄りのPoPに接続されます。 また、優先して接続したいPoPを定義している場合、まず優先PoPとの接続を試みます。 詳細は、過去のブログ記事（「 経路選択の仕組み 」「 Site(拠点)を指定のPoPに接続する 」あたり）を参照ください。 Catoクラウド PoP (Point of Presence)について Catoクラウドの肝となる、インターネットを介してCatoクラウドのサービスを利用するためのアクセスポイント、PoP(Point of Presence)についてご紹介します！ Catoクラウドでは世界中に自前のPoPを配備しグローバルでサービスを展開しています。 blog.usize-tech.com 2023.11.13   PoPが切り替わるときはどんな時？ SocketとPoP間では、パケットロス、遅延などを常時監視しています。 常時監視する機能を「 Connection SLA 」と呼びます。 Connection SLAの監視項目の数値が閾値を下回ったりPoPとのトンネルが切断されると、Socketは通信復旧を自動で試みます。 この通信復旧手段の一つとして「 PoPの切り替わり 」も試みます。 つまり、 「 PoPの切り替わり 」が発生するのは、SiteとPoPとの通信が切断された時、 もしくは通信が不安定な時ということです。   PoPが切り替わるとどうなるの？ PoP切り替えのタイミングで、瞬断～数秒程度の通信が発生する可能性があります。 「 PoPの切り替わり 」は通信が不安定なタイミングで発生するため、切り替わることで通信状況が改善される可能性があります。   PoPの切り替わりタイミングを制御したい 「PoPの切り替わり」は、SiteとPoPとの通信が切断されたとき、または通信が不安定なタイミングで発生します。 通信が不安定なタイミングとは、前述の Connection SLA(監視機能)の閾値を下回っている状態を指します。 閾値によっては、PoPの切り替わりが頻繁に起こったり、逆に切り替わりに時間がかかることがあるため、閾値をチューニングしたい、というお客様もいらっしゃると思います。 監視項目（Connection SLA）の閾値を変更することで、 PoP切り替えタイミングについて 制御する方法をご説明します。   閾値のチューニング方法～Connection SLA～ 「 Connection SLA 」は以下から設定可能です。 「 Network 」＞「 Connection SLA 」を選択し、「 SLA Thresholds 」をクリックします。 デフォルトの状態だと以下の通り、「 Cato Smart SLA 」が選択されています。 デフォルト（Cato Smart SLA）の閾値は以下の通りです。 パケットロス：10% 遅延（レイテンシー）：300 ms 評価期間：10分間 ※パケットロスと遅延はor条件です。 つまり、 パケットロスが10%、もしくは遅延が300ms以上の状態が10分間発生すると切り替わりが発生します。   任意の設定をする場合は、「 Use custom SLA thresholds for Packet Loss and Latency 」を選択いただき、表示される項目に任意の値を設定ください。   注意点 回線冗長構成の場合 シングル構成の場合は、PoPとのトンネルがダウンしたり、パケットロスが100％になったり、「Connection SLA」の閾値を下回ればすぐにPoPが切り替わりますが、回線冗長構成の場合、すべてのアクティブリンクが上記状態にならないとPoPの切り替わりが発生しません。 ※　回線冗長構成：1台のSocketに複数のインターネット回線が接続されている構成   例えば、Activeポートのインターネット回線のみで障害が発生している場合、PoPは切り替わらずPassiveポートを利用します。 ※ ActiveポートとPassiveポートはそれぞれ独立してPoPとトンネルを常時接続していますが、Active/Passiveで必ず同じPoPを利用します。   閾値を厳しくすると逆に不安定になるかも 閾値を厳しくし過ぎると、頻繁にポートのステータスや接続PoPが変わり、逆に通信が不安定になってしまう可能性があります。 例えばフレッツ回線のようなベストエフォート回線をご利用の場合、数％のパケットロスが発生することは珍しくありません。 ご利用のインターネット回線の種類に応じて、適切な閾値を検討ください。   全Siteを対象とした設定と、Siteごとの設定が可能 上記の設定方法は、全Siteを対象とした設定になります。 特定のSiteのみ設定したい場合は、以下の方法で可能です。 「 Network 」＞「 Sitesから設定したいサイト 」を選択します。 「 Site Configuration 」>「 Connection SLA 」>「 SLA thresholds 」で「 Override Account Settings 」をチェックし、 任意の閾値を設定ください。   まとめ 今回のポイントは以下になります。 ・「PoPの切り替わり」が発生する時は、「SiteとPoPとの通信が切断された時」と「通信が不安定な時」 ・通信の不安定さは監視項目（Connection SLA）の閾値を下回るかどうかで判断 ・監視項目（Connection SLA）の閾値は手動で変更可能 本機能含め、弊社の 「Catoに関するFAQサイト」 にはCatoに関する多数の情報ございますのでご参考にください。 よくあるご質問 | Cato Cloud ケイトクラウド - SCSK Cato SASE Cloud Platform. powered by SCSK cato-scsk.dga.jp 最後に、SCSKではPoCから導入、運用まで幅広くCatoに関する支援を行っております。 本番構成への移行を見据えたPoC構成や、PoCでつまづきやすい点のサポートなど、豊富な導入実績を基にご支援いたします。 ぜひお声がけください！