Azure SQL Database の便利機能!!使わないと損ですよ!!

こんにちは。
コンサルティング & テクノロジー部の Azure チームの吾郷です。

今月は、Azure のトレーニングのお仕事を多めにやっていました。
今回は、トレーニングをやっている中で反応がよかった SQL Database のちょっとした機能について紹介します。



SQL Database について



 Microsoft Azure の RDB のマネージドサービスです。
イメージとしては、SQL Server の Database エンジンの機能となります。

管理ツールは、SQL Server と同様に、SQL Server Management Studio が利用できます。
また、Connect(); で、Windows だけでなく、Mac / Linux にもインストールができる、SQL Operations Studio でも管理することができます。

■Azure SQLDatabase
https://azure.microsoft.com/ja-jp/services/sql-database/

■SQL Operations Studio
https://docs.microsoft.com/en-us/sql/sql-operations-studio/what-is

今回紹介する機能は以下の機能です。
これらの機能が標準で含まれるのに使わないのは損ですよ~。

・ファイアウォール
・仮想ネットワーク
・監査
・脅威検出
・Transparent Data Encryption
・Geo レプリケーション
・動的データマスク
・脆弱性評価
・別のデータベースに同期
・自動チューニング




ファイアウォール



SQL Database を使っている方ならご存知ですよね。
だって、ここでファイアウォールで接続元IPを許可してあげないとSSMSとかで繋げないですもんね。
Azure の中のサービスは、デフォルトで接続が許可されてますが制限することもできます。

 

ただ、ファイアウォールは、Azure SQL Server の機能ですので、同じサーバを共有してSQL Database を使用する場合は、管理上は丸見えってことっすね。
まぁー、見えちゃいけないDB同士を見えちゃうような使い方する人いないんでしょうけどw 

ファイアウォールをかけられる単位がサーバ単位だと思い込んでいたのですが、DB単位もあるよって教えていただきました
(多謝)


以下のドキュメントにも記載ありますように、DB単位のファイアウォールとサーバ単位のファイアウォールがあります。
■Azure SQL Database のサーバー レベルおよびデータベース レベルのファイアウォール規則
https://docs.microsoft.com/ja-jp/azure/sql-database/sql-database-firewall-configure

DB単位のファイアウォールを設定する場合は、以下をご覧ください。
■sp_set_database_firewall_rule (Azure SQL Database)
https://docs.microsoft.com/ja-jp/sql/relational-databases/system-stored-procedures/sp-set-database-firewall-rule-azure-sql-database

まー。思い込みはダメですね。。。


仮想ネットワーク



9月の Ignite でアナウンスされた機能です。
ついに、Azure SQL Database も仮想ネットワークにつながるようになりました。
詳しいことは、弊社のインフラ隊長がネスケラボを書いているという噂を聞いていますので、こうご期待!


監査



監査は、Azure SQL Databaseのデータベース イベントを追跡し、Azure ストレージ アカウントの監査ログにイベントを書き込む機能です。
まぁー、簡単に言ってしまえば監査ログを取得する機能ってことですね。 

監査ログは、オンプレミスのDBでも取得していると思いますが、同様な形で収集することができます。
多分、セキュリティ的なコンプライアンスを取得するときに、監査ログの取得が必要となることもあると思いますが、
ポータルの画面から簡単に設定ができるので、取得しない理由もないかなって思います。

監査ログの取得を行うことで、SQL Database で追加の課金は必要とはなりませんが、
ログがストレージに保存されるので、その分の課金は発生します。


脅威検出



脅威の検出は、データベースにアクセスしたりデータベースを悪用したりしようとする、異常で有害な可能性がある不自然な動作を検出する機能です。
「SQL インジェクション」、「SQL インジェクションの脆弱性」、「異常なクライアントログイン」の検出を行うことができます。

この機能を利用する場合は、サーバ毎に月$15が追加で必要となりますが、最初の60日は無料ですので、一度試してからあとから考えるとかでもいいかもです。
ただ、このようなセキュリティ的な監視を行うとすると、セキュリティ的な知識も必要となりますのでその設計費用も含めての費用と考えると、かなり安いと思います。

脅威を検出した場合は、メールで管理者に通知がされます。

Transparent Data Encryption



Transparent Data Encryption を使用することで保存中のデータを暗号化することができます。

Azure SQL Server で設定する場合は、サービス管理 TDE と Bring Your Own Key (BYOK)のどちらかで、Azure SQLDatabase の場合は、サービス管理TDE のみとなります。

ちなみに、以下のケースについていは、本機能の暗号化が透過的に行われます。
・geo リストア
・セルフ サービスによる特定の時点での復元
・削除されたデータベースの復元
・アクティブな地理的レプリケーション
・データベースのコピーの作成

補足として、SQL Databaase周りの暗号化については、以下が適用されます

・レプリケートなどの通信上の暗号化は、トランスポート層セキュリティ
(https://support.microsoft.com/ja-jp/help/3135244/tls-1-2-support-for-microsoft-sql-server)

・使用中のデータは、Always Encrypted
(https://docs.microsoft.com/ja-jp/sql/relational-databases/security/encryption/always-encrypted-database-engine)


Geo レプリケーション



Geo レプリケーションの機能をざっくりまとめると、
・指定したリージョンに自動的に読み取り専用のレプリカを作成できる。
・レプリケーションのタイミングが5秒間隔。
・レプリカを複数指定することもできる。
・フェールオーバをしたときに、

あと、切り替えをしてもアプリからDBへの接続文字列を変えなくてもいい。ってところですね。
ですので、フェールオーバーした後、アプリをデプロイせずに運用できるのは大きなメリットだと思います。
(ちなみに、フェールオーバー中は、DBアクセスはできないです。)

以下のドキュメントで、Geo レプリケーションとバックアップストレージのGRSから別リージョンにリストアする場合の比較について記載されています。
■Azure SQL Databases Disaster Recovery 101
https://azure.microsoft.com/en-us/blog/azure-sql-databases-disaster-recovery-101/

上記のドキュメントでは、Gep レプリケーションの切り替え時間は5秒以内と書いてあるようにみえますが、実際には5分程度はかかっているように思います。
なにか特定の条件が必要なのかな?
また、現状はポータルで Geo レプリケーションを設定する場合は、言語設定を「英語」にすることをお勧めします。


動的データマスク



動的データマスクは、名前のとおりデータのマスクを行う機能ですが、クエリでデータを引っ張ってくるときに権限に応じてデータをマスクした形で返す機能です。
例えば、クレジットカードの情報を表示するときとかに、「xxxx-xxxx-xxxx-1234」 のように表示する場合に、
これまではプログラムでマスクをしていたと思いますが、これをDBの機能でやってくれるというものです。

マスクの種類は、以下の方法が選べます。
・規定値(文字列であれば4文字以上ならマスクするなど)
・クレジットカード
・電子メール
・ランダム(指定範囲を乱数を生成してマスクする)
・カスタム(指定した最初と最後の文字をマスクする)

DBの項目から、マスクする項目をレコメンドしてくれたり、なかなかおりこうさんな機能です。
多分、使うシーンってそんなに多くないじゃんって思う方もいるかもしれませんが、テストのエビデンスを取るときとかも
何気に有効な気がします。

ちなみに、以下のスクリーンショットは、上が管理者でマスクがかかってない状態。下が非管理者でマスクがかかっている状態です。





また、「行レベルのセキュリティ」というのもあり、
こちらは、クエリを実行するユーザーの特性に基づき、データベース テーブルの行へのアクセスを制御できます。
簡単に言っちゃうと、ユーザによってデータを表示したり、そもそも検索に引っかからないようにするというのをDBの機能で制御するというものです。


脆弱性評価



脆弱性評価は、データベースの潜在的な脆弱性を検出、追跡、修復できる、簡単な構成のツールです。 このツールを使って、データベースのセキュリティを事前に強化できます。
一番のメリットは、データベース スキャン レポートが必要なコンプライアンス要件を満たしていることだと思います。
なお、この機能は現時点ではプレビューの機能です。


別のデータベースに同期



別のデータベースに同期は、選択したデータを複数の SQL データベースや SQL Server インスタンスの間で双方向に同期させる機能です。
利用シーンとしては、以下が想定されています。
・ハイブリッド データ同期
・分散アプリケーション
・グローバル分散アプリケーション
なお、この機能は現時点ではプレビューの機能です。


自動チューニング



自動チューニングは、人工知能を利用した継続的なパフォーマンス チューニングによって、最大限のパフォーマンスと安定したワークロードを実現する機能です。

なお、ドキュメントの記載では自動チューニングでできることは、以下となります。
・Azure SQL Database のパフォーマンスの自動チューニング
・パフォーマンス向上の自動検証
・自動ロールバックと自己修正
・チューニングの履歴ログ
・手動でデプロイするためのアクション T-SQL スクリプトのチューニング
・ワークロードのパフォーマンスのプロアクティブな監視
・数十万のデータベースのスケールアウト機能
・DevOps リソースと総保有コストに対する良い影響

この機能も、現時点では無料ですし、パフォーマンスの向上ができることを考えると、設定しておいてもいい機能だと思います。



もし、Drop Index に不安がある方は、パフォーマンス問題が出たときに「パフォーマンスの推奨事項」を確認するという運用をしてみて、自動化してもいいと判断したときに利用するというのも一つの作戦だと思います。


まとめ


今回紹介した SQL Database の機能はオンプレミスの環境で導入しようとした場合に、大きなコストとなる機能です。
それを追加コストがほどんどなく利用できるので、使わないと損だと思います。

また、今回は紹介を省きましたが、Backup は自動的に取得されGRS のストレージに保存されたり、認証には、Azure Active Directory が利用できたりと、ただのDBエンジンとしてだけ使うのだともったいないサービスです。

是非これらの機能を有効につかってください。

余談ですが、ネクストスケープ クラウド事業部のみんなで、今年は Advent Calendar に参加します。是非そちらもよろしくお願いします!!



ネクストスケープ企業サイトへ

NEXTSCAPE

検索する

タグ

メタデータ

投稿のRSS