contentHeartbleed脆弱性に対する対策OpenSSLはサーバとして機能しているシステムがその通信内容を暗号化するために用いるライブラリです。従って、サービスを利用している側の立場からは基本的に何もできません。できることと言えば、本脆弱性への対応が済んだサービスについて、ユーザIDとパスワードを変更するなどの対応と、銀行口座やクレジットカードの明細に注意するなどといった程度です。未対策のサービスでは、ログインIDやパスワードを変更しても結局は同じことになるので安心はできません。サービス側から「修正が完了したのでパスワードを変更して下さい」といった連絡があった段階で変更して下さい。騒ぎに便乗してフィッシングの偽メールを送っている悪意ある第三者もいるので、メールのリンクは絶対にクリックしないよう気を付けて下さい。ちなみに、対策済みのサービスではSSL証明書が更新されているはずです。Chromeについては「設定>詳細設定を表示...>HTTP/SSL:サーバー証明書の取り消しを確認する」がデフォルトでは無効になっているので、ここにチェックを入れ、本機能を有効にしておいて下さい。サーバ運用側エンジニアの取るべき対策としては、基本的には対策済みの1.0.1gにバージョンアップすることになりますが、単にアップデートしただけでは不完全です。脆弱性のあるバージョンを使っていた場合、先にも述べたとおりSSL証明書の秘密鍵が奪取されている可能性を踏まえ、偽サーバへの対策も含めて、使用していたSSL証明書を一旦失効(revoke)させ、新たに再発行するところまで実施する必要があります。諸事情により今すぐにバージョンアップ作業はできないので、Heartbleed脆弱性だけをとりあえず何とかしたい、という場合は、該当バージョンのライブラリにおいて、原因になっている前述のHeartbeat機能を削除(-DOPENSSL_NO_HEARTBEATSを設定)しコンパイルし直しても、本脆弱性を取り除くことが可能です。OpenSSLはアクセスしたウェブページ上で入力された情報を暗号化するためのライブラリですので、サーバ用のOSによく用いられるLinuxディストリビューションなどに最初から搭載されているOpenSSLをそのまま利用することも多いと思います。この場合、基本的にはパッケージ更新などでOpenSSLをバージョンアップした上で、サーバ自体を、もしくはOpenSSLを利用する各サービスを再起動という手順になります。デフォルトで搭載されているOpenSSLが1.0.0およびそれ未満のバージョンであれば、そもそもHeartbeat機能が搭載されていないので本脆弱性に関しては問題ありません。サーバ用OSや各種ソフトウェア、ネットワーク機器などにOpenSSLが実装されている場合、そのバージョンが1.0.1~1.0.1eのままであっても本脆弱性については修正されていることもありますので、OpenSSLのバージョンのみ確認するのではなく、ディストリビューションパッケージ自体の方のバージョンも確認し、本脆弱性が修正されているかどうかをチェックしてください。前述の通り、該当バージョンより古いバージョンのOpenSSLを利用している場合は、今回のHeartbleed脆弱性の影響は受けません。言ってその古いバージョンのまま運用を続けるとか、あまつさえ過去のバージョンに戻して運用するなどという選択は、他の「既知の脆弱性」をそのままに運用するということに他ならず、間違っても正しい選択とは言えません。0.9.8以前のバージョンには、SSL_OP_ALLオプションを利用した場合にSSL2.0へのバージョンロールバックを許可してしまうため、通信経路上の改竄により弱い暗号化通信方式を強制できてしまうというバージョンロールバックの脆弱性があります。他にも、古いバージョンのOpenSSLにはバッファオーバーフローの脆弱性やサービス運用妨害(DoS)の脆弱性などが公表されています。Japanは、CIOとITマネージャーを対象に、ビジネス課題の解決とITを活用した新たな価値創造を支援します。ついて運営会社サイトマップ当サイトは最新ブラウザでの閲覧を推奨します。permission.このサイトでは、利用状況の把握や広告配信などのために、Cookieなどを使用してアクセスデータを取得・利用しています。これ以降ページを遷移した場合、Cookieなどの設定や使用に同意したことになります。Cookieなどの設定や使用の詳細、オプトアウトについては詳細をご覧ください。