この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
みなさんこんにちは、杉金です。
今回は 2022 年 5 月 25 - 26 日の 2 日間開催された AWS Summit Onlineのセッションレポートをしていきます。セッションのサマリーを理解し、興味があるセッションをチェックすることにご活用ください。また、セッションのアーカイブも公開されておりますので、詳細が気になった方は是非そちらをチェックして下さい。
セッション概要
医療分野でのクラウド活用の領域は日々拡がってきています。個人情報も扱うこの業界においては、医療情報に対する各種ガイドラインに沿ったセキュリティ対策を実施することが非常に重要です。このセッションでは、ガイドラインに沿ったセキュリティ対策の検討の考え方と、特に昨今重要となるランサムウェアリカバリや、脅威検出の対策について関連する AWS のサービスとともにご紹介します。
スピーカー
AWS パブリックセクター技術統括本部 シニアソリューションアーキテクト 岡本 真樹 氏
セッションレベル
Level 300: 中級者向け
セッションの対象者とゴール
対象者
- 医療情報システムのクラウド移行を検討しているIT部門の担当者、事業者
- クラウド上の医療情報システムのセキュリティ運用管理の担当者
ゴール
- 医療情報システムに対するガイドラインに沿ったセキュリティ管理をAWSサービスを用いて実現する考え方を学ぶ
- リスクベースの対応としてランサムウェアに対するバックアップ対策と、様々な脅威をモニタリングから検知する方策についての関連サービスと技術を習得する
アジェンダ
- 医療業界のクラウド活用とガイドラインへの対応
- セキュリティのリスクに対応するためには
- ランサムウェア対策としてのバックアップ
- 脅威を継続的に検知するモニタリング
レポート
1.医療業界のクラウド活用とガイドラインへの対応
- 医療業界では日本の病院においても紙のカルテが電子カルテに置き換わり、IT化を推進
- 法整備も進み、オンラインでの診療も広まってきている
- その中で、常にその中心には患者がいることがこの業界の重要なポイント
- AWSも患者の情報を安全に取り扱うことを意識して、インフラサービスやセキュリティソリューションの提供を行っている
- 多くの医療関連のお客様がクラウド活用を進めている
医療情報の扱い
- 医療現場の情報システムにおいて、患者に関する情報としての医療情報、これをどう安全に扱うかが大切な要件
- 医療情報は、個人情報保護法における要配慮個人情報に該当する
- 病院内に設置されるオンプレミスのシステムであっても、クラウドにシステムを移行したとしてもその扱いは一定の要件を満たしていくことが必要となる
- 医療情報システムに対しては、厚生労働省、総務省、経済産業省の３つの省から、２つのガイドラインが定められている（３省２ガイドライン）
医療情報を扱うシステムのガイドライン
- ガイドラインの位置付けを見ていく
- 登場人物
- 患者
- 医療機関
- 情報システム・サービス提供者
- 登場人物
- 厚生労働省が策定した「医療情報システムの安全管理に関するガイドライン」
- 医療機関と情報システムに関わる全ての関係者が遵守すべき安全管理の要求事項を定めたガイドライン
- 総務省・経済産業省が策定した「医療情報を取り扱う情報システム・サービスの提供事業者における安全管理ガイドライン」
- よりシステムに近い部分での情報システムサービスの提供者が対応すべきガイドライン
- クラウドプロバイダは情報システムのインフラの外部調達先として位置付けられ、ガイドラインに則って要求事項を満たす必要がある
医療情報システムにおける責任共有モデル
- クラウド環境におけるガイドラインへの対応を整理
- クラウドにおいては責任共有モデルをもとに考える
- 責任共有モデルではお客様とAWSの間でセキュリティとコンプライアンスへの対応を共有する
- AWS：クラウドのセキュリティに対する責任
- AWSクラウドで提供されるすべてのサービスを実行するクラウドのインフラストラクチャの保護について責任を負う
- AWSのインフラについては自らの管理状況を統制およびコンプライアンスに関するドキュメントとしてホワイトペーパーなどで提供している
- 利用者はこれらの情報をもとにガイドラインの要求事項への対応を確認していく
- お客様：クラウド内のセキュリティに対する責任
- 医療情報システムの情報資産としてのデータ・アプリケーションを守るのはお客様の責任範囲となる
- 実際の構築の場面では情報システム・サービスの提供事業者が責任をもつ範囲となる
- 医療情報アプリケーションの機能およびAWSの各種セキュリティサービスの活用により、ガイドラインに沿った対策を自ら実施することが必要となる
医療情報システム向けAWS利用リファレンス
- ガイドラインに沿ったシステムの構築・運用を進めるために、「医療情報システム向けのAWS利用リファレンス」をご覧いただきたい
- ３省２ガイドラインに沿ってAWS環境で対応するための考え方を整理した資料となる
- この資料はAWSのサイトを経由して4社のパートナー企業のサイトから資料をダウンロードできる
- このリファレンスを活用することで、3省2ガイドラインで求める個々の要求事項やリスクへの対処を把握できる
- AWS側の管理がどう実施されているのか
- 医療情報システムとしてどのような対処が求められるのか
リスクベースのアプローチ
- 経済産業省「医療情報を取り扱う情報システム・サービスの 提供事業者における安全管理ガイドライン」ではリスクベースのアプローチを採用
- リスクベースとは要求事項が一律のチェックリストのような形で提示される
- すべての対応や実装を求めるものではなく、それぞれの医療機関の利用環境やシステムの状況に合わせて、そのシステムに関わるリスクを評価し、有効な対応策を検討していくもの
- リスクマネジメントプロセス
- リスクアセスメント
- リスク対応
- 関係者へのコミュニケーションのための記録作成および報告
- このプロセスを継続的に実施してシステムに関わるリスクへの対応を強化していく
- リスクシナリオの一例：正当な利用者以外により、医療情報システム等の情報が閲覧・操作される
- リスク ”低減” としての人/組織的・技術的 対応の例
- 医療機関の方々
- パスワードの定期的な変更、類推されないパスワードの設定
- 情報システムの提供事業者
- パスワードポリシーの強制機能の実装等
- 関連するAWSサービス
- AWS Identity and Access Management(IAM)
- AWSインフラストラクチャ関連事項
- 「AWS リスクとコンプライアンスの概要」 アクセス制限に関するSOCの統制について
- 医療機関の方々
- 上記は「医療情報システム向け AWS 利用リファレンス」より一部抜粋したもの
- リスク ”低減” としての人/組織的・技術的 対応の例
- リスクベースとは要求事項が一律のチェックリストのような形で提示される
5つの機能をもとにしたセキュリティ対策の基盤
- 5つの機能
- 識別（Identify）
- 防御（Protect）
- 検知（Detect）
- 自動化（Automate）
- 調査（Investigate）
- 対応（Respond）
- 復旧（Recover）
- リスクへの対応としてシステムの防御の機能に目が行きがちだが、検知しその対応や復旧の手段も同じく実装の中で検討していくことが重要
まず見ていただきたいAWS Trusted Advisor
- このツールはAWSの環境をベストプラクティスに基づき判定して推奨の設定を与えてくれる
- 例1）IAMパスワードポリシー
- 例2）Amazon S3のバケット許可
- CloudWatchアラートによる通知
- 週次の日本語レポート
- 組織のレポートを統合
- AWS Trusted AdvisorがAWS Security Hubと統合
- 100 以上のチェック項目の追加
- AWSビジネスサポートとAWSエンタープライズサポートにご契約のお客様はすべてのチェック項目を評価可能
前半の部分のまとめ
- 医療情報システムのガイドライン - 3省2ガイドラインへの対応
- AWSにおけるセキュリティの考え方 責任共有モデル
- ガイダンスに対応したセキュリティ対策の考え方
- 「医療情報システム向けのAWS利用リファレンス」を活用
- 5つの機能をもとにセキュリティ対策の設計をすることも大切
- まず見ていただきたい – AWS Trusted Advisorによる継続的なチェック
2.セキュリティのリスクに対応するには
後半のトピックス
- 医療機関のセキュリティ対策の重要なポイント
- ランサムウェア対策としてのバックアップ
- 脅威を継続的に検知するモニタリング
バックアップの重要性
- 医療情報の見読性、保存性の確保という視点でバックアップの重要性がガイドラインでも触れられている
- それに加えて現在ではランサムウェアによるデータ破壊・暗号化も意識すべき重要な課題になってきている
- 厚生労働省ガイドライン 5.1版
- 見読性の確保(7.2)
- バックアップサーバ
- 遠隔地のデータバックアップを使用した見読機能
- 保存性の確保(7.3)
- 不適切な保管・取り扱いによる情報の滅失、破壊の防止
- バックアップの内容に改ざん等が行われていないよう検査する機能
- 見読性の確保(7.2)
- 厚生労働省のガイドライン改定の方向性
- ランサムウェアによる対応を重視
- 特にランサムウェアの被害がバックアップデータまで拡大しないよう対策
- ランサムウェア対策を見据えたバックアップ戦略が重要
- 特にランサムウェアの被害がバックアップデータまで拡大しないよう対策
- ランサムウェアによる対応を重視
ランサムウェア対策
- ランサムウェアは特徴としてデータを人質にとるため感染したパソコンやサーバのデータを破壊したり暗号化を行う
- 実際の対策
- 防御：日頃のシステムのパッチを適用
- 検知：感染を素早く気づける仕組み・体制
- 脅威に対する更なる対応として、病院の業務においてデータが使えない状況から迅速な業務再開を目指すために、病院の業務をいち早く再開する=レジリエンスに重点をおくことの重要性が高まっている
- 実際の対策
- 対策検討のキーファクター
- 保護する最も重要なデータは何ですか?
- 一部のデータの回復は、他のデータよりも優先されるべきですか?
- 許容できる回復時間はどの位ですか?
- 予算、時間、およびデータの完全性の間でどのようなトレードオフを行う必要がありますか?
ランサムウェア”復旧”のポイント
- ランサムウェアからの復旧に求められる3つの技術要素
- イミュータブル(不変)
- ランサムウェアに感染しても復旧に活用できる以前の完全なデータを保持することは業務再開の命綱
- バックアップを作成後に変更できない状態にする
- S3 Object Lock
- Backup Vault Lock
- 分離(復旧の準備)
- クラウドの場合、感染が確認された環境を分離、新たに複製サイト再構築して素早い復旧を目指すことが可能
- インフラストラクチャのテンプレート、ファイル、およびアプリケーションのコピーを物理的および論理的に分離しておく
- AWS Storage Gateway
- AWS Directory Service
- Amazon Route 53
- Amazon VPC
- AWS Direct Connect
- インテリジェンス(分析機能)
- 復旧の過程において感染する前の安全なデータであることの確証をもって作業を実施することが重要
- 機械学習やコンテンツのスキャンデータから、バックアップ破損の兆候・状況を把握する
- Amazon EC2, Amazon ECS, または Amazon Lambda（分析のためのシステム）
- Amazon GuardDuty
- Amazon Athena
- S3 StorageLens
オンプレミスからのバックアップ
- イミュータブル(不変)の方法について紹介
- Amazon S3バックアップの活用
- データ容量の制限なし
- 99.999999999%の耐久性（3つのアベイラビリティゾーンへの分散配置）
- 暗号化によるデータ保護
- DR対策（他のリージョンへのレプリケーション）
- Amazon S3 Object Lock
- イミュータブルなデータの保存の実現
- Write Once Read Many (WORM：ウォーム) モデル
- 削除または上書きされることを、一定期間または無期限に防止
- ２つのモードがある
- ガバナンスモード
- 特別アクセス許可をもたない限りオブジェクトのバージョンの上書きや削除、ロック設定を変更できない
- コンプライアンスモード
- AWSアカウントのrootユーザーを含め、ユーザーからの変更ができない
- ガバナンスモード
- イミュータブルなデータの保存の実現
クラウド上でのバックアップ
- AWS Backup
- バックアップの集中管理
- 対応サービスの一例
- Amazon EC2
- Amazon EBS
- Amazon EFS
- Amazon FSx for Windows File Server
- Amazon RDS
- Amazon DynamoDB
- Amazon Aurora
- 対応サービスの一例
- バックアップの自動化、ライフサイクル管理
- バックアップデータの暗号化
- 本番環境とバックアップで異なる暗号キー(AWS KMS)
- バックアップの集中管理
- AWS Backup Vault Lock
- ボールトロックのボールトとは貴重品保管庫や金庫のような意味合いを持つ
- イミュータブルなデータの保管庫
- WORM 設定を適用
- 保持期間の設定
- ボールトロックによる保護
- データの削除
- 保持期間を変更
- AWS Backup API, CLI, or SDKからも設定が可能
オンプレミスからのバックアップの利用例
- AWSでのランサムウェアの復旧戦略の実装を簡単にまとめる
- このアプローチは既存のオンプレミスのバックアップ機能と復元機能を利用する方法で、AWSのISVパートナーの提供するバックアップソリューションを活用する
- 利用中のバックアップソリューションがAmazon S3 Object Lockと統合できる場合
- オンプレミスのデータの保管先にAmazon S3 Object Lockの環境を指定する
- システム障害時の復旧オペレーションはオンプレミスのものを活用しつつ、ランサムウェアの脅威に迅速に対応するためのイミュータブルなバックアップの保管が実現
- オンプレミスのデータの保管先にAmazon S3 Object Lockの環境を指定する
AWSランサムウェアリカバリソリューション
- 同じくAmazon S3を使用したより高度な実装のパターン
- ランサムウェア被害の回復に向けてデータの検証を取り込んだプロセス
- 4つのアカウントを活用しデータへのアクセス権、認証の分離を行うことによりデータを保護する
- ステージングアカウント
- ボールトアカウント
- リカバリアカウント
- ボールトフォレンジックアカウント
- 保護対象はオンプレミスのデータセンター
- データバックアップのプロセス
- オンプレミスからのデータのコピーを最初に受け取る場所としてステージングアカウントを指定（オンプレミス→ステージングアカウント）
- Amazon S3 Object Lock機能を利用したボールトアカウントにそのコピーを定期的に作成する（ステージングアカウント→ボールトアカウント）
- ボールトアカウントは完全に分離されており、ステージングアカウントからのみデータを受け取る
- 利用システムからデータの直接PUSHはできないため、ランサムウェアによる直接の被害を受けない隔離されたデータ保管場所となる
- データ復旧のプロセス
- 大切なことはどのデータコピーがクリーンかを把握すること
- フォレンジックはデータの検証を意味する
- ボールトフォレンジックアカウントにデータをコピーし、保管されたデータがクリーンでマルウェアの影響を受けていないかの検証をAmazon EC2やAWS Labmdaの機能を活用して実施する（ボールトアカウント→ボールトフォレンジックアカウント）
- フォレンジックが完了したらデータを消去して、ボールトアカウント上のクリーンなデータをリカバリ用に活用する
- 復旧の段階では、リカバリアカウントに読み出した確認済みのクリーンなデータをオンプレミスまたは他のクラウドの場所に提供しデータの復旧に活用（ボールトアカウント→リカバリアカウント）
- このような形でAmazon S3 Object Lockを利用しつつアカウントを分割しデータの保護を行うこと、そして復旧の前にデータの安全性を確認した後に復旧プロセスに入ることがランサムウェアのリカバリを実現する環境のポイントとなる
AWS上でのバックアップの利用例
- クラウド上のシステムのバックアップ例
- クラウド上のストレージやデータベースのシステムに対して、バックアップ管理としてAWS BackupのVault Lock機能を活用
- この例でもアカウントの分離とVault Lockを活用することがポイント
- 認証も含めて別環境にすることにより、システム側からのバックアップ取得の方向にのみデータが流れ、その他のアクセスから完全に分離することが可能
- AWS Organizations
- AWS Backup
- Org メンバー-Zアカウント
- リージョン (同一または別)
- 分離された クレデンシャル
- AWS Backup Vault Lock
モニタリングの重要性
- 想定されるリスクの例 (一部)
- 業務上通信する必要のないIPアドレスやTCP/UDPポートにより、ネットワークを経由した攻撃を受ける。
- 不正プログラムや不正アクセス等の被害がネットワーク内で拡大する。
- 総務省・経済産業省ガイドライン
- 閉域のシステムであってもリスクは存在
- 保守用や、パッチ適用のためのルートを通じた外部との接続
- 端末のマルウェア感染をもとにしたサーバへの侵入
- 外部システムとの接続・データ交換の機会の増加
- 閉域のシステムであってもリスクは存在
- システム/ネットワークの脅威を継続的に検知する仕組みが重要
AWS のログ保管・モニタリングの基本
- AWS CloudWatch
- メトリクスの収集と追跡
- ログのモニタリングと保存
- アラームの設定
- グラフと統計の表示(ダッシュボード)
- AWS CloudTrail
- アカウントのAPIコールを記録
- AWS Config
- リソースの設定変更を継続的に記録
- VPC フローログ
- Amazon VPC、サブネット、または単一インターフェイスのネットワークトラフィックのログ記録
変化する環境に対して脅威を検知するには
- Amazon GuardDuty
- 脅威インテリジェンスと継続的監視により拡大していくAWSアカウントやリソースを効果的に保護
- ワンクリックで有効化、性能影響も無し
- AWSアカウントとリソースの継続的監視
- 各リージョンの結果によるグローバル対応
- 既知の脅威と未知の脅威を検出(重要なので太字にしました）
- 組織全体の統合と管理
- 脅威インテリジェンスと継続的監視により拡大していくAWSアカウントやリソースを効果的に保護
- Amazon GuardDuty動作
- データソース
- VPC フローログ
- DNSログ
- CloudTrailイベント
- S3データイベント
- EKSコントロールプレーンログ
- 脅威検出種類（2パターンある）
- 脅威インテリジェンス
- 異常検知(ML)
- 検出結果種類
- 脅威インテリジェンス
- 仮想通貨マイニング
- C&Cアクティビティ
- 異常検知(ML)
- 通常とは異なるユーザの挙動
- インスタンス起動
- ネットワーク構成変更
- 通常とは異なる通信パターン
- 通常と異なるポートや通信ボリューム
- 通常とは異なるユーザの挙動
- 脅威インテリジェンス
- 重要度(3つのレベル)
- High
- Medium
- Low
- AWSサービスとの連携
- Amazon Detective
- AWS Security Hub
- Amazon EventBridgeイベント
- アラート
- 対処
- パートナーソリューション
- SIEMへ連携
- データソース
実際に何が検出されるのか
- 100以上の検出結果(以下は一部)
- Backdoor：バックドア
- CredentialAccess：認証情報へのアクセス
- Crypto Currency：暗号通貨関連のアクティビティ
- Persistence：永続化
- Policy：ポリシー関連
- Privilege Escalation：権限昇格
- PenTest：侵入テスト
- Trojan：トロイの木馬
- Recon：偵察行為
- Discovery：リソースの検出
- Exfiltration：データ流出
- Unauthorized Access：許可されないアクセス
- 重要度（Severity）
- High：直ちに修正を推奨
- Medium：できるだけ早く調査することを推奨
- Low：侵害されなかった不審なアクティビティの試行
GuardDutyの対応の自動化の例
- Amazon GuardDutyで侵害されたインスタンスを検知
- Amazon EventBridgeと連携してLambdaとSNSを実行
- Lambda
- 侵害されたEC2の分離
- Amazon SNS
- Eメール/SNSでの通知
- Lambda
- Amazon EventBridgeと連携してLambdaとSNSを実行
- このような形で検知、通知・対応までの流れをAmazon GuardDutyを起点として自動化していくことが可能
更なる調査のために – 情報の集約と分析
- Amazon GuardDutyの検出結果をもとに他のサービスと組み合わせながらセキュリティインシデントへの対応につなげることが可能
- AWS Security Hub
- 組織内の様々なセキュリティデータを集約
- 一元的に可視化してリスクを評価
- Amazon Detective
- 検出結果の分析(正しい検出か)
- インシデントの影響範囲の特定
- 障害痕跡の調査
セキュリティアカウントによる集中管理
- 多数のシステムを持つ大きな医療機関の中でセキュリティ監視の統合について触れていく
- AWS Organizationsによる医療機関全体のアカウント管理
- 各部局の本番システム、開発・試験の環境を分離
- 適切な分離により影響範囲の限定
- セキュリティ管理の統合
- Amazon GuardDuty,AWS Security Hub の権限移譲された管理アカウント(Delegated Administrator)にセキュリティアカウントを指定する
再掲:5つの機能もとにしたセキュリティ対策の基盤
- 後半のセクションではリスクへの対応例を学んだ
- ランサムウェアに対するバックアップの考え方
- 脅威検知およびその対応の自動化
- 5つの機能による整理の中では今回触れた話題は「検知、対応、復旧」に相当する部分になる
まとめ
- 医療業界のクラウド活用と医療情報ガイドラインへの対応
- 責任共有モデルをもとにお客様のシステム側のセキュリティ対策を自ら実施
- 医療情報ガイドラインへの対策の AWS 利用リファレンスをパートナーが提供
- 5 つの機能をもとにセキュリティ対策の設計をすることも大切
- セキュリティのリスクに対応するためには
- ランサムウェア対策としてのバックアップ
- Amazon S3 Object Lock / AWS Backup Vault Lockの活用
- 脅威を継続的に検知するモニタリング
- Amazon GuardDutyの活用
- ランサムウェア対策としてのバックアップ
参考資料
- 医療情報システム向けAWS利用リファレンス
- AWSTrustedAdvisorがAWSSecurityHubと統合
- AmazonS3ObjectLockドキュメント
- Amazon Backup Vault ドキュメント
- AWSブログ:”セキュアなバックアップを実施するための10のベストプラクティス(2022/01/12)”
- AmazonGuardDuty(AWSBlackBeltOnlineでのAWSサービス別資料)
感想
めちゃくちゃ勉強になりました。ランサムウェアの対策について複数のアプローチを紹介して下さり、活用できるシーンが多くありそうでした。GuardDutyを活用したモニタリングも検知は行うようにしているのですが、自動化にまで踏み込めていなかったので今後ぜひ取り組みたいところです。医療業界に限らず参考になるセッションですので、興味を持たれた方は6/30までオンデマンド視聴できますので是非ご覧下さい！
8
