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