標的型攻撃やランサムウェアなどの脅威が巧妙化、複雑化し、企業の事業継続を脅かすようになっています。最近では従来のセキュリティ対策に加え、多くの脅威がインターネットを介して侵入することに着目した「インターネット分離」という対策手法が注目を集めています。
今回は第2回目から引き続き、具体的な対策のひとつである「RDS on Azure」について、日本マイクロソフト株式会社の前島鷹賢氏にお話をうかがいます。
インターネット分離の手法として「RDS on Azure」を利用する３つのメリット
–では「RDS on Azure」を活用するメリットは何でしょう。
Azureならではのメリットは、大きく3つあります。ひとつは「大がかりな初期投資を必要とせず、すぐに始められること」です。オンプレミスのように、まずサーバを調達するといった必要がないのは当然として、AzureではRDS環境を数ステップで構築可能なテンプレートが用意されています。これは「Azure クイック スタート テンプレート」というもので、RDSを動かすために必要なコンポーネントがすべてテンプレート化されています。
たとえば「Azure クイックスタート テンプレートfor RDS on Azure」の「Azureに展開」というボタンを押せば、必要最小限のパラメーターの入力だけで、AzureのRDS環境を作ることができます。RDSにあまり詳しくなくても一定の品質で構築できますし、属人性を省けるわけです。なお、テンプレートは無料で利用可能で、「GitHubで参照」を選ぶとソースコードを見ることもできます。
2つ目は「ランニングコストの最適化」です。インターネット分離はエンドユーザが使うシステムなので、企業の形態にもよりますが、夜間はほとんど使われていません。たとえば夜間は1割しか使っていないのであれば、残りの9割は簡単に止めることができます。Azureは分単位での課金ですので、止めた時間がそのまま経費の節約になります。たとえば週末2日間、夜間8時間止める運用では、24時間フル稼働に比べて単純計算で半額以下になります。逆にリソースを増やすことも簡単です。
3つ目は「いつでも止められること」です。今はインターネット分離がブームになっていますが、サイバー攻撃の手法はどんどん進化していますし、セキュリティ側の技術も進歩しています。そうしますと、たとえば5年後にはインターネット分離の手法が必ずしもベストな対策であるとは限りません。そのときに、すぐに利用をやめて別の対策に移行することができます。オンプレミスで構築してしまうと減価償却もありますし、そうはいかないですよね。
「RDS on Azure」導入の傾向と構成で注意すべきこと
–「RDS on Azure」によるインターネット分離を導入、または検討している企業や団体の業種や傾向はいかがでしょう。やはり自治体と金融でしょうか。
今は自治体が一番多いですね。そして金融。特に自治体では数年前からインターネット分離の採用が進んでいますが、一方で予算の問題で導入が先延ばしになっているケースも少なくありません。そこに費用対効果の高い「RDS on Azure」をご提案していくことになるでしょう。また、最近では製造業などほかの業界でも同様の動きが出始めていますので、まだまだ旬のソリューションといえるでしょう。
–「RDS on Azure」を実装する上での注意点があれば教えてください。
まさに構成の話に入ってくると思うのですが、基本的には構成テンプレートを使うことで構築できます。冗長化なしのベーシックな環境を作るテンプレートもありますし、HAデプロイメントである程度の冗長化を考えて展開するモデルもあります。
たとえば冗長化なしの場合、エンドユーザがつなぎにくる入口になるWebサーバ（RD Webアクセス）、それからADドメインコントローラ、RD 接続ブローカー、RD ライセンスサーバ、プロファイル管理サーバといったサーバ群、そして、実際にエンドユーザがインターネットを見るためのWebブラウザやPDFリーダーを置くためのサーバ。これが最小限の構成になります。
インターネット分離は、業務上クリティカルではないと判断するお客様は、冗長化なしの構成を使用することがあります。しかし、今の時代はインターネットアクセスもビジネス上クリティカルです。可用性を担保しておかないと業務が止まってしまう可能性があります。そこで冗長化を考えたパターンもテンプレートで簡単に構築できます。入口は一般的なWebの仕組みですし、その他管理系のサーバ群の冗長化もOSが標準機能として持っています。
ただ、ネックになるのがデータベースサーバと、プロファイル管理サーバです。データベースサーバはセッション情報を管理する非常に小さなものですが、ここが死んでしまうとユーザが新しくRDSにアクセスできなくなってしまいますので、非常にクリティカルです。
プロファイル管理サーバはユーザのお気に入りやマイドキュメントを保存するファイルサーバですが、これらもクッキー情報などを消さずにインターネット上の業務を効率的に継続していくためには、冗長化して可用性を担保する仕組みが必要になります。インターネットアクセスができなくなってしまうと、従業員が個人のデバイスで業務を継続しようとする可能性もあり、それは新たなリスクになってしまいます。
そこで、「DataKeeper」を使ってサーバを2台並べて、2台間でブロックエンドのレプリケーションを取ることで冗長化するというご提案をしています。ここはマイクロソフトの製品技術だけではできない部分です。オンプレミスでは共有ディスクがありますので、共有ディスクベースのクラスタのファイルサーバが一般的でした。でもAzureをはじめとするパブリッククラウドは基本的に共有ディスクという概念がないので、可用性のためには別のクラスタを組む手段が必要になります。その際、「DataKeeper」は非常に有効ですね。
日本マイクロソフト株式会社
Microsoft Azure について |
>>最終回 インターネット分離(4) – Azure上でRDSの可用性を担保し、鉄壁のインターネット分離ソリューションを実現 に続きます
