タイでAWSを安全に利用するには？セキュリティ対策と運用設計を解説

タイ拠点でアマゾン ウェブ サービス（AWS）を利用する場合は、アカウントや権限、ネットワーク、ログ監視だけでなく、タイ国内外のデータ配置や日本本社との責任分担まで整理する必要があります。現地拠点や工場からAWSへ接続する場合は、接続経路の保護やインシデント発生時の連絡体制も欠かせません。

また、タイリージョンを利用したからといって、すべてのデータが自動的にタイ国内へ保存され、PDPAへの対応が完了するわけではありません。利用するAWSサービスやバックアップ先、日本本社・外部サービスへのデータ移転を確認する必要があります。

この記事では、タイでAWSを安全に利用するためのセキュリティ対策、タイリージョンとPDPAへの考え方、日本本社とタイ現地法人の役割分担、支援会社を選ぶポイントを解説します。

タイでAWSを利用する際のセキュリティ課題

タイ拠点でAWSを利用する場合、クラウド上の設定だけでなく、日本本社が定める管理基準との整合、現地担当者の体制、拠点ネットワークとの接続まで含めて設計します。AWS環境が適切に構成されていても、運用ルールや責任の所在が曖昧であれば、設定変更の遅れや不正アクセスの見落としにつながります。

日本本社の基準とタイ現地の運用に差が生じる

日本本社で定めたセキュリティ基準をタイ現地法人へ適用しても、同じ水準で運用されるとは限りません。本社では多要素認証、権限申請、操作ログの保管などを定めていても、現地では担当者や利用ツールが異なり、手順の一部が実施されない場合があります。

本社の基準をそのまま共有するだけでなく、タイ拠点で実行できる手順へ落とし込む必要があります。権限の申請者と承認者、ログを確認する担当者、異常を検知した際の連絡先を明確にし、本社と現地法人で共通の運用ルールを設けます。

現地担当者の不足により権限管理が属人化する

タイ現地法人にAWS専任の担当者がいない場合、社内システムやネットワークの担当者が、AWSアカウントの管理も兼任することがあります。少人数で運用すると、特定の担当者に管理者権限が集中し、退職や異動の際に不要なユーザーやアクセスキーが残る可能性があります。

利用者の追加・変更・削除を本社と現地法人のどちらが担当するかを決め、定期的に権限を棚卸しします。

現地拠点や工場からの接続経路を管理する必要がある

タイのオフィスや工場からAWSへ接続する場合は、AWS側だけでなく、現地のルーター、ファイアウォール、端末、インターネット回線も管理対象になります。拠点内のネットワークからAWSへ広い範囲でアクセスできる状態では、端末の感染や認証情報の漏えいがAWS環境へ波及するおそれがあります。

接続元のネットワークや利用者を限定し、必要な通信だけを許可する構成が基本です。インターネット経由で接続する場合は、AWS Site-to-Site VPNによって、拠点ネットワークとAmazon Virtual Private Cloud（Amazon VPC）の間に暗号化されたトンネルを構成できます。

通信量や安定性の要件に応じてAWS Direct Connectを利用する場合も、通信は標準では暗号化されません。専用接続の対応ポートとオンプレミス側の対応機器でMACsecを有効にする、またはAWS Site-to-Site VPNを組み合わせるなど、要件に応じて暗号化方式を設計します。

AWSと利用企業のセキュリティ責任

AWSのセキュリティは、AWSと利用企業がそれぞれの範囲を担う責任共有モデルに基づいています。AWSがクラウド基盤全体を管理する一方、利用企業はAWS上に保存するデータやアクセス権限、利用サービスの設定を管理します。

タイ拠点でAWSを利用する場合は、この分担に加えて、日本本社、タイ現地法人、支援会社の担当範囲も明確にします。

AWSが管理するクラウド基盤の範囲

AWSは、クラウドを構成するハードウェア、ソフトウェア、ネットワーク、施設などのインフラストラクチャを管理します。物理データセンターへの入退室管理や、基盤となる設備・ネットワークの保護もAWSの責任範囲です。

ただし、AWSが管理する範囲は、利用するサービスによって異なります。例えば、Amazon Elastic Compute Cloud（Amazon EC2）では、ゲストOSの更新やセキュリティパッチ、インストールしたアプリケーションの管理を利用企業が担います。一方、マネージドサービスでは、AWSが管理する範囲が広がります。利用するサービスごとに責任の境界を確認することが前提です。

利用企業が管理するデータ・権限・設定の範囲

利用企業は、AWS上で扱うデータ、ユーザーのアクセス権限、ネットワークや各サービスの設定を管理します。具体的には、IAMによる権限設定、セキュリティグループの通信制御、データの暗号化、ログの保存、バックアップなどが該当します。

AWSの基盤が保護されていても、過剰な権限の付与や外部公開の設定、不要なアクセスキーの放置があれば、セキュリティリスクは残ります。人によるアクセスには一時的な認証情報を利用し、最小権限を適用するなど、継続的に管理します。

タイ現地法人が独自にAWS環境を運用する場合も、設定やデータ管理の責任がAWSへ移るわけではありません。日本本社が定める基準を踏まえ、現地で誰が設定を変更し、誰が確認するのかを具体化します。

日本本社・タイ現地法人・支援会社の役割を決める

AWSと利用企業の責任範囲を整理した後は、利用企業側の業務を日本本社、タイ現地法人、支援会社へ割り振ります。役割が曖昧なままでは、権限変更や異常検知への対応が遅れたり、同じ作業を複数の組織が重複して実施したりする可能性があります。

例えば、日本本社はセキュリティ基準や管理方針を定め、タイ現地法人は利用者の申請や現地ネットワークの状況を確認します。支援会社には、AWS環境の設定、監視、技術調査、復旧支援などを依頼できます。

ただし、支援会社へ運用を委託しても、利用企業の管理責任がすべて移るわけではありません。設定変更の承認者、監視アラートの連絡先、インシデント発生時の判断者を決め、責任分担を文書化しておきます。

タイのAWS環境で必要なセキュリティ対策

タイ拠点のAWS環境では、認証情報や通信経路の保護に加え、データの保存方法、設定変更の監視、障害や攻撃からの復旧まで設計します。日本本社とタイ現地法人で運用を分担する場合は、各対策の実施者と確認者も定めます。

アカウント・権限とネットワークを管理する

AWSへのアクセスには多要素認証を設定し、利用者や業務に必要な範囲だけに権限を付与します。AWSは、人によるアクセスについて、IDプロバイダーと連携して一時的な認証情報を利用する方法を推奨しています。長期的なアクセスキーの発行を抑え、未使用のユーザーや権限を定期的に見直すことも対策に含まれます。

日本本社、タイ現地法人、支援会社が同じ管理者アカウントを共有すると、操作した人物を特定しにくくなります。利用者ごとに認証情報を分け、設定変更や障害対応に必要な権限を役割別に割り当てます。

ネットワークは、Amazon Virtual Private Cloud（Amazon VPC）のサブネットやセキュリティグループを用いて、公開範囲と通信先を制限します。タイのオフィスや工場から接続する場合も、拠点ネットワーク全体へ一律に許可を与えず、接続元、通信先、ポートを業務に必要な範囲へ絞ります。

データを暗号化し、ログと設定不備を監視する

AWS上で扱うデータは、保存時と通信時の両方で暗号化します。暗号鍵をAWS Key Management Service（AWS KMS）で管理する場合は、鍵を利用できるユーザーやサービスを限定し、データへのアクセス権限と鍵の管理権限を分離します。

暗号化だけでは、不正な操作や設定変更を把握できません。AWS CloudTrailでAPI操作を記録し、ネットワーク通信や各サービスのログとあわせて確認できるようにします。ログの保存先には、閲覧権限や保存期間を設定し、改ざん防止や暗号化の対策を講じます。CloudTrailのログファイルは、AWS KMSキーによる暗号化も可能です。

設定不備の検出には、AWS Security Hub CSPMを利用できます。同サービスはセキュリティチェックを実行し、AWS環境の設定不備に関する検出結果を生成します。複数のAWSアカウントを運用する場合は、日本本社側で基準を定め、タイ現地法人のアカウントを含めて設定状況を確認する構成も選べます。

アラートを取得するだけでは、異常への対応にはつながりません。誰が内容を確認し、どの条件で日本本社や支援会社へ連絡するのかまで決めておきます。

バックアップと復旧手順を整備する

バックアップは、障害だけでなく、ランサムウェア、誤操作、不正な設定変更から業務を復旧する際にも利用します。対象となるシステムやデータごとに、取得頻度、保存期間、保存先を定めます。

タイ拠点で業務を継続するうえでは、バックアップの有無だけでなく、必要な時間内に復旧できるかが判断基準となります。業務への影響を踏まえ、許容できるデータ損失の範囲と再開までの時間を、日本本社とタイ現地法人で合意します。

復旧手順には、作業担当者、承認者、連絡先、復旧後の確認項目を含めます。AWS Backupには復元テストの機能があり、計画に沿って復元処理を実行し、結果を確認できます。定期的なテストを通じて、バックアップデータの有効性と手順の実行可能性を検証します。

タイリージョンとPDPA対応の考え方

AWSアジアパシフィック（タイ）リージョン（リージョンコード：ap-southeast-7）を利用すると、AWS上のデータをタイ国内に配置する構成を選択できます。PDPAへの対応では、利用サービス、バックアップ先、外部システムとの連携を含め、個人データの保存先と移転経路を確認します。

利用サービスとデータの保存先を確認する

AWSでは、利用企業がコンテンツを保存するリージョンを選択します。タイ国内でのデータ保管が求められる場合は、タイリージョンを選んだうえで、利用予定のサービスが同リージョンに対応しているかを確認します。

確認対象は、業務データを保存するデータベースやストレージだけではありません。ログ、バックアップ、暗号鍵、監視データなども含め、保存先のリージョンを把握します。災害対策として別リージョンへ複製する場合は、タイ国外へのデータ移転が発生する点も設計に反映します。

また、サービスや機能の提供状況はリージョンごとに異なります。タイリージョンで利用できない機能をシンガポールや日本などのリージョンで補う場合は、処理対象となるデータと通信経路を確認したうえで構成を決めます。

日本本社や国外サービスへのデータ移転を整理する

タイ現地法人のデータは、日本本社への報告、グループ共通システムとの連携、国外のSaaSへの送信などを通じて、タイ国外へ移転する場合があります。AWS上の保存先をタイリージョンに設定していても、こうした連携を含めなければ、データの流れを正確に把握できません。

個人データを含む情報について、送信元、送信先、利用目的、保存期間、アクセスできる組織を明確にします。そのうえで、日本本社や委託先との契約、アクセス権限、暗号化、ログ管理など、移転先で講じる保護措置を確認します。

タイでは、個人データの国外移転に関する規則が2024年3月に施行されました。移転先の保護水準や、企業グループ内のルールを含む保護措置などが判断要素となるため、具体的な法的要件はタイの法律専門家へ確認します。

タイリージョンの利用だけでPDPA対応にはならない

タイリージョンは、タイ国内にデータを保存するための選択肢です。一方、PDPAへの対応には、個人データの取得目的、利用範囲、アクセス権限、保存期間、国外移転、削除方法など、データ管理全体の整備が含まれます。

タイリージョンを選択しても、個人データの分類、権限設定、ログ管理などは利用企業が担います。リージョンの所在地だけで判断せず、どのデータを、誰が、どの目的で扱い、どこへ移転するかを明確にします。

AWSの技術設計と社内のデータ管理ルールを組み合わせることで、タイ拠点の運用実態に即した管理体制を構築できます。

インシデントに備えた運用体制

セキュリティ対策を講じていても、不正アクセスや設定ミス、システム障害を完全に防げるとは限りません。タイ拠点でインシデントが発生した際に対応が滞らないよう、日本本社、タイ現地法人、支援会社の担当範囲と連絡手順を事前に定めます。

タイ現地法人と日本本社の対応範囲を決める

インシデント対応では、異常を最初に把握する組織と、影響範囲や対応方針を判断する組織が異なる場合があります。タイ現地法人が利用者や現地ネットワークの状況を確認し、日本本社が事業への影響や対外対応を判断するなど、それぞれの役割を明確にします。

対応範囲は、AWS環境だけでなく、現地の端末、ネットワーク、業務システムまで含めて定めます。例えば、タイ現地法人は利用者への聞き取りや端末の隔離を担当し、日本本社は関係部門への報告、システム停止の判断、再発防止策の承認を担います。

担当者名だけを指定すると、異動や不在によって対応が止まる可能性があります。担当部署、代替担当者、判断権限、連絡先を文書化し、定期的に更新します。

検知・連絡・復旧の手順と言語を統一する

インシデント対応の手順は、検知、一次確認、連絡、影響範囲の調査、封じ込め、復旧の順に定めます。監視アラートを受け取っても、確認項目や連絡基準が明確でなければ、初動に時間がかかります。

アラートの種類ごとに、緊急度、一次確認の内容、連絡先、対応期限を設定します。業務停止や個人データへの影響が疑われる場合など、日本本社へ直ちに連絡する条件も明確にしておきます。

日本本社とタイ現地法人で使用言語が異なる場合は、報告項目と用語を統一します。発生日時、対象システム、検知内容、業務への影響、実施した対応、次の判断事項を共通の様式で記録すると、翻訳や説明の行き違いを抑えられます。復旧後の正常性確認と、業務再開の承認者も手順に含めます。

外部の監視・運用支援を活用する

タイ現地法人だけで継続的な監視や技術調査を担うことが難しい場合は、外部の支援会社を活用します。監視アラートの確認や一次切り分けを委託することで、現地担当者の負担を抑えながら、インシデントへの対応体制を補完できます。

委託する業務と社内に残す判断を分け、日本本社、タイ現地法人、支援会社の連絡経路を定めておきます。具体的な対応範囲は、次章で解説する支援会社の選定時に確認します。

タイのAWSセキュリティ支援会社を選ぶポイント

タイ拠点のAWS運用を外部へ委託する場合は、AWS環境だけでなく、現地ネットワークや日本本社との連携まで支援範囲を確認します。監視サービスの有無だけで判断せず、異常を検知した後に、どこまで調査や復旧を依頼できるかも比較します。

AWSと現地ネットワークを一体で支援できるか

タイのオフィスや工場からAWSを利用する構成では、AWS側の設定と現地ネットワークの双方が、通信の安全性や安定性に影響します。AWS環境だけを支援対象とする会社では、接続障害や不正通信が発生した際に、原因調査を複数の事業者へ依頼しなければならない場合があります。

支援会社を選ぶ際は、AWS環境だけでなく、現地回線やネットワーク機器を含めて調整できるかを確認します。担当事業者が分かれる場合は、関係各社との連絡や原因調査を取りまとめられる体制も選定基準です。

日本本社とタイ現地法人の双方へ対応できるか

日本本社はセキュリティ基準や予算、システム全体への影響を管理し、タイ現地法人は利用者や現地ネットワークの状況を把握しています。支援会社には、双方から必要な情報を収集し、技術的な状況と業務への影響を分けて報告する役割が求められます。

対応言語に加え、連絡先、報告方法、対応時間帯も選定時の確認項目です。タイ現地法人への英語またはタイ語での確認と、日本本社への日本語報告を一つの窓口で進められる体制であれば、説明の重複や認識のずれを抑えられます。

設計書、設定情報、運用手順、障害報告書などの成果物を、どの言語で受け取れるかも確認します。担当者が交代しても運用を継続できるよう、対応内容や設定変更の履歴を記録として残せる会社が適しています。

監視後の調査・復旧・改善まで任せられるか

監視サービスの対応範囲は、アラートの通知に限られる場合と、一次切り分けや復旧支援まで含む場合があります。通知後の調査を利用企業が担う契約では、タイ現地法人または日本本社にAWSの技術者を配置する必要があります。

契約前に、アラートの確認、影響範囲の調査、原因特定、設定変更、復旧作業のうち、どこまで依頼できるかを明確にします。緊急時の承認方法や、支援会社へ付与する権限もあわせて定めておきます。

復旧後の対応範囲も選定基準です。発生原因や対応内容の報告に加え、設定の見直し、監視項目の追加、再発防止策の提案まで受けられる体制であれば、インシデントを継続的な運用改善へつなげられます。

タイのAWSセキュリティ対策をサーバーワークスとIIJグループが支援

サーバーワークスとIIJ Global Solutions (Thailand) Co., Ltd.（IIJ GS Thailand）は、「IIJ Managed Cloud for AWS Powered by Serverworks」を提供しています。サーバーワークスのAWS技術・運用ノウハウと、IIJグループのタイ現地における事業基盤やネットワーク対応力を組み合わせ、AWS環境の設計・構築、現地拠点とのネットワーク接続、運用監視、コスト管理、運用自動化を支援します。

サーバーワークスは、AWS環境の24時間365日の運用監視にも対応しています。セキュリティに関する重要なアラートを検知した際は、あらかじめ定めた連絡先へ通知します。原因調査、復旧支援、設定の見直しなど、通知後の対応範囲は契約内容によって異なります。

タイ拠点のAWS環境や現地ネットワーク、監視体制に課題がある場合は、現状の確認と改善範囲の整理からご相談ください。