Azureにおけるセキュリティを考えてみる2

・Azureにおけるセキュリティを考えてみるのその2です
今回は全体的な環境を考えてみましょう

まあ、よくある販売購買やってる会社的な感じかな?

AzureやMSのクラウド製品群に関して言えば、MSのサブスクリプションによるセキュリティが一番大きなくくりとなります。
ポータルや管理画面などでのユーザー制御や、サービス制御がそれにあたります。

つまりここでの管理者アカウントや上位権限ユーザーアカウントの漏洩が最も大きなセキュリティリスクとなります。
これは当然のことだと思うので、管理や引継ぎはしっかり行うべきですね。

On-PremissでのActiveDirectory(以下AD)情報はAzureAD(以下AAD)へAD Connectサービスで同期が可能ですが、クラウドサービスへ軸足を移すのであれば、On-PremissのADをAADを正にするように移行を計画するべきでしょう。

On-Premiss ADはAADのOn-Premissサービス用認証サービスとして、AD FSもそのためのサービスとして運用を切り替えましょう。

D365での認証についてですが、AADでの認証を標準とした構成にしないとAzure連携アプリが非常に作成しにくくなります。
もちろん、証明書認証に関するコードを用意することでAD FSも含んだOn-Premiss側認証を利用できますが、環境によって開発工数変わるんではないでしょうか。

・簡単に言えばどういうこと?
AzureはActive Directory(AAD)で認証、セキュリティが担保されるようになっているので、それをもとに各種機能をAADにアプリケーション登録することでAD認証配下とし、AD認証を必須としてください。

さて、ここのところが普段アプリ系記事しか書いてない私が、こんな記事書いた理由です。
アプリ書いてるとなると、Azure サービスプリンシパルでの認証がよくやることとですが、上記の部分がきちんと立てつけられていないと、そもそもセキュリティを考慮したも何もあったもんではないとうことで、書きました。

今後さらにクラウド上へ自社サービスやシステムの構築ということが行われ、On-Premiss環境との連携はクラウド側が主体となることが多くなっていくことでしょう。

開発者はいろいろなIaaS/PaaS/SaaS/FaaSを駆使しながら開発を行うこととなりますが、セキュリティへの考慮が特に求められることとなっていきます。
Azureでは各種サービスをシークレットキーで基本的に守る形となっていますが、万が一の漏洩に対しては、Azure Key Vaultを使用し、自動でシークレットキーが更新され続ける機能もあります。

シークレットキーの管理に関しては、そもそも内部犯行許さないようにしてれば、Key Vaultまではと思いますが、高セキュリティが求められる場合は仕方がないですね。

また、StorageServiceにもファイヤウォールが登場し、もともと暗号化などはされていましたが、アクセス制御が可能となり、データ保護が一段と進みました。

クラウドサービスでUWPアプリ開発しようぜ!
いや、クラウドサービスそのものの開発もしますがw

「Azureにおけるセキュリティを考えてみる2」への1件のフィードバック

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です