Azure DBとAzure SQL VMの両方に機密データを保存しています。
許可されたDBAはデータベースにログオンしてクエリを実行できますが、理論的には、Microsoftのランダムな従業員が許可を求めずに同じことを実行できますか?
答えが「いいえ」であることを示唆するこのオンラインを見つけましたが、それは本当にですか?
顧客データの所有権:マイクロソフトは、顧客がAzureに展開するアプリケーションを検査、承認、または監視しません。さらに、Microsoftは、顧客がAzureに格納することを選択したデータの種類を知りません。 Microsoftは、Azureに入力された顧客情報に対してデータの所有権を主張しません。
SQL Developer Licenceを使用することのマイナス面について議論しているサイトでもこれを見つけました。
Microsoftはお客様のデータにアクセスします。SQLServerの非商用インストールでは、パフォーマンス、エラー、機能の使用、IPアドレス、デバイス識別子などを含むすべての使用状況データがMicrosoftに送信されることが必須です。例外はありません。これは、特に機密性の高いデータを扱うすべての企業にとっては除外される可能性があります。
Azureで開発者ライセンスを使用することを提案しているわけではありませんが、それはそれです-マイクロソフトはデータを合法的または不正な従業員のどちらで検査できますか?
法的に言えば、彼らはあなたのデータを読んだり、正しい裁判所命令なしに警察にあなたのデータを送ることはできません。
顧客データのリクエスト
政府による顧客データの要求は、適用される法律に準拠する必要があります。非コンテンツデータを要求するには、召喚状またはそのローカル同等物が必要です。コンテンツデータには、令状、裁判所命令、またはそのローカル同等物が必要です。
マイクロソフトからの透明性ごとに、彼らが回答した法律召喚状の現在の状態を確認するには there 。
そのため、Azureリージョンを賢く選択する必要があります。たとえば、カナダのHIPAA企業は、データの例としてカナダでホストされる必要があります。
悪意のあるMicrosoft従業員があなたのデータを閲覧する可能性があります。 プロセスは不明ですが、そのリスクは、企業内のホスティング業者や悪意のある従業員と同じです。
あなたは誰か他の人のコンピュータにあなたのデータを置いています、そして、データは何らかの方法でアクセスすることができます。言い換えれば、あなたの正確な質問に対する答えはほぼ確実です:はい、一部のMicrosoft従業員canデータを表示しますが、そうすることができるタスクを実行しないように積極的に選択します。
より広い問題は、そのようなデータの漏洩のリスクが実際にどれほど大きいかということです。私のopinionは、テナントとして構成またはソフトウェアのエラーが発生した場合よりも、Microsoftの従業員がデータにアクセス(および漏洩)するリスクがかなり低くなることです。第三者。後者は、ニュースにつながるデータ漏洩に関して私たちが通常目にするものです。
私はそこで働いていたので、経験からこれを述べます。
Microsoftは内部的にユーザーと顧客のデータを保護することについて非常に厳格であり、他のいくつかの有名なWEB衣装とは異なり、Microsoftは明示的に[〜#〜] not [〜#〜]のコンテンツをスキャンしますマーケティングや広告に使用されるユーザーのプライベートファイル(Hotmail.comメール、VMのデータファイルなど)。
ユーザーデータにアクセスするための内部ルールに違反した従業員は、ドアのPDQが表示され、法的責任を問われる可能性があります。そして、制限された幹部だけがそれを行う技術的な能力/アクセスさえ持っています。
「メタデータ」は、Microsoftが前もって行っているさまざまなルールに該当しますが、実際に誰がそれを見るかについては厳格です。通常、匿名で収集され、社内のデータベースに分類されるため、運用担当者はシステムを稼働させ続けることができます。これらの人々は、実際のユーザーデータ(通常は見ることができない)ではなく、全体的な統計情報のみを気にします。
あなたが言及するSQL開発者のライセンスデータは、顧客のSQLデータではなくメタデータ(「使用状況データ」など)です。
要するに、裁判所命令や特定のファイルの検査を必要とするいくつかの悲惨なシステム修復の問題(非常にありそうもない)がない限り、Microsoftサーバー上にあるファイルを人間が読み取ることはありません。そしてどちらの場合でも、それは限られた数の眼球であり、内部の承認が与えられた後にのみなります。
実話:非常に昔(1980年代)に、2人の技術者が定期的に古いハードドライブの束を駐車場に取り出し、そりハンマーでそれぞれに鉄道スパイクを打ち込みました。非常に治療的です。ファイルを削除するのはどうですか?
彼らはできますか?はい、データは彼らのサーバーにあり、彼らが管理しています。
彼らはいますか?おそらくそうではありませんが、理由がある場合を除きます(通常は法的であり、あなたはそれについて素晴らしい答えを持っています。また、彼らが開示できない法的なケースがあることにも留意してください)。確率は、データがどの程度興味深いか、問題があるかによって異なります。
何が使えるか?その部分はあなた次第です。クリアテキストデータを送信する場合は、はい、送信前に暗号化する場合は、いいえ
Microsoftの内部アクセスポリシーの正確な詳細はわかりませんが、パンフレットには一般情報が記載されています "クラウドにおけるプライバシーの考慮事項" (PDFダウンロード、リンク先 Microsoftのプライバシー ページ:
マイクロソフトは、データへのアクセスに関して、厳格なポリシーと手順を遵守しています。ほとんどのサービスオペレーションを自動化しているため、少数のセットのみが人間の操作を必要とします。 Microsoftは「知る必要がある基礎」で動作します。つまり、Microsoftの担当者によるデータへのアクセスは制限されており、これらの操作に必要な場合にのみアクセスできます。その後、アクセス権はすぐに取り消されます。
さらに、削除をリクエストすると、データが適切に削除または破壊されたように見えます。 (ここでの「リクエスト」には、仮想ハードドライブの解放や同様のアクションなどが含まれているようです。)
データを削除するためのポリシーは何ですか?完全に削除されることを保証できますか?マイクロソフトは、再利用する前にストレージを上書きするための厳格な基準に従っています。お客様がデータを削除するか、契約を終了した場合、当社はお客様との契約に従ってデータを確実に削除します。ハードドライブが故障した場合、ハードドライブは物理的に破壊され、データの回復が不可能になります。
とはいえ、一部の顧客データは上記のポリシーに該当しないようであり、顧客はこれが何であるかを理解し、アップロードするデータに注意する必要があるため、そのポリシーに注意する必要があります。これのほとんどはかなり明白に見えますが、 Microsoftデータカテゴリおよび定義 からの1つの例:
オブジェクトのメタデータ
お客様またはお客様に代わって提供される情報であり、ソフトウェア、システム、コンテナーなどのオンラインサービスリソースを識別または構成するために使用されますが、それらのコンテンツやユーザーIDは含まれません。例には、Azureストレージアカウント、仮想マシン、Azureデータベース、およびデータコレクション(およびそれらのテーブル、列見出し、ラベル、ドキュメントパスの該当する場合)の名前と技術設定が含まれます。オブジェクトのメタデータは操作とトラブルシューティングを容易にするためにグローバルなMicrosoftシステム全体で共有される可能性があるため、お客様はオブジェクトのメタデータに個人データやその他の機密情報を含めないでください。
Azure内のデータのセキュリティと安全性に関する主要なドキュメントは次のようです "Microsoft Azureでのデータの保護" (PDFダウンロード、途中で "Azureデータ保護"としてリンク Microsoft )。これは、17ページのMSスタッフアクセスにのみ触れています。ここでは、スタッフのトレーニング方法、監査される厳格なプロトコルなどについて説明していますが、詳細についてはあいまいです。上記ですでに見たものを繰り返しますが、場合によってはもう少し明示的です:
顧客情報をさらに保護するポリシーでは、顧客が明示的にアクセスを許可しない限り、Microsoftの担当者はVM、ファイル、キー、データベース、ADテナント、ログ、またはその他のタイプを含む顧客データに永続的にアクセスできないようにする必要があります。緊急の問題を解決する必要がある場合、Microsoft Azure管理者またはサポートスタッフは顧客データへの「ジャストインタイム」アクセスが提供され、問題が解決または要求されるとすぐに取り消されます。
また、2段落のテキストにより、データセンターから削除されたものは最初にワイプされること、および「削除は削除を意味する」こと、および「瞬時に一貫性がある」ことが明らかになります。
とは言うものの、セキュリティの問題はMicrosoftよりも組織内から発生する可能性がはるかに高いため、セキュリティ上重要な情報にAzureを使用している場合でも、ドキュメント全体を読む価値があります。
¹ ところで、「包括的な監査」の部分はあまり読みすぎないでください。 ISO/IEC 27001 などの多くのセキュリティフレームワークは、実際に物事を保護する上で優れた仕事をしていることではなく、特定のセキュリティ管理を文書化しており、それを確実に遵守するための手順があることを監査しますドキュメンテーション。したがって、パスワードが8文字以下で、小文字のみで構成されていることを文書化する場合は、それに従っていることを示すことができれば、監査に合格します。
「不正な従業員」の側面のみを取り上げます。
Microsoftの従業員の大多数は、データにアクセスできません。それへのアクセスを要求するためにいくつかのフープをジャンプする必要があるまだ少数の人。
私は元マイクロソフトの従業員です。数回私がユーザーデータにアクセスしたのは、顧客の知識と同意によるものでした。