シナリオ 2 のソリューション - ミッション クリティカルなアプリケーション
前のユニットでは、911 派遣システムの高可用性に関するシナリオに取り組みました。 このユニットでは、考えられる 1 つのソリューションと、考慮すべきその他のいくつかの項目を確認します。
確認する場合、提供されたソリューションを前のユニットで開発したものと比較する必要があります。 多くの場合、問題には適切なソリューションが複数存在しますが、常にトレードオフがあります。 自分のソリューション内のどの項目が提案されたものと異なりますか。 自分のソリューションには、再考の可能性があるものは何かありますか。 提供されたソリューションに、自分のソリューション内でより詳細に対処されると考えられることが何かありますか。
デプロイ オプションと構成
シナリオに取り組む際の最初の選択肢は、多くの場合、最適である可能性がある Azure SQL デプロイ オプションを特定することです。 サービス レベル アグリーメント (SLA) のみを検討する場合、99.995% の SLA が必要です。これを提供できるのは、Azure SQL Database のみです。 この SLA を取得するには、Business Critical サービス レベルをデプロイし、可用性ゾーンの使用を有効にする必要があります。
もう 1 つの一連の決定事項は、geo 冗長を有効にし、災害時に高可用性を維持する方法に関連します。 ここでは geo レプリケーションと自動フェールオーバー グループをどちらも選択できますが、自動フェールオーバー グループを使用すると、顧客は接続文字列を変更せずに、必要に応じてフェールオーバーすることができます。 このセットアップは、アプリケーションの接続文字列を更新する必要がなくなるため、そのためのダウンタイムを短縮するのに役立つ可能性があります。 また、監視クエリを構成して、状態を確認することもできます。 これにより、問題が発生した場合に、フェールオーバーを強制することもできます。
この構成では、コロケーションが果たす役割について考えることも重要です。 高可用性を維持するには、アプリケーションがデータベースにできるだけ近い必要があります。同じリージョン内が確実です。 アプリケーション(Web アプリなど) の冗長コピーが存在するように、アプリケーションが自動フェールオーバー グループの両方のリージョンにデプロイされていることを確認する必要があります。 フェールオーバーが発生した場合は、Azure Traffic Manager を使用して、セカンダリ リージョン内のアプリケーションにトラフィックを再ルーティングすることができます。
DBA と機密データ
911 派遣システムのコーディネーターは、DBA に彼らの業務の遂行を許可しつつ、機密データ (既往歴やその他の個人情報など) を保護することに懸念を示してきました。
DBA が特定の列に格納されている機密データを表示できないこと、および機密データを含むテーブルへのアクセスがすべて監視されることを確実にするために、いくつかの Azure SQL テクノロジを使用することができます。 SQL 監査を使用することは、アクセスを監視するためのベスト プラクティスですが、DBA は引き続きデータを表示できます。 データ分類を使用して機密データを分類すると、機密データにラベルが付けられ、SQL 監査を使用して追跡できるため、役に立ちます。 しかし、これらを実装しても、DBA はまだ機密データを表示できます。 動的データ マスクを使用すると、機密データをマスクするのに役立ちますが、アクセス許可のみを使用して、db_owner がユーザー データを表示することを防ぐことはできません。
データベース内に機密性の高いデータがある場合は、Always Encrypted を使用して、安全に db_owner でもその表示ができないようにすることができます。 セキュリティ管理者がデータベースにアクセスせず、DBA がプレーンテキストの物理キーにアクセスしないように、役割の分離を使用して Always Encrypted キーを管理することができます。 この戦略を SQL 監査による監視と組み合わせて使用することで、db_owner 権限を持つ DBA によるものでも、機密データへのアクセスを監視、マスク、追跡できます。
DBA は機密データをマスクする必要がありますが、Azure portal と SQL Server Management Studio または Azure Data Studio を使用して、引き続きパフォーマンスをトラブルシューティングできる必要があります。 また、Microsoft Entra プリンシパルにマップする必要がある、新しい包含データベース ユーザーを作成できる必要があります。
1 つの解決策は、各インスタンスで DBA 用に SQL DBA という Microsoft Entra グループを作成することです。 その後、そのグループを Azure ロールベースのアクセス制御 (RBAC ) ロールの SQL Server 共同作成者に割り当てます。 最後に、そのグループを論理サーバーの Microsoft Entra 管理者として設定できます。