こんにちは。SCSKのふくちーぬです。 DX(デジタルフォーメーション)が加速する現代のビジネス環境において、APIを公開しサービス連携を実現してAPIエコノミーを拡大していくことが重要となっています。これはUberやStripe、楽天等のパブリックAPIに限らずプライベート(社内)APIについても同様です。企業内に埋もれたデータ活用が叫ばれている中で、API の重要性はますます高まっています。プライベート API を組織内で効果的に運用するための実践的なアプローチとして、カスタムドメインの活用方法について解説します。 Amazon API Gatewayについて Amazon API Gatewayは、AWS が提供するフルマネージド型のAPI管理サービスです。REST、HTTP、および WebSocket の API を作成、公開、管理、保護するために使用されます。これによって、開発者はサーバレスアーキテクチャやマイクロサービスを構築する際に、スケーラブルで高可用な API を迅速にデプロイすることが可能です。 REST APIでは、HTTP API よりも柔軟かつ強力な認証・認可(IAM認証やLambda Authorizer、Amazon Cognitoと連携したOauth2.0認証)に始まり様々な機能を有しています。 高度な認証機能 API流量の制御 データ変換とバリデーション機能 バージョン管理、カスタムドメイン アクセスログ、実行ログのモニタリング AWS Lambdaを始めとしたマイクロサービスとの統合 本記事ではエンタープライズで頻繁に採用実績のある、REST型APIを取り上げています。 Amazon API Gateway（規模に応じた API の作成、維持、保護）| AWS Amazon API Gateway は、数回クリックするだけで、簡単に API の作成、配布、保守、監視、保護が行えるフルマネージドなサービスです。どのようなスケールにも対応するパフォーマンスを低コストでご利用いただけます。 aws.amazon.com デフォルトドメイン vs カスタムドメインの利用について 以下の観点でも解説していますが、エンタープライズの本番環境利用用途であればカスタムドメインを利用する方針がベストプラクティスです。パブリックAPIにおいても、同様です。デフォルトドメインだと、企業ブランドイメージや視認性が悪く使い勝手も良くはありません。 デフォルトドメイン curl https://<apiid>.execute-api.<awsリージョン>.amazonaws.com/<stage>/<resourcepath> カスタムドメイン curl https://fukuchiiinu.net/<stage>/<resourcepath> ガバナンスとコンプライアンス デフォルトドメインでは、迅速な導入による俊敏性は確保できるものの、ガバナンス管理が難しくなります。 カスタムドメインでは、ドメインの一貫性を保つことができ、社内ポリシーやセキュリティガイドラインに適した統制要件を満たすことができます。 運用ライフサイクル デフォルトドメインでは、ドメインについてはAWS管理されます。 そのため、API開発者者はPoC環境では迅速にプロトタイピング作成等に使用できます。一方、ドメインは一意のIDによって自動で割り当てられるためAPIを再作成した場合は、クライアントサイド開発者はURL等の変更を余儀なくされ運用負荷が高まります。 カスタムドメインでは、独自ドメインで用意できるため、APIの再作成や追加等があってもクライアントサイドは柔軟に対応することが可能です。ドメインについては、利用者側で管理するため社内発行CAを利用する場合は証明書の管理が必要になりますが、ACM発行証明書で代替できる場合は自動更新されます。 デフォルトドメイン利用時の構成 オンプレミス環境からから、RDSのデータベースに格納されている情報に安全にアクセスするシナリオを考えてみます。 オンプレミス業務アプリケーションがデータ取得のためのAPIリクエストを発行 Direct Connectを通じてた閉域網でアクセス VPCエンドポイントを経由してプライベート型のAPI Gatewayにリクエストが到達 バックエンドのVPC Lambdaを起動 Lambdaがプライベートサブネット内のRDSからデータ取得 取得したデータがオンプレミス環境のアプリケーションに返却 以下のように、デフォルトドメイン利用時は、VPCエンドポイント及びPrivate型のAPI Gatewayの構成で社内向けAPIやシステム間連携などで、安全な通信とアクセス制御を実現できます。 API Gatewayの各種APIエンドポイントを叩く用のVPCエンドポイントを作成する必要があります。  com.amazonaws.<リージョン>.execute-api VPCエンドポイントでのアクセス制御 本構成の場合、クライアントサイドからAWSへの玄関口はVPCエンドポイントとなります。そのため、VPCエンドポイントにアタッチされているセキュリティグループにてホワイトリスト形式でのアクセス制御をすることが重要です。 具体的には、クライアントサイド（オンプレミスのサーバやVPC内のEC2や、VPC Lambda等）のIPアドレスやセキュリティグループをホワイトリスト形式で登録することで、その他のクライアントからのアクセスをブロックすることができます。 Amazon API Gatewayでのアクセス制御 Amazon API Gatewayでは、リソースポリシーを利用して、特定のVPCエンドポイント経由でのみアクセスできるよう制御します。 許可ステートメントと拒否ステートメントを組み合わせることで、特定のVPCエンドポイントからのみAPIアクセスができるよう強固なセキュリティ制御をしています。 “*/*/*/*”のパターンについては、APIのID・ステージ・リソースパス・メソッドで制御することも可能です。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Deny", "Action": "execute-api:Invoke", "Resource": "arn:aws:execute-api:<awsリージョン>:<awsアカウントid>:*/*/*/*", "Condition": { "StringEquals": { "aws:SourceVpce": "<vpcエンドポイントid>" } } }, { "Effect": "Allow", "Action": "execute-api:Invoke", "Resource": "arn:aws:execute-api:<awsリージョン>:<awsアカウントid>:*/*/*/*", "Condition": { "StringNotEquals": { "aws:SourceVpce": "<vpcエンドポイントid>" } } } ] } TLS通信について 以下のプロセスで、デフォルトドメイン/カスタムドメインでAPIにアクセスする際のTLS通信が行われます。 DNS解決 クライアントがドメイン名の名前解決 オンプレミスのDNSサーバまたは、Amaozn Route53インバウンドエンドポイント経由でAmazon Route53 ResolverでIPアドレスに解決 TCP接続確立 3ウェイハンドシェイク TLSハンドシェイク ClientHello：クライアントサイドのブラウザまたは業務アプリケーションが対応しているTLSバージョンと暗号スイートのリストを提示 ServerHello：API GatewayがTLS1.2と特定の暗号スイートを選択 Certificate：API GatewayがAWS管理証明書またはACM証明書の情報を送信 KeyExchange：ECDHE鍵交換で共通の秘密鍵を安全に確立 Finished：双方が暗号化モードに切り替わり完了 証明書検証 クライアントサイドが証明書チェーンを検証 ドメイン名、有効期限、発行者を確認 データ交換 確立した暗号化通信にて、HTTPリクエスト/レスポンスを交換 接続終了 プライベート型のAPI Gatewayにおいては、TLSバージョンが強制されており、TLS1.2のみをサポートしています。（TLS1.3については、未サポート） 暗号スイートについては、下記表に記載されているように比較的近代的なものが利用できますが、こちらも制御はできません。 API Gateway で REST API カスタムドメインのセキュリティポリシーを選択する - Amazon API Gateway カスタムドメインのセキュリティポリシーを選択する方法について説明します。 docs.aws.amazon.com カスタムドメイン利用時の構成 プライベートAPIにおいて、カスタムドメインを使用する主要パターンを説明します。API Gatewayにおいて、カスタムドメインがサポートされていますので、ELB(ALB、NLB)のコストや管理負荷が不要であるパターン１が推奨構成です。 パターン１：VPCエンドポイント+Amazon API Gateway 本構成は、re:Invent2024で発表されたアップデートとなります。従来までは、Amazon API Gateway単体ではカスタムドメイン設定がネイティブにサポートしていませんでしたので、待望の機能拡張となります。 カスタムドメインを作成します ACM証明書をカスタムドメイン名と合わせて設定します ベースパスマッピングを行い、複数のプライベートAPIのステージをマッピングします カスタムドメイン名とVPCエンドポイント間で、ドメイン名アクセスを関連付けます Amazon API Gateway がプライベート REST API のカスタムドメイン名のサポートを開始 - AWS AWS の新機能についてさらに詳しく知るには、 Amazon API Gateway がプライベート REST API のカスタムドメイン名のサポートを開始 aws.amazon.com 本アップデートにより、証明書の管理をAmazon API Gatewayのみで完結することができ、TLS通信の一貫性を保ったエンドツーエンドの安全な通信が確立できるようになりました。 VPCエンドポイントでのアクセス制御 本構成の場合、デフォルトドメイン利用時と 同様 のアクセス制御します。クライアントサイドからAWSへの玄関口はVPCエンドポイントとなります。そのため、VPCエンドポイントにアタッチされているセキュリティグループにてホワイトリスト形式でのアクセス制御をすることが重要です。 Amazon API Gatewayでのアクセス制御 デフォルトドメイン利用時と 同様 のアクセス制御を実施します。Amazon API Gatewayでは、リソースポリシーを利用して、特定のVPCエンドポイント経由でのみアクセスできるよう制御します。 TLS通信について デフォルトドメイン利用時と 同様 のプロセスです。利用する証明書の管理が異なります。 パターン２：ALB＋VPCエンドポイント+Amazon API Gateway 本構成は、API Gateway単体ではカスタムドメイン設定がネイティブにサポートしていなかったため、Application Load Balancerを前段に挟む構成となっています。つまりALBは、リバースプロキシとして機能を提供します。そしてACM証明書は、ALBとAPI Gatewayで同一の証明書を関連付けます。 カスタムドメインを作成します ACM証明書をカスタムドメイン名と合わせて設定します ベースパスマッピングを行い、複数のプライベートAPIのステージをマッピングします リソースポリシーにてドメインに対するアクセス制御をします リスナーとしてHTTPS:443を持つALBを作成します。加えてALBとACM証明書を関連付けます。 ALBのターゲットグループとして、VPCエンドポイントを指定します 本構成は、ALBのDNSでAPIアクセスさせるため、DNS設定にCNAMEまたはALIASで登録をする必要があります。ALBのDNS名は複数の動的IPアドレスに変換される性質を持つつため、クライアントがhostsファイルでアクセスを想定している環境では、適さないことを理解してください。 ALBでのアクセス制御 本構成の場合、クライアントサイドからAWSへの玄関口はALBとなります。ALBにアタッチされているセキュリティグループにてホワイトリスト形式でのアクセス制御をしましょう。 VPCエンドポイントでのアクセス制御 VPCエンドポイントのセキュリティグループでは、ALBからのアクセスのみを受け付けることができるよう、ALBのセキュリティグループからのインバウンドアクセス許可をします。 API Gatewayでのアクセス制御 デフォルトドメイン利用時と 同様 のアクセス制御を実施します。 TLS通信について 本構成では、①クライアントサイド-ALB間の通信と②ALB-API Gateway間の通信でTLS終端されます。クライアントサイドでの証明書検証に加えて、API Gateway側でも正しく証明書検証を実施します。 パターン３：NLB＋VPCエンドポイント+Amazon API Gateway 本構成もパターン2と同様に、re:Invent2024以前でのカスタムドメインを利用する際の代替案の一つです。パターン2との違いとしては、Network Load Balancerに置き換わっています。 カスタムドメインを作成します ACM証明書をカスタムドメイン名と合わせて設定します ベースパスマッピングを行い、複数のプライベートAPIのステージをマッピングします リソースポリシーにてドメインに対するアクセス制御をします リスナーとしてTLS:443を持つALBを作成します。加えてNLBとACM証明書を関連付けます。 NLBのターゲットグループとして、VPCエンドポイントを指定します 本構成は、NLBの静的IPアドレスを利用することができます。オンプレミス内の複雑なネットワーク構成の場合、AWSへの通信時にもホワイトリスト形式で制御している環境もよく見かけますが、FW要件を満たすことができるのが特徴です。   NLBでのアクセス制御 本構成の場合、クライアントサイドからAWSへの玄関口はNLBとなります。2023/7までは、NLBにセキュリティグループをアタッチできなかったため、AWS Network FirewallやネットワークACLを利用する必要がありました。 セキュリティグループがアタッチできるタイプのNetwork Load Balancer（NLB）へ移行する手法[Elastic Load Balancing +Amazon Elastic Compute Cloud + AWS CloudFormation] セキュリティグループがアタッチされていないNetwork Load Balancer（NLB）をIPアドレスを保持したまま、セキュリティグループがアタッチできるNetwork Load Balancer（NLB）へ移行する手法をご紹介します。 blog.usize-tech.com 2024.02.13 現在はサポートされているため、NLBにセキュリティグループを必ずアタッチしてホワイトリスト形式でのアクセス制御をしましょう。 VPCエンドポイントでのアクセス制御 ALBの場合と同様です。 VPCエンドポイントのセキュリティグループでは、NLBからのアクセスのみを受け付けることができるよう、NLBのセキュリティグループからのインバウンドアクセス許可をします。 API Gatewayでのアクセス制御 デフォルトドメイン利用時と 同様 のアクセス制御を実施します。 TLS通信について 本構成では、①クライアントサイド-NLB間の通信と②NLB-API Gateway間の通信でTLS終端されます。しかし、NLBではTLSリスナーの場合、証明書の検証を実施しないという仕様があります。 ターゲットグループに TLS プロトコルが設定されている場合、ロードバランサーは、ターゲットにインストールした証明書を使用して、ターゲットと TLS 接続を確立します。ロードバランサーはこれらの証明書を検証しません。したがって、自己署名証明書または期限切れの証明書を使用できます。 Network Load Balancers のターゲットグループ - エラスティックロードバランシング Network Load Balancer のターゲットグループを設定する方法について説明します。 docs.aws.amazon.com そのため、通常通りクライアントサイドではNLBに関連付いた証明書の検証は実施します。NLBではSNI自体は転送しますが証明書を検証しないため、TLSパススルーで動くということになります。つまり、NLBでは正規の証明書を関連付けて、API Gateway側では異なる証明書（期限切れの証明書など）を関連付けていても通信が確立してしまいます。 NLBとAPI Gatewayで関連付けている証明書が異なる場合でも、APIリクエスト/レスポンスが成功してしまいますので注意する必要があります。 このようなリスクを最小限に抑えるために、証明書を不用意に変更されないような仕組みとして、予防的統制と発見的統制を取り入れた多層防御を導入することもできます。 　予防的統制 　AWSのIAMポリシーによる権限制御 　CloudFormationテンプレートによる一元的な管理 　発見的統制 　Config+Lambdaのカスタムルールによる継続的な監視 or EventBridge+CloudTrailによる変更検知 　証明書が不一致になった際の自動修復ルール 　アラーム通知 ログの取得 API Gatewayでは、アクセスログ及び実行ログをCloudWatchLogsへ出力できるので、どちらもONにします。 API Gatewayのアクセスログ アクセスログはセキュリティ監査とトラブルシューティングのために必須です。デフォルトのログ形式に加えて要件に併せて追加のパラメータを設定します。 { "requestId":"$context.requestId", "ip": "$context.identity.sourceIp", "caller":"$context.identity.caller", "user":"$context.identity.user","requestTime":"$context.requestTime", "httpMethod":"$context.httpMethod","resourcePath":"$context.resourcePath", "status":"$context.status","protocol":"$context.protocol", "responseLength":"$context.responseLength" } 例えばXrayによるAPIの可視性、WAFによるAPIのL7防御をしている際は、追加のパラメータを設定します。 API Gateway のアクセスのログ記録のための変数 - Amazon API Gateway 変数のアクセスのログ記録などのリファレンス。 docs.aws.amazon.com ALB/NLBのアクセスログ 加えて、ALB/NLBではアクセスログを取得できるため、アクセスログをS3に出力します。 Application Load Balancer のアクセスログ - エラスティックロードバランシング Elastic Load Balancing が提供するアクセスログを使用して Application Load Balancer を監視する方法について説明します。 docs.aws.amazon.com Network Load Balancer のアクセスログ - エラスティックロードバランシング Elastic Load Balancing が提供するアクセスログを使用して Network Load Balancer を監視する方法について説明します。 docs.aws.amazon.com ALB/NLBのアクセスログでは、API Gatewayのアクセスログ・実行ログでは取得できない下記の情報を取得することができます。 ・リクエストサイズ（received_bytes / received_bytes） ・レスポンスサイズ（sent_bytes / sent_bytes） ・TLSプロトコルバージョン（ssl_protocol / tls_protocol_version） ・暗号スイート（ssl_cipher / tls_cipher） リクエスト/レスポンスサイズを継続的にモニタリングしておくことで、バッファーオーバーフロー攻撃/データ流出/DDoS攻撃等の兆候を捉えることができます。これに加えてWAFのリクエストヘッダやボディ検査をすることで、異常なリクエストについてBlockすることが可能となります。 また暗号化プロトコルと暗号スイート情報を取得しておくことで、脆弱性のある暗号化設定がされていないか継続的に監視することができます。 API Gatewayの実行ログ 実行ログでは、リクエスト/レスポンスのパラメタータ・ボディの記録に加えてバックエンドのエラー情報も含まれるものになります。 エンタープライズ利用において、実行ログでは”データトレース”はオフに設定して、”エラーと情報ログ”のみ記録します。 OWASPのAPIセキュリティに関する文書や、AWS公式ドキュメントにおいても、 ログ内に機密情報（個人情報やデータペイロード）に記録されないように設定するように との記載があります。 Error messages include stack traces, or expose other sensitive information API8:2023 Security Misconfiguration - OWASP API Security Top 10 The Ten Most Critical API Security Risks owasp.org API Gateway での CloudWatch による REST API のログの設定 - Amazon API Gateway Amazon API Gateway で CloudWatch によるログを設定する方法について説明します。 docs.aws.amazon.com 最後に いかがだったでしょうか。 企業内のデータ分析やデータ連携をするニーズが増えている中、プライベート APIは安全かつ効率的な基盤となります。 本記事で紹介したベストプラクティスを活用して、エンタープライズ固有の要件に沿った最適なプライベートAPIを実装いただけますと幸いです。 本記事が皆様のお役にたてば幸いです。 ではサウナラ～🔥

こんにちは　ＳＣＳＫ　池田です。 前回は LifeKeeperのプロダクトサイクル（サポートフェーズ） について解説しましたが、そのサポート契約をするとどのように問い合わせすることができるのかを解説します。 サポートには「サイオスサポート」と「パートナーサポート」があります まず問い合わせの前に、サポートを契約する際に「サイオスサポート」か「パートナーサポート」かによって問い合わせ方法が異なります。 まずは以下の絵をご覧ください。 サイオスサポート は、 お客様から直接サイオステクノロジーのサポート窓口 に問い合わせしていただきます。 パートナーサポート は、 SCSKのようなSI&サポートパートナーが間に入り 、お問い合わせに対応します。SI&サポートパートナーで回答が難しい場合は、SI&サポートパートナーがサイオステクノロジーに問い合わせをエスカレーションします。 現在のご契約がどちらのサポートになっているかは、サポート証書の「５．サポート窓口」に書いてあります。 ※以下はサポート証書のイメージ図となります。 サイオスサポートかパートナーサポートかによって問い合わせ先が異なります サポート形態に、サイオスサポートとパートナーサポートという種類があることをご理解いただいたと思いますが、それぞれ問い合わせ先が異なります。 サイオスサポートの場合 上述した「５．サポート窓口」に記載のリンクからお問い合わせサイトに移動してください。 https://bccs.sios.jp/contact/ 　（2025/3/28 現在） ※24/365のサポートを提供する「Premiumサポート」や「拡張Premiumサポート」、「拡張Premium＋＋サポート」をご契約のお客様には、上記フォームとは別の連絡先が通知されますので、メーカーからの案内にご注意ください リンクをクリックすると以下のような画面が表示されますので、サインインIDをお持ちの方は赤枠の「お問い合わせフォームへ」をクリックしてください。 ※サインインIDをお持ちでない場合は、以下画面最下部の「サインインIDを登録する」からサインインID作成手続きに進んでください。 問い合わせしたい時に慌てないように予めサインインIDを作成しておくことをお勧めします。 すると以下のログイン画面が表示される為、メールアドレスとパスワードを入力し「サインイン」をクリックしてください。 ログインに成功すると「購入後のお問い合わせ」画面が表示される為、必要事項を記入の上、「送信」をクリックすることで問い合わせすることができます。 この際にサポート証書の右上に記載されている「PSC No.」を入力してください。これによりどの契約のお問い合わせかが紐づけられます。   パートナーサポートの場合 パートナーサポートの場合は、パートナー会社でそれぞれ異なりますが、ＳＣＳＫの場合は「LK@scsk.jp」宛にメールにてお問合せいただく形式になります。 お問い合わせいただく際のメール本文には、以下の内容を必ず書いていただくようお願いします。 ・PSC No.　※サポート証書に記載 ・お客様名　※サポート証書に記載 ・お問い合わせ内容   まとめ 今回は、LifeKeeper購入後の問い合わせ方法について、また問い合わせにはサイオスサポートとパートナーサポートがあり、それぞれ問い合わせ方法が異なるという点について解説させていただきました。 ・サポートには「サイオスサポート」と「パートナーサポート」がある ・サポート種類により問い合わせ方法が異なる ・サイオスサポートの場合は、予めサインインIDを作成しておくこと   詳しい内容をお知りになりたいかたは、以下のバナーからSCSK LifeKeeper公式サイトまで

みなさん、こんにちは。SCSKの津田です。 先日AWSクラウド環境にてLifeKeeperの構築を行っていたところ、Amazon Route 53のリソース作成ができない事象が発生しました。 当初は単なるエラー対応で解決するかと思っていましたが、要件定義レベルの見直しが必要になる事態に発展してしまいました… 今回はその体験記を共有いたします。 本記事がLifeKeeperでRoute 53リソースを作成予定の方、また同様の問題が発生して困っている方にとっての参考になれば幸いです。 前提(構成について) まず、前提としてLifeKeeperの構築を行っていた環境の構成をお話します。 第４回　【LifeKeeper】AWSでは仮想IPアドレスが使えない！？をこうして解決する！！ でもお伝えした通り、 AWS環境では仮想IPアドレスの機能が提供されていないため、今回の環境では、Amazon Route 53を利用した接続方式を採用しました。 そのためLifeKeeperでは「Recovery Kit for Route 53」でAmazon Route 53リソースを作成することにより、Amazon Route 53のホストゾーン上の一部レコードを管理し、VPC外のクライアントからクラスタへの接続を冗長化する構成で環境構築を進めていました。 <イメージ図＞ ■OS：Redhat Enterprise Linux release 8.6 ■LifeKeeper：LifeKeeper for Linux Version 9.8.0 Amazon Route 53リソースの作成ができない！ LifeKeeperGUI画面でAmazon Route 53リソースの作成を進めていたところ、 プライマリサーバでのリソース作成時に以下のような画面が表示され、先に進めなくなってしまいました。 メッセージによれば複数のゾーンが該当したとのこと… ＜GUI表示画面＞ ※上記画面はRoute 53リソースの作成でプライマリサーバのリソースタグ名を設定し、「Create」ボタンを押下した後に出力されました。 ※上記画面で「Cancel」を押すとRoute 53リソースの作成は終了し、入力していたRoute 53リソースの設定は初期化されてしまいます。 メッセージの原因 メッセージについてサイオステクノロジー社が公開するオンラインドキュメントを確認しましたが、 関連した記述が見当たらず対処できなかったため、サイオステクノロジー社のサポート窓口へ問い合わせを行いました。 その結果、 メッセージの原因は「同名のホストゾーンが存在している」ことであり、これによりRoute 53リソースが作成できないことが分かりました。 LifeKeeperでRoute53リソースを作成する際、対象のホストゾーン(ドメイン)を設定しますが、IDではなく名前で識別する仕様上、ホストゾーン名は一意である必要があるようです。 メッセージの通り、今回の環境ではパブリックホストゾーンとプライベートホストゾーンで同名のホストゾーンを2つ作成していました。 その後の対応 サポート窓口からは対応案として、重複しているホストゾーンのうちどちらか一方を削除または名前変更することを提案頂きました。 しかしこれらホストゾーンは既に稼働中の他システムでも使われており、名前の削除や変更、クラスタ用に別のホストゾーンを作成することは難しく、、、 様々な観点で検討した結果、今回の環境ではRoute53を用いた接続方式は利用せず、 第８回　AWS外からAWS内のHAクラスターシステムへどう接続する！？ ～ LifeKeeper ～ にてお伝えしたような、ルートテーブル+Transit Gateway経由を用いた接続を行う方針へ大きく変更となりました。 皆さまもご注意を！ 今回名前が重複していたホストゾーンは、それぞれパブリックホストゾーンとプライベートホストゾーンのtypeで作成しており、 ホストゾーンは同名ではあるものの異なる範囲で機能しています。 他の環境においても同様にホストゾーンを作成するケースは珍しくないかと思います。 しかし、 ホストゾーンの重複が解決できない場合、LifekeeperのRoute53リソースの作成ができなくなってしまうので、 要件定義段階からの注意 が必要です。 LifekeeperのRoute 53リソースの作成ができない場合、クライアントからサーバへのRoute 53を用いた接続を冗長化できず、構成の見直しが発生する恐れがあります！！ なお今回起きた問題については、サイオステクノロジー社と連携をとり、LifeKeeperのオンラインマニュアルに注意書きを載せて頂くことになりました。Recovery Kit for Route 53の要件に以下のように記載頂いています。 パブリックホストゾーンとプライベートホストゾーンで同名のホストゾーンが存在しないことを確認してください。同名のホストゾーンが存在するとRoute53リソースの作成に失敗します。 (上記は2025年3月時点での記載) ※LifeKeeper for LinuxではVersion 9.6.0以降のマニュアルに記載 ※LifeKeeper for WindowsではVersion 8.9.0以降のマニュアルに記載 また、現状LifeKeeperのRoute 53リソース作成ではホストゾーンを名前で指定しておりますが、 今後はIDで指定できるように検討頂くことを、 サイオステクノロジー社の開発部隊 へ依頼しました。 このようにSCSKのLifeKeeperチームではサイオステクノロジー社と連携をとりながらLifeKeeperの改良にも努めております。 まとめ 今回はLifeKeeperでRoute 53リソースの作成ができなかった事象を体験記としてお伝えしました。 クライアントとクラスタ間の接続方式で大幅な見直しが発生する事態にもなりかねませんので、 Route53の接続方式をとる場合は、要件定義段階から以下にご注意ください！ ・Amazon Route 53で同名のホストゾーンが複数存在する場合、LifekeeperでRoute 53リソースの作成ができない。  　(=クライアントからクラスタサーバへのRoute 53を用いた接続が冗長化できなくなる。)   詳しい内容をお知りになりたいかたは、以下のバナーからSCSK Lifekeeper公式サイトまで

皆さん、こんにちは！USiZEサービス部第一課の黄です。 これまでの記事では、Rubrikのランサムウェア対策や機密データ検知など、主要な機能についてご紹介してきました。 Rubrikは バックアップ&復元からバックアップデータの活用までデータ管理 に特化したIT企業です。 「まだ読んでいない！」という方は、ぜひ以下の記事もあわせてご覧ください。 Rubrikとは？クラウド＆オンプレにも対応する次世代バックアップ管理を紹介 – TechHarmony Rubrikのランサムウェア対策：仕組みとシミュレーションで確認 – TechHarmony Rubrik Sensitive Data Discoveryとは？機密データを簡単に管理・可視化する方法 – TechHarmony さて、今回は少し視点を変えて、「Rubrikとクラウドサービスの連携」にフォーカスしたいと思います。 Rubrikは複数のクラウドプラットフォーム（例：AWS、GCP、VMWare）との連携も対応していますが、 今回は特に利用者の多い「 AWSとの連携 」に絞ってご紹介します。 Rubrikをクラウド環境で活用したいと考えている方は、ぜひ最後までチェックしてみてください！ RubrikとAWS連携の概要 AWSでは、 EC2、S3やRDSなどの多様なリソースを RSC（Rubrik Security Cloud）上でまとめて保護・管理する ことが可能です。 RSC（Rubrik Security Cloud）は、Rubrikが提供するクラウドベースの統合管理プラットフォームです。 今回の記事では、 EC2インスタンスのバックアップ管理 を中心にご紹介していきます。 上図は、RSCを使ってAWSのEC2をバックアップ・管理する流れをまとめたものです。 大きく「一次バックアップ」と「二次バックアップ」の 2 段階に分かれます。 一次バックアップ段階 Rubrikは API経由で EC2インスタンスに対してバックアップデータを取得します。 EC2 の AMI（Amazon Machine Image）や EBS（Elastic Block Store） に保存されます。 ただし、AMI や EBS は ストレージコストが高め で、 長期保存には不向き というデメリットがあります。 二次バックアップ段階 Rubrik Exocompute（次の章で説明） により、取得したバックアップデータを S3バケットにアーカイブ することで、 コストを大幅に抑えながら長期保存 することが可能になります。  ※ S3 は「安くたくさん保存できる場所」とイメージしてもらえるとわかりやすいかもしれません。 RubrikとAWS連携の検証レポート 本章では、上の図にある 一次バックアップから二次バックアップまでの一連の流れ を、 実際の操作手順・設定画面のスクリーンショットとともに、わかりやすく紹介 していきます。 大きな流れとしては、以下の3ステップで構成されています： Rubrik と AWS アカウントの連携 一次バックアップの取得 二次バックアップの取得 この流れに沿って、それぞれのステップを以下で詳しくご紹介していきます。 1. Rubrik と AWS アカウントの連携 まずは、RSC上でAWSアカウントを登録します。 RSC の「 ワークロードの追加 」画面から AWS EC2 を選択すると、下図のように 2 種類の登録方法が表示されます。 CloudFormation テンプレート（CFT）を使用する方法 手動で IAM ロールなどを設定する方法 今回の検証では、より便利な CFT を使用する方法 を選択しました。 次に、RSC 上で登録したい AWS アカウント と リージョン（Region） を設定すると、Rubrik 側で CloudFormation テンプレート（CFT）が自動生成されます。 ここで設定が必要なのは以下の3項目です： アカウントID ：AWS側のIDで、RubrikとAWSを紐づけるために使用します。 アカウント名 ：AWS側とは無関係で、RSC上で識別しやすくするための任意の名前です。今回は「 test-kou 」です。 リージョン ：今回は「東京」を選択しました。 CloudFormation テンプレート（CFT）をダウンロードし、 AWSのCloudFormation にアップロードしてスタックを作成します。 上の図に示すように、Rubrikから作成してくれたCFTに三つの項目があります。 CrossAccountRole ：Rubrik が AWS リソースにアクセスするための IAM ロールです。 EC2ProtectionPolicy ：EC2 のバックアップを実行するために必要な権限を定義したポリシーです。 RubrikSecurityCloudNotifier ：AWS アカウントの連携情報を Rubrik 側に通知するための仕組みです。 スタックの作成が完了すると、Rubrik 側で連携が自動的に完了し、RSC 上にも登録済みとして反映されます。 2. 一次バックアップの取得 次は、 一次スナップショットの取得 についてご説明します。 前章の RubrikとAWS アカウントの連携 により、すでに AWS アカウントとの接続は完了しており、CloudFormation テンプレート（CFT）を通じてRSC側に EC2 操作の権限も付与されています。 この上で AWS 上に EC2 インスタンスを作成すると、 自動的に RSC に反映され 、管理対象として一覧に表示されます（下図参照）。 ※ kou-test-rubrikは事前にAWS側で作成されたEC2インスタンスです。 RSC の画面上からkou-test-rubrikをクリックして、「 オンデマンドスナップショット 」を実行するだけで、スナップショットの取得が可能です。 この操作により、 Rubrik が自動で EC2 の AMI および EBS のスナップショットを作成 してくれます。 API ベースで処理されるため、特別な手作業や設定は必要ありません。 少し時間が経つと、下図のように、 EC2のAMIやEBS スナップショット が AWS 上に作成されていることが確認できます。 同時に RSC上 にもバックアップデータとして反映されます。 3. 二次バックアップの取得 実際、 一次バックアップの取得だけでも、RSC 上でバックアップを扱うことは可能 です。 ただし、一次スナップショットでは EC2 の AMI や EBS をそのまま保持 するため、保存期間が長くなると コストが高くなる という課題があります。 この課題を解決するために用意されているのが、 二次バックアップ です。簡単に説明すれば、 取得したバックアップデータをS3などのストレージにアーカイブする ことで、コストを抑えながら長期保管を実現する仕組みです。 二次スナップショットを利用するには、Rubrik 側でいくつかの設定が必要です。主に以下の3点になります： Rubrik Exocompute の設定 アーカイブ先の設定 SLA ドメインの設定 Rubrik Exocompute の設定 Rubrik Exocompute とは、 RubrikがAWS側でEKS（Elastic Kubernetes Service）を使って一時的な処理用リソースを自動で立ち上げる仕組み です。 この機能を設定することで、バックアップデータの転送や整形といった処理を Rubrik が AWS 上で自動的に行えるようになります。 設定方法については、「 Rubrik と AWS アカウントの連携 」の章と同様に、RSC 側で CloudFormation テンプレート（CFT）を生成し、それを AWS 側で CloudFormation のスタックを更新することで完了します。 上図に示すように、先ほど連携した「 test-kou 」AWSアカウントについては、Exocomputeがまだ設定していません。 そのため、既に連携済みの AWS アカウントに対して、Exocomputeを操作するための権限を付与する必要があります（下図参照）。 権限の管理方法としては、以下の 2 つのオプションがあります： Rubrik Managed ：Rubrik が EKS を自動的に作成・管理します Custom Managed ：自分たちで用意した既存の EKS クラスタを使用します 今回は Rubrik Managed を選択しました。 次には、自動的に生成されたCFTにより、AWS 側で CloudFormation のスタックを更新します。 更新が完了すると、上図のように CFT によって 4 つの新しいリソースが自動で作成されます。 それぞれ Rubrik が一時的に処理用サーバー（EKS）を起動し、必要な操作を実行するために使われるものです。 AWS側での作成が完了すると、RSC 側にもExocomputeが自動的に反映されます。 ※ 上図のとおり、Exocompute の設定には VPC の情報も含まれています。設定時にどの VPC を使うかは任意で選べますが、今回は検証で一次バックアップの段階と同じVPCを指定しました。 アーカイブ先の設定 次に、 二次バックアップとしてバックアップデータをどこに保管するか を設定します。 保管先には、オンプレミスのストレージやクラウド上の S3 バケットなどを選択できますが、今回の検証では AWS S3 を指定しました。 具体的な操作は、大きく2つのステップに分かれます。 AWS アカウントに対して S3 関連の操作権限を付与します。 その後、RSC 上でアーカイブ先として S3 バケットを設定します。 ※ S3 バケットは Rubrik 側で自動的に AWS に作成されるため、ユーザーが手動で準備する必要はありません。 まず、既存の「 test-kou 」AWSアカウントに対して、S3 関連の操作権限を付与します。 今回の検証では S3 をアーカイブ先として選択するため、下図のように「クラウドネイティブロケーション」を選択します。 次に、生成された CFT を用いて CloudFormation のスタックを更新すると、下図のように新たな権限が 1 つ追加されていることが確認できます。 ※ 「CloudNativeArchivalLocationPolicy」と呼ばれますが、今回はアーカイブ先として S3 を選択しているため、実際には S3 の操作に関する権限です。 権限追加した後に、RSC側でアーカイブ先（S3 バケット）を設定します。 上図に示されている 「kou-test-s3」は、RSC 側で設定したアーカイブ先の名前 です。一方、 「rubrik-kou-test-location」は、AWS 側に自動作成されるS3バケットの名称 になります。 また、 S3バケットに保存されるオブジェクト （今回の場合はバックアップデータ）については、 6種類のストレージクラスから選択できます。 ただし、S3 のバックアップデータ以外の用途では、上位 4 種類のみが選択可能です。 なお、ストレージクラスは上にあるものほど高コストで、下に行くほど低コストになります。 設定が完了すると、AWS 側にも正しく反映されていることが、下図から確認できます。 現時点では Exocompute がまだ動作していないため、S3 バケットの中身は空のままです。Exocompute を動かすには、SLA ドメインの設定が必要です。 SLAドメインの設定 SLAドメインとは、「どのくらいの頻度でスナップショットを取得するか」「どこにアーカイブするか」「どのくらいの期間保存するか」など、バックアップに関するルールをまとめたポリシーのことです。 SLAドメインをEC2インスタンスに適用することで、Exocomputeが実際に動作し、バックアップデータのアーカイブ処理が実行されるようになります。 まずは、SLAドメインを新規作成します。 SLAドメインの設定対象として「 AWS EC2/EBS 」を選択します。 ※ 対象によって設定できる項目が異なるため、適切な対象を選ぶ必要があります。 次に、バックアップデータを取得する 頻度と、保持期間 を設定します。 ※ 保持期間は、一次バックアップ・二次バックアップに関係なく、バックアップデータ全体の保存期間を指します。 あらかじめ指定したバックアップ全体の保持期間は 7 日間のため、 ローカルストレージ（一次バックアップの保存先：AMI や EBS）での保持期間も 0～7 日の範囲で設定できます。 今回は「1日」を設定しました。 つまり、バックアップデータは取得後、1 日間 AMI や EBS に保存され、その後自動的に削除される形になります。 なお、今回は検証のため、 「インスタントアーカイブ」 をクリックしたため、バックアップデータ取得のタイミングで、すぐに二次バックアップ先（S3 バケット）にもアーカイブされます。 インスタントアーカイブを使用しない場合は、バックアップデータはまず一次バックアップ（AMI や EBS）として 1 日間保持され、その後、Exocompute の処理を通じて S3 バケットに転送され、残りの 6 日間保持される流れになります。 あわせて、先ほど作成したアーカイブ先「kou-test-s3」もここで指定します。 最後、SLAドメインの名前を設定します。 バックアップの結果確認 ここまでの設定で、一次バックアップから二次バックアップまでの準備がすべて完了しました。 あとは、 作成した SLA ドメインを対象の EC2 インスタンスに割り当てるだけで、Rubrik が自動的に一次バックアップ（AMI・EBS スナップショット）を取得します。さらに Exocompute を経由して、バックアップデータを指定した S3 バケットにアーカイブしてくれます。 まず、指定したEC2インスタンス「test-kou」に対して、SLAドメインを割り当てます。 SLAドメインを割り当てた後、しばらくすると画面上に反映されます。 AWS側の S3 バケットにバックアップデータのオブジェクトが作成されていることが確認できます。 設定した保存クラスについても、下図のように確認可能です。 RSC側でも下図通り、一次バックアップおよび二次バックアップの取得状況が反映されており、それぞれの処理が正しく実行されたことを確認できます。 「Location」が「Archived」と表示されているものが二次バックアップ、「Primary」と表示されているものが一次バックアップです。 まとめ 今回は、Rubrik と AWS の連携に関する検証内容を整理してご紹介しました。 少し内容が多く、読みづらく感じられた方もいらっしゃるかもしれませんが、最後までご覧いただきありがとうございました。 今回は EC2 インスタンスのバックアップデータ管理に絞ってご説明しましたが、実は S3 や RDS など他の AWS リソースについても、基本的な手順は大きく変わりません。 ご興味のある方は、ぜひ参考にしていただければと思います。

本記事は 新人ブログマラソン2024 の記事です 。 2024年度新人の野上です。 社内業務でQuickSightを初めて利用したのですが、思い通りにデータを扱えず苦戦しました。 QuickSightの分析の中で、計算式や関数を組み合わせて「計算フィールド」を作成できるのですが、エクセルの計算式と同じように使うことはできず、QuickSight独自のルールがありました。 私が苦戦したのは「集計関数」に関するルールです。 このルールを詳しく解説しているブログは少なかったため、同様の問題に直面した初心者方の力になればと思い記事にしました。 集計関数とは まず、「集計関数」とは何かを説明します。 集計関数 とは、複数の行から集計した値を返す関数のことを言います。これはデータ分析などで一般的に用いられる数学的計算です。 表を用いた例で説明すると、以下のようになります。 ここで平均単価＝avg(単価)という計算式で計算されていますが、複数行にわたる単価の値（ 青く囲んだ部分 ）の平均値を返しています。 また、1つの行レベルで計算が可能な関数は 非集計関数 と呼ばれます。 販売金額＝販売個数×単価という計算式で計算していますが、これは1つの行レベルで計算しています。（ 赤く囲んだ部分 ） 直面した集計関数の使用ルール 私が今回直面した集計関数のルールは以下です。 計算フィールドには、入れ子になった集計関数を含めることができません。 上記のルールは普段エクセルを利用している方が直面する問題だと思います。 [参考]: 集計関数 – Amazon QuickSight エラーの例 今回は、販売履歴を時系列で並べたデータセットを使用して、以下のような年度別累計販売金額を表示することを目的としていました。 ここでは、以下の手順で表示することを考えました。 「前年度販売金額」という計算フィールドを作成する 「販売金額」、「前年度販売金額」を使用して累計値を計算する「今年度累計販売金額」、「前年度累計販売金額」という計算フィールド作成 折れ線グラフを2本重ねて表示して、前年度と今年度を比較するグラフを作成する しかし、2.の「前年度累計販売金額」の計算フィールド作成で、以下のようなエラーが確認できました。   ここでは、SUM関数（集計関数）と前年度販売金額が入れ子になっていました。 上記では、集計関数をSUM関数のみしか使っていないように思えますが、計算フィールドである「前年度販売金額」に集計関数が含まれていることで、入れ子になっていると判定されました。「前年度販売金額」では集計関数としてmax関数が用いられていました。   集計関数を複数使用しなければ、目的のグラフを作成することができないため、QuickSight上でグラフが作成できませんでした。   実際に対処した方法 実際には違う対処方法があるかもしれませんが、初心者なりの対処方法ですのでご容赦ください。 エクセルファイルの加工 私は手動でアップロードしたエクセルファイルをデータセットに使用していたため、エクセルファイルを加工することで対処しました。 エクセルファイルにて、日付のセルから年度を切り出すセルを作成 年度ごとに累積値を表示するセルを作成 集計関数を入れ子にすることができないので、入れ子にならないようエクセルファイル上で集計関数を実装してしまうことで、Quicksight上では集計関数が入れ子にならないようにしました。 データセットの再アップロード 先ほど作成できなかった「前年度累計販売金額」の計算フィールドをエラーなく作成することができ、年度別累計販売金額を表示するグラフを作成することができました。 まとめ 今回は、Amazon QuickSightにおける「集計関数」のルールについて説明しました。 私が実際に試したように、BI製品の仕様や制約によっては、元となるデータの加工が必要になることがあります。 案件の中でも同じようなケースが往々にしてありそうだと感じました。 初めてのBI製品を使用する際には、公式のドキュメントなどを確認して仕様を十分に理解することをお勧めします。 この記事がQuickSightを初めて使う方の役に立てば嬉しいです。

こんにちは。SCSK株式会社の安藤です。 先日、AWS X-Rayを操作する機会がありましたので、Zabbixと比較してみたいと思います。監視ツール選定のご参考になれば幸いです。   ZabbixとAWS X-Rayの概要 まずは、ZabbixとAWS X-Ray、それぞれの概要を記載します。   Zabbixとは まずはZabbixの説明を簡単にさせていただきます。 Zabbixは、エンタープライズ対応のオープンソース統合監視ツールです。 サービスやそれを支える ITシステム(サーバ、ネットワーク機器等)の状態を把握し、障害の予兆やサービスへ影響を及ぼす事象が発生した際に、システム管理者やオペレータに通知を行うオープンソースの統合監視ソリューションです。 数万デバイス規模のエンタープライズ環境でも多数の稼動実績を誇っています。 Zabbixの詳細情報については、以下をご確認ください。 Zabbix :: The Enterprise-Class Open Source Network Monitoring Solution ZabbixはITインフラストラクチャ・コンポーネントの可用性やパフォーマンスを監視するためのエンタープライス向けソフトウェアです。Zabbixはオープンソース・ソフトウェアとして開発されており、無料でダウンロードいただくことが可能です。 www.zabbix.com   AWS X-Rayとは 次に、AWS X-Rayについて簡単に説明させていただきます。 X-Rayは、マイクロサービスアーキテクチャにおけるリクエストの流れを追跡し、各サービス間の通信を可視化します。これにより、サービス間の依存関係を視覚的に把握し、パフォーマンスのボトルネックを特定できます。AWSのサービスですので、他のAWSサービス（Lambda、EC2、ECSなど）とシームレスに統合できます。また、カスタムメタデータを追加して、詳細なトレース情報を収集できます。 X-Rayの詳細情報については、以下をご確認ください。 AWS X-Ray（分散アプリケーションの分析とデバッグ）| AWS AWS X-Ray では、リクエストのトレースによりマイクロサービスアプリケーションをデバッグおよび分析できるため、問題の根本原因とパフォーマンスのボトルネックを見つけることができます。 aws.amazon.com   ZabbixとX-Rayの比較 早速比較していきます。 簡単に一覧表にしてみました。 比較項目 Zabbix X-Ray 概要 オープンソースの監視ツール AWSマネージド監視サービス 難易度 Zabbixの知識が必要 AWSの知識があれば 比較的容易 デフォルト機能で有効化できないサービスの場合は 知識が必要 監視対象 クラウド・オンプレどちらも対応 AWSのサービス （Lambda、EC2、ECSなど） コスト ソフトウェア自体： 無料 AWS上に構築する場合：EC2料金 サポート入る場合：年間サポート料金 従量課金制 （監視項目数に応じた課金） 監視対象数 無制限（サーバのスペックに依存） 無制限 サポート Zabbix Enterpriseサポート AWSの公式サポートとコミュニティ   導入難易度 ZabbixはGUIで設定可能ですが、柔軟性が高い分、目的とする監視を設定するために、知識が必要です。 一方X-RayもGUIで設定可能です。AWSの操作に慣れていれば、比較的容易に設定可能と思います。ただし、一部サービスではデフォルト機能で有効化できないので、その場合には知識が必要です。   参考までに、設定方法を記載します。   Zabbix設定方法 サーバは構築済とします。新規導入の場合は、以下の手順をご参照ください。 LinuxサーバーへのZabbixインストール手順 オープンソースの統合監視ツールである「Zabbix」を、Linuxサーバーへインストールする手順を紹介します。 blog.usize-tech.com 2024.02.13 Zabbix 7.0 LTSをインストールしてみた 最新バージョンであるZabbix 7.0 LTSがリリースされましたので、AWS上にインストールしてみたいと思います。 また、インストールするために必要な手順を本記事にて記載いたします。 blog.usize-tech.com 2024.06.12   Web監視の設定例です。 ①監視対象ホストを登録します ②監視アイテムを追加します ③登録されたことを確認します ※上記は、Webページへのアクセスを確認するアイテムを作成しています。より詳細なステップを設定した監視をすることも可能です。   X-Ray設定方法 ①対象のマイクロサービスで、X-Rayトレースを有効化します API Gateway： ログ/トレース のセクションから、有効化します   Lambda：関数の設定から、 CloudWatch Application Signals and AWS X-Ray  セクションの アクティブトレース を有効化します   DynamoDB：デフォルト機能では有効化できません。ライブラリをインストールし、X-RayのSDKを使ってトラッキングの設定をします。   ② AWSマネジメントコンソールより、X-Rayへアクセスします   ③ トレースマップを表示します 左側のナビゲーションペインの  [X-Ray トレース]  セクションで  [トレースマップ]  を選択します。   ③確認したいサービスノードを選択します 直観的操作で、メトリクス、アラート、応答時間の分布など、追加情報を確認できます。ドリルダウンで詳細表示も可能です。   監視対象 監視対象は、Zabbixはクラウド・オンプレ環境両方のサービスを監視できます。管理画面を一元化することが可能です。一方X-Rayは、AWSのサービスとの親和性が高くなっています。   どちらを選ぶ？ 環境や目的に合わせて、最適なツールを選択してください。それぞれ、メリット・デメリット、強み・弱みがあります。 最後まで読んでいただき、ありがとうございました。   最後に 弊社ではZabbix関連サービスを展開しています。以下ページもご参照ください。 ★Zabbixの基礎をまとめたeBookを公開しております！★ FAQ・お問い合わせ｜SCSK Plus サポート for Zabbix 導入をご検討される際、よくあるご質問と回答についてまとめております。 www.scsk.jp   ★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アカウントを開設しました！★ x.com x.com

こんにちは、SCSKの嶋谷です。 前回私の部署の先輩である谷さんがMackerelを使用してAWSのサーバレスサービスを監視する方法と結果についての記事を掲載しました。 ご覧になっていない方は是非ご覧ください。 Mackerel で AWS のサーバーレスサービスを監視してみた – TechHarmony 話は変わりますが、私が前回投稿した記事の中で紹介しているDify環境は複数のコンテナから構築されてます ( Mackerel で Docker を監視してみた – TechHarmony )。この環境全体の処理の流れや遅延原因を従来のサーバ監視で実現することは不可能です。近年では、このようなマイクロサービスを監視するためにオブザーバビリティフレームワークであるOpenTelemetryが注目を集めています。 OpenTelemetry を使用すればDify環境の詳細な処理の流れや遅延場所の特定ができると思い、検証したいと思いました！ Dify環境のデータをOpenTelemetryで収集するためには、OpenTelemetryの設定をDify環境のプログラムに書き加える必要があります。この処理を1から実装するのは大変だと思いました。そこで今回は、手始めに公開されているデモ環境でデータを収集して、Mackerelで可視化してみました。 OpenTelemetryとは OpenTelemetryとは、システムやサービスの状態を詳細に把握するために必要となるテレメトリーデータ(ログ・トレース・メトリクス)を生成・収集・送信するためのソフトウェアです。CNCF(Cloud Native Computing Foundation)のOpenTracingプロジェクトとOpenCensusプロジェクトが統合されて誕生したプロジェクトによって開発されたソフトウェアです。詳細は以下をご参照ください。 Cloud Native Computing Foundation 近年クラウドネイティブ等の普及により、アプリケーションをそれぞれ異なるコンテナやサーバで構築するシステムが一般的になっています(マイクロサービス)。その結果、情報が分散されシステム全体の状態を把握しづらくなり、迅速なトラブルシューティングが困難となっています。システム全体の状態を把握するためにはテレメトリーデータの収集が必要不可欠です。 旧来はテレメトリーデータは標準化されておらず、ベンダーによってフォーマットや取得方法などが異なっていました( ベンダー依存 )。近年、テレメトリーデータのフォーマット・取得方法などを標準化しようとする動きが活発化しています。OpenTelemetryでは、ベンダー依存することなくテレメトリーデータを収集することができます。さまざまなプログラミング言語に対応可能なAPIやSDKが公開されており、システム構築の際に使用する言語を気にする必要はありません。 詳細については、以下をご参照ください。 OpenTelemetry公式サイト MackerelとOpenTelemetryを連携している記事が数少ないため、実際に実装して記事を書いてみました。 今回の記事ではOpenTelemetryでデータを収集するための「デモ(マイクロサービス)環境の構築」と「Mackerelでデータの可視化」の 2部構成 になっています。 1.デモ(マイクロサービス)環境の構築 まずはデモ(マイクロサービス)環境の構築について説明します。 監視対象について OpenTelemetryの公式サイトにデモ環境が公開されているため、こちらを今回の監視対象としました。具体的には、模擬のECサイトでの操作(商品閲覧・購入・会計など)からテレメトリーデータを収集しています。デモ環境の詳細は以下をご参照ください。 デモ環境 今回はAWSのEC2上にデモ環境を構築しました。構成図は以下の通りです。   デモ環境の構築 Githubからデモ環境のレポジトリをクローン git clone https://github.com/open-telemetry/opentelemetry-demo.git レポジトリをクローンしたディレクトリに移動 cd opentelemetry-demo docker composeコマンドで環境を作成 docker compose up --force-recreate --remove-orphans --detach 起動確認 各サービスごとのコンテナが作成され、起動できていることを確認しました。 ECサイトへのアクセス 4の手順でコンテナが作成され起動できていることを確認したため、実際にアプリケーションが動作していることを確認します。ドキュメントでは、ECサイトに「http://localhost:8080」でアクセスすると記載されています。私はEC2上に環境を構築しているため、同じサブネットに配置した別のEC2からデモ環境が構築されているEC2のプライベートIPアドレスでアクセス(http://プライベートIP:8080)しました。 上記の図のように、初期画面から商品を選択して購入するなどの一般的なECサイトを模倣した操作を行うことが可能となっています。 2.Mackerelへのデータ送信・可視化 前章で構築したECサイトを操作することでテレメトリーデータが生成されます。生成されたテレメトリーデータをMackerelに送信して可視化してみます。今回はトレースデータの可視化について説明します。 トレースデータとは分散システムにおけるリクエストの処理経路を表すデータです。詳細については下記サイトが参考になります。 トレースデータとは何か – その重要性を理解する デモ環境での設定 OpenTelemetryで収集したデータをMackerelに送信するにはデモ環境の設定ファイルでデータの送信先(エンドポイント)にMackerelを設定する必要があります。手順は以下の通りです。 デモ環境のsrc/otel-collectorの設定ファイル(otelcol-config.yml)に以下を追記 exporters: #途中省略 otlphttp/vaxila: endpoint: "https://otlp-vaxila.mackerelio.com" headers: Accept: "*/*" "Mackerel-Api-Key": ${env:MACKEREL_APIKEY} デモ環境直下の設定ファイル(docker-compose.yml)に以下を追記 >otel-collector: #途中省略 enviroment: #途中省略 - MACKEREL_APIKEY=xxxxxxxxxxxxxxxxxxxxxxxxx この処理がとても重要です。 当初は手順1のMACKEREL_APIKEYに直接APIキーを入力していました。この設定時に、APIキーを正しく設定していたのですが、APIキーが無効であるエラーに直面しました。デモ環境はdocker上で動作しており、docker composeコマンドで起動しているため設定ファイル(docker-compose.yml)に環境変数(APIキー)を記述しないと正しく動作しません。私のdocker composeコマンドの理解不足でこの問題を解決するのにとても苦労しました。 環境を再作成 docker compose up --force-recreate --remove-orphans --detach Mackerel上でデータの閲覧 デモ環境での設定が完了すると、Mackerelの画面上でデータを可視化することができます。手順は以下の通りです。 Mackerelのサイドメニューのトレースをクリック クリックするとMackerelの画面がトレースを閲覧する画面に遷移します。 トレース閲覧 トレース閲覧画面では、アプリケーションのサービスごとにトレースを閲覧することができます。 トレース一覧で閲覧したいサービスを選択してデータを可視化します。今回はcheckout(会計)サービスのデータを可視化してみました。 上記の図のようにデータはレイテンシーの分布として表示されています。グラフは横軸が時間で縦軸がレイテンシーとなっており、トレースをヒートマップで表示しています。時間帯・レイテンシーにおけるトレースの総数を可視化することができました！ トレース詳細を閲覧 トレース閲覧画面の下部にはトレースの一覧が表示されています。閲覧したいトレースの行をクリックすることでトレースの詳細を閲覧することができます。 トレースデータはスパン(APIコールやストレージアクセスなどのさまざまなアクション)の集合体であるため　1つのトレースにさまざまな処理が含まれています。トレースの閲覧画面ではサービス毎にスパンが色分けされています。スパンの右端にはレイテンシが記載されており、どの処理に時間を要しているかを確認できます。1つのトレースデータを閲覧するだけでも各サービス間の連携や通信方法などさまざまな情報を理解することができます。 スパンの詳細を閲覧 トレースの詳細画面で1つのスパンをクリックすることでスパンの詳細を閲覧することができます。 スパンの詳細からトレース・スパンのID、開始・終了時刻、ホストOSの情報やサービスで使用されているプログラミング言語など多くの情報を知ることができます。今回はLinux環境でデモ環境を構築したため、OS情報はLinuxが表示されています。今後はWindowとLinuxで表示内容にどのような差があるのかも調査していきたいです。           トレース画面からサービスの処理数(トレース数)や流れ、各処理の詳細を知ることができるためシステム全体を理解することが容易になるのではないかと感じました。また今後は複数の監視サービスとの違いなども調査してみたいと思います。 おわりに OpenTelemetryで取得したデータをMackerelで可視化することができました。デモ環境の構築・Mackerelとの連携ともに詰まった点はありましたが、なんとか解決できたので自分自身の技術力が少し向上した気がしています。 1月~3月までMackerelに関するブログを投稿してきましたが、皆さんも少しMackerelに興味を持ったのではないでしょうか。2週間のトライアルなどもありますので、是非実際に触れてみてほしいと思います。 最後までお付き合いいただきありがとうございました。

こんにちは、SCSKの田中です。 今回は、Azure VM（AVD（Azure Virtual Desktop）ではありません）にOfficeを導入する際、Microsoft 365 E3ライセンスを紐づける際の注意点やつまづきそうなポイントをご紹介いたします。 前提 まずはじめに抑えておきたい前提として、 E3ライセンスは1ユーザーにつき、1ライセンス紐づけられるといったルールがあります 。 デバイスに対して割り当てるようなボリュームライセンス(買い切り)とは異なるものであることをご認識ください。 また E3ライセンスを割り当てることができるユーザーは、Entra ユーザーである ことも前提となります。 Microsoftドキュメントでは、 E3ライセンスを割り当てたEntraユーザーでAzure VMにサインインすることでライセンスをアクティベートすることができる と記されています。 Windows Enterprise は、たとえば、Microsoft 365 管理センターを使用してユーザーに割り当てられます。 ライセンスを持つユーザーが、Microsoft Entra資格情報を使用して要件を満たすデバイスにサインインすると、Windows は Pro エディションから Enterprise、または Pro Education から Education にステップアップします。 エディションがステップアップされると、Enterprise/Education 機能のロックが解除されます。 ユーザーのサブスクリプションの有効期限が切れたり、別のユーザーに転送されたりすると、現在のサブスクリプションの有効期限が切れると、デバイスはシームレスに Windows Pro または Windows Pro Education エディションに戻ります。 Windows サブスクリプション ライセンス認証 | Microsoft Learn   条件 最終的にAzure VMにE3ライセンスをアクティベーションする為に必要な条件を以下に記載いたします。 Azure VMのOSがProエディションであること(評価版でないこと) デバイスがMicrosoft Entra　参加済みであること   実際の手順 はじめに構築したAzure VMに対してMicrosoft Entraへ参加させていきます。 仮想マシン構築時に[管理]タブから[Azure AD資格情報を使用してログインする]を選択することで、Microsoft Entraに参加した状態で起動することができます。 もしチェックをせず構築した場合でもAzure CLIから拡張機能をインストールすることで参加させることができます。   Microsoft Entra ID を使用して Azure の Windows 仮想マシンにサインインする - Microsoft Entra ID Windows を実行している Azure VM に Microsoft Entra 認証を使用してサインインする方法について説明します。 learn.microsoft.com   無事Microsoft Entraに参加されると以下のようにデバイスに表示されます。   続いてE3ライセンスを割り当てたユーザでアクティベーションさせたいAzure VMにサインインします。 E3ライセンスを割り当てたユーザは以下のように製品名とアクティブ状態が表示されます。   アクティベーションが完了していない状態のAzure VMのライセンス認証画面は以下となります。 ライセンスを割り当てたユーザでサインインすることで以下のようにアクティベーション状態となります。   Azure VMへのE3ライセンスアクティベーション手順は以上になります。

はじめに 私はAWSでの構築やPythonプログラムの改修・開発などを行う業務を担当しています。私の開発チームでは開発手法が古く、小規模なチームではあるものの、高品質でスピード感のある開発ができていないという問題がありました。 そこでGitとCI/CDを利用した開発手法を取り入れて、開発チームが高品質でスピード感のある開発ができるような案を考案してみました。チームへの導入はまだ途中ですが、導入背景・課題から構成や具体的な設計方針・運用ルールまでを記載している記事は少ないかと思いますので、同じような問題を抱えている方のお役に少しでも立てればと思い、記事を書きました。 GitやCI/CDを初めて耳にするような方にも理解してもらえるように用語の説明も記載しています。 GitとCI/CD導入の背景・課題 開発は高品質でスピード感あることが理想ですが、私のチームはそんな理想的な開発ができずに困っていました。 そこでデジタル庁のレポート( CI/CDパイプラインにおけるセキュリティの留意点に関する技術レポート )にて定義されている、開発における一般的な業務プロセスごとに現行手法と、その手法によって発生している課題を整理しました。 開発における一般的な業務プロセス ソースコードや設定ファイルに対する作業 品質保証に関わる作業 実行環境への配送および実行 以下のように整理した結果、チームの現行開発手法が全体的に古く、それが原因となってこれら課題が発生していることが分かりました。そして、これら課題が品質・スピードを低下させ、理想的な開発ができていないと推測しました。 業務プロセス 現行手法 課題事例 ソースコードや 設定ファイルに対する作業 詳細設計書をエクセルで作成する 実機と差分が発生 プログラムをバージョン管理せず、 共有フォルダに保管して管理する 変更の追跡が困難 共同作業によりデグレ発生 品質保証に関わる作業 作業前後を見比べて、 作業箇所を発見し、レビューする 作業箇所の見落とし レビューする側の稼働状況により、リリース遅延 動作確認テストまたは、机上検証をする テスト、検証、稼働工数不足 実行環境への配送および実行 手作業で構築する 構築時の設定値誤り プログラムを実行環境へ手作業で配置する 実行環境へのプログラム配置忘れ   GitとCI/CD導入後の手法 現行手法にGit、CI/CDを取り入れて、先ほどの課題を改善し、高品質化、スピード向上を目指す場合、 下記の改善手法が最適と考えました。なお、AWS環境での開発を前提に検討しています。 業務プロセス 現行手法 検討した改善手法 ソースコードや 設定ファイルに対する作業 詳細設計書をエクセルで作成する 詳細設計書をCloudFormationで代替する プログラムをバージョン管理せず、 共有フォルダに保管して管理する プログラムをGitでバージョン管理する 品質保証に関わる作業 作業前後を見比べて、 作業箇所を発見し、レビューする 作業箇所をGitで自動的に表示し、レビューする 動作確認テストまたは、机上検証をする 自動動作確認テストまたは、AIによる机上検証する 実行環境への配送および実行 手作業で構築する CI/CDを利用して自動で構築する プログラムを実行環境へ手作業で配置する プログラムを実行環境にGitで半自動に配置する 補足：Gitとは Gitはファイルの変更履歴を記録・管理するアプリケーションです。 Git周りの用語も説明すると、Gitでは作業者はファイルやディレクトリに対する編集結果を自身の作業端末上の「ローカルリポジトリ」という保管場所に記録します。これを「コミット」と呼びます。 複数人で作業をする場合は、ローカルリポジトリにおける差分を関係者と同期するために、差分をソースコード管理システム上の「リモートリポジトリ(リポジトリ)」に送信します。これを「プッシュ」と呼びます。 他作業者への影響を最小限とするために、一般的に「ブランチ」を作成します。 元のブランチの内容に影響を与えることなく安全に変更を加え、そして変更が完了したら、メインの内容に統合します。これを「マージ」と呼びます。マージの承認依頼を「プルリクエスト」と呼びます。 補足：CI/CDとは CI(Continuous Integration)は継続的インテグレーションと呼ばれ、ソースコードから環境で実行できる成果物を生成(ビルド)し、動作確認テストをすることを意味します。 CD(Continuous Delivery)は継続的デリバリーと呼ばれ、成果物(ソースコード)を実行環境に自動的に配送することを意味します。 CI/CDパイプラインについて デジタル庁レポートを参考に、CI/CDパイプラインを用いた実行環境への配備までの各フェーズを説明します。 CI/CDパイプラインにおけるセキュリティの留意点に関する技術レポート ローカル作業フェーズ 先ほどの表における、業務プロセスの「ソースコードや設定ファイルに対する作業」に相当します。 主に作業者がソースコードや設定ファイルに対する作業と検証を行うフェーズとなります。 作業者は手元の端末や統合開発環境（IDE）で作業をし、その内容をGitでソースコード管理システムに送ります。 ビルドフェーズ 先ほどの表における、業務プロセスの「品質保証に関わる作業」に相当します。 最新のソースコードや設定ファイルを元とした成果物の生成、検証・テスト、保管を行うフェーズです。 CI/CD パイプラインの内、CIがこれに当たります。 デリバリフェーズ 先ほどの表における、業務プロセスの「実行環境への配送および実行」に相当します。 成果物の実行環境への配送と実行を行うフェーズです。CI/CD パイプラインの内、CDがこれに当たります。   GitとCI/CD導入後の構成 今回、改善を行うシステムはAWSを利用しており、開発環境と本番環境の2面構成です。また、業務用プログラムの実行環境として社内に2台のPCを設置しています。 体制は開発チームと運用チームの2チーム体制で、運用チームは監視結果のレポートの発行やお客様の新規追加・解約に合わせて、AWSの構成変更を行います。 こういった環境や体制にGitとCI/CDを導入すると、以下構成になると考えています。   次に、先ほどのデジタル庁レポートで用いられていた3つのフェーズに当てはめて、検証開始から本番環境や実行環境への配備までの作業の流れを説明します。なお、各フェーズを行ったり来たりしますのでご注意ください。 開発環境での作業の流れ 開発環境では、検証や検証完了リソースを本番環境にデプロイする前の動作確認が目的です。 ローカル作業フェーズ 開発者は機能開発や改修を契機に開発ブランチから機能検証ブランチを新たに作成して検証を開始します。 開発者は検証における作業結果を機能検証ブランチにプッシュします。 検証終了後、開発者は機能検証ブランチから開発ブランチへのプルリクエストを送信し、CodeGuruの指摘コメントを反映し、承認者へレビューを依頼します。 承認者はプルリクエストをレビューし、問題が無ければ承認の上、機能検証ブランチを開発ブランチへマージします。 ビルドフェーズ 開発者からのプルリクエストをトリガにコードチェック用のパイプラインが起動し、CodeGuruが作業結果をレビューし、指摘をプルリクエストのコメントに記載します。 （AWSデプロイを伴う時）マージをトリガにデプロイ用パイプラインがCloudFormation(CFn)テンプレートをCFnへ取り込める形式に変換して、S3に保管します。 デリバリフェーズ （AWSデプロイを伴う時）デプロイ用パイプラインが変換されたCFnテンプレートをCFnに取り込み、CFnがリソースを構築し、動作確認可能な状態とします。 （実行環境PC上のスクリプト更新を伴う時）開発者が実行環境PC上の開発ブランチでプルを実行。開発ブランチのスクリプトが実行環境PCに配置され、動作確認可能な状態とします。 本番環境での作業の流れ 本番環境では、本番稼働リソースを本番環境へ配備すること、実行環境へプログラムを配備することが目的です。 ローカル作業フェーズ 開発環境での動作確認終了後、開発者は開発ブランチから本番ブランチへのプルリクエストを送信し、CodeGuruの指摘コメントを反映し、承認者へレビューを依頼します。 承認者はプルリクエストをレビューし、問題が無ければ承認の上、開発ブランチを本番ブランチへマージします。 （顧客追加・解約時）運用者が開発ブランチにて顧客情報を記載したCFnテンプレートを配置します。 運用者は開発ブランチから本番ブランチへのプルリクエストを送信し、CodeGuruの指摘コメントを反映し、承認者へレビューを依頼します。 （顧客追加・解約時）承認者はプルリクエストをレビューし、問題が無ければ承認の上、開発ブランチを本番ブランチへマージします。 ビルドフェーズ プルリクエストをトリガにコードチェック用パイプラインが起動し、CodeGuruが作業結果をレビューし、指摘をプルリクエストのコメントに記載します。 （AWSデプロイを伴う時）マージをトリガにデプロイ用パイプラインがCFnテンプレートをCFnへ取り込める形式に変換して、S3に保管します。 デリバリフェーズ （AWSデプロイを伴う時）デプロイ用パイプラインが変換されたCFnテンプレートをCFnに取り込み、CFnがリソースを構築し、リリースされます。 （実行環境PC上のスクリプト更新を伴う時）開発者が実行環境PC上の本番ブランチでプルを実行。本番ブランチのスクリプトがPCに配置され、本番利用可能な状態となります。   改善手法を実現するための設計方針・運用ルール 改善手法を実現するための設計方針や運用ルールを記載します。これら設計方針や運用ルールはデジタル庁のレポート（ CI/CDパイプラインにおけるセキュリティの留意点に関する技術レポート ）を参考にしました。 CloudFormation、Gitについては導入済みで、実績のある設計方針や運用ルールもありますが、それ以外の技術は机上検証はしていますが、実績はありません。以下は参考程度に利用いただき、利用する際は十分に検証してから利用いただくことをお勧めいたします。   CloudFormationにおける運用ルール テンプレート作成に関するルール CloudFormationには機密情報を載せず、最悪ソースコードが流失しても問題ない状態とすること。 機密情報、個人情報を利用する場合はParameterStoreへ保管し、そこから取得すること。 取得した機密情報、個人情報は後続フェーズへ引き継がないこと。 テンプレートが詳細設計書としても機能するように、各設定値の真上にコメントでその設定値とした理由を記載すること。 ただし、JSONの場合は仕様によりコメントを記載できないためコメントは不要とする。 テンプレートは原則YAML とするが、プログラムで処理がしやすい場合はJSONを利用しても良い。 本番、開発環境で一貫して同じテンプレートを利用するため、アカウントIDや自リージョンなどは組み込み関数の変数(例えば、自リージョンは!Ref “AWS::Region”)を利用すること。 効率性、安全性を高めるため、原則、ネストテンプレート構成とする。 リソースの参照はリポジトリ内のリソースパスを参照パスとして利用すること。 CloudFormationへ取り込む前のルール テンプレートのアップロード前に”aws cloudformation validate-template”コマンドを使用して、テンプレートの構文に誤りが無いことを事前に検証すること リソースによっては設定変更時に一度削除して、構築される場合があるため、テンプレートのアップロード前に変更セットを作成し、意図しない作成、削除が発生しないことを確認してから、アップロードすること。 「aws cloudformation create-change-set」コマンドを使用して、変更セットを作成します。 変更セットを作成したら、「aws cloudformation describe-change-set」コマンドを使用してその内容を確認できます。 その他 AWSでの構築は原則、CloudFormationによる構築とし、マネジメントコンソールでの構築は禁止とする。 定期的にリソースを自動作成したい場合、定期実行EventBridgeでテンプレートを修正・追記する方針とする。 EventBridgeで直接リソースを作成し、コードで管理していないリソースを作り出さないため。   Gitにおける運用ルール 作業環境 開発ツール 開発者はVSCodeを統合開発環境とし、GitLens(無料版)という拡張機能を導入すること。 生成AIを利用し、CFnテンプレートやソースコードのたたき台を作成する時に活用すること。 認証情報を一度入力したら以降は毎回入力する必要が無いように、GitCredentialManagerを利用する。 開発ルール 誰が更新したのかが分かるようにGitコマンドにおけるUsernameは姓名(アルファベット)で設定し、Emailは会社アドレスを設定する。 Gitの作業履歴はコミットとして残す方針とし、Gitコマンドの強制プッシュを原則禁止とする。 生成AIは社内ガイドラインに沿って利用すること。必要に応じて情報をマスクして利用すること。 作業者毎にリポジトリアクセス用IAMユーザを発行し、開発者はフルアクセス権限、それ以外（実行環境PCや運用チーム)には読み取り権限を付与する。 フルアクセス権限はAWSCodeCommitPowerUserポリシーのみを、読み取り権限はAWSCodeCommitReadOnlyポリシーのみを付与する。 リポジトリアクセス用ユーザには利便性向上のため、Gitコマンド実行時のMFAを強制しない。 開発、本番ブランチの削除、直接のプッシュができない権限をリポジトリアクセス用ユーザ、マネコンユーザに付与する。 ただし、顧客追加/解約時に利用するため、運用チームはマネコンユーザで開発ブランチへファイルを配置できるようにする。 運用チームは原則、実行環境PC上のCFnテンプレートやプログラムの更新を行わないこと。ただし、ブランチにアップロードしていない実行環境PC固有のファイルであれば更新可能 実行環境PCではグローバルな.gitignoreファイルを作成すること。（git config –global core.excludesfile ~/.gitignore_global) 情報漏えいを防ぐため、個人所有のGit系SaaSの認証情報を作業者端末に設定しない。 ブランチ構成について CFnテンプレートを可能な限り検証から本番まで一貫して利用すること。バグの早期発見が目的。 開発、本番環境用にブランチを作成する。開発、本番ブランチは削除せずに永続的に残す。 開発環境での検証用に機能検証ブランチを複数作成・削除して良い。機能検証ブランチは機能開発やバグ改修のたびに開発ブランチから分岐して、機能検証ブランチを作成すること。 緊急改修が必要な時でも機能検証→開発→本番ブランチという順番で迅速に改修できるため、緊急改修ブランチは作成しない。 顧客追加/解約時、運用チームはマネコン経由で開発ブランチにCFnテンプレートをアップロードし、本番ブランチへのプルリクエストによって新規顧客に必要なリソースを構築/削除すること。 各ブランチの分岐元ブランチ、ブランチへのプッシュ可否、ブランチへマージできるブランチ、ブランチ削除可否は以下表を参照すること。 ブランチ名 概要 分岐元ブランチ ブランチへのプッシュ可否 このブランチへマージできるブランチ ブランチの削除可否 本番ブランチ 本番環境で稼働するリソースやソースコードが格納されるブランチ 無 不可 開発ブランチ 不可 開発ブランチ 開発環境で稼働するリソースやソースコードが格納されるブランチ 本番(初回だけ) 開発チーム：不可 運用チーム：可 機能検証 ブランチ 不可 機能検証 ブランチ 機能開発や改修を頻繁に行うブランチ 開発 可 無し 可 各ブランチの分岐、マージのイメージを以下に図示する。 プッシュ、プル、プルリクエストについて プッシュ時、レビューする人が修正内容を判断しやすくするために、担当した修正タスク名、要件、設計方針のいずれかをプッシュ時のコミットにコメントすること。プッシュが大量に実施される場合は任意のコメントで良い。 デバッグにより同じ修正タスクに対して、複数回プッシュする必要がある場合、修正タスク名と回数をコメントに記載するなど適当なコメントでも良い。 強制プッシュ（例えば、”git push origin main –force”,”git push origin main -f”）を禁止とする。ただし、リモートリポジトリへの影響がないローカル環境での強制力のある操作は許可する。 特にVSCodeのエラーウィンドウが出現した際は、強制力のある操作がされることがあるため、forceやf、上書きといった言葉が使われているエラーメッセージの場合は翻訳して意味を理解したうえでOKボタンを押す。 プッシュしたコミットを取り消す場合、”git revert”を利用し、コミットの取り消しを行う。コミットを取り消した状態のコミットでプッシュしてリモートリポジトリに反映すること。（取り消し履歴を残すことが目的） プルリクエスト時、レビューする人が修正内容を判断しやすくするために、プルリクエストのタイトル欄に担当した修正タスク名、説明欄に要件、設計方針、修正したことのいずれかを記載すること。 コミットしていない変更がある状態でブランチ移動などをしたい場合、”stash”を利用して変更を一時保存する。（コミットしていない変更が存在する場合はブランチ移動などの一部操作が不可のため） プッシュ、プルリクエストでコンフリクトが発生した場合、コンフリクト行を影響が無いように修正したうえで再度プッシュ、プルリクエストを送信すること。 影響が発生する場合は、必要に応じてGitLensで該当行のコミッターを特定し、そのコミッターと相談してコンフリクトを解消すること。 フォルダ構成について 顧客新規追加/解約時はマネコン経由で開発ブランチにCFnテンプレートをアップロードし、本番用ブランチにプルリクする。 リポジトリルートに.gitignoreファイルを配置して、.conf、.log、.xls、.jsonなどログや認証情報は除外する レビューについて レビューイ（レビューしてもらう側） 分岐したブランチから本番または、開発用のブランチにプルリクエストをする。 Amazon CodeGuruがプルリクエストの更新分に対して自動的にレビューし、指摘をコメントする。 CodeGuruからの指摘コメントがある場合は指摘反映後、そのプルリクエストを閉じて、再度プルリクエストする。指摘コメントがなくなるまで繰り返す。 CodeGuruからの指摘コメントが無い場合、レビュアーにプルリクエストのレビューを依頼する。 CodeGuruのレビューコメントが間違っている、意図的にベストプラクティスに沿わないコードとする場合はコメントに対してその理由をコメントし、その指摘を無視する。 レビュアー（レビューする側） プルリクエストのマージ先ブランチが正しいことを確認する。 意図しないリソースの置き換えが発生していないかを確認する。 過去にCodeGuruから指摘があったどうかを確認し、CodeGuruからの指摘を反映できているか確認する。 ファイル内の特定行に対して指摘があれば、その行にコメントをする。 ファイルに全体的な指摘があれば、ファイルに対してコメントをする。 レビュー合格であれば、プルリクエストを承認して、マージする。 マージ時はソースブランチを削除する。   CI/CDにおける設計方針、運用ルール CodePipeline ステージ共通 パイプラインの構成もCFnテンプレートで管理する。パイプライン用CFnテンプレートをCFnへ手動で取り込んで構築する。 パイプラインやCloudFormationが利用するIAMロールには基本的にAWS管理ポリシーを付与せず、必要最低限のポリシーを付与すること。 開発環境にコードチェック用、AWSデプロイ用のパイプラインを構築し、本番環境にはAWSデプロイ用のパイプラインを構築する。 検証ではパイプラインを利用しないため、コードチェック用のパイプラインで実行されるコマンドをローカル環境で実行しておくこと。 ソースステージ ソースリポジトリはCodeCommitを指定すること。 ブランチは本番環境では本番ブランチを、開発環境では開発ブランチまたは、機能検証ブランチを紐づける。機能検証ブランチは複数作成されるため、機能検証ブランチごとにパイプラインを作成すること。 検出はEventBridgeを利用してソースの変更を検知する。ソース変更のポーリングは開発、検証環境は自動ポーリングを有効としても良いが、本番は手動ポーリングとする。 ビルドステージ ビルド端末内ではソースステージからのアーティファクトを解凍し、ビルドステージの端末内で展開する。 パッケージ化を行うアクショングループでは、リソースへの参照パスはそのままではCloudFormationへ取り込めないことからS3 URLパスに変更するために親テンプレートをビルド端末内で「aws cloudformation package」コマンドでパッケージ化する。 保存先バケットのオブジェクト名にはコミットIDを含める。 既に構築されているリソースへの更新、削除はスタックを設定し、ドリフト検出する。 ビルド端末内で変更セットを作成させ、置き換え、削除、更新が発生する場合、ビルド端末からプルリクエストにコメントを追記すること。コメント追記後に変更セットを削除する。 ビルド時のログは全てCloudWatchLogsへ保管すること。 コードチェック用パイプライン向け CodeGuru Securityへパッケージテンプレートを送信する。 AWSデプロイ用パイプライン向け ビルド端末内でパッケージ化したテンプレートをアーティファクトとしてデプロイステージへ引き渡す。 デプロイステージでアーティファクトの改ざん検証に利用するため、テンプレートのハッシュ値を取得し、パイプラインの変数にハッシュ値を格納する。 デプロイステージ（AWSデプロイ用パイプライン向け） アーティファクトが改ざんされていないか検証するため、S3から取得したテンプレートのハッシュ値とパイプラインの変数に格納したハッシュ値を比較し、検証する。 デプロイステージであるが、CodeBuildを利用して上記を実現する。 ビルドステージから引き渡されたアーティファクトに対して、パッケージ化されたファイルをデプロイするように設定する。 S3 バケットはAWS管理のキーで暗号化し、公開設定としないこと。 バケットはバージョニングを有効化すること。 バケットポリシーで同環境のコードパイプラインとAdministratorのIAMユーザ以外のアクセスを拒否する。 ParameterStore 機密情報、個人情報は全てパラメータストアに保管すること。 IAM、EventBridge 以下クロスアカウントアクセス用のIAMロールを開発環境に作成する 本番環境のIAMロールが本ロールを引き受けられる(AssumeRoleされる)こと 本番環境のCodePipelineが開発環境のCodeCommitにアクセスできること CodeCommit上のソースコードを本番におけるCodePipelineのアーティファクトバケットに格納できること 以下クロスアカウントアクセス用のIAMロールを本番環境に作成する 上記開発環境のIAMロールを引き受ける(AssumeRoleする)こと CodeCommitの変更イベントを本番環境に通知するEventbridgeを開発環境に作成し、通知をトリガーにパイプラインを起動するEventbridgeを本番環境に作成する ※IAM、EventBridgeは以下記事を参考にさせていただきました。 https://qiita.com/ozzy3/items/079f82b6123ec57f3c91

SCSKの畑です。 これまでのエントリで説明してきた Redshift テーブルデータのメンテナンスアプリケーションにテーブルデータの差分比較機能を実装しているのですが、バックエンド側についてどのように実装したのかを記載してみます。 アーキテクチャ図 性懲りもなく今回も。今回はバックエンド側の処理として実装しているため、以下図では AppSync から呼び出される Lambda が対象となります。ただ、Lambda ならではの話みたいなものは今回は正直ないです・・   背景 テーブルデータの差分比較機能については、元々お客さんと詰めた 機能要件の一つ にありましたので実装は規定路線でしたが、フロントエンド/バックエンドのどちらで実装するかというのがちょっとした考えどころでした。本アプリケーションにおけるテーブルデータの差分比較機能は、 アプリケーション上でユーザが編集したデータと編集前のデータを比較 異なるバージョン間のテーブルデータを比較 の2パターンで使用されますが、前者の方が使用頻度は高いと思われること、及び（当然ながら）ユーザはアプリケーション上でテーブルデータを編集することの2点より、当初はフロントエンド側で実装する方針としました。しかし、具体的にどのようなアプローチで実装するのかなかなか定まりませんでした。 まず、 少し前のエントリ で紹介した Tablator 上で編集した項目（セル）の情報を保持できるためそれをそのまま使用しようかと考えていましたが、ライブラリの仕様上 削除した行データ＆外部ファイルからインポートしたデータ の場合は対象とならないことが分かりました。また、異なるバージョン間のテーブルデータを比較する場合は実質的に S3 上のテーブルデータ同士を比較する処理となり、Tablator の機能は使用できないため見送ることに。 Tabulator - Editing Data Use built in cell editors to allow users to edit table data, or build out your own for fully customizable table input tabulator.info よって、真っ当に2つのテーブルデータを比較するような処理をフロントエンドでどう実装するかを考えたのですが、Javascript（Typescript）でその手の処理を実装したことがなかったため、ライブラリや比較手法の調査でこれという正解が見つかりませんでした。元々 Python の pandas ライブラリについては過去案件などで使い慣れていたため、pandas ライクに使用できるライブラリが良さそうということで調べたところ danfo.js なるものを見つけました。 Danfo.js Documentation | Danfo.js Danfo.js is an open-source, JavaScript library providing high-performance, intuitive, and easy-to-use data structures fo... danfo.jsdata.org 使い勝手も良さそうだったのですが、実はこの調査の過程で pandas であれば簡単に差分比較できる方法を見つけてしまっており・・残念ながらその方法が使えなさそうだったため、その分のロジックについて自前で実装することを考慮するとバックエンド側で Python/pandas を使用して実装してしまう方がトータルで効率良いのではないかということで、バックエンド側で実装する方針に変更しました。また、差分比較処理自体は相応に重い処理であるため、フロントエンド（クライアント）側で実装した場合の影響を憂慮したことも理由の一つです。バックエンド側で実装する分には、（極論） Lambda に頑張ってもらえれば良いだけなので・・ なお、バックエンド側で差分比較を実装するにあたり、フロントエンド側で編集したテーブルデータをバックエンド側に持ってくる処理が追加で必要となりましたが、ちょうど編集中のデータを S3 上に一時保存するような機能を実装したところだったため、同機能と合わせて差分比較を実施するようにすることで問題なく実装できました。異なるバージョン間のテーブルデータ比較については先述した通りS3 上のテーブルデータ同士を比較する処理であり、Lambda 上から直接処理できたため問題ありませんでした。   pandas を使用した実装方法 ということで本題なのですが、pandas.DataFrame.merge の indicator 引数を使用することでテーブルデータの差分比較を容易に実現することができました。 pandas.DataFrame.merge — pandas 2.2.3 documentation pandas.pydata.org 例として以下のような2つのテーブル間での差分比較を考えてみます。table_1 を編集前のデータ、table_2 を編集後のデータと想定し、同テーブルにおける PK 列を「pk」列とします。 [table_1] pk col_1 col_2 col_3 row_0 1 2 3 4 row_1 11 12 13 14 row_2 101 102 103 104 [table_2] pk col_1 col_2 col_3 row_0 2 3 4 5 row_1 11 12 13 14 row_2 101 102 1030 1040 よって、差分比較の結果としては、 table_1 の 1行目：table_1 にのみ存在するデータ（＝編集で削除された行データ） table_2 の 1行目：table_2 にのみ存在するデータ（＝編集で追加された行データ） table_1/table2 の 3行目：table_1 の 3行目の「col2」「col3」列の値が変更されたデータ のように差分が検出されることを期待しています。 具体的な実装例は以下の通りです。df_table_1 及び df_table_2 にそれぞれのテーブルに対応した DataFrame が定義されている前提として、DataFrame.merge で差分比較を実施しています。この関数自体は2つのテーブルを結合（マージ）する関数であり、結合条件は on 引数で、結合方法は how 引数で示されます。よって、以下の実装例は 全ての列を結合条件とした外部結合処理 となります。 純粋にテーブル間での差分比較を実施するために全ての列を結合条件としています。別の言い方をすると、結合条件に指定する列のみが差分比較の対象となり、それ以外の列における差異は無視されます。よって、ユースケースにより差分を検出したい列のみを結合条件に指定すると良いでしょう。 import pandas as pd df_table_1 = pd.DataFrame( [[1, 2, 3, 4], [11, 12, 13, 14], [101, 102, 103, 104]], columns=['pk', 'col_1', 'col_2', 'col_3'], index=['row_0', 'row_1', 'row_2'] ) df_table_2 = pd.DataFrame( [[2, 3, 4, 5], [11, 12, 13, 14], [101, 102, 1030, 1040]], columns=['pk', 'col_1', 'col_2', 'col_3'], index=['row_0', 'row_1', 'row_2'] ) df_compared = pd.merge(df_table_1, df_table_2, on=['pk', 'col_1', 'col_2', 'col_3'], how='outer', indicator=True) すると、実行結果として以下のような DataFrame が得られます。この _merge 列の内容が実質的に差分比較結果を示しており、それぞれ以下のような意味となります。つまり、both 以外の行については何らかの差分があるということになります。 both：両方のテーブルに存在している行データが一致している行 left_only：左側のテーブルにのみ存在している行 本実装例では table_1 が該当 right_only：右側のテーブルにのみ存在している行 本実装例では table_2 が該当 pk col_1 col_2 col_3 _merge 0 1 2 3 4 left_only 1 2 3 4 5 right_only 2 11 12 13 14 both 3 101 102 103 104 left_only 4 101 102 1030 1040 right_only 実行結果を見ますと、想定される差分比較結果の項目で示した内、1. と 2. の項目については想定通りに検出されていることが確認できます。一方で 3. の項目については left_only と right_only の両方が出力されています。 これは先述した外部結合のロジックを踏まえると自明なのですが、全列のデータを比較している以上 table_1 と table_2 で異なる行データとして出力されることから、即ち left_only と right_only の両方が出力されている行はデータの一部が変更されていることが分かります。ただ、この実行結果自体からはプログラム上でそれを簡単に判断することができません。よって、行データを一意に区別するための情報である PK 列で実行結果を GROUP BY することにより、各行ごとの差分比較結果を得ることができます。以下変更後のコードとなります。 本実装のロジック上、PK 列のみの行データ更新は実質的に行削除/行追加のセットとして認識されます。先述した通り、PK 列が行データを一意に区別するための情報であるためですが、これは一般的な RDBMS や KVS でもオペレーション上はそのような制約がある（PK列のみの変更はできず、行削除/行追加が必要）ことがあるため、差分比較のロジックとしても特に問題はないと判断しています。お客さんにも業務上そのようなオペレーションが基本的に発生せず、発生した場合は行削除/行追加のセットとして差分認識されても問題ないことを確認しています。 import pandas as pd df_table_1 = pd.DataFrame( [[1, 2, 3, 4], [11, 12, 13, 14], [101, 102, 103, 104]], columns=['pk', 'col_1', 'col_2', 'col_3'], index=['row_0', 'row_1', 'row_2'] ) df_table_2 = pd.DataFrame( [[2, 3, 4, 5], [11, 12, 13, 14], [101, 102, 1030, 1040]], columns=['pk', 'col_1', 'col_2', 'col_3'], index=['row_0', 'row_1', 'row_2'] ) df_compared = pd.merge(df_table_1, df_table_2, on=['pk', 'col_1', 'col_2', 'col_3'], how='outer', indicator=True).query(f'_merge != "both"').groupby(['pk']) for pk_cols, group in df_compared: print(f'pk_cols: {pk_cols}') print(group) その結果、以下のように PK の値ごとに差異のある行データがそれぞれ取得できていることが分かります。 pk_cols: (1,) pk col_1 col_2 col_3 _merge 0 1 2 3 4 left_only pk_cols: (2,) pk col_1 col_2 col_3 _merge 1 2 3 4 5 right_only pk_cols: (101,) pk col_1 col_2 col_3 _merge 3 101 102 103 104 left_only 4 101 102 1030 1040 right_only もちろんこのままでは3.のパターンについてどの列のデータに差異があるのか分からないため、Lambda 上では差異検出用のロジックを組んだ上で追加された行・削除された行・変更された行の3パターンに分けて最終的に JSON 形式で情報を出力するようにしていますが、そのあたりの実装は本情報を扱うアプリケーション/処理によって適宜変更されるものと思います。 なお、本実装の制約事項として、ロジック上テーブル定義（列定義）の異なる2つのデータを比較した場合はエラーが出力されてしまい比較できません。本アプリケーションにおいて列定義の変更はスコープ外としておりその観点では考慮の必要がありませんでしたが、アプリケーション外での列定義変更についてはユースケース上あり得るため、Lambda 上の実装では DataFrame.merge の実行前に列定義が同一であることを確認するようにしています。 そのような背景もあって、 テーブルデータのメンテナンス機能について補足したエントリ に記載している通り、テーブルの列定義はファイル単位で保持した上で、ファイルのハッシュ値のみで同一性を比較できるようにしています。   まとめ 本案件事例ではアプリケーション内の一機能として実装していますが、例えばデータベースの移行時や ETL/ELT 関連処理時においてデータベース外でテーブルデータの差分比較を実施したいケース自体はこれまでも度々あったため、備忘も兼ねてまとめてみた次第です。もちろん、データベース内で比較してしまうのが、処理速度やリソース面の観点も含めて一番手っ取り早い方法かと思いますが、ファイルベースで比較したいという機会も意外と多かったりするので・・ 本記事がどなたかの役に゙立てば幸いです。

1. はじめに こんにちは。SCSK志村です。 Azureの仮想ネットワークサービスにおける「ネットワークセキュリティグループ(以下NSG)」と「ルートテーブル」の既定値および実機挙動の確認方法についてまとめました。 2.NSGの既定値について NSGは作成時にAzure によって既定の規則が作成されます。 既定の規則の詳細は公式ドキュメントの以下に記述があります。 Azure ネットワーク セキュリティ グループの概要 | Microsoft Learn 受信規則の一つを例にとって確認してみます。 Priority source 送信元ポート 宛先 送信先ポート Protocol アクセス 65000 VirtualNetwork 0-65535 VirtualNetwork 0-65535 Any Allow source/宛先が「VirtualNetwork」に対するすべての通信が許可されていることが確認できます。 この「VirtualNetwork」は「サービスタグ」と呼ばれる、Azureで定義されたIPアドレスプレフィックスのグループを表します。 Azure サービス タグの概要 | Microsoft Learn 例えば、「VirtualNetwork」は仮想ネットワークアドレス空間をグルーピングしたものであることがわかります。 仮想ネットワーク アドレス空間 (仮想ネットワークに対して定義されているすべての IP アドレスの範囲)、すべての接続されたオンプレミスのアドレス空間、 ピアリング された仮想ネットワーク、 仮想ネットワーク ゲートウェイ に接続された仮想ネットワーク、 ホストの仮想 IP アドレス 、および ユーザーが定義したルート で使用されるアドレス プレフィックス。 このタグには、既定のルートも含まれる場合もあります。 上記の受信規則が実際の環境でどのような許可をしているのかを実機で調査してみました。 3.NSGの実機挙動の確認方法 Azure上で以下の環境を作成しました。 サービス IPアドレスプレフィックス/IPアドレス VNet 10.0.0.0/16 Subnet 10.0.0.0/24 VM 10.0.0.4 サブネットに既定の設定で作成したNSGを紐づけています。 公式ドキュメントの記載通り、「VirtualNetwork」からの通信が許可されています。 この「VirtualNetwork」が指す具体的なIPアドレスプレフィックスは、「有効なセキュリティルール」の機能で確認することができます。 ネットワークセキュリティグループの画面から　「ヘルプ」>「有効なセキュリティルール」を表示します。 対象サブネットに存在する「仮想マシン」・「NIC」を選択すると対象のNICで有効となっているルールが表示されます。 ここでサービスタグ「仮想ネットワーク※」を選択します。 ※表示により「VirtualNetwork」と「仮想ネットワーク」の翻訳の表記ゆれが発生するのでご注意ください。 アドレスプレフィックスとしてソース、宛先に「10.0.0.0/16」「168.63.129.16/32」と表示されました。 「10.0.0.0/16」：このSubnetが存在するVNetのIPアドレスプレフィックス 「168.63.129.16/32」：Azureプラットフォームリソースへの通信で利用するIPアドレス(ホストノードの仮想 IP) IP アドレス 168.63.129.16 とは | Microsoft Learn この2つのIPアドレスプレフィックスが「VirtualNetwork」タグとしてグルーピングされていることを確認することができました。 受信規則も送信規則も許可されているので同一VNet内の通信は既定の設定で許可されていることがわかります。 4.ルートテーブルの既定値について 次にルートテーブルの既定値を確認します。 既定のルートの詳細は公式ドキュメントの以下に記述があります。 Azure 仮想ネットワーク トラフィックのルーティング | Microsoft Learn Azure 仮想ネットワークのサブネットごとにルート テーブルが自動的に作成され、既定のシステム ルートがテーブルに追加されます。  と記述があるため、このシステムルートの一つを例にとって確認してみます。 ソース アドレス プレフィックス 次ホップの種類 Default 仮想ネットワークに固有 仮想ネットワーク 仮想ネットワーク(VNet)のIPアドレスプレフィックスの次ホップが仮想ネットワークとなっています。 仮想ネットワーク内のルーティングはシステムルートで定義されていることが確認できます。 上記のシステムルートが実際の環境でどのような許可をしているのかを実機で調査してみました。 ５.ルートテーブルの実機挙動の確認方法 既定の設定でルートテーブルを作成し、サブネットにアタッチします。 システムルートが存在するはずですが、表示上はルートが存在しないことが確認できます。 実際にルートは存在しないのか、どのようなルートが有効になっているのかは「有効なルート」の機能で確認することができます。 ルートテーブルの画面から　「ヘルプ」>「有効なルート」　を開き、「仮想マシン」・「NIC」を選択します。 すると、対象のNICで有効となっているルートが表示されます。 ルートテーブル上には何も表示されませんでしたが、有効となっているルートが存在することを確認できます。 VnetのIPアドレスプレフィックス「10.0.0.0/16」のネクストホップが仮想ネットワークとなっており、先のシステムルートの記述の通りとなっていることがわかります。 表示上ルートは存在しませんがルートテーブルの確認時は「システムルート」が有効化されていることに注意が必要です。 6.まとめ NSG、ルートテーブルの既定値と実機挙動の確認方法をまとめてみました。 既定で一定の通信が許可されるのはユーザフレンドリーではありますが、想定しない通信許可にもつながります。 設計通りの通信許可となっているか実機で確認をしておくと安心と考えます。 この記事がAzureにおけるネットワーク設計の一助になれば幸いです。

この記事はCatoクラウドをご利用中の方に向けた重要なお知らせです。 2024年11月に Cato Networksより、Catoクラウドのルート証明書が更新される旨の下記アナウンスがありました。 FAQ for the New Default Cato Certificate for TLS Inspection 現在のルート証明書は、有効期限が2025年10月29日までとなっています。この期限前までに各Catoクラウド環境にて新しいルート証明書への切り替え作業が必要です。 SCSKのご契約者様向けFAQサイトにも詳細を掲載しておりますが、本件に関するお問い合わせを多数いただいていることから、この記事でも対応方法、よくあるご質問等をご説明します。 この記事の要約 現在、Catoクラウドのルート証明書は、有効期限が2025年10月29日までのもの(旧証明書)と、2034年3月3日までもの(新証明書)の2種類が存在します。 2024年11月以前は旧証明書のみが配布されていたため、ご利用の多くのお客様は、新証明書への切り替えを行う必要があります。 ルート証明書は、端末側では新旧の両方をインストール可能です。しかしながら、Catoクラウド側で利用されるルート証明書は1つのみのため、すべての端末で新証明書のインストールが完了した後に、Cato管理画面から証明書の切り替えを行います。この作業は、旧証明書の有効期限である2025年10月29日までに完了する必要があります。 WindowsでCatoクライアントをご利用の場合は新旧証明書が自動でインストールされますが、macOS、Linux、iOS(iPhone/iPad)、Androidについては、新証明書を手動でインストールする必要があります(※macOSは例外があるため記事内容をご参照ください)。また、Catoクライアントをインストールしていない端末は、どのOSであっても新証明書の手動インストールが必要です。 ただし、Catoのルート証明書を利用せず、お客様独自のルート証明書を利用されている場合は、本対応の対象外となります。 前提情報 Catoクラウドのルート証明書とは? Catoクラウドには、TLS Inspectionという機能があります。これは、暗号化されたHTTPSトラフィックをCato PoP上で検査する仕組みで、セキュリティ上重要な機能です。TLS Inspectionが有効な環境では、端末がHTTPS接続を行う際にCatoクラウドのルート証明書が使用されます。そのため、Catoクラウドを経由して通信するすべての端末に、このルート証明書のインストールが必要となります。 また、ルート証明書はTLS Inspectionの他に、Firewall等での通信Block/Warning時の警告画面を表示するときにも使用されています。このため、TLS Inspectionを利用していない場合であっても、端末にルート証明書のインストールが必要です。 証明書の有効期限切れとは? すべての電子証明書には有効期限があり、期限を過ぎると使えなくなってしまいます。 Catoクラウドの既存のルート証明書は10年の有効期限で発行されており、2025年10月29日に期限切れとなります。これ以降は使用することができないため、 もし新しいルート証明書に切り替えをしなかった場合、HTTPSのWebページが表示できなくなる等の影響があります。 本記事では、以降の項目にて新しいルート証明書への切り替え方法をご案内していきます。 対応フローチャート まず、対応の流れは以下となります。 作業Step0: 対応が必要かどうか確認 ご利用の環境で対応が必要かどうかは、CMA(Cato管理画面)から確認可能です。Security > Certificate Management から、現在有効となっているルート証明書がどれなのかをご確認ください。 「2015～」と「2024～」の行があり、 2015のほうが「Active」になっている場合 👉️対応が必要です。「2024～」への切り替えを行う必要があります。 Step1へ進んでください。 「2024～」の1行のみがあり「Active」になっている場合 👉️ 対応は不要 です。2024年11月以降で開設されたアカウントのため、すでに新しい証明書が適用されています。 「2015～」と「2024～」の行があり、2024のほうが「Active」になっている場合 👉️ 対応は不要 です。すでに切り替えが完了しています。 「Custom Certificate」が「Active」になっている場合 👉️ 対応は不要 です。Catoのルート証明書ではない独自証明書を利用されています。証明書期限はご自身で管理をお願いいたします。 作業Step1: 各端末へ新しいルート証明書をインストール Catoクラウドを使用するすべての端末に、新しいルート証明書をインストールし、新旧両方の証明書が入っている状態にします。 OSや利用状況ごとに必要な対応が異なる点にご注意ください。 Windowsで、Catoクライアントをインストールしている端末 Catoクライアントがアップグレードされる際に、新証明書が自動でインストールされます。クライアントがバージョン5.11以上であれば新証明書もインストール済みです。もしそれ以下の場合には最新バージョンにアップグレードしてください。 macOSで、Catoクライアントをインストールしている端末 クライアントバージョン5.7以上を新規にインストールした場合は、新証明書・旧証明書の両方が自動でインストールされますので、対応不要です。 5.6以下をご利用中の場合、または 5.6以下から5.7以上へアップグレードした場合には、新証明書が自動でインストールされません。 新証明書の配布・インストールが必要です。 また、いずれの場合も、キーチェーンアクセスからCatoのルート証明書を信頼設定してください。 Linux、iOS、Androidで、Catoクライアントをインストールしている端末 新証明書が自動でインストールされません。新証明書の配布・インストールが必要です。 なお、Linux・Androidは TLS Inspectionの対象外ですが、ルート証明書はFirewall等の警告画面の表示にも使用されているため、インストールが必要です。 OSを問わず、Catoクライアント未導入で、Catoのネットワーク内にある端末 拠点内の据え置きPCなど、Catoクライアントをインストールしていない、Catoのルート証明書のみを導入している端末では、 新証明書が自動でインストールされません。新証明書の配布・インストールが必要です。 各OSの証明書導入手順 新しいルート証明書は、 Catoダウンロードサイト より入手可能です。 また、各OSへの導入手順は、以下のCato KnowledgeBase をご参照ください。 Windows Installing the Cato Certificate on Windows Devices macOS Installing the Cato Certificate on macOS Devices iOS Installing the Cato Certificate on iOS Devices Android Installing the Cato Certificate on Android Devices Linux 環境ごとに異なるため、OSのドキュメント等をご確認ください なお、各端末への新証明書の配布・インストールは、手動での対応の他、ご利用のActive DirectoryやMDM・端末管理システムから配布する方法もあります。 作業Step2: CMAからルート証明書を切り替え 以降の作業は、全ての端末に新証明書を導入した後に実施してください。切り替え作業後は、新証明書が入っていない端末は通信不可となります。 Cato側で利用する証明書を、新証明書に切り替えます。 CMAで Security > Certificate Management を開きます。「2024～」の行の右端「…」から「Activate」をクリックします。 切り替えの確認画面が表示されます。「OK」をクリックします。 切り替えすると以下のように「2024～」のほうが「Active」となります。 以上で、ルート証明書の切り替え作業は完了です。 よくあるご質問 ルート証明書の切り替えに関し、これまでにいただいているご質問をご紹介します。 端末に新・旧両方の証明書をインストールして問題ないのか はい。両方の証明書が入っていても、OSやCatoクライアントの動作には問題ありません。 旧証明書を入手したいときはどうしたらよいか Catoダウンロードサイト から入手できる証明書は、すでに新証明書となっています。旧証明書が必要な際は、CMAにログインし Security > Certificate Management を表示、「2015～」行の右端「…」をクリックしダウンロードしてください。 TLS Inspectionを利用していないが、証明書更新は必要なのか 必要です。ルート証明書はTLS Inspectionの他に、Firewall等の警告画面を表示するときにも使用されているためです。 なお、Catoクラウドの機能を有効活用いただくため、TLS InspectionはONとすることを強くおすすめしております。 端末側で旧証明書・新証明書を見分けるにはどうしたらいいか 証明書のCommon Name(CN)が異なりますので、表示される名前で判別可能です。 旧証明書(2015) ⇒ Cato Networks CA 新証明書(2024) ⇒ Cato Networks Root CA もちろん有効期限で見分けることも可能です。 新証明書へ切り替え後、一部の端末のみWebサイトが正しく表示できない 当該端末に新証明書がインストールされていない可能性があります。端末側を確認してください。 新証明書へ切り替え後、特定のアプリケーションやブラウザのみ利用不可となった アプリケーションやブラウザによっては、OSの証明書を参照しないものがあります。 その場合、当該アプリケーションへ個別に新証明書を設定する必要があります。 例) JavaSE、Git、IntelliJ、Firefox Developer Edition、Waterfox等 新証明書に切り替えしたが、旧証明書を使うよう戻したい 「2015」のほうの証明書をActivateすることで戻せます。切り替え・切り戻しに回数等の制限は無く、何度でも可能です。 切り替え完了後、旧証明書はどうしたらよいか 端末側の旧証明書はそのままで差し支えありませんが、削除しても問題ありません。CMA側は、現時点ではそのまま表示され続けます。今後削除されるかどうかは未定です。 今後もこのような証明書更新が発生するのか 新証明書の期限が2034年のため、2033年に同様の更新が必要となる予定です。 最後に 以上、ルート証明書更新についてのご案内でした。期限は2025年10月29日ですが、早めの対応をお願いいたします。 ご不明な点がありましたら、SCSKをはじめ、Catoクラウドのライセンス提供元へお問い合わせください。

SCSKの畑です。 今回は完全に Nuxt3 に閉じた話題ですが、アプリケーションのルーティングパス設計を当初の意図通りのものにするのにちょっと苦労したので、その経緯と解決策もといちょっとした Tips について紹介してみます。タイトルの通り完全に小ネタです。。。   本題 これまでのエントリで取り上げてきた Redshift テーブルデータのメンテナンスアプリケーションにおいては、テーブルの主な編集状態（ステータス）が以下3種類定義されており、設計上それぞれで画面（URL パス）を分けています。 normal：通常状態 editing_content：テーブルデータの編集中 awaiting_approval：編集後のテーブルデータ更新承認待ち 以前のエントリ で記載したような更新承認用の簡易ワークフローに対応 上記の各画面に対応した機能が各テーブルで共通であることから、実装及びメンテナンスコストを抑えるために各テーブルごとにページ/コンポーネントは作成せず、共通化する方針としていました。よって、テーブル名については URL パスからパラメータとしてページ/コンポーネントに渡してあげるような形で、以下のような URL パス設計を考えていました。対象テーブルのステータスが normal であればテーブル名のみ、そうでなければ対象のステータスがその後ろの URL で指定されるような形式です。 <ルートURL>/mastertable/<テーブル名>：通常状態の画面 <ルートURL>/mastertable/<テーブル名>/editing_content：テーブルデータの編集中画面 <ルートURL>/mastertable/<テーブル名>/awaiting_approval：テーブルデータ更新承認待ち画面 Nuxt3 の場合はデフォルトでファイルシステムベースのルーティングが使われており、pages ディレクトリ配下のファイル/ディレクトリ配置に応じてルーティングが定義されます。また、パスの一部をパラメータとしてページ/コンポーネントに渡すような動的ルーティングも可能となっており、ファイル/ディレクトリ名の一部を [] で囲むと、その部分がパラメータとして解釈されます。先述の通り、今回の場合はテーブル名を [table_name] としてパラメータとして渡すことを考えて、ファイル/ディレクトリ構造を以下のようにしていました。 pages/mastertable ├ [table_name].vue：通常状態の画面 └ [table_name] ├ editing_content.vue：テーブルデータの編集中画面 └ awaiting_approval.vue：テーブルデータ更新承認待ち画面 ところが、この方法だと上手くいきませんでした。[table_name] の定義が同じディレクトリ階層で重複してしまったことが原因と考えられますが、ちょっと調べた限りでは他の方法が見当たらず。 後から調べたところ Nested Routes というルーティング（というよりはファイル/ディレクトリ構造によりページ/コンポーネントをネストする仕組み？）に該当していたようなのですが、どちらにせよ本来の目的外でした。。 pages · Nuxt Directory Structure Nuxt provides file-based routing to create routes within your web application. nuxt.com この時点では各機能の開発中であったため以下のような仮のルーティングに変更して作業を進めていたのですが、URL パスの末尾にテーブル名が来てしまい当初の設計通りになっていない上、各画面の Vue ファイル名が同一になってしまう分かりづらさなども相まって、事あるごとに何とかならないかとモヤモヤすることに。 pages/mastertable ├ [table_name].vue：通常状態の画面 ├ editing_content └ [table_name].vue：テーブルデータの編集中画面 └ awaiting_approval └ [table_name].vue：テーブルデータ更新承認待ち画面 その後開発が進み、テーブルデータのバージョン管理（参照）機能を追加したのですが、バージョン情報を URL パスとしてどう取り扱うかを検討する必要がありました。同機能においても画面としては通常状態のものを共用する想定であり、バージョン情報を URL パスとして渡すかどうかで画面上に表示するデータの種類（最新データ or 指定バージョンのデータ）を切り替えるようなイメージで考えていました。 それと合わせて先述したルーティングの課題についても検討すべく色々調べた結果どうにか解決策に辿り着き、最終的には以下のようなディレクトリ構成となりました。 pages/mastertable └ [table_name] ├ [[version_index]].vue：通常状態（最新データ）の画面 兼 特定のバージョンデータ参照画面 ├ editing_content.vue：テーブルデータの編集中画面 └ awaiting_approval.vue：テーブルデータ更新承認待ち画面  version_index というバージョン情報を表すルートパラメータを [[]] で囲んでいますが、この記法が解決策のキモでして、オプショナル（省略可能）なルートパラメータという意味合いとなります。 pages · Nuxt Directory Structure Nuxt provides file-based routing to create routes within your web application. nuxt.com 即ち、URL パスに version_index ルートパラメータを含むか否かで画面に表示するデータの種類の出し分けを行うロジックを実装できる上、URL パスとしても <ルートURL>/mastertable/<テーブル名>：通常状態（最新データ）の画面 <ルートURL>/mastertable/<テーブル名>/<バージョン情報>：特定のバージョンデータ参照画面 <ルートURL>/mastertable/<テーブル名>/editing_content：テーブルデータの編集中画面 <ルートURL>/mastertable/<テーブル名>/awaiting_approval：テーブルデータ更新承認待ち画面 のように、通常状態（最新データ）に対応する URL パスはバージョン番号が省略された結果テーブル名のみの形式となり、編集中/承認待ちの場合はテーブル名の後ろに対応するステータス名が指定される形式となります。よって、バージョン情報の取り込みと共に当初の設計通りの URL パスを指定することができ、無事にモヤモヤ感も解消することができました。。 なお、本解決策は以下の Nuxt3 解説書を読んでいて見つけたものだったのですが、公式 URL をよくよく見るとちゃんと書いてありました。あまりにシレっと書いてあるので、このエントリを書くにあたって改めて見返すまで気づきませんでしたが・・ Nuxt 3 フロントエンド開発の教科書 本書は，最近需要が急増しているSSR（Server Side Rendering）によるSPA開発に適したWebアプリケーションフレームワーク「Nuxt 3」の解説書です。Nuxtは，最新のバージョン3でVue 3に完全対応したことで，Co... gihyo.jp ちなみに、Nuxt3 ではカスタムルーティングを実装することも可能ですが、本案件事例ではそこまでの必要性がなかったため本記事では触れません。そのあたりも含めたルーティング設定の詳細については以下のサイト様がよくまとまっているかと思いました。 Nuxt 3 × Vue Router の主要な機能をまとめてみた zenn.dev   まとめ Nuxt3 における動的ルーティングについては色々な情報があるのですが、オプショナルなパラメータの使用例も含めた情報はそれほど多くないように思えたため、備忘がてら書いてみた次第です。 本記事がどなたかの役に立てば幸いです。

本記事は 新人ブログマラソン2024 の記事です 。 皆さん、こんにちは！新米エンジニアの佐々木です。 今日は、企業のデータ活用をグッと加速させる、ビッグなお知らせがあります！ 企業のデータ活用を強力に後押しするため、 SCSKはSnowflake Inc.と販売代理店契約を結びました！ これにより、 SCSKからSnowflakeを販売できるようになりましたが、それだけではなく、Snowflakeの導入から運用・保守に至るまでの技術支援、また、 最短5日でSnowflake環境を用意することができるサービス など、魅力的なサービスラインナップを用意しました！ なぜ、このサービスが必要なのか？ 多くの企業がDX（デジタルトランスフォーメーション）やAI（人工知能）の活用に大きな期待を寄せていますが、実際にはデータが社内のあちこちに散らばっていて、なかなか有効活用できていないのが現状です。特に大企業では、組織の壁がデータの一元管理を阻み、本格的なデータ活用が進んでいないという課題があります。 そこでSCSKは、このデータ管理の課題を解決して企業がもっと手軽に、そして効果的にデータを使えるように、Snowflakeと連携したサービスを提供開始しました！ Snowflakeとは？ Snowflakeとは、シンプルで効率的、そして信頼性の高いAI活用を実現するためのデータプラットフォームです。 世界中の1万社以上もの企業が、このSnowflakeのAIデータクラウドを活用し、データ共有、AI/機械学習アプリケーションの開発、そしてAIによるビジネスの強化に取り組んでいます。 Snowflakeのここがすごい！ マルチクラウド対応:  Amazon Web Services、Microsoft Azure、Google Cloudといった主要なクラウドプラットフォームで利用可能。 データ共有とエコシステム:  データ共有やマーケットプレイスを通じて、安全かつ柔軟なデータコラボレーションが実現。 高パフォーマンス & メンテナンスフリー:  コンピューティング層とストレージ層が分離されているため、高いパフォーマンスを維持しながら、運用にかかる負担を大幅に軽減。 Snowflakeについてもっと詳しく知りたい方はこちらへ！ Snowflake AIデータクラウド | Snowflake Japan Snowflakeデータクラウドにぜひご参加ください。このグローバルネットワークでは、何千もの組織がコラボレーション、多様なワークロードの強化、データアプリケーションの構築を行っています。 www.snowflake.com SCSKのSnowflake活用サービス：3つのポイント SCSKは、Snowflakeを活用してお客様のデータ活用を強力にサポートします。主なサービスは以下の3つです。 クラウドデータ活用基盤クイックスタートパック： データ分析に必要なシステム環境を、Snowflakeを含めて 最短5日 で構築できるテンプレートをご提供。すぐにデータ活用を始められます。 Snowflakeテクニカルエスコートサービス： データ戦略の企画から、基盤構築、運用、活用まで、Snowflakeのエキスパートがお客様に寄り添い、データ活用を内製化できるようサポートします。 「ナレコレBI」のSnowflake対応： SCSKのデータ分析ツール「ナレコレBI」がSnowflakeに対応。Snowflakeのスモールスタートの強みを活かし、「ナレコレBI」を導入することで、より迅速にデータ分析を始めることが可能です。 各サービスについては近日中にそれぞれ別ブログとして発信しようと思っているので、乞うご期待下さい！ 今後の展開 SCSKは、今回発表した「クラウドデータ活用基盤クイックスタートパック」を、 2025年度に10社、2027年度までに累計30社 のお客様にご導入いただくことを目標としています！ さらに、Snowflake関連サービスを拡充するとともに、これまで培ってきた基幹・サプライチェーン領域のソリューションとの連携も視野に入れ、データ活用の可能性を広げる新たなサービスを開発していきます！ 皆さんも、SCSKの今後のデータ活用に関する取り組みに、ぜひご期待ください！ 最後に 最後に、本件に関する内容は社外向け発信文書としても公開しておりますので、是非以下もご覧ください！ https://www.scsk.jp/news/2025/pdf/20250311i.pdf

SASE。ゼロトラスト。 「近年バズワードとして注目されていることは知っているが、調べてみてもよく分からない。」 「ネットワークやセキュリティのソリューションなのは理解できたが、自分の言葉で説明できない。」 私は2024年12月から新たにSASEを担当することになりましたが、最初に感じた壁が上記でした。 今回は私のような「これを機にSASEを理解したい」という方に向けて、超初心者向けの「SASEとは？」を説明していきます。   SASEの概要 まずはSASEについて、その概要をご説明します。 表面だけでなく、自分の中に落とし込んで理解することが大事だと思いますので、本記事を見て腑に落ちない部分があれば、ぜひ他の記事などで深掘りしてみてください。 SASEを一言で言うと SASEを一言で言うと「“ネットワーク”と“ネットワークセキュリティ”をクラウドベースで統合したもの」 です。 ※SASEとは、 S ecure A ccess S ervice E dgeの略 となります。 “ネットワーク”とは・・・ 光ファイバーや専用線などで行うような通信の提供と、その通信を制御・管理する仕組みのことを指します。 具体的には、SD-WAN、MPLS、Ethernet、VPN、AWSのDirect Connect、AzureのExpressRouteなどです。 “ネットワークセキュリティ”とは・・・ ネットワークの利用に関わるあらゆる脅威を防御する仕組みを指します。 具体的には、ファイアウォール、セキュアゲートウェイ(SGW)、CASB、DLPなどです。 上記を一体化しクラウドサービスで提供する製品(もしくはそのような概念)を、SASEと呼びます。 ちなみに、ここから“Access(ネットワーク)”を抜いた、SSE(Secure Service Edge)という概念・製品もあります。 詳細を知りたい方は、以下を参照ください。 SSEとSASEどちらを選べばよいのか？ SSE（Security Service Edge）とSASE（Secure Access Service Edge）どちらを選択すれば良いのかについて解説を行っています。 blog.usize-tech.com 2023.11.27 なお、SASEとゼロトラストの違い・関係についてイマイチ理解できない、という方もいるかもしれません(私もそうでした)。 これらの関係性をイメージするために、次はゼロトラストについて説明します。 ゼロトラストの考え方と、SASEとの関係性 ゼロトラストとは、サイバーセキュリティにおける概念(考え方) です。 どんな概念かというと、 「すべて信用しない(Zero Trust) という前提に立ち、適切な認証を受けたユーザーと端末だけが、許可されたアプリケーションやデータにアクセスできるようにする」 というものになります。 これは、従来の 境界型セキュリティの考え方、 「外部(インターネット)と内部(社内LAN)を境界で分け、内部は信用できるという前提のもと、内部を外部攻撃から防御する」 とは全く異なる考え方 となります。 IaaS(AWSなど)やSaaSの普及、リモートワークの増加、サイバー攻撃の巧妙化に伴い、徐々にゼロトラストが重要視され始めました。 ゼロトラストアーキテクチャ（ゼロトラストを実現するための7つの要素） は、以下のように定義されています。  これら各要素のサービスを提供する会社が、それぞれ“ゼロトラスト”を謳っているため、世の中には様々な“ゼロトラストソリューション”が存在します。(会社によっては、MFAも“ゼロトラストソリューション”と呼ばれ、CASBも“ゼロトラストソリューション”と呼ばれます。) いろいろな製品が“ゼロトラストソリューション”と呼ばれると分かり辛いのですが、 SASEに関しては、ゼロトラストアーキテクチャ上で、主に“ネットワークセキュリティ”の要素/機能を提供するソリューション です。 つまり、SASEはゼロトラストを実現する要素の1つ、と言うことです。 繰り返しになりますが、 SASE自体は“ネットワーク”と“ネットワークセキュリティ”のクラウドソリューションである 、とご理解ください。 SASEを構成する機能 SASEが持つべき機能は何なのか？　を具体的に以下に羅列します。 ※こちらは、私がGartner(最初にSASEを提唱した会社)のレポートから、分かりやすさ/耳なじみの良さを重視して再整理したものです。 ＜ネットワーク機能＞ ・プライベートバックボーン(専用の回線)、SD-WAN、Proxy、WAN最適化、QoS、ネットワークアプライアンス(NW機器)　他 ＜ネットワークセキュリティ機能＞ ・ファイヤーウォール(FW)、SWG、ZTNA、CASB、RBI　他 ※出典：Magic Quadrant for Single-Vendor SASE, Published 3 July 2024 また、これら全てはクラウドベースで提供されることが大前提となります。 なお、 世の中にSASEを呼称するソリューションは沢山ありますが、その中には、上記全ての機能が含まれていない製品も数多くあります。 （例えば、ネットワークセキュリティ機能はあるがSD-WAN、Proxyの機能はない・・・など） SASEを検討される際には、「自社に必要な機能は何なのか？」、「その機能が検討しているSASEに含まれているのか？」について、ぜひ整理していただければと思います。 ※弊社にご相談いただければ、お客様の要件と最適なSASEについて、ご一緒に整理させていただきます。   SASE導入のメリット 「SASEが一体何なのか？」、少しでも理解が深まりましたでしょうか？ 概要が理解できれば、次のステップとして 「SASEは私達にどんな価値をもたらすのか？」 が気になるところです。 SASEは、 境界型(従来型)のネットワーク/セキュリティを利用している方にとって多大なメリット がありますが、複合的で一言では表現し辛いため、自分なりの分類で説明してみます。 ＜SASE導入のメリット＞ No 特徴(利点) 価値をもたらす領域 ① ネットワーク構成がシンプルになる 運用面、コスト面、セキュリティ面 ② 全ての通信をリアルタイムに一元管理できる (ネットワークの)品質面、運用面 ③ 境界だけではなく、拠点/端末間の通信も全てセキュアに管理できる セキュリティ面 ④ すぐに利用できる・スモールスタートできる デリバリー面、コスト面 ①ネットワーク構成がシンプルになる これが、 SASEの最大の特徴であり、かつ最大のメリット だと思います。 従来型のネットワークは、複数キャリアを使い分け・管理していたり、セキュリティ機器がバラバラであったりと、シンプルな構成ではないことがほとんどです。 近年ではリモートワーク環境、SaaS・IaaSの導入が急激に進んだことで、継ぎ接ぎの対応による更なる複雑化が進んでしまっています。 SASEでは、 ネットワークとネットワークセキュリティの機能が全てクラウドサービスで提供 されるため、 これまで多種多様な機器・サービスで対応していたネットワーク領域を集約化 できます。 ネットワーク領域の集約化によって、 運用負荷は大きく軽減 されます。（キャリア/機器ごとの細かな管理・調整は必要なくなります。） コスト面では、 通信キャリアのサービスや各種機器にかかる費用は不要と なります。 もちろんSASE分のコストは新たに発生しますが、ネットワーク全体のコストで見ると、環境次第で大幅な削減が可能となります。 また、集約化により企業の セキュリティポリシーも統一化され、一元管理が可能 となるため、企業のセキュリティレベルを向上させます。 ②全ての通信をリアルタイムに一元管理できる 従来のネットワーク(インターネット・専用線)では、専用の分析ツール・サービスなどを利用しない限り、通信量や通信内容を可視化することができません。 つまり 「誰が」、「いつ」、「どこに」、「どれくらい」通信したかが、分からない状況 です。 この状態には、様々な問題があります。 まず、通信帯域がひっ迫している場合に、その原因特定・対処が出来ません。 そうすると、品質が悪いという結果論で、本当は必要ない回線増強(コスト増)を行ってしまう可能性があります。 ※具体的に例えると、通信がひっ迫している原因が実は「多くの社員が業務内にYoutubeを見ているから」だと特定できれば、 回線増強をしなくても、社員へのYoutubeアクセスを制限するだけで問題は解決するかもしれません。 同様に、ネットワーク障害やセキュリティインシデントが発生した場合にも、その原因特定・対処が困難となります。 (対応できる場合もありますが、可視化している場合と比べて格段に時間を要します。) SASEでは、 全ての通信量・通信内容をリアルタイムに可視化・一元管理でき、上記のような問題を解消 します。 ③境界だけではなく、拠点/端末間の通信も全てセキュアに管理できる サイバー攻撃はどんどん巧妙化しており、もはや従来の境界型セキュリティでは対応しきれなくなっています。 例えば、直近の脆弱性を突いた「ゼロデイ攻撃」、セキュリティの弱い子会社・関連会社・地方/海外拠点からターゲットの企業に侵入する「サプライチェーン攻撃」などが有名です。 また、「フィッシング(メールを通じた偽URLへの誘導など)」もかなり巧妙化しており、馬鹿にできません。 境界型セキュリティ(内部は安全)のネットワークでは、外部からの攻撃は想定(対策)していても、社内通信を利用した内部からの攻撃は想定(対策)していません。 つまり、高度な攻撃で一度社内に侵入されると、全てのシステムに自由にアクセスされてしまいます。 毎年、こういった方法で多くの企業がランサムウェアや情報漏洩の被害に遭っています。 この問題を解消するために注目されているのが「ゼロトラスト」であり、SASEはその実現を手助けします。 先述の通り、 SASEは クラウドで“ネットワーク”と“ネットワークセキュリティ”を提供 する製品 です。 それは、 外部だけでなく、内部(拠点/端末間の通信)も全てセキュアに管理できる ということであり、拠点を経由しターゲット侵入する　「サプライチェーン攻撃」への防御を可能とします。 また、 クラウドサービスのため自社で管理するセキュリティ機器は無くなり 、「ゼロデイ攻撃」など脆弱性を狙った攻撃も回避できます。 ※各種機器の脆弱性対応（パッチ適応・バージョンアップ作業）は、SASEベンダー側で厳格に管理・実行されます。 巧妙化するサイバー攻撃への対策には、SASEの導入が大きな効果を発揮します。 ④すぐに利用できる・スモールスタートできる これはクラウドサービスの一般的なメリットですが、もちろんSASEでも同様です。 従来、新たな回線を手配する場合には、開通まで数か月程度のリードタイムが発生します。(増速する場合にも、同様に数か月必要です。) セキュリティ機器に関しても、モノにもよりますが少なからず納期の影響を受けます。 クラウドサービスである SASEでは、インターネット回線さえあれば、新規回線の手配や増速にリードタイムを必要としません。 （既存ネットワークやSASEの設定・構築期間は必要となります。） 所定の手続きの経てライセンスが発行されれば、即利用可能となります。 すぐに利用可能なため、SASEはスモールスタートしやすいソリューションでもあります。 クラウドサービスの特性を活かして、小規模から始められる価格形態のSASEも多数あります。 最小構成から始め、後から必要に応じて拠点/帯域/セキュリティ機能などを追加する 、 という柔軟な導入を行える事が、SASEの強みの１つとなります。   おわりに SASEを学び始めて3ヶ月の私の言葉で、できるだけ詳しくない方にも伝わるように解説してみました。 「SASEとは何？」「何が魅力なの？」について、理解が深まりましたでしょうか？ 何か知識を身に着けるうえで「しっかり理解すること(=自分の中に落とし込み、嚙み砕き、自分の言葉で説明できるようになること)」は　とても大事ですが、解説サイトや説明資料を見ても表面上・文字面でしか理解できない、という悩みは良くあると思います。 特にSASEは、ネットワークやセキュリティ関連の経験があれば別ですが、初心者の方にとっては「しっかり理解すること」が難しい領域だと感じています。 私も3ヶ月前までそういった経験がなく、とても苦労しました。 この記事が、皆さんのSASEに対する理解を深める一助となれば、嬉しく思います。 最近は、 生成AIを活用するとより具体的で分かり易く解説してくれたりもする ので、ピンとこなかった説明は、ぜひご自身でも深掘りしてみてください。

SCSKの畑です。 弊社 AWS 環境で開発したアプリケーションをお客さんの AWS 環境に移行したのですが、移行当初は正常動作しなかったため、原因切り分けのためにタイトルの内容を試しました、という内容となります。   背景 お客さんの AWS 環境（AWSマネジメントコンソール）上から実行できるオペレーションが IAM 権限により限定されていた、という話は 初回のエントリ でも説明した通りなのですが、構築や実装に使用する変更関連の権限だけでなく、参照関連の権限についても付与対象が絞られていました。その1つとして 「IAM ロール/ポリシーに割り当てられている IAM 権限が確認できない」 という制限がありました。 元々このお客さんの AWS 環境は過去フェーズの案件も含めて数年前から使用していたのですが、当初は StepFunctions や Lambda を使用して Redshift にデータを投入するための ETL/ELT を実装するような内容がメインでした。元々バックエンド側の開発はフロントエンド側と比較して手慣れていたことや、エラー発生時にまず確認すべき CloudWatchLogs には参照権限があったため、この制限があってもそこまで問題を感じていませんでした。（もちろんこれが原因でエラーの切り分けに苦労したことも過去ありましたが・・）また、切り分けの結果 IAM 権限の問題が疑われる場合に設定内容の開示や追加設定をお願いすることは問題ありませんでした。 ただ、本案件事例にて実装したアプリケーションはこれまでと異なりフロントエンド/バックエンド両方の開発要素を含んでおり、かつ使用するサービスも多いため、これまでと比較してエラー発生時の原因切り分けや究明に手間取ってしまうことがありました。今振り返ると、今回取り上げる内容もその延長線上にあったのだなと思いますが・・   アプリケーション移行後の動作確認中にエラー発生 冒頭で記載した通り、弊社 AWS 環境で開発したアプリケーションをお客さんの AWS 環境に移行した後の動作確認中に、Cognito ユーザ認証後にクライアント側から AppSync API を叩いたタイミングで以下のようなエラーが発生しました。 { message: "Unauthorized", recoverySuggestion: `If you're calling an Amplify-generated API, make sure to set the "authMode" in generateClient({ authMode: '...' }) to the backend authorization rule's auth provider ('apiKey', 'userPool', 'iam', 'oidc', 'lambda')` } 先にエラー発生の原因についてネタばらししてしまうと、単純に Cognito ID プールの「認証されたロール」経由で付与される IAM ポリシーにおける appsync:graphql 権限の resource 句が正しく設定されていなかったことにより、結果として同 IAM 権限が不足していたことによるものでした。（本案件事例における AppSync の 認可方式については、 このエントリ の内容をご参照ください） ところが、上記アプリケーション側のログからだけでは当初原因が掴めませんでした。 message の内容は「Unauthorized」という単語のみなので原因究明には不十分であり、かつ Cognito ユーザ認証後に AppSync API を叩いている以上 Unauthorized と判定されている理由からしてそもそも良く分からない。 recoverySuggestion の内容は Amplify のスキーマ定義における @auth 句の設定に関する内容と思われ、そもそも弊社環境においては同じ設定で問題なく動作している以上、設定変更しても本質的な解決に繋がらないことが推測されたのでこちらも情報としては参考にならないと判断。 では AppSync のログに何かしら出ているのでは？と考えて CloudWatchLogs を見てみたのですが・・ { "logType": "RequestSummary", "requestId": "eafb8d66-f76c-4100-a836-e860dbca1808", "graphQLAPIId": "<graphQLAPIId>", "statusCode": 401, "latency": 63460261 } bd4f8c67-6eb0-4c98-8c6a-432e6f9f57dd Response Headers: {x-amzn-ErrorType=UnauthorizedException} 以上のように、ほぼアプリケーション側のログと同じ程度の情報量しかなかったため、同じく参考にならず。 なお、本エントリの作成にあたり手元の環境で再現試験を実施してみたのですが、AppSync のログレベルを「すべて」に設定変更してもログの情報量は特に変わりませんでした。。 クライアントから AppSync API を叩いているタイミングでエラーが発生している以上、現時点ではこれ以上のログ情報が出力されていないことから、改めてこの「Unauthorized」というメッセージから原因を考えてみたのですが、 Cognito の「認証されたロール」で指定している IAM ロール/ポリシーに appsync:graphql 権限が付与されていない Cognito でのユーザ認証後、「認証されたロール」で指定している IAM ロールが何らかの原因で正常に AssumeRole されていない のどちらかではないかと考えました。理由は以下の通りです。 先述した通り Cognito ユーザ認証については成功しており、ユーザ未認証の状態で実行されたとは考えがたい。 そもそもユーザ未認証ではアプリケーション上から AppSync API を実行する画面に遷移しない。 つまり考えられる可能性は、正常に「認証されたロール」で指定している IAM ロールが AssumeRole されなかったか、AssumeRole されたものの IAM 権限が不足しているか、のどちらかと推測。 バックエンド用の Lambda からは AppSync API が正常に実行できていることから、AppSync 側の設定については一旦考慮外。 厳密には個々のスキーマ/リゾルバ/関数定義などが誤っている可能性はあるが、そもそも AppSync API の実行すらできないことを鑑みるとそれ以前の問題と判断。 この内、1.については先述した 「IAM ロール/ポリシーに割り当てられている IAM 権限が確認できない」 制限があることから直接 IAM ロール/ポリシーの設定確認ができなかったため、弊社環境で再現試験を実施したところ同じようなエラーメッセージが発生することを確認できました。2.については以下の理由より可能性は低いと考えられたため、1.の可能性が濃厚という結論になりました。 「認証されたロール」に指定した IAM ロールが設定されていることがお客さんの AWS 環境上で確認できている。 上記を踏まえると、正常に AssumeRole できない原因は IAM ロールに設定するCognito ID プールとの信頼関係設定程度しか思い付かなかったが、弊社環境で意図的に設定を間違えた場合は以下のように別のエラーが発生することが分かったためこの可能性はなし。とすると他の可能性が思い浮かばない。。 InvalidIdentityPoolConfigurationException: Invalid identity pool configuration. Check assigned IAM roles for this pool. ただ、よりにもよってこの事象が発生したタイミングが、 お客さんから「認証されたロール」に設定している IAM ロール/ポリシーの設定（修正）が完了したと連絡を受けた直後 だったのですよね・・。経緯として、元々こちらから設定依頼した IAM ロール/ポリシーの内容が一部不正確だったため修正を依頼していたのですが、その対応をお客さんが完了したと言ってきた側から設定内容の開示や再修正を再度お願いするというのは、お客さんに対して 「エラー出てるんだけど本当にできてるんですよね？大丈夫ですか？」 みたいなニュアンスを言外に含んでいると捉えられかねないと憂慮してしまい・・内部で相談したところ、念のためもう少し裏取りしてから打診しようという方向性になりました。 もちろん、お客さん（フロント）とはある程度フランクにコミュニケーションを取れるような関係性はあるのですが、厳密にはお客さんの AWS 環境を管理しているのはお客さん（フロント）とは別の組織であったことから、そのあたりも考慮するともう少し慎重に進めた方が良いなと・・ 具体的には、2.の可能性の有無（＝AssumeRole 自体が正常に動作しているかどうか）までをお客さん AWS 環境で確認してから、対象 IAM ロール/ポリシーの設定内容の開示や再修正をお願いすることにしました。お客さん AWS 環境上の権限不足で確認できない場合は一旦諦める他ないですが、打診する前にできることはやっておこうということで。   本題 ということでようやく本題です。調べたところ、AssumeRole のログは CloudTrail に出力されるとのことで、お客さん AWS 環境で CloudTrail を開いたところ問題なく中身が見られたので、ログの確認を進めました。 AWS CloudTrail による IAM および AWS STS の API コールのログ記録 - AWS Identity and Access Management AWS STS による IAM および AWS CloudTrail のログ記録について説明します。 docs.aws.amazon.com 具体的には、上記 URL における 「AssumeRoleWithWebIdentity」 イベントが該当します。よって、お客さん AWS 環境のアプリケーションから意図的にエラーを発生させた上で、同時刻前後に「AssumeRoleWithWebIdentity」イベントが発生しているかどうかを確認しました。 その結果、以下スクリーンショットのような「AssumeRoleWithWebIdentity」イベントが発生しているログが確認できました。また、「参照されたリソース」の黒塗りしているリソース名が、Cognito ID プールの「認証されたロール」に設定している IAM ロールと同一でした。よって、アプリケーションから AppSync API を実行しようとした時に、想定通りの IAM ロールが Cognito ID プール 経由で AssumeRole されていることが確認できました。 よって、先述の方針通り Cognito ID プールの「認証されたロール」に設定している IAM ロール/ポリシーの設定が誤っている可能性が高いと判断しお客さんに設定内容の開示及びを依頼したところ、冒頭に記載した通り appsync:graphql 権限の resource 句が正しく設定されていなかったことが判明したため、再修正を依頼して無事クローズと相成りました。 以下の CloudTrail スクリーンショットやログは弊社環境で再現したものです。ご了承ください。 ちなみに、JSON 形式の CloudTrail ログも同画面から以下のように確認できます。今回確認したかった観点は上記画面から確認できたため、詳細については本エントリでは省略します。 { "eventVersion": "1.08", "userIdentity": {   "type": "WebIdentityUser",   "principalId": "cognito-identity.amazonaws.com:<COGNITO_APP_ID>:<COGNITO_APP_USR_NAME>",   "userName": "<COGNITO_APP_USR_NAME>",   "identityProvider": "cognito-identity.amazonaws.com" }, "eventTime": "2025-02-24T14:15:12Z", "eventSource": "sts.amazonaws.com", "eventName": "AssumeRoleWithWebIdentity", "awsRegion": "ap-northeast-1", "sourceIPAddress": "<SOURCE_IP_ADDRESS>", "userAgent": "aws-internal/3 aws-sdk-java/1.12.780 Linux/4.14.355-275.582.amzn2.x86_64 OpenJDK_64-Bit_Server_VM/25.432-b06 java/1.8.0_432 kotlin/1.3.72 vendor/Oracle_Corporation cfg/retry-mode/standard cfg/auth-source#imds", "requestParameters": {   "roleArn": "arn:aws:iam::<AWS_ACCOUNT_ID>:role/service-role/<COGNITO_ROLE_NAME>",   "roleSessionName": "CognitoIdentityCredentials" }, "responseElements": {   "credentials": {     "accessKeyId": "ASIA5NBR5LH3GUDX65GT",     "sessionToken": "<ENCODED_SESSION_ROKEN_BLOB>",     "expiration": "Feb 24, 2025, 3:15:12 PM"   },   "subjectFromWebIdentityToken": "<COGNITO_APP_USR_NAME>",   "assumedRoleUser": {     "assumedRoleId": "AROA5NBR5LH3HYAQNDM6Y:CognitoIdentityCredentials",     "arn": "arn:aws:sts::<AWS_ACCOUNT_ID>:assumed-role/<COGNITO_ROLE_NAME>/CognitoIdentityCredentials"   },   "provider": "cognito-identity.amazonaws.com",   "audience": "<COGNITO_APP_ID>" }, "additionalEventData": {   "identityProviderConnectionVerificationMethod": "IAMTrustStore",   "RequestDetails": {     "endpointType": "regional",     "awsServingRegion": "ap-northeast-1"   } }, "requestID": "ef3bb0c4-ed23-472e-9a93-3377cd9928dc", "eventID": "93c286a7-1732-4428-93e5-15875fa6b2a3", "readOnly": true, "resources": [   {     "accountId": "<AWS_ACCOUNT_ID>",     "type": "AWS::IAM::Role",     "ARN": "arn:aws:iam::<AWS_ACCOUNT_ID>:role/service-role/<COGNITO_ROLE_NAME>"   } ], "eventType": "AwsApiCall", "managementEvent": true, "recipientAccountId": "<AWS_ACCOUNT_ID>", "eventCategory": "Management", "tlsDetails": {   "tlsVersion": "TLSv1.3",   "cipherSuite": "TLS_AES_128_GCM_SHA256",   "clientProvidedHostHeader": "sts.ap-northeast-1.amazonaws.com" } }   まとめ つらつら書いていたら、本題より前段の話題である背景やエラー発生時の原因切り分けの内容の方が長くなってしまいました。すみません。ただ、お客さんの AWS 環境へのアプリケーション移行に関しては、こちらのエントリで記載した内容も含め最終的に正常に稼働させるまで結構な労力を要したので、備忘がてら忘れない内にまとめておきたかったんですよね。後、具体的な解決策について記載するのはもちろん、そこに至るまでの思考のプロセスも合わせてまとめておいた方が、少なくとも自分にとってはより有意義な記録になるというのもあります。 いずれにせよ、本記事がどなたかの役に立てば幸いです。

こんにちは、広野です。 個人的に JPCYBER S3 Drive という、Amazon S3 バケットを Windows のエクスプローラで操作できるツールを使い始めまして、ファイルサーバ代わりにしています。若干レスポンスは遅いですが、Amazon S3 ユーザーにとっては想像以上に便利です。Microsoft OneDrive と同じじゃん、って言われたらそれまでなんですが。w このツールは Windows に設定用のアプリをインストールして、アクセスしたいバケット名と IAM アクセスキーを入れれば使用開始できます。当然ですが AWS 側であらかじめ IAM ユーザーとアクセスキーを作成しないといけないので、それを AWS CloudFormation で作成しました。 今回は具体的な例になりますが、他の似たような用途で IAM アクセスキーが必要なケースにも応用できると思います。 要件 JPCYBER S3 Drive のドキュメントに、必要な IAM ユーザーの最小権限が掲載されていました。 Amazon S3のアクセスに必要な最低限のIAMポリシーの設定 - JPCYBER AWS Amazon S3 バケットにアクセスするために必要な最低限の IAM ポリシーの設定は、以下のように設定してください。（IAM ユーザー、または IAM ロールの設定で、既に「AmazonS3FullAccess」ポリシーをアタッ... www.jpcyber.com これをベースに AWS CloudFormation テンプレートを作成します。 Amazon S3 バケットは作成済みとします。 作成する IAM ユーザーではマネジメントコンソールへのログインはできません。(権限もパスワードもない) アクセス可能な S3 バケットは指定した 1 つだけです。他へのアクセスはできません。 作成されたアクセスキーは AWS Secrets Manager で参照できます。 AWS CloudFormation テンプレート 作成したい IAM ユーザー名と、アクセスしたい Amazon S3 バケット名をパラメータに入力して実行します。 AWSTemplateFormatVersion: 2010-09-09 Description: The CloudFormation template that creates an IAM user with the grant to access the specific S3 bucket only. # ------------------------------------------------------------# # Input Parameters # ------------------------------------------------------------# Parameters: IamUserName: Type: String Description: The IAM user name. Default: S3BucketAccessOnly MaxLength: 100 MinLength: 5 AllowedPattern: ^[A-Za-z0-9_+=,.@-]+$ S3BucketName: Type: String Description: The target S3 bucket name. Default: bucketname MaxLength: 63 MinLength: 3 AllowedPattern: ^(?!.*\.\.)[a-z0-9]([a-z0-9-]{1,61}[a-z0-9])?$ Resources: # ------------------------------------------------------------# # IAM User # ------------------------------------------------------------# IamUser: Type: AWS::IAM::User Properties: UserName: !Ref IamUserName Path: / # ------------------------------------------------------------# # IAM User Policy # ------------------------------------------------------------# IamUserPolicy: Type: AWS::IAM::UserPolicy Properties: UserName: !Ref IamUser PolicyName: !Sub ${IamUserName}-${S3BucketName} PolicyDocument: Version: "2012-10-17" Statement: - Effect: "Allow" Action: "s3:ListAllMyBuckets" Resource: "arn:aws:s3:::*" - Effect: "Allow" Action: - "s3:ListBucket" - "s3:ListBucketVersions" - "s3:GetBucketACL" Resource: !Sub "arn:aws:s3:::${S3BucketName}" - Effect: "Allow" Action: - "s3:GetObject" - "s3:PutObject" - "s3:AbortMultipartUpload" - "s3:DeleteObject" - "s3:GetObjectVersion" - "s3:DeleteObjectVersion" - "s3:GetObjectACL" - "s3:PutObjectACL" Resource: !Sub "arn:aws:s3:::${S3BucketName}/*" DependsOn: - IamUser # ------------------------------------------------------------# # IAM Access Key # ------------------------------------------------------------# AccessKey: Type: AWS::IAM::AccessKey Properties: Serial: 1 Status: Active UserName: !Ref IamUser DependsOn: - IamUser # ------------------------------------------------------------# # Secrets Manager # ------------------------------------------------------------# Secret: Type: AWS::SecretsManager::Secret Properties: Name: !Sub IamAccessKey-${IamUserName} Description: !Sub IAM Access Key for the IAM user ${IamUserName} SecretString: !Sub "{\"accessKeyId\":\"${AccessKey}\",\"secretAccessKey\":\"${AccessKey.SecretAccessKey}\"}" DependsOn: - AccessKey 結果 AWS CloudFormation テンプレートを実行すると、指定した名前の IAM ユーザーが作成され、アクセスキーが発行されます。アクセスキーの情報は、以下のように AWS Secrets Manager で参照可能です。   この値を使用して、無事 JPCYBER S3 Drive を使用することができました！   まとめ 本記事の仕様は、セキュリティ面で個人使用限定の AWS アカウントであったり、他の IAM ユーザーの権限管理をきっちりできていたりする状況でないと使いづらいと思いますが、外部ツールから AWS にアクセスさせる要件に応用できると思います。 AWS Secrets Manager にアクセスキー情報を格納することで、作成後もキー情報を参照することができます。ただしセキュリティ的にそうやって残しておくのが良いのか？というと微妙ではありますが、どこかに情報を保存して忘れたーとなるのもどうかと思いますので、これを良しとするかは判断が必要です。また、AWS Secrets Manager の料金がかかってしまうのはデメリットです。 記事では書いていませんが、Amazon S3 バケットへのアクセスログ取得とセットで使いたいですね。 本記事が皆様のお役に立てれば幸いです。

こんにちは、SCSK の松山です。 Amazon Aurora DSQL (以下 DSQL と略す) について、従来の PostgreSQL との差異に焦点をあてて調べてみたシリーズ、前回(第一弾)は、DSQL の簡単な要約と構築についてお伝えしました。 Amazon Aurora DSQL について調べてみた (構築編) Amazon Aurora DSQL について従来の PostgreSQL との差異に焦点をあてて調べてみたシリーズ第一弾。第一弾は DSQL の簡単な概要と構築編です。 blog.usize-tech.com 2025.03.17 Amazon RDS や Amazon Aurora、オンプレの PostgreSQL と比較して、非常に簡単に構築できることがわかりました。 第二弾として、本件では 従来の PostgreSQL と比較した場合の機能制限 に焦点をあててまとめていきます。 ※本件は 2025/3 時点の Amazon Aurora DSQL User Guide – PostgreSQL compatibility を参考に記載しました。 DSQL は 2025/3 現在プレビュー版のため、今後機能の追加によって制限が変更されることが想定されます。 実際に DSQL を使用する場合は、その時点の最新マニュアルを合わせてご確認ください。    DSQL の制限を知る重要性 DSQL は PostgreSQL と一部機能の互換性があると発表されていますが、完全な互換性を保証するものではありません。そのため、従来の PostgreSQL と同じ構成ができるつもりで DSQL を使い始めた場合、予期せぬ問題に直面する恐れがあります。 DSQL を有効活用するためにも、まずはできること、できないことを正確に把握しておくことが重要です。 DSQL の制限 以下、いくつかの項目に分けて制限事項をまとめていきます。 オブジェクトの制限 以下のオブジェクトはサポートされていません。 Database (DSQL 作成時に作られる Database 以外は追加できない) View Temporary Table Trigger Type Tablespace Sequence Materialized View Procedure SQL 以外を使用する Function Foreign key (参照整合性制約) Exclusion constraint (排他制約) Function に関しては、SQL のみを使用した単純な構成の物は作成することが可能です。 (後述しますが、DSQL では plpgsql をサポートしていません) Procedure や Function、Trigger などのソースコード系オブジェクトが制限されている点から、Database 内で複雑な処理を行う使用方法は想定されていないと考えられます。 また RDBMS として利用頻度の高い参照整合性制約がサポートされていない点は抑えておきたいポイントです。 オペレーションの制限 以下のオペレーションはサポートされていません。 ALTER SYSTEM TRUNCATE VACUUM SAVEPOINT 従来の PostgreSQL として特徴的な VACUUM が手動実行できない点は抑えておきたいポイントです。 SQL の制限 DSQL では SQL の一部構文がサポートされていません。 全てを網羅的には公開されていませんが、マニュアルより以下をサポートしていない点が確認できます。 CREATE 「オブジェクトの制限」に記載した各種オブジェクト 拡張機能の追加 (EXTENTION) CREATE INDEX ソート順 (ASC、DESC)  CREATE TABLE AS SELECT  照合順(COLLATE)  テーブルの継承(INHERITS)  パーティション(PARTITION)  データ型の制限 データ型については大きく分けて3つのポイントがあります。 サポートされるデータ型の制限 DSQL でサポートされているデータ型が Amazon Aurora DSQL User Guide Supported data types in Aurora DSQL  に記載されています。記載されていないデータ型については、動作するかを個別に確認する必要があります。    データ型のサイズ制限 サポートされているデータ型に対しても、DSQL 独自のサイズ制限が設けられているケースがあります。そのため、合わせて確認が必要です。                        DSQL のデータ型 サイズ制限 Name Implicit Limit character [ (n) ] 4096 bytes bpchar [ (n) ] 4096 bytes character varying [ (n) ] 65535 bytes text 1MB bytea 1 MB numeric [ (p, s) ] numeric (18,6) Primary Key および 索引付与の制限 以下のデータ型は Primary Key や 索引を付与することができません。                        bytea numeric timestap with time zone interval 　特に numeric は使用頻度の高いデータ型のため、DSQL への移行を検討している場合には留意が必要です。 拡張機能の制限 従来の PostgreSQL にはさまざまな拡張機能が存在します。 マニュアルでは例として、以下代表的な拡張機能をサポートしていない旨が記載されていました。 PL/pgSQL PostGIS PGVector PGAudit Postgres_FDW PGCron pg_stat_statements しかし「SQLの制限」に記載した通り、拡張機能を追加するための CREATE EXTENTION がサポートされていません。 そのため、拡張機能は全般的にサポートされていないと考えたほうがいいでしょう。 システム管理表 および 管理ビューの制限 DSQL はメンテナンスを含めてサービスに任せる運用になります。 そのため、多くのシステム管理表 および 管理ビューに情報が出力されません。 どのシステム管理表 および 管理ビューに対応しているかは Amazon Aurora DSQL User Guide Using system tables and commands in Aurora DSQL に記載されています。 DSQL のサービス上、DBA としての作業はあまり発生しないと考えられますが、頭の片隅に入れておくといいかと思います。 トランザクションの制限 トランザクションには以下の制限が設けられています。 接続は1時間を超えることはできない トランザクションに DDL と DML を混在させることはできない トランザクションに含められる DDL は最大1つ トランザクションは10,000行を超える更新を行うことはできない (索引が付与されている場合、索引更新行数も制限内に含まれる) 実行時間に制限がある点や、1トランザクションの更新量に制限がある点からも、複雑な処理の実行は想定していないことが伺えます。 なお1トランザクションの更新量については、索引の付与状況によってさらに減少するという記載がありました。 この点はマニュアルの記載からは把握が難しいため、今後のシリーズにて実機検証を踏まえた内容をまとめていきます。 まとめ DSQL では従来の PostgreSQL と比較して、さまざまな制限があることがわかりました。 制限されている内容から、従来の PostgreSQL のような Database 内で複雑な処理を行うことは想定していない と考えます。 分散SQLデータベース かつ 事実上無制限のスケーラビリティを提供している点から、単純 かつ 短時間で完了するクエリが大量に同時実行されるようなシステム( OLTP系の処理 )に適しているのではないでしょうか。 DSQL は 2025/3 現在まだプレビュー中のため、今後機能の追加によって制限が緩和されることにも期待したいと思います。 次回は DSQL と 従来の PostgreSQL で大きな違いとなる トランザクションの同時実行制御の差異 を深堀していきます。 ご興味のある方は引き続きご確認いただければ幸いです。

Catoクラウドのクライアントソフトに、待望のAnti Tampering機能が実装されます! この機能追加により、 ユーザによるCatoクライアントのプロセス停止やアンインストールを禁止できます。 本記事では、Anti Tamperingの概要と、動作確認の結果をご紹介します。 本機能は、2025/3/18時点でEarly Availabilityとして提供されています。正式リリース時には機能が変更となる可能性がありますので、ご留意ください。 Anti Tampering(改ざん防止)とは Anti Tamperingは「改ざん防止機能」と訳され、通信・セキュリティ系のソフトウェアに搭載されることの多い機能です。 悪意ある侵入者やマルウェアは、自分の動作を検知されることを避けるため、端末の管理者権限を取得し、ソフトウェアの設定を変えたり、ソフトウェア自体を終了させたり、ログを削除・改ざんしたりします。これを防ぐため、端末の管理者権限を持っていても、ソフトウェアの終了や関連ファイルの書き換えを許可しないのがAnti Tampering機能です。 今回、Catoクライアントにこの機能が追加されたことにより、 Catoクラウドがよりセキュアなサービスになった と言えます。 CatoクラウドのAnti Tampering機能について CatoクラウドにおけるAnti Tampering機能は、2025/3/18現在、以下の内容となっています。 対象: Windowsクライアント バージョン5.14以上で対応 現状はWindowsのみですが、将来的にmacOSクライアントにも実装予定です 制限できる内容 Catoクライアントのアンインストールをさせない CatoVPNのプロセス停止をさせない Catoクライアントの動作に影響するレジストリの変更をさせない インストールフォルダ内のファイル削除・変更をさせない (ログファイル・設定ファイル等の保護) 詳細については、以下のCato Knowledge Baseをご参照ください。 Cato KnowledgeBase | Working with Anti-Tampering for the Cato Client それでは、どのように設定を行うのか、また本当に上記を制限できているのか等、検証した内容をご紹介します。 Anti Tamperingの設定方法 Cato管理画面(CMA)側の設定 Anti Tamperingの利用には、まず機能を有効化する必要があります。Anti TamperingはAlways-On(常時接続)機能の追加機能となっており、Cato管理画面(CMA)の「Always-On Policy」の箇所にて設定します。 以下がルールの設定例です。 対象としたいユーザ・OS等を指定して、Always-Onを有効にすると、Anti Tamperingの設定項目が選択できるようになります。こちらをEnabledにすることで、Anti Tamperingが有効になります。 なお、Always-On Policy自体の使用や設定方法については、以下の記事にて詳細をご紹介しておりますので、ご参照ください。 CatoクラウドのAlways-Onを試してみた Catoクラウドで「Always-On」を試してみました。設定方法～動作検証までやってます。 blog.usize-tech.com 2023.08.28 Cato クラウド Always-On の新機能を徹底解説！ ～2023.11のアップデートについて～ 2023年11月にアナウンスされた Cate クライアント Always-On のアップデート情報です。 blog.usize-tech.com 2023.12.13 クライアント側での確認 CMAを設定後、Catoクライアントを接続し10分程度置くと、Cato側からクライアントへ設定内容が反映されます。 CatoクライアントのStatsにて、Anti-Tamper Protectionの欄が「Enforced(Protect)」となっていれば、Anti Tamperingが適用されています。 ※この項目自体が表示されない場合は、Windowsクライアントのバージョンが古いため、5.14以上にアップグレードしてください。 本当に停止できないのか検証 Anti Tamperingが有効な状態で本当にクライアントを停止できないのか、実際に検証してみました。もちろんWindows端末のAdministratorで試しています。 アンインストール Anti Tamperで保護されている旨のエラーが表示され、 アンインストールできません 。Catoクライアントのアンインストーラーでも、設定>アプリからのアンインストールでも、MsiExec.exeを使ったコマンドライン操作でも、同じエラーとなります プロセス・サービス停止 タスクマネージャのプロセスから、「CatoClient」をタスク終了してみますと、終了でき、Catoクライアントのアプリが表示されなくなります。 しかしながら、Catoの接続は切断されず、接続されたままです。サービスを確認すると「CatoNetworksVPNService」が実行中となっており、接続が維持されていることが確認できます。 このサービスを停止しようとすると下記のエラーとなります。このため Catoへの通信を切断することはできません。 また、サービスを無効化することもできません。 レジストリ変更 Catoクライアントの実行に関連するレジストリキーを変更や削除しようとすると、エラーとなり、レジストリ変更ができません。このため、レジストリ操作でCato接続を停止することはできません。 実行ファイル・ログファイル等の削除・改ざん Catoクライアントの実行ファイルや各種ログがあるフォルダにて、ファイルを変更や削除しようとすると、エラーとなり、ファイル編集できません。これにより、Cato接続を動作不能にしたり、ログファイルを改ざんすることはできません。 ネットワークアダプタの停止 Cato Networks VPN Adapterを無効化してみました。無効化はできますが、Catoへの通信は切断されません。メトリック値を変えてみたりもしましたが、通信には影響せず、Catoを迂回することはできませんでした。 以上、思いつく限りの手段を試してみましたが、Anti Tamperingが有効な状態で、Catoを無効化し通信迂回することはできませんでした。 他に試せそうなことがありましたら、ぜひ検証いただければと思います。 アンインストールしたいときはどうするか では、運用上の事由などで、どうしてもAnti Tamperingを回避したいときはどうしたらいいのでしょうか。 まず、一時的にCatoの通信を切断したいだけで、クライアントのアンインストールは不要な場合、Always-Onを一時的にBypassし通信を切断することが可能です。Always-OnのBypass方法については、以下のCato Knowledge Base をご参照ください。 Cato Knowledge Base | Temporarily Bypassing Secured Internet Access 次に、クライアントをアンインストールしたい場合は、以下いずれかの方法で可能です。 Always-On Policyにて対象ユーザに対するAnti Tamperingを解除した上でアンインストールする Anti-Tamper Bypass を使用し、 一時的に Anti Tamperingを解除した上でアンインストールする このうち、Anti-Tamper Bypassについては少しわかりづらいため、以下に詳細をご説明します。 Anti-Tamper Bypass Anti Tamperingを一時的に無効化する機能です。 1. Always-On Policyの「Settings」にある、「Show anti tamper bypass code」を開くと6桁の数字が表示されます。このコードには有効期限があり、コードの下に表示される時間の間のみ有効です。 2. 無効化したいCatoクライアントの「Settings」を開き、「Ctrl+Shift+O」を押すと、「Anti-Tamper Bypass」の入力欄が表示されます。 3. 1のコードを2に入力して「Submit」すると、一時的にAnti Tamperingが無効化され、アンインストール等が可能となります。 なお、無効となる時間の長さは、Always-On Policyのルールにて設定可能です。 最後に Anti Tamperingは、ユーザの意図しないアンインストールなどを防ぐため、多くのお客様からご要望をいただいていた機能です。 ユーザの通信保護に大きく寄与する機能ですので、ぜひご検証の上、ご活用いただければ幸いです。

こんにちは、SCSK の松山です。 2024/12/2～12/6 米国ラスベガスで開催された AWS 最大のカンファレンス re:Invent 2024 にて Amazon Aurora DSQL (以下 DSQL と略す) が発表されました。 DSQL は PostgreSQL と一部互換性を持っていると発表されています。 この点から従来の PostgreSQL との差異に焦点をあてて DSQL について調べてみました。 その結果を数回にわけてまとめていきたいと思います。 第一弾として、本件では  DSQL の構築 についてまとめていきます。 ※本件は 2025/2 時点の検証結果をもとに記載しています。 　今後動作が変更される可能性がある旨、ご注意ください。 前提：DSQL とは DSQL の構築を行う前に、まずは re:Invent 2024 で発表された DSQL の説明をまとめてみました。 DSQL の特徴 高い可用性を備えたサーバレスな分散SQLデータベース 障害復旧の自動化 事実上無制限のスケーラビリティ インフラ管理(パッチ適用など) が不要 PostgreSQL と一部機能の互換性がある Amazon RDS や Amazon Aurora においても、通常の Database 構築と比べて簡易化されていますが、DSQL ではさらに管理面を含めて自動化されています。 サーバーレスのため、DBインスタンスのエンジン選択や Database のパラメータ設定などがありません。 本来大きなコストを要する Database の設計、メンテナンス、障害復旧が自動化されている点が大きなメリットと言えるでしょう。 考慮が必要な点 PostgreSQL と完全な互換性を保証するものではない 従来の PostgreSQL とはトランザクションの同時実行性管理方法が異なる 1トランザクションで更新可能な件数や実行時間に制限がある PostgreSQL と互換性はありますが、アーキテクチャに違いがあるため、この点は十分に考慮が必要です。 また従来の PostgreSQL は基本的に単一インスタンスでの動作を前提としていますが、 DSQL は分散SQLデータベースです。 そのため、パフォーマンスを引き出すためには、従来の PostgreSQL とは異なるオブジェクト設計を検討する必要があります。 DSQL を構築する ※2025/3 現在、DSQL はプレビュー版のみ公開されています。 　プレビュー版に対応しているリージョンは、 バージニア または オハイオ のみ です。 AWS コンソールにログイン    「DSQL」で検索し、 「Amazon Aurora DSQL」のページへ移動    バージニア または オハイオ リージョンを選択 東京リージョンで DSQL のページへ移動した場合リージョン変更を求められるため、バージニア または オハイオを選択します。    「Create cluster」をクリック    初期設定後、「Create cluster」をクリックし DSQL を構築 設定項目はマルチリージョンの有無とタグ設定のみです。                             「Cluster settings」 でマルチリージョンの有無を設定 マルチリージョン構成にする場合、「Add linked Regions」にチェックを入れます。 本件では以下を選択しています。                    Linked cluster Region us-east-2(Ohio) Witness Region us-west-2(Oregon) 「Deletion protection」はデフォルトでチェックが入っているため、そのままの設定にします。 「Tags」に任意のタグを設定 「Create cluster」を実行 Aurora DSQL のコンソールへ画面が推移します。 「Status」が「Active」に変化したら、構築完了です。    【構築中】    【構築完了】                      状態確認 マルチリージョンで構築した場合、バージニアとオハイオ それぞれに DSQL が構築されます。 双方のクラスタ状態について以下の方法で確認します。                               構築元(今回の場合バージニア) ：表示されている 「Cluster ID」 をクリック     マルチリージョン先(今回の場合オハイオ)：オハイオリージョンへ移動し、Aurora DSQL 画面を確認 構築直後の場合は、メッセージに表示されている「us-east-2(Ohio)」のリンクから直接移動が可能です。                        上記のメッセージを消している場合は、リージョン オハイオを選択し DSQL の画面へ移動し、対象DSQLの「Cluster ID」 を選択します。    接続確認 対象リージョンの AWS CloudShell から簡易接続テストを行います。                               AWS CloudShell を表示 画面上部の CloudShell アイコンをクリックし、CloudShell 画面を表示します。    DSQL の「Connect」をクリックし、エンドポイントをコピー                       AWS CloudShell から psql 接続 (パスワード入力前まで進める) psql のオプションには以下を指定します。   –dbname postgres –username　  admin –host Ⅱでコピーしたエンドポイント     DSQL の「Connect」をクリックし、パスワードをコピー                       AWS CloudShellにパスワードを入力 ※PostgreSQL バージョンの関係で WARNING が出力されていますが、DSQL 環境に接続出来ている状態です。    同様の確認をマルチリージョン先でも実施 (手順は省略) なお本件では AWS CloudShell から簡易検証していますが、プログラムから接続することも可能です。 各プログラムから接続を行うサンプルコードは以下マニュアルに記載されています (本件では詳細は割愛します) Programming with Aurora DSQL  以上で DSQL の構築は完了です。 まとめ 設定項目はマルチリージョンの有無のみであることがわかりました。 Database に対するスキルがない状態でも、非常に簡単に構築できる点にメリットを感じました。 プレビュー版を使用できる機会に触れてみるのはいかがでしょうか。 次回以降のシリーズでは、PostgreSQL と比較した制限や、本件で構築した環境を使用してアーキテクチャの差異を深堀していきます。ご興味のある方は引き続きご確認いただければ幸いです。