Amazon Web Services ブログ

ランサムウェア被害から医療データの安全を守る

近年、世界中の機関や組織がランサムウェア攻撃の被害を受けています。医療機関も例外ではなく、ランサムウェアを用いた攻撃の標的となることがしばしばあります。

本ブログでは、医療機関でも被害が増えているランサムウェアとその被害からの復旧における重要な指標、バックアップを活用したデータ保護についてご紹介します。また、その中でバックアップや復旧において、ご活用いただける AWS のサービスや機能についてご紹介します。

ランサムウェアについて

ランサムウェアとは、ビジネスに不可欠なデータへ不正にアクセスし、データの暗号化やアクセス遮断を行い、身代金を要求するようなマルウェアの一種です。
昨今では様々なタイプのランサムウェアが出てきており、ファイルを暗号化するだけでなくデバイス自体を暗号化するなど、ランサムウェアは継続的に変化する脅威として知られています。
デバイスやファイルを不正にロックされることにより、被害者はそれらのリソースへのアクセスが遮断されてしまいます。医療機関の場合、患者の診察履歴や投薬の記録といった、ミッションクリティカルなデータへのアクセスができなくなります。そのため、医療機関は、サイバー攻撃に備えた事業継続計画の策定が急務となっています。

また、攻撃者に対して身代金を支払う行為は、必ずしもデータが回復するとは限らず、攻撃者に対する支援につながるため、決して行ってはいけません。

ガイドラインに則ったソリューション構築におけるポイント整理

医療機関では電子カルテをはじめ、診療報酬請求のためのレセプトコンピューター、PACS (医用画像管理システム)、各種部門システム等多くの医療情報システムが稼働しています。日本におけるすべての医療行為は医療法等で医療機関等の管理者の責任で行うことが求められています。クラウドサービスを利用する場合も、医療情報システムの構築や運用に関連して、安全かつ適切な技術的及び運用管理方法を確立し、安全管理や e-文書法の要件等への対応を行っていく必要があります。具体的には 3 省 2 ガイドラインと称される、厚生労働省、総務省、経済産業省の 3 省が定めた医療情報システムに関する各ガイドラインに対して、関連事業者や責任者が要求事項を整理検討し、必要に応じて対策を施す必要があります。

医療機関及び医療情報システム事業者における 3 省 2 ガイドラインの位置付けについては、医療情報ガイドラインの改定から読み解くクラウド化 | Amazon Web Services ブログにて解説を行なっております。

医療情報の電子保存における要求事項の 3 基準

厚生労働省のガイドラインに記載されている医療情報の電子保存における要求事項の 3 基準には、「真正性」「見読性」「保存性」の 3 つがあります。各基準は以下のように定義されています。電子カルテのような医療情報を扱うシステムは、これらも考慮する必要があります。

真正性:
正当な権限で作成された記録に対し、虚偽入力、書き換え、消去及び混同が防止されており、かつ、第三者から見て作成の責任の所在が明確であること。

見読性:
電子媒体に保存された対象を、「診療」「患者への説明」「監査」「訴訟」などの要求に応じて、それぞれの目的に対し支障のない応答時間やスループット、肉眼で見読可能な状態にできること。

保存性:
記録された情報が法令などで定められた期間にわたって真正性を保ち、見読可能にできる状態で保存されること。

復旧における重要な指標

データの復旧には、目標復旧時点 (RPO) と目標復旧時間 (RTO) という 2 つの重要な指標が存在します。

RPO:
データを過去のどの時点まで復旧させる必要があるかという指標です。例えば、ランサムウェアの被害においては、データの損失をどれだけ許容できるかに関連があります。

RTO:
どれだけの時間で復旧を完了させるかを示す指標です。システムの停止時間やダウンタイムと関連があります。

バックアップ取得対象とするシステムの RPO や RTO を確認し、適切なバックアップ頻度で適切な復旧環境を検討できているかについて確認することが重要です。

ランサムウェア被害とRPOとRTOの関係性を表す画像

ランサムウェア被害とRPO、RTOの関係性

バックアップと復旧戦略を考える上で、データ量とコストはトレードオフの関係であることに注意してください。優先すべき復旧対象データを特定し、RPO や RTO を明確にすることが、ビジネスの継続や復旧コストなどの観点から重要となってきます。

従来のバックアップ戦略

AWS サービスを紹介する前に、従来のバックアップ戦略について説明します。医療機関内で、各種のアプリケーションおよびデータベースサーバーが稼働しており、院内にある 1 次バックアップサーバーにバックアップが集約されることがよくあります。これらのバックアップを長期間テープストレージに書き出したり、遠隔地に 2 次バックアップサーバーを用意することで、物理的に隔離して保管されている場合もあります。しかし、このような仕組みは、増え続けるバックアップデータに対して、都度ストレージの追加が発生するなど、コスト効率の良いアプローチとは言えません。
これらの課題については、利用した分だけ料金が発生する従量課金という、クラウドならではの特徴を活かしたアプローチで解決することができます。

AWS ストレージサービスでの Immutable なデータ保護環境

ランサムウェア被害を受けた際のリカバリにおいては、保存されたデータは本当にランサムウェアの被害を受ける前の正しいデータかどうか疑われます。そのため、ランサムウェアに対応するためには、災害対策で考えられるような物理的な遠隔地に置かれるだけでなく、一度書いたら二度と上書きができないような、Immutable なストレージが必要です。Immutable とは、「変更不可能な」という意味で、一度作成したら、その状態を変えることができないということです。AWS のストレージサービスには Immutable を実現するための、Write Once Read Many (WORM) 機能を備えているものもあります。このように物理的に離して障壁(エアギャップ)を設けるだけでなく、Immutable な状態のように論理的な障壁 (ロジカルエアギャップ) を生じさせるような構成を、クラウドであれば容易に実装することが可能です。
ここからは、AWS のストレージサービスとその詳細を紹介します。

S3 Object Lock

Amazon Simple Storage Service (Amazon S3) は、任意の量のデータの保存と取得をどこからでも行えるように設計されたオブジェクトストレージです。S3 Object Lock は、WORM モデルを使用したオブジェクトの保存を可能にします。この機能を有効化することで、S3 上にアップロードされたオブジェクトに対する上書きや削除操作が行えなくなり、データの改ざん防止機能としてご利用いただくことができます。
医療機関の場合、例えば S3 上に保存している電子カルテのバックアップなどを、ランサムウェアによるデータ上書きや削除といった攻撃から保護することができます。
S3 バケットの作成時に詳細設定から S3 Object Lock を有効化するか、既存のバケットに対してはAWS サポートへのサポートケースの起票により有効化することができます。

Amazon S3 オブジェクトロックの設定画面

Amazon S3 オブジェクトロックの設定画面

S3 Object Lock には、「ガバナンスモード」と「コンプライアンスモード」の2種類の保持モードが存在します。ガバナンスモードでは、特定の IAM アクセス許可を持つユーザー以外の上書きや削除操作から保護し、コンプライアンスモードでは、保持期間中はルートユーザーを含むすべてのユーザーの上書きや削除操作からオブジェクトを保護することができます。

ガバナンスモードとコンプライアンスモードの選択画面

ガバナンスモードとコンプライアンスモードの選択画面

また、デフォルトの保持期間を設定せずに、リーガルホールドの設定を行うことが可能です。リーガルホールドは、保持期間を設定していないので、上書きや削除操作から無期限に保護することができます。こちらを適用することで、IAM でリーガルホールドの権限が付与されたユーザーのみ、上書きや削除操作を許可するように設定することができます。

ガバナンスモードとコンプライアンスモードの場合、保持期間が終了した後は、リーガルホールドの設定を有効にしない限り、オブジェクトバージョンを上書きまたは削除することができます。
以上のように、S3 Object Lock を有効化することで、データを Immutable な状態で保存することができます。

より詳細な情報は、「S3 オブジェクトロックの仕組み – Amazon Simple Storage Service」や「Amazon S3 オブジェクトロックによるデータの保護 | Amazon Web Services ブログ」をご参照ください。

AWS Backup Vault Lock

AWS Backup は、バックアップの一元管理と自動化を実現するフルマネージドサービスです。手動と自動スケジュールのバックアップを実施することができます。1 つのコンソールで、多岐にわたる AWS リソースのバックアップの設定と実行、復旧を実施することができ、一元管理することができます。暗号化した個別の Vault と呼ばれる単位でデータを格納することができるため、セキュリティを確保することもできます。Vault は、バックアップを保存および整理するためのコンテナです。

AWS Backup Vault Lock は AWS Backup のオプション機能で、対象の Valut を読み込み専用である WORM に設定することができます。この機能により、バックアップデータを変更できなくなるため、バックアップデータの暗号化といった、ランサムウェアによる悪意ある攻撃を防ぐことができます。また、不注意や誤操作によってバックアップが削除されることも防ぐことができるという利点もあります。
医療機関に限らず、ランサムウェア被害から復旧する際に利用するバックアップデータを、悪意ある上書きや削除から保護することができます。

AWS Buckup Vault の設定画面

AWS Buckup Vault の設定画面

AWS Backup Vault Lock 機能も、S3 Object Lock と同様に、特定の IAM 権限でのみ Vault に格納されたリカバリポイントを削除可能な「ガバナンスモード」と、ルートユーザーであったとしても Vault に格納されたリカバリポイントを削除できない「コンプライアンスモード」が用意されており、お客様の要件に合わせて選択することが可能です。また、リーガルホールドの機能も提供しており、保持期間が終了していても、明示的に解除されるまではバックアップの削除を防ぐことができます。

より詳細な情報は、「AWS Backup Vault Lock – AWS Backup」や「AWS Backup | 一元管理型クラウドバックアップ | よくある質問 #Write-Once-Read-Many (WORM)」をご参照ください。

EBS スナップショットゴミ箱機能のルールロック

Amazon Elastic Block Store (Amazon EBS) は、EC2 インスタンスで使用するためのブロックレベルのストレージボリュームを提供します。 EBS スナップショット とは、Amazon EBSボリュームのデータを Amazon S3 にバックアップできます。そして、EBS スナップショットゴミ箱は、EBS スナップショット を誤って削除した場合でも、スナップショットを復旧できる機能です。ゴミ箱からの手作業での削除インターフェースは存在せず、ゴミ箱ルールに入れたものはゴミ箱ルールで指定された保持期間を迎えるまでは削除できません。

しかし、ランサムウェアや悪意を持った攻撃者は、ゴミ箱ルールを削除してからスナップショットを復元してデータを不正に取得し、それを削除するという方法でゴミ箱の回避を試みることもあり得ます。それを阻止することができる機能が、EBS スナップショットのゴミ箱のルールロック です。これは、EBS スナップショットゴミ箱機能のルールを編集、削除することを防ぐ機能です。「ロック解除の遅延期間」を設定すると、その期間中は遅延期間を変更や削除ができない状態になります。
ルールがロックされると、保持ルールの編集もできなくなるため、保持しているゴミ箱内の EBS スナップショット の削除保護が実現できます。ルール自体の変更や削除ができないため、攻撃者は前述の手法でスナップショットを削除することができなくなります。
例えば、医療機関で本番運用している AWS アカウントの権限が侵害された場合、ロック解除の遅延期間を設けているため、その期間中は EBS スナップショットからデータを復旧できなくなることを心配せず、セキュリティ脅威を検出して対応するための時間を確保することができます。

ルールロックの設定画面

ルールロックの設定画面

より詳細な情報は、「保持ルールの操作 – Amazon Elastic Compute Cloud」をご参照ください。

Amazon FSx for NetAPP ONTAP の SnapLock

Amazon FSx for NetApp ONTAP は、ONTAP ファイルシステムの一般的な機能、パフォーマンス、API を AWS のフルマネージドサービスとして利用でき、AWS の俊敏性、スケーラビリティ、セキュリティ、および耐障害性を享受することができます。
SnapLock は、WORM を備えたボリュームを作成する ONTAP 機能で、指定された期間内のファイルの変更や削除を防止することができます。そのため、ランサムウェアや悪意を持った攻撃者によるデータの改ざんや削除から、データを保護することができます。
現在オンプレミスで利用中のファイルシステムがあり、AWS クラウド上に移行する場合、ランサムウェア被害に対策できるファイルストレージの移行先として検討することができます。

SnapLock の設定画面

SnapLock の設定画面

SnapLock では、「コンプライアンスモード」と「エンタープライズモード」の 2 つのモードが用意されています。
コンプライアンスモードでは、保持期間が終了するまで、全てのユーザーはファイルの名前変更や削除操作を行うことができなくなります。
エンタープライズモードでは、コンプライアンスモードでボリュームを作成する前に、組織のデータ保持ポリシーや、保存設定をテストするために使用されます。このモードでは、承認されたユーザーのみに削除操作を許可することができます。また、有効な保存期間内の WORM ファイルが含まれていても、そのボリュームを削除することができます。

この機能は、既存のボリュームに対して有効化することができませんが、SnapLock が有効なボリュームを新規作成して、そのボリュームにデータをコピーすることはできます。

より詳細な情報は、「新着情報 – 規制コンプライアンスとランサムウェア対策を目的として Amazon FSx for NetAPP ONTAP が WORM 保護のサポート提供を開始 | Amazon Web Services ブログ」をご参照ください。

各サービスの機能の比較

今回ご紹介した、4 つのサービスの機能の比較表を以下に示します。

Amazon S3 AWS Backup ゴミ箱機能(EBS スナップショット) Amazon FSx for NetAPP ONTAP
名称 Object Lock Vault Lock Rule Lock SnapLock
保護対象リソース バージョニングされたオブジェクト リカバリポイント ゴミ箱内の EBS スナップショット ファイルとボリューム
設定対象リソース オブジェクトまたはバケット Vault ゴミ箱機能のリテンションルール SnapLockの設定はボリューム単位、リテンションの設定はファイル単位
リソース削除のタイミングとロックのリテンションの関係 ロックのリテンションとオブジェクトの削除は独立 ロックのリテンションとリカバリポイントが削除されるタイミングが同じ ロックのリテンションとゴミ箱からスナップショットが削除されるタイミングが同じ ロックのリテンションとファイルの削除は独立
実際に保護対象リソースが削除できるタイミング ロック解除後のライフサイクルなどで指定したタイミング Backup plan でのリテンション次第 ゴミ箱機能のリテンションルール次第 ロック解除後のファイルの標準的な削除タイミング
ユースケース オブジェクトストレージである S3 上に保存している電子カルテのバックアップなどを、ランサムウェアによるデータ上書きや削除といった攻撃から保護 AWS上の各種リソースや、オンプレミスのVMware 仮想環境のバックアップで利用でき、ランサムウェア被害から復旧する際に利用するバックアップデータを、悪意ある上書きや削除から保護 既に EC2 で稼働している医療情報システムがあり、AWS アカウントの権限が侵害された場合、ロック解除の遅延期間中に EBS スナップショットからデータを復旧できなくなることを心配せず、セキュリティ脅威を検出して対応するための時間を確保 医用画像や文書ファイルを、ランサムウェア被害から保護することができるファイルストレージ

ランサムウェア被害を対策する上では、ロックの保持期間やロック解除の遅延期間を適切に設定することが重要です。適切に設定するためには、セキュリティ侵害の特定と対応にかかる時間を見積り、それよりも長くする必要があり、過去のセキュリティインシデントやアカウント侵害の特定と修復に必要な時間を確認しなければなりません。一方で、お客様自身が意思をもって削除を試みたい場合、ロックの保持期間やロック解除の遅延期間が終了するのを待つ必要があり、その後にリソースの削除やルールの変更、もしくはルールの削除する必要があります。

まとめ

本ブログでは、ランサムウェアの脅威に備えるためのガイドラインの要点、復旧戦略を検討する上でのポイントとなる目標復旧時点と目標復旧時間についてお話ししました。また、バックアップのストレージとして AWS では S3 の Object Lock や AWS Backup の Vault Lock、EBS スナップショットゴミ箱機能のルールロック、Amazon FSx for NetAPP ONTAP の SnapLock がランサムウェア対策において有効であることを説明しました。

内閣サイバーセキュリティーセンターの NICS厚生労働省情報処理機構医療機関向けセキュリティ教育支援ポータルサイトなど、各組織よりランサムウェア対策の特設ページが設けられています。最新の情報をご確認の上、対策を検討いただければ幸いです。

著者について

吉村 弘明 (Yoshimura, Hiroaki) は AWS Japan のソリューションアーキテクトです。週末は料理をしたり、美味しいご飯を求めて都内を歩いています。

 

 

 

片山 洋平 (Katayama, Yohei) は AWS Japan のパブリックセクターのソリューションアーキテクトです。主に医療機関をはじめとしたヘルスケア業界のお客様のソリューション構築の支援を行なっています。週末は登山を嗜んでいます。