HIPAA準拠のIoTソリューション

HIPAAとIoT

モノのインターネット（IoT）は指数関数的に成長しており、一部のレポートでは、モノのインターネットが到達すると予測しています。 38年に2020億台のデバイス。 より多くと より多くの物語 ハッキングされたデバイスが登場するにつれ、モノのインターネットを保護する必要性がますます緊急になっています。HIPAAを念頭に置いた医療機器メーカーにとってはなおさらです。

米国の医療保険の相互運用性と説明責任に関する法律（HIPAA）は冗談ではありません。 HIPAAは、患者の電子保護医療情報（PHIまたはePHI）のセキュリティとプライバシーを保護し、米国保健社会福祉省（DHS）の市民権局（OCR）によって施行されます。 HIPAA準拠の通信用のデジタル証明書をお探しの場合は、 こちらの記事をご覧ください.

HIPAAは、医療提供者が輸送中または休憩中にPHIを保護することを要求しており、保護しないと多額の罰金が科せられる可能性があります。 HIPAA違反に対する罰金 違反ごとに100ドルから50,000ドルの範囲で、年間最大1.5万ドルのペナルティがあります。 2019年には、418件の違反が34.9万人のアメリカ人のPHIの侵害につながりました。 

患者情報を保護し、HIPAAに準拠し続けるために今すぐ措置を講じることは、確かに正しい行動です。 2019年には、ネットワークサーバーの侵害により、30.6万人の個人情報が侵害されました。 2018年に、American Medical Collection Agency（AMCA）のネットワークサーバーがハッキングされ、22万人の患者が データが危険にさらされている。 財政的影響と事業の喪失により、AMCAは第11章破産を申請しました。 

HIPAA情報送信要件

HIPAAは、情報伝達のセキュリティに関して次のように述べています。

164.312（e）（1）：標準：伝送セキュリティ。 電子通信ネットワークを介して送信されている電子的に保護された健康情報への不正アクセスを防ぐための技術的なセキュリティ対策を実装します。

HIPAAは将来を見据えたものであることが意図されていたため、この指令は無制限のままです。 基本的に、潜在的にコストのかかる違反から保護するには、電子通信ネットワークを介して送信される情報を保護するためのプロトコルを導入する必要があります。

組織にとって、これは、ネットワークを介してデータを送信するデバイス、特に会社のファイアウォールの外部でデータを送信するデバイスは、認証と暗号化のメカニズムを実装する必要があることを意味します。 SSL /TLS 一方向またはいずれかの方法でこれを処理できます 相互認証. 

SSL /TLS HIPAA準拠のIoT向け

SSL /TLS プロトコルの使用 非対称暗号化 インターネット上のXNUMX台のコンピューター間で共有されるデータを保護するため。 さらに、SSL /TLS サーバーやクライアントのIDが検証されていることを確認します。 最も一般的なシナリオでは、一方向認証を使用して、HTTPSサーバーが訪問者のブラウザーにSSL.comなどの公的に信頼されている認証局（CA）によってデジタル署名された証明書を提供します。 

SSL /の背後にある数学TLS 十分な大きさのキーサイズがあれば、CAのデジタル署名された証明書を改ざんすることは事実上不可能であることを確認してください。 パブリックCAは、証明書を発行する前に申請者の身元を確認します。 また、オペレーティングシステムとWebブラウザプロバイダーによる厳格な監査の対象となり、トラストストアで受け入れられて維持されます（のリスト 信頼されたルート証明書 ブラウザとOSソフトウェアとともにインストールされます）。

SSLと認証クライアント

ほとんどのアプリケーションでは、SSL /TLS クライアントに対するサーバーの一方向認証を使用します。 匿名クライアント（Webブラウザ）は、暗号化されたセッションをWebサーバーとネゴシエートします。Webサーバーは、公的に信頼されたSSL /を提示します。TLS SSL /中に自分自身を識別するための証明書TLS ハンドシェーク。 

一方向認証はほとんどのWebブラウジングで完全に受け入れられますが、攻撃者がユーザー名やパスワードなどのログイン資格情報を標的とするフィッシングなどの資格情報盗難攻撃に対して脆弱です。 フィッシング攻撃 によると、データ侵害の22％を占めています ベライゾンによるレポート。 追加の保護のために、相互認証を選択できます。 相互認証では、ハンドシェイク中にサーバーが認証されると、サーバーは CertificateRequest クライアントへのメッセージ。 クライアントは、認証のためにサーバーに証明書を送信することで応答します。 両側で認証された PKI、相互認証は、従来のパスワード中心の方法よりもはるかに安全です。

相互認証とIoT

医療機器メーカーにとっては、サーバーとデバイスの相互認証が最善の選択肢である可能性があります。これは、クライアントとサーバーのIDにチャンスを与えるものが何もないためです。 たとえば、スマート医療機器がインターネットに接続されると、製造業者は、ユーザーが情報にアクセスできるように、会社のサーバーとの間でデータを送受信することを希望する場合があります。 この情報の安全な転送を容易にするために、製造業者は次のことを考慮することができます。

• 一意の暗号化キーペアとクライアント証明書を使用して各デバイスを出荷します。 すべての通信はデバイスと会社のサーバー間で行われるため、これらの証明書は個人的に信頼されている可能性があり、証明書の有効期間などのポリシーに追加の柔軟性を提供します。
• ユーザーがスキャンするか、メーカーのWebポータルまたはスマートフォンアプリでユーザーアカウントに入力してデバイスをアカウントに関連付けることができる一意のデバイスコード（シリアル番号やQRコードなど）を提供します。
• デバイスがユーザーのWi-Fiネットワークを介してインターネットに接続されると、相互接続が開かれます TLS 製造元のサーバーとの接続。 サーバーはデバイスに対して自身を認証し、デバイスのクライアント証明書を要求します。クライアント証明書は、ユーザーがアカウントに入力した一意のコードに関連付けられています。

これで、接続のXNUMXつのパーティが相互認証され、SSL /を使用してメッセージを送受信できます。TLS HTTPSやMQTTなどのアプリケーション層プロトコルによる暗号化。 ユーザーは、デバイスからデータにアクセスしたり、Webポータルアカウントまたはスマートフォンアプリを使用して設定を変更したりできます。 XNUMXつのデバイス間で認証されていないメッセージやクリアテキストメッセージが必要になることはありません。

最後の言葉

戸外に巻き込まれないでください。 SSL.comのカスタムIoTソリューションに興味がある場合は、以下のフォームに記入して詳細情報を入手してください。