クラウドサービスで情報漏えいは起きる？実際の事例や原因、取るべき対策を徹底解説

1. クラウドサービスで情報漏えいが起きるとどうなる？

クラウド利用時に情報漏えいが発生すると、その影響は単なるデータ流出にとどまりません。自治体や企業では、住民・利用者への説明、原因調査、再発防止策の策定など、組織として対応すべき業務が一気に増えます。特に個人情報を扱う部門では、個人情報保護法との整合性が問われ、監査対応や関係機関からの照会が発生する場合もあります。

情報漏えいが判明した直後は、広報・法務・システム部門を横断した対応が不可欠となり、通常業務の停止や、予定していたプロジェクトの見直しを余儀なくされるケースも珍しくありません。報告義務や是正措置の提示が求められるため、担当者の負荷は急激に高まります。

SaaS／IaaSの設定不備が原因であった場合、責任分界点への理解が不十分だと、「どこからが事業者の責任範囲なのか」を社内で正しく共有できず、判断が遅れる場面も見受けられます。その結果、対応方針が定まらないまま時間が経過し、関係部署との調整が難航するリスクが高まります。

理想はリスクをゼロにすることですが、現実的には完全なゼロは困難です。だからこそ、万が一のトラブルにも迅速に対応できる仕組みを整えておくことが重要になります。緊急時の対応手順や連絡用テンプレートを事前に準備しておくことは、セキュリティ担当者にとって基本となる対策です。

クラウドサービスにおける情報セキュリティ対策を知りたい方はお問い合わせください。

2. クラウドサービスにおける情報漏えいの主な原因

クラウドサービスにおける情報漏えいは、外部からの高度な攻撃だけでなく、日々の運用の中で生じる設定不備やアカウント管理のミスが原因となるケースが数多く見られます。

特に、Microsoft 365やGoogle Workspaceのように、多くの職員・社員が日常的に利用する環境では、権限構造が複雑になりやすく、アクセス権限や共有設定のわずかな誤りが、そのまま重大な情報漏えいにつながることも少なくありません。

以下では、自治体や企業の現場で特に発生しやすい情報漏えいの要因を4つに分け、それぞれどのようなトラブルにつながりやすいのかを解説します。

2-1. アクセス権限の設定ミス

クラウド環境では、アクセス権限や共有設定の誤りによって、情報漏えいが発生するケースが多く見られます。

SaaS（Software as a Service）は、インターネット経由でアプリケーションやデータを利用できる利便性の高い仕組みです。ファイル共有や共同作業を簡単に行える一方で、権限設定が細かく、サービスごとに設計思想が異なるため、管理が複雑になりがちです。

たとえば、BoxやGoogleドライブでは、特定の社員との共有を意図していたにもかかわらず、実際には「リンクを知っている全員が閲覧可能」という設定になっていた事例が数多く報告されています。

また、Salesforceのプロファイル／ロール設定や、Microsoft 365のSharePoint／Teamsの権限モデルは階層構造が複雑で、気付かないうちに部門外まで閲覧権限が広がってしまうケースも珍しくありません。

IaaS環境でも同様のリスクがあります。たとえばAWSのS3では、バケットの公開設定やアクセス制御リスト（ACL）の設定ミスによって、意図せずデータが外部に公開されてしまう事例が後を絶ちません。

これらの設定ミスは、操作した本人が問題に気付きにくく、ログからも追跡しづらい場合があるため、発覚までに長期間を要する点が特徴です。そのため、設定変更の監視や、定期的な権限レビューを行う仕組みが不可欠です。

2-2. アカウント管理の不備

クラウドサービスでは、ユーザーアカウントと付与された権限をもとにアクセスが制御されます。そのため、アカウント管理が不十分な状態は、直接的なセキュリティリスクにつながります。

特に問題になりやすいのが、退職者や異動者のアカウントが削除されず、そのまま残っているケースです。こうしたアカウントが有効なままだと、元社員による内部不正のリスクが残るだけでなく、外部で漏えいしたパスワードを悪用され、不正アクセスにつながる可能性も高まります。

また、管理者権限の過剰付与にも注意が必要です。複数のクラウドサービスで管理者ロールを持つアカウントが存在する状態で、そのアカウントが乗っ取られると、全社的な設定変更や大量のデータ持ち出しが一気に可能となり、被害が急激に拡大します。

これは、クラウド環境において最も避けるべきリスクのひとつです。

アカウント管理の不備は、攻撃者が「正規ユーザーになりすました状態」で侵入することを可能にするため、通常の操作ログに紛れ込み、検知が遅れやすいという点にも注意が必要です。

2-3. サイバー攻撃や脆弱性の悪用

クラウドサービスは高い安全性を備えていますが、インターネットに接続されている以上、外部からの攻撃を完全に防ぐことはできません。実際、クラウド環境は常に攻撃者の標的となっています。

特に多いのが、正規ユーザーになりすまして侵入されるケースです。フィッシングメールによってIDやパスワードを盗まれたり、偽のログイン画面に誘導されたりして、Microsoft 365やGoogleアカウントが乗っ取られる事例はいまも数多く確認されています。

多要素認証（MFA）が設定されていない場合、パスワード総当たり攻撃などによって不正ログインを許してしまう可能性も高まります。

また、ソフトウェア側の弱点を突く攻撃も存在します。公開されたばかりの脆弱性（ゼロデイ）を悪用されたり、API や外部連携の設定ミスを足がかりに侵入されたりするケースです。

ログ監視が十分でない場合、侵入の形跡に気付かないまま、数週間から数カ月後に情報漏えいが発覚することもあります。

「クラウドは安全」というイメージが先行しがちですが、実際には攻撃を受けやすい側面もあります。そのため、認証情報の保護、MFAの徹底、ログの継続的な確認など、日常運用で防げる対策を確実に実施することが重要です。

2-4. 従業員のセキュリティ意識不足

クラウドサービスは操作が簡単で、誰でもすぐに情報共有や作業が行えるという利点があります。その一方で、利用者の判断や操作が、そのまま情報の公開範囲に影響するという特徴があります。

たとえば、次のような行動は、実際に情報漏えいにつながりやすい代表例です。

• 外部共有リンクを深く考えずに発行し、URLを知っている第三者が閲覧できる状態にしてしまう
• 個人のスマートフォンや自宅PCなど、管理されていない端末からクラウドにアクセスする
• 出所が不明なアプリケーションに対して、組織のデータへのアクセス権を許可してしまう
• フィッシングメールや偽のログイン画面に気付かず、IDやパスワードを入力してしまう

クラウドでは、こうした操作が即座に外部公開やデータ漏えいにつながるため、一人の誤った判断が組織全体のリスクに直結しやすい点が大きな特徴です。

また、「クラウドは提供事業者が守ってくれるから安全」という認識が残っていると、共有設定や権限付与、アプリケーション連携といった利用者側の責任範囲が見過ごされがちになります。

このような理解の差を放置すると、設定や操作のばらつきとして表れ、結果的に情報漏えいの原因となります。誤操作を防ぐためには、共有方法や外部公開の基準、アプリケーション許可のルールを明確にし、組織として共通の教育と運用ルールを整備しておくことが欠かせません。

クラウドサービスにおける情報セキュリティ対策を知りたい方はお問い合わせください。

3. クラウドサービスの情報漏えいを防ぐための対策

クラウドサービスにおける情報漏えい対策では、個々のセキュリティ機能を有効にするだけでは十分とは言えません。アクセス権限や共有方法など、組織としてクラウドをどのように利用・管理するかという方針を整えることが重要になります。

ここでは、クラウド運用の現場で特に重要となる対策を7つに分けて紹介します。専任のセキュリティ監視体制（SOC）がなくても取り組みやすい内容を中心に、実務に即した観点で整理しています。

3-1. アクセス権限の細分化と定期的な見直し

クラウド環境では、業務に必要な範囲を超えた権限を付与しないことが、情報漏えい対策の基本となります。多くのSaaSでは、次のように複数の管理レベルが用意されています。

• 全体設定を管理する「全社管理者」
• 特定サービスを管理する「サービス管理者」
• 部署単位で運用を担う「部門管理者」

業務内容に応じて権限を細かく分け、どの担当者がどのレベルの管理を行うのかを明確にすることが重要です。過剰な権限を与えたままにしておくと、誤操作や不正利用が起きた際の影響が大きくなります。

また、異動や退職に伴って不要になったアカウントや権限が残りやすい点にも注意が必要です。TeamsやGoogle ドライブなどは共有範囲が広がりやすいため、外部共有の制限やリンク共有ルールをあらかじめ設定しておくことで、意図しない情報公開を防ぎやすくなります。

四半期など一定の周期で権限の棚卸し（ロール監査）を行い、不要なアカウントを削除する仕組みを設けることで、リスクを継続的に低減できます。

3-2. 情報を重要度別に管理

クラウド上の情報をすべて同じ扱いにしてしまうと、「どの情報を特に守るべきか」が分かりにくくなり、適切な制御が難しくなります。そのため、情報の重要度をあらかじめ整理しておくことが有効です。

一般的には、次のような区分で管理します。

• 機密情報（計画書、重要契約、行政判断に関わる文書など）
• 個人情報（住民情報、担当者情報など）
• 内部情報（庁内・社内共有資料、議事録など）
• 公開可能情報（広報資料、案内文書など）

分類したうえで、「誰が閲覧できるか」「外部共有を許可するか」「どこに保存するか」を決めておくと、現場での判断に迷いが生じにくくなります。

たとえば、機密情報は特定のフォルダやワークスペースに限定し、原則として外部共有をしないといったルールが考えられます。クラウドサービスによっては、ファイルに機密区分を付与できるラベルや分類機能を備えているものもあります。こうした機能を活用することで、誤った共有や取扱いのばらつきを抑えやすくなります。

3-3. 保存データと通信経路の暗号化

クラウドでは、データが外部ネットワークを経由してやり取りされるため、保存時（静止データ）と通信時（通信データ）の両方を暗号化することが重要です。

多くのSaaSでは保存データの暗号化が標準で有効になっていますが、IaaS環境では暗号化設定が任意となっている場合もあります。Amazon S3やAzure Storageなどでは、ストレージ暗号化の設定が有効になっているかを、導入時だけでなく定期的に確認しておく必要があります。

また、API連携や外部システムとの接続では、通信部分が弱点になりやすい傾向があります。TLSの設定が古いまま残っている場合や、不要な暗号方式が有効になっている場合には、通信内容が盗み見られるリスクが高まります。

さらに、特に重要な情報については、クラウド事業者の暗号化に加え、独自の鍵管理（KMS）を用いた暗号化を適用する方法もあります。データへのアクセス権と暗号鍵の管理を分けることで、内部不正や誤操作によるリスクの低減につながります。

3-4. ログ監視と異常検知の自動化

クラウド環境では、設定ミスや不正アクセスが発生しても、すぐに気付けない場合があります。そのため、ログを継続的に監視し、通常と異なる動きを検知できる仕組みを整えることが重要です。

Microsoft 365、Google Workspace、AWS、Azure、GCPでは、ログイン状況やファイル共有設定の変更、大量のデータダウンロードなど、さまざまな操作がログとして記録されます。ただし、これらを人手で確認するのは現実的ではありません。

そこでSIEM（ログの分析・異常検知）、CASB（クラウド利用の可視化と監視）、CSPM（設定ミスの検出） といったツールを活用し、不審なログインや急激な共有範囲の拡大など、リスクの高い挙動を自動で検知することで、初動対応を早めることができます。

アラートが過剰にならないよう、検知条件を調整し、重要な事象に絞って把握できるようにしておくことも運用上のポイントです。

3-5. 脆弱性診断とアップデートの定期実施

クラウド環境は常時インターネット接続であるため、脆弱性の放置は攻撃対象となりやすい状況を生みます。

SaaSは事業者側の自動更新が中心ですが、IaaS／PaaSや自社開発アプリケーションでは、OS・ミドルウェア・API を自組織で更新管理する必要があります。仮想マシンやコンテナは更新漏れが生じやすいため注意が必要です。

また、クラウド向けの脆弱性診断ツール（CSPM・CWPP など）を定期的に活用することで、設定ミスや意図しない外部公開を早い段階で把握しやすくなります。

重要なのは、アップデートや診断を「一度きりの対応」で終わらせず、継続的な運用サイクルとして組み込むことです。ベンダーの通達や脆弱性情報（CVE など）を日頃から確認し、迅速に対応できる体制を整えておきましょう。

3-6. 情報セキュリティに関する従業員教育

クラウドサービスでは、利用者の操作や判断が、そのまま外部公開や情報漏えいにつながる場面が多く見られます。そのため、技術的な対策と同様に、従業員への継続的なセキュリティ教育が重要になります。

特に、次のような点について共通理解を持たせておくことが効果的です。

• フィッシングメールへの対応方法
• 外部共有のルール
• 持ち出し禁止データの判断基準
• 私用端末の利用可否
• アプリ連携（OAuthアプリ）の許可基準

単発の研修だけでなく、eラーニングや疑似フィッシング訓練を定期的に実施することで、理解度を維持しやすくなります。また、ツール上の警告表示やガイドを活用することで、日常業務の中で誤操作を防ぐ効果も期待できます。

3-7. 適切なクラウド提供事業者の選定

クラウドの安全性は、運用方法だけでなく、どのクラウド提供事業者を選ぶかによっても大きく左右されます。自治体や大規模組織では、クラウドが長期的な基盤となることを前提に、導入前の確認が重要になります。

事前に確認すべき主なポイントは次のとおりです。

• 可用性および障害時の対応体制
• セキュリティ認証の取得状況
• 監査ログの取得範囲と保存期間
• 権限設計の柔軟性
• 外部共有の制御機能
• DLP（データ漏えい防止）機能の有無
• サポート体制やSLA

機能が豊富であっても、自組織のセキュリティ要件や運用体制と合わなければ、十分に活用できない可能性があります。導入時点で適切な事業者を選定することが、情報漏えいリスクを抑えるための重要な第一歩となります。

クラウドサービスにおける情報セキュリティ対策を知りたい方はお問い合わせください。

4. クラウドサービスで情報漏えいが起きた事例

クラウド環境では、設定の誤り・アカウントの不正利用・更新の遅れなど、複数の要因が重なって情報漏えいにつながることがあります。

SaaSとIaaSが混在する環境では、ひとつのミスが別のサービスにも波及し、短期間で影響が広がるケースも確認されています。

以下では、公表情報をもとにした3つの事例を取り上げ、「何が起きたのか」「どのようなプロセスで漏えいに至ったのか」という観点で整理します。自組織の運用ルールや監査体制を見直す際の参考にしてください。

4-1. アクセス権限の設定ミスにより大規模な個人情報が閲覧可能な状態に

ある企業グループでは、クラウドファイルサービス（Googleドライブ）上の1,000件以上のファイルについて、「リンクを知っているインターネット上の全員が閲覧可能」という共有設定が有効になっていたことが確認されました。

閲覧可能な状態が続いていた期間は、最長で6年以上とされ、ユニーク対象人数が約93万5千人規模に達したと公表されています。

原因としては、アクセス範囲の設定が意図せず広くなっていた点が指摘されました。社内のセキュリティ製品のレポート検証の中で、「リスクがあるファイル」として検知されたことを契機に発覚しています。

対応として、直ちにアクセス制限・関係者への連絡・個別報告が行われ、再発防止策として、監視の強化、共有設定・権限の見直し、役員・全従業員への教育が掲げられました。

示唆：SaaS環境では、共有リンクとアクセス範囲の組み合わせが誤設定の温床になりやすいことが知られています。権限・共有ガバナンスの定期点検と、外部共有のルール化・ツールによる自動検知の併用が有効です。

参考元：個人情報漏えいの可能性に関するご報告とお詫び

4-2. 従業員アカウント情報の窃取による不正アクセス

ある金融グループでは、第三者による不正アクセス事案により、取引先口座関連情報や連絡先情報などの個人情報が流出したことが公表されました。

調査の結果、子会社が保有していたクラウドアクセス用アカウント情報が窃取され、契約中のクラウドサービスへ侵入されたとされています。マルウェア感染や既知の脆弱性の悪用ではなく、通常の利用ログに紛れる形での不正操作が行われていたため、特定までに時間を要したことが報告されています（調査は4か月以上）。

示唆：クラウドでは、「正規ユーザーになりすました状態」で侵入されると、ログ上の異常が目立ちにくい場合があります。多要素認証（MFA）の徹底、アカウントのライフサイクル管理（退職・異動時の確実な失効）、リスクベースの検知ルール設定が、初動の早期化につながります。

参考元：不正アクセスによる情報流出について

4-3. 脆弱性対策の遅れによる不正アクセスと行政指導

あるクラウドサービス事業者では、外部からの不正アクセスを受け、法的に保護される「通信の秘密」を含む情報漏えいが発生したとして、総務省から行政指導を受けています。

公表資料によると、クラウドサービス機器に残存していた脆弱性が悪用された事案が含まれており、対策の遅れが侵入の一因となったとされています。同時期には、親会社ネットワーク経由の侵入も確認されており、外部接続点を含む複合的なリスク管理に課題があったことが示唆されています。

示唆：サービス提供者・利用者のいずれにとっても、脆弱性の早期把握と迅速な修正対応（パッチ適用 など）が重要です。CVE情報やベンダー通達の継続的な確認、変更管理プロセスへの組み込み、定期的な診断（CSPM・CWPP など）により、設定ミスや想定外の外部公開を早い段階で把握しやすくなります。

参考元：富士通クラウドテクノロジーズ株式会社に対する通信の秘密の保護及びサイバーセキュリティの確保に係る措置（指導）

事例からの横断的な学び

• 共有設定の可視化と統制：外部共有リンクの扱い、アクセス範囲の標準ルール化、定期的な棚卸し
• アカウントのライフサイクル管理：MFAの必須化、退職・異動時の即時失効、管理者権限の最小化
• 継続的な監視と診断：SIEM（ログ分析・異常検知）／CASB（クラウド利用の可視化・監視）／CSPM（設定ミスの検出）といったツールを、過剰アラートを避ける条件設計で運用
• 脆弱性対応の運用化：CVE・ベンダー通達の定期確認、パッチ適用の計画化、「一度きりではなく継続的なサイクル」として組み込

5. セキュリティに強いクラウドサービスの選び方

クラウドサービスは利便性が高い一方で、事業者ごとにセキュリティ機能、ログ提供範囲、障害時の対応体制などに違いがあります。導入前の段階で「どの水準まで確認・管理できるサービスなのか」を把握しておくことは、運用上のトラブルを防ぐうえで有効です。

特に、中堅〜大企業や自治体のように、SaaS／IaaS／PaaSを組み合わせて運用する環境では、事業者のセキュリティ体制を事前に評価しておくことが欠かせません。ここでは、選定時に押さえておきたい4つのポイントを整理します。

5-1. セキュリティ認証を取得しているか

クラウドサービスを比較する際には、どのセキュリティ認証を取得しているかを確認しておくと、事業者の管理水準を把握しやすくなります。たとえばISO/IEC27017（クラウド向け）のような認証を保有していれば、権限設計・データ管理・運用体制などクラウド特有のリスクに対して一定の基準を満たしていると判断しやすくなります。

合わせて、認証の適用範囲（SaaS／IaaS／PaaS、管理対象の範囲、事業者側と利用者側の責任分界点など）を確認しておくことが実務では重要です。範囲が明示されていれば、どこまで統制が担保されるかを把握しやすくなります。

認証の有無だけで優劣が決まるわけではありませんが、第三者基準で確認できない場合は、設定・権限管理・障害対応などの実装レベルを、自社側で丁寧に評価することが求められます。

【関連コラム】セキュリティの基本とFISC安全対策基準について

5-2. セキュリティ機能が充実しているか

次に、標準で利用できるセキュリティ機能の範囲と、自社の運用に合わせてどこまで調整できるかを確認します。日常の統制に直結する代表的な機能は以下の通りです。

• 保存時・通信時の暗号化
• ユーザー／グループ単位の詳細な権限設定
• 多要素認証（MFA）の提供と適用範囲
• 監査ログの取得範囲・保持期間
• 不審な操作を検知するアラート機能

これらが標準搭載か追加オプションか、また設定の柔軟性がどの程度あるかを事前に確認することで、導入後に想定外の運用負担が発生することを避けられます。高度な機能があっても、現場で継続運用できるかが伴わなければ統制が追いつかず、リスクを残す原因になり得ます。

特に、監査ログの形式・取得方法・保持期間が既存の運用と合うかは、SaaSとIaaSを併用する環境で重要です。機能の有無だけでなく、日々の監査・分析と無理なく連動できるかを評価ポイントにするとよいでしょう。

5-3. インシデント対応体制が明確か

クラウドサービスを導入する際は、障害や不正アクセスが発生したときに事業者がどう動くかが明確に提示されているかを確認します。検知時の通知方法、SLA（サービス品質保証）の範囲、事後の調査体制は、いずれも初動の早さに直結します。

加えて、責任分担（どこまでが事業者の対応範囲で、どこから先を利用者側が対応するか）が明確であることが欠かせません。これが共有されていれば、インシデント時の混乱を避け、必要な対応を迅速に進められます。

中堅〜大企業や自治体では、インシデント発生後に監査・法務・現場部門が連携して対応することが一般的です。そのため、報告書の形式、再発防止策の支援、調査に必要なログの迅速な提供といった点も、事前確認の対象に含めると良いでしょう。

【関連コラム】NTT東日本でクラウドセキュリティ対策(CASB)を運用してみた

5-4. 総務省の公的ガイドラインに準拠しているか

日本国内でクラウドサービスを検討する場合、そのサービスが公的ガイドラインとどの程度整合しているかを確認することが重要です。

総務省の「クラウドサービス提供における情報セキュリティ対策ガイドライン（第3版）」では、利用者側が担うべき統制範囲、設定ミス防止の考え方、運用体制の整え方などが具体的に示されています。これと照らし合わせることで、サービス設計や管理方針が自組織の要件に合致するかを判断しやすくなります。

また、政府機関向けクラウドの評価制度であるISMAPに登録されているサービスは、要求水準が明確で、審査項目が公開されているため、選定時にどの基準まで担保されているかを把握しやすい利点があります。

中堅〜大企業や自治体では、個人情報保護法・ISMS・ISO・ISMAPなど複数の基準が関わります。候補となるサービスがこれらの基準とどう整合しているかを文書で確認しておくことが、実務では欠かせません。準拠状況が不明確なサービスを採用すると、監査対応や再契約時に追加調整が必要になり、結果として運用負担が大きくなる可能性があります。

クラウドサービス選定時の視点

• 認証の有無・適用範囲を確認し、管理水準を把握する
• 標準機能／オプションの境界と運用の柔軟性を評価する
• インシデント時の役割分担と調査支援の具体度を事前に確認する
• 公的ガイドラインとの整合を文書で押さえ、監査対応の負荷を見通す

6. ISO認証×閉域接続で情報を守る「地域エッジクラウド」とは

「地域エッジクラウド タイプV」は、NTT東日本が提供する国産クラウドです。ISO/IEC 27001・27017といった情報セキュリティ認証を取得しており、運用管理やアクセス制御の水準を第三者基準で確認できる点が特徴です。導入時の社内説明や、内部統制で求められる確認事項への対応もしやすい構成です。

接続については、インターネット経由に加え、閉域網を介した接続にも対応しています。閉域を組み合わせることで、外部からの到達経路を限定でき、共有範囲の誤設定やインターネット経由の攻撃リスクを抑えやすくなるメリットがあります。

情報漏えい対策を重視しつつ、法令順守や監査対応にも配慮したクラウド利用を進めたい組織にとって、検討しやすい選択肢のひとつです。

クラウド移行に関しては、NTT東日本のクラウドエンジニアが、現状の課題や運用上の懸念点をヒアリングし、環境に合わせた構成・運用方法を提案できます。地域エッジクラウド タイプVのご案内も可能ですので、必要に応じてお問い合わせください。

クラウドサービスにおける情報セキュリティ対策を知りたい方はお問い合わせください。

7. まとめ

クラウドサービスは利便性と柔軟性を備えていますが、設定誤りや権限管理の不足、アカウントの不正利用など、日常運用の判断がリスクにつながる場面は少なくありません。特に、複数のSaaSとIaaSを併用する環境では、限られた体制で統制を維持する負荷が課題になりがちです。

本コラムで触れた、「アクセス権限の最適化」「データ分類」「暗号化」「ログ監視の整備」などの対策は有効ですが、環境が大きくなるほど自社だけで継続管理する難易度が上がるケースも見られます。

そのような状況で、ISO認証の取得や閉域接続対応、国内でのサポート体制を備えたNTT東日本のクラウドソリューションは、運用負荷を抑えながら安全性を高めたい組織にとって、検討に値する選択肢となりえます。

クラウドの安全性に不安がある／日々の運用負担を軽減したいといったご要望があれば、ぜひNTT東日本へご相談ください。

お客さまの現状と課題を伺い、環境に適した構成や運用方法を具体的にご提案します。

クラウドサービスにおける情報セキュリティ対策を知りたい方はお問い合わせください。

• Amazon Web Services（AWS）およびその他のAWS商標は、米国その他の諸国における、Amazon.com, Inc.またはその関連会社の商標です。
• Microsoft Azureおよびその他のMicrosoft商標は、Microsoft Corporationの米国及びその他の国における登録商標または商標です。
• Google Cloudおよびその他関連サービスは、Google LLCの商標です。