オンプレミスからAWSに移行した際、最も恩恵を受けられるセキュリティ機能が「防御」だ。AWSを利用するメリットとしては以下の2つが挙がる。
AWSには高い機密性や完全性を実現する機能が数多く用意されている。ディスクやオブジェクトストレージではデータの暗号化機能によって機密性を、ログの改ざん防止機能や「AWS Config」による設定監視で完全性を高める。
また、AWSは世界中に設置されたデータセンター群で構成される。リージョンやアベイラビリティゾーンを考慮してシステムを構築することで、ユーザーは高い可用性を実現できる。
また、AWSは「防御」機能をサポートする多くのサービスを提供している。各サービスを活用することで、オンプレミスで必要だったコスト削減や運用作業の自動化が可能になる。次項からは、AWSに移行することで「防御」機能のセキュリティ対策がどう変わるのか、バックアップ運用とパッチ適用を例にAWSの具体的なサービスを交えて解説する。
オンプレミスでサーバを運用した経験がある方は分かるかもしれないが、サーバというものは想像よりも簡単に壊れる。原因はデータ書き込み時のエラーや停電による強制シャットダウン、ハードウェアの故障など多岐にわたる。筆者が過去に参画した監視プロジェクトでも、HDDの故障を検知するオレンジランプ点灯のアラートを月1〜2件は対応していた。
サーバ故障の対策としてよくあるものは、定期的なサーバイメージの取得や無停電電源装置(UPS)の設置、複数ディスクを使用してのレイド構成などだ。加えて、ハードウェア面だけではなくデータ面においてもバックアップシステムを別途検討する必要があり、システム要件に応じて必要な設備や工数が増えていく傾向がある。
一方、AWSでのバックアップ運用は「Amazon Elastic Block Store」(EBS)の機能を利用する。EBSは「Amazon Elastic Compute Cloud」(以下、Amazon EC2)におけるインスタンスのディスク部分に利用されるサービスで、基本的にAmazon EC2インスタンスのデータは全てEBSに保存される。EBSの特徴は以下の2つだ。
連載第1回で触れた通り、AWSはサービスが稼働するハードウェアの保守を担う。EBSの稼働に利用されるハードウェアについても機器故障が発生すればAWSが水面下で対処するため、ユーザーはハードウェアの可用性を考慮する必要がない。
次に、EBSはバックアップとして「スナップショット機能」を備えている。AWSコンソールから数ステップでディスクのスナップショットを取得し、99.999999999%(イレブンナイン)の耐久性を持つAmazon S3に保存するため、簡易的なバックアップであれば別途バックアップシステムを検討する必要がない。
このように、EBSはハードウェアとデータの両面からバックアップ運用を支援するサービスだ。また、スナップショットの世代管理や保管設定、自動取得を支援する「Amazon Data Lifecycle Manager」や「AWS Backup」なども用意されている。これらを活用すれば、オンプレミスと比較してバックアップに必要なコストと運用工数を大幅に削減できる。
2つ目はWindows Updateでなじみがあるパッチ適用作業だ。多くのケースでは休日の深夜など、利用者が少なくなった時間帯に作業する。筆者が過去に参画した中で最も大きなプロジェクトでは休日のデータセンターに数十人のメンバーが集まり、寒さに震えながら一日中Windows Updateをかけて回った(データセンターは機器のオーバーヒート防止の為、真冬でも冷房が強く効いていてとても寒い)。AWSに移行することでこのような作業はどう変わるのだろうか。
AWSはサーバ管理に特化した「AWS Systems Manager」(以下、Systems Manager)というマネージドサービスを用意している。Systems Managerの機能はさまざまだが、本稿では「Patch Manager」について解説する。
Patch Managerの機能は主に「パッチ適用状況の管理」「パッチ適用の自動化」だ。
以下のスクリーンショットはPatch Managerのダッシュボードだ。
Patch Managerは“パッチが適用されていない状態”を「非準拠」として報告してくれる。このダッシュボードの赤枠部分から「パッチが適用されていないインスタンスは何台か」「適用されていないパッチの緊急性はどれくらいか」を一目で把握できる。また、インスタンス毎にコンプライアンスレポートが提供され、「Windows OS」であれば以下のスクリーンショットの赤枠部分で適用されていないパッチのサポート技術情報(KB《Knowlge Base》番号)と概要も確認できる。
ユーザーはこれらの情報に基づいて「パッチが適用されていないインスタンスは存在するかどうか」「何のパッチをインストールすべきなのか」を判断できる。
Patch Managerの2つ目の機能がパッチ適用の自動化だ。
パッチの適用自体は「シェルスクリプト」や「PowerShell」を工夫することで、比較的簡単に実装できるかもしれない。Patch Managerが優れている点は、スケジュール自動実行に加えてパッチ適用時の「オーケストレーション機能」が用意されている点だ。
オーケストレーション機能では、パッチ適用対象のインスタンスをあらかじめグルーピングしておくことで、同時にパッチを適用するインスタンスの数を制御できる。この機能によって、冗長構成を組んでいるインスタンス群に対してもサービス断を引き起こすことなくパッチ適用を実行できる。従来のパッチ適用作業はシステムによって必要なプロセスが異なっていたため、手動で行われてきた。実行対象やプロセスを柔軟にカスタマイズできるPatch Managerであれば、さまざまなシステムでパッチ適用の手動作業を減らせる。
“組織が必要とするサービスを提供し続けること”がセキュリティ対策の真の目的だ。一方でリソースに制約がある中堅・中小企業は、セキュリティ対策を後回しにしがちで、その結果ビジネスに影響を及ぼす問題が発生するというジレンマに陥ることもある。機密性や完全性、可用性を高める機能や、ユーザーをサポートする多様なサービスを提供するAWSを活用すれば、リソースの制約があってもセキュリティ対策とビジネスのミッションを両立できるかもしれない。
本稿ではNIST CSFの「防御」機能におけるAWS活用のメリットを解説した。次回は「検出」機能で必要なセキュリティ対策がAWS利用によってどう変わるのかを解説する。
Copyright © ITmedia, Inc. All Rights Reserved.