電子カルテとセキュリティガイドラインとAWSと私 /Rails Developers Meetup 2018 Day 3 Extreme

7/14(土)にRails Developers Meetup 2018 Day 3 Extremeで、メドレーの宍戸が発表させていただいた資料です。

・Rails Developers Meetup 2018 Day 3 Extreme
https://techplay.jp/event/679666

Transcript

1. 電子カルテとセキュリティガイ ドラインとAWSと私 株式会社メドレー　宍戸展志
2. 自己紹介 - 宍戸展志（@joe_hrmn） - 株式会社メドレー - CLINICSカルテ / オンライン診療アプリCLINICS
3. 今日は電子カルテに関する話をします - CLINICSカルテというやつです
4. 今日の内容 - CLINICSカルテ - 3省4ガイドライン - ガイドラインへの対応 - セキュリティ対応 - クライアント認証 - まとめ
5. CLINICSカルテ - クラウド型電子カルテ - 院内への設備投資や準備の手間を削減 - ORCAを内包し、患者の管理も電子カルテでワンストップに - アップデートやセキュリティもプロダクト側で対応 - オンライン診察とも連携
6. ３省４ガイドライン - 電子カルテをはじめ、電子化された医療情報をパブリッククラ ウドなどに外部保存する際に遵守する必要があるガイドライン - 医療情報システムの安全管理に関するガイドライン - ASP・SaaS事業者が医療情報を取り扱う際の安全管理に関するガイドライン - 医療情報を受託管理する情報処理事業者における安全管理ガイドライン - ASP・SaaSにおける情報セキュリティ対策ガイドライン
7. ガイドライン内容（かなり抜粋） - 個人情報の保護方針の公開(プライバシーポリシーなど) - アカウントごとの権限管理や各種操作のログ管理 - 運営組織に属する社員へのセキュリティ教育や退職者のアカ ウント管理（内部統制） - データのバックアップやリカバリ方法の文書化 - クライアント認証や通信に関する要件 - 日本国法の適用範囲での管理 - etc
8. ガイドライン内容（かなり抜粋） - 個人情報の保護方針の公開(プライバシーポリシーなど) - アカウントごとの権限管理や各種操作のログ管理 - 運営組織に属する社員へのセキュリティ教育や退職者のアカ ウント管理（内部統制） - データのバックアップやリカバリ方法の文書化 - クライアント認証や通信に関する要件 - 日本国法の適用範囲での管理 - etc
9. カルテシステムの基本構成（イメージ）
10. カルテシステムの利用サービス群（※一部） CodeBuild ビルド CloudWatch Lambda 通知 Cloud Trail Inspector VPC flow logs Guard Duty セキュリティ Route 53 S3 Automation Documents Inventory Parameter Store Patch Manager Systems Manager Run Command インスタンス管理
11. カルテシステムの利用サービス群（※一部） GuardDuty 監視 設定履歴、ルール管理 Config CloudTrail VPC Flow Logs ログ収集 CloudWatch Lambda 通知 SNS
12. カルテシステムの利用サービス群（※一部） GuardDuty 監視 設定履歴、ルール管理 Config CloudTrail VPC Flow Logs ログ収集 CloudWatch Lambda 通知 SNS
13. カルテシステムの利用サービス群（※一部） GuardDuty 監視 設定履歴、ルール管理 Config CloudTrail VPC Flow Logs ログ収集 CloudWatch Lambda 通知 SNS
14. カルテシステムの利用サービス群（※一部） GuardDuty 監視 設定履歴、ルール管理 Config CloudTrail VPC Flow Logs ログ収集 CloudWatch Lambda 通知 SNS
15. 医療機関からのNW接続や認証 - これまでのガイドライン - オンプレの構成が前提 - オープンなNWに対してはVPNでの接続が必要だった - 2017年（第５版） - TLS1.2でのクライアント認証も選択肢に
16. クライアント認証 - サーバー証明(書)とSSL通信 - 信頼された認証局によりがサービスを提供する運営組織が実在することを証 明（電子証明書の発行） - 証明書を利用しSSLにより利用者とサービス間で暗号化通信を行う - クライアント証明 - システムを利用するユーザーのデバイスに証明書を設定 - 上記証明書をチェックしサーバー側で利用者を認証 - 証明書を持たない端末からのアクセスを制限
17. クライアント認証（前）
18. クライアント認証（後）
19. クライアント認証 - Application Load Balancer - TLSクライアント認証に非対応 - SSL終端となるためNginxでのクライアント認証不可 - API Gateway - TLSでのクライアント認証に非対応 - SSL終端となるためNginxでのクライアント認証不可 - API Gateway〜backend間で、API Gatewayをclientと見なすケースにおいて はクライアント認証の設定も可能（ｺﾚｼﾞｬﾅｲ...） - 結果として - ELBでのTCPロードバランシング（SSL終端しない） - Nginxで認証（SSL終端とクライアント認証）
20. 今後 - 医療システムとしての機能拡充 - 機能増大に伴うコンポーネントの増加 - サービス分割・・・？ - いかにシンプルにガイドラインを守ることが出来るか - 現状の構成でどこまでいける・・？ - FargateやEKSを利用した構成の検証
21. まとめ - 医療情報を扱う上で守るべきガイドラインの存在 - そのガイドラインへの対応の一例 - 各種マネージドサービスを使うことで様々な要件に対応できた - クライアント認証の一例 - 引き続き、マネージドサービスの力を借りつついい感じの構成 を模索中 - アプリケーションの開発に力を入れていけるように