こちらの内容についてMicrosoft社のAzureドキュメントを見ながら勉強し理解した内容を共有する。
Microsoft社の資格は取得後も１〜２年での更新が必要。仕事で頻繁に使用していないと知識を維持することは難しいので、自分の知識をまとめて後で振り返れるようにしておくことはとても重要。
この記事をサクッと読んでからMicrosoft社のドキュメントを読むと少し理解が早いかもしれない。（逆に混乱したらすみません）
昔の日本語ドキュメントサイトに比べて最近は本当に改善されて読みやすくなったので、もっと深く理解したいと思った方は記事途中に参照リンクを貼っておくのでそちらを参照されたし。
Azure Storage で実施できるセキュリティ保護機能
Azure Storagre では以下の機能により保存データの安全な転送、保管、アクセス制御を行うことができる。
- 保存データの暗号化
- データ転送経路の暗号化
- ブラウザーのCORSサポート
- ユーザーからのデータアクセスの認可
- ストレージアクセスの監査
保存データの暗号化
- 保存データは漏れなく256bit AES暗号化方式（以下参照）で自動的に暗号化される
- データを取り出す時は自動的に復号される
- 暗号化／復号に係る機能は標準機能として提供されている（無効化できない）
- FIPS 140-2（以下参照）で定義されたセキュリティモジュールの最小要件に適合している
- 暗号化に使用されるキーはAzure Key Vaultに自動的に保管される（VHDイメージだけコピーされても復号することができない）
※仮想マシンのディスクの暗号化
仮想マシンにアタッチされているディスクの場合、OSがサポートしている暗号化ツール（WindowsであればBitBlocker、Linuxであればdm-crypt）を利用した「Azure Disk Encryption」（以下参照）が利用される。
Azure Disk Encryption
VMと同じようにゾーン回復性を持ったディスクとして利用できるもの。
これが設定されていない場合、Microsoft Defender for Cloud によって重要度の高い警告としてアラートが登録されることになる。
ただし、これを利用するためには別途Azure KeyVaultという暗号化キーを保存するためのリソースが必要となるので準備しておくこと。
256bit AES共通鍵暗号化
- 「安全で実用的」なレベルで情報を暗号化したり復号したりできる方式の事。
- 「鍵」というのは、情報を暗号化や復号する時に使用する小さな情報の事。
- 「共通鍵」というのは暗号化する時に使用した「鍵」を用いて復号できる方式の事。
- 「256bit」というのは「共通鍵」の情報として256ビットという長さの情報を使用するという事。
この暗号化方式は、様々なところで利用されており、一番身近なところではWIFIを利用している機器をお持ちの方はほぼ漏れなく恩恵を受けているであろう暗号化方式と思ってよいと思う。
FIPS 140-2
IT製品で実装されるセキュリティに必要とされる最小要件を定義した標準(規格)とのこと。
以下のサイトでかなりわかりやすく解説してくれている。
もう少し勉強して、説明できるぐらい整理できたら、改めて別の記事で取り上げてみたい。
転送中の暗号化
- Azure Storageへの接続時にHTTPS接続することで安全なデータ転送を行うことができる
- ストレージアカウントで「安全な転送を要求」という設定を有効化することで、REST API経由の接続時には常にHTTPS接続を強制することができる（これをしないとHTTPS/HTTPどちらでも接続できる）
- HTTPS接続を強制する設定を行うと、HTTP接続は拒否される
- ファイル共有の場合、SMB3.0を利用することで転送中の暗号化が強制される
安全なデータ転送を強制する
CORSのサポート
Azure Storageでは、CORSに応答するためのレスポンス設定をすることができる。
- ストレージアカウント／サービス毎(Blob、キュー、テーブル、File共有)に設定することができる
- Azure Portalの「リソースの共有(CORS)」で設定できる。
- 設定しない（デフォルト）場合は全ての要求に対して応答する
Azure StorageのCORS対応
オリジン間リソース共有（CORS）
「オリジン」とは以下の３つの情報で構成されるサーバーと通信ポートを特定するためのURLの一部を表す。
- 「プロトコル(http or https)」
- 「ドメイン」
- 「ポート」
（このサイトのURLの「https://juncleit.com:80/」がオリジン）
一般的なブラウザでは、WEBページをロードしたサーバー（自分自身）に対するJavaScriptを使用した後続リクエストは問題なく実行できる。
WEBページをロードしたサーバーとは異なるサーバーに対してJavaScriptからリクエストを実行しようとするとセキュリティ制限より実行できない。
これを回避するためには、CORSリクエストに対応するよう、サーバー側でCORSリクエストへの対応処理を行う必要がある。
Azure Storageではこの対応処理がAzure Portal上で実施できる。
Azure RBACによるアクセス制御
- 保存されているコンテンツに対するアクセス許可があること（認可されること）を要求できる
- Azure RBACはアクセス許可（認可）の確認で利用することができる
- セキュリティプリンシパルまたはマネージドIDに対して以下の単位でRBACロールを割り当てることができる
- サブスクリプション
- リソースグループ
- ストレージアカウント
- 個々のコンテナーやキュー
アクセス監査
- Storage Analyticsサービスで、ストレージに対する全てのアクセスを監査できる
- リアルタイムのログ記録
- 特定要求に関するアクセスログの検索
- 各種フィルター
- 認証メカニズム
- 操作の成否
- アクセスリソース
アプリの登録によるアクセスとアクセスキー（共有キーもしくはストレージアカウントキー）によるアクセス
アプリの登録によるアクセスが最適なストレージタイプ
- Blog Storage
- Queue Storage
アクセスキーによるアクセスをサポートしているストレージタイプ
- Blog Storage
- Queue Storage
- File Storage
- Table Storage
HTTP 要求時のアクセスキーの指定
HTTPヘッダーの”Authorization”に指定する。
以下はAPIバージョン、日付、アクセスキーを指定したHTTP Headerの例。
x-ms-version: 2018-03-28
Date: Wed, 23 Oct 2018 21:00:44 GMT
Authorization: SharedKey myaccount:CY1OP3O3jGFpYFbTCBimLn0Xov0vt0khH/E5Gy0fXvg=
アクセスキー
アクセスキーには以下の特徴がある。
- アクセスキーを指定した場合、ストレージアカウント内の全てのオブジェクトにアクセス可能
- プライマリとセカンダリの２つのアクセスキーが発行される
- どちらのキーでもアクセスできる
アクセスキーが権限が非常に強いので、漏えいは避けなければならない。
定期的にキーの交換を実施するようにし、アクセス元アプリケーションはキー交換による影響が最小限となるよう、交換後のキーを利用できる仕組みにしておく必要がある。
プライマリキーの交換は以下の手順で実施できる。
- アクセス元アプリケーションが使用しているアクセスキーをセカンダリに切り替える
- Azure Portalでプライマリとセカンダリを切り替える
- Azure Portalで元々プライマリだったキーを更新する
アクセスキーを用いたアクセスは、内部の信頼されたアプリケーションでストレージアカウント上のコンテンツやデータにアクセスする場合のみ利用することとし、外部アプリからのアクセス時にはShared Access Signatureを利用するのがよい。
Shared Access Signatureを理解する
Shared Access Signatureはアクセスキーとは異なり、一時的なアクセストークンとして機能する。
またアクセス範囲、アクション、時間を制限することができるので、外部サービスなど信頼されないソースからアクセスさせる目的で利用することができる。
例えば、以下のように目的に応じてアクセス権限を付与できる。
- 顧客：SASを用いて画像をアップロードできる（Uploadのみ）
- 顧客のWEBアプリ：SASを用いてアップロード済みの画像を読む（Readのみ）
SASの種類
- サービスレベル
- ストレージアカウント内の特定リソースへのアクセスを許可
- ファイルシステムに保存されているファイルのリストの取得
- ファイルのアップロード／ダウンロード
- アカウントレベル
- サービスレベル以上のアクセスを許可
- ファイルシステムの作成など
SASを利用した場合の設計パターン
- プロキシサービス経由のアクセス
プロキシサービスとは、ユーザー認証やストレージへのアクセス前に詳細なビジネスロジックを実行するサービスを提供するアプリケーションのこと。
細かい制御ができる反面、パフォーマンスや可用性を考慮した設計にするためリソース構成に複雑さを伴う。
- SASプロバイダー経由のアクセス
SASプロバイダーとは、ユーザー認証とSASトークンの提供を目的としたサービスのこと。
ユーザーもしくはクライアントを認証後、SASを発行することで、後続のストレージへのアクセスはクライアントに任せることができるため、SASプロバイダーは軽量サービスになる。
ストレージへのアクセスはSASが制御する。
ストレージアカウントへのネットワークアクセス制限を設定する
既定では、任意の場所からアクセスが可能。
ネットワークアクセスを制限するためには、この規定の設定を「許可」から「拒否」へ変更する。
※変更する前に、現在アクセスしているネットワークがあることを確認し、拒否後もアクセスできるよう、明示的にネットワークからのアクセスを許可設定する必要がある。
ネットワークアクセスの制限の設定ツール
- Azure Portal
- Azure CLI
- PowerShell
変更方法
Azure Portalを使用する場合、「ストレージアカウント」の「ネットワーク」で設定できる。
- 許可するアクセス元
- すべてのネットワーク：インターネットのどこからでもアクセスできる（既定）
- 選択されたネットワーク：指定のIP範囲からのみアクセスを許可する
- ネットワークルーティング
- Microsoft network routing：アクセス元アプリやユーザーに近い位置でMicrosoft クラウドに入る
- Internet routing：ストレージエンドポイントにより近い位置でMicrosoftクラウドに入る
「Microsoft network routing」の方が、少ないホップ数でMicrosoftクラウドに入り、Microsoftバックボーン経由のアクセスとなると想像する。
Azure Storageルーティング優先設定
ルーティングの設定は帯域幅のデータ転送に関する価格にも影響する。
例えば、Microsoftクラウド内で異なるリージョン間でデータ転送が発生した場合、受信側は無料だが、送信側は課金対象となるため、大きなファイルやデータの転送が必要な場合は注意が必要。
帯域幅の価格
Azure Storage の Advanced Threat Protection（Azure Defender for storage → Microsoft Defender for Storage）
ちょろちょろ名前が変わってるw
ストレージアカウント毎にMicrosoft Defender for Storageを有効化することができる。
有効化すると、Microsoft Defender for Cloudで監視が開始される。（別途お金かかるので要注意）
Microsoft Defender for Cloud
Microsoftのセキュリティ専門チームが定義したセキュリティとAI技術を活用し、ネットワークアクセス、ユーザーアクティビティなどを分析して不審なアクティビティや脅威と判断されるアクセスのアラート通知、セキュリティ上脆弱な設定になっている箇所の修正提案などを自動的に行なってくれるサービス。
利用可能なストレージタイプ
- Blobストレージ
- ファイルストレージ
- Data Lake Gen2 ストレージ
セキュリティ異常の調査
- アラートメールの通知
- Microsoft Defender for Cloudでの「セキュリティアラート」の詳細確認
Azure Data Lake Storageのセキュリティ機能
Azure Blog StorageとData Lake Storage Gen1の機能を集約したようなもので、Blobのデータ暗号化、可用性、RBACでのアクセス制御、アクセスキーやSASでのアクセスに加え、Data Lakeの大規模処理対応、階層構造、POSIX ALCなどの機能が利用できる。
またアクセス認証にOAuth2.0が利用できるため、Azure AD認証を用いたMFAなど高度な認証が実行できる。
Azure Data Lake Storageとは
コメント