落とし穴になりやすい暗号鍵の運用

電子資産を保護するためには暗号鍵は欠かせません。もしその暗号鍵の運用が不十分で盗難にあってしまうと、資産を保護できず被害を受ける可能性が高まります。本記事では暗号鍵の運用時で落とし穴になりやすいポイントを例を挙げてご紹介します。

はじめに

ソフトウェアのセキュリティを考えるうえで暗号鍵の運用は非常に重要な項目の一つです。どれだけ強固な機能で大事な資産を守っていたとしても、暗号鍵の運用が不十分だと簡単にセキュリティは破綻します。これはソフトウェアに限ったことではありません。たとえば鍵とパスワードがなければ絶対に開けることができない金庫があったとしても、その鍵やパスワードの管理がずさんで誰でも簡単に入手できる状態であれば、その金庫内の資産は簡単に泥棒に持ち出されてしまうでしょう。

現代では世界中の人々が日常でさまざまな鍵を管理・運用しています。自動車の鍵、家の鍵、引き出しの鍵、金庫の鍵、ロッカーの鍵が一例です。物理的な鍵だけでなくスマートフォンのスクリーンロック解除の生体認証データやSNSアカウントのパスワードも鍵に相当します。そしてそれらの鍵で資産を保護しています。

みなさんは鍵をどのように管理・運用しているでしょうか？

例えば自転車の鍵であれば玄関先の鍵ホルダーに置く、金庫の鍵は別のダイアル付きの金庫の中に保管する、などです。鍵によって管理する場所はきっと違うでしょう。それは主に鍵の利便性と資産を盗まれた時の被害額と盗まれやすさのトレードオフで決まってきます。よく使う鍵であれば使いやすさの考慮が必要ですし、価値の高い資産を守るときであれば、簡単に盗まれないようにあえてわかりにくい場所に鍵を保管することを考えます

利便性を重視する場合とセキュリティ性を重視する場合で管理方法は変わることになります。

また同じ資産であっても人によって価値が違います。もし資産を盗まれても別のものを用意すればいいと考える人もいますし、絶対盗まれてはいけないと考える人もいます。また資産の使い方によっても鍵の運用方法は変わります。利用者が複数いる場合は、その利用者全員が使える環境で管理する必要が出てきます。

資産の価値や使い方に違いがあるため、鍵の管理・運用手段は利用条件によってそれぞれ異なるものになります。

このように鍵を管理する場合、ある決まった一つの管理ルールに統一することは難しいです。ただし注意すべきポイントというものは存在します。

今回はソフトウェアの暗号鍵の運用・管理をテーマとして、落とし穴になりやすいポイントを紹介していきます。ここで説明する内容はソフトウェアの暗号鍵を想定していますが、ハードウェアの鍵に当てはまるものもありますので、日常で使えるノウハウに置き換えることができるかもしれません。参考にしてみてください。

暗号鍵の管理はなぜ必要？

暗号鍵を利用すると主に次の２つのことが実現できます。

• 情報資産を第三者に読み取られないようにする【暗号化】
• 情報資産が改ざんされていないかどうかを確認する【改ざん防止】

暗号鍵を持っている人は、暗号鍵を使って保護している情報資産を扱うことが許可されている人です。暗号鍵を第三者が入手した場合、その第三者も情報資産を扱うことが可能になります。言い換えると、暗号鍵と情報資産は同等の価値があるといえます。情報資産の価値が高いほど、暗号鍵の管理も厳重にする必要があります。

暗号化

まず一つ目の情報資産を第三者に読み取られないように暗号鍵を使うケース、暗号化について説明します。

太郎さんから花子さんに秘密の情報を送りたい場合、まず太郎さんはその秘密の情報を第三者が読み取れないように暗号化します。その時に暗号鍵を使います。次に作成した暗号化データを花子さんに送信します。

花子さんは次の2つの情報を使ってその暗号化データを復号し、秘密の情報を復元して読むことができます。

• 暗号鍵
• 暗号化された秘密の情報

では第三者がその暗号鍵を入手してしまうとどうなるでしょうか？

花子さんが鍵を持っているので秘密の情報に復元できるのと同様、第三者である悪夫さんも鍵を持っているので太郎さんから送られてくる秘密の情報を復元することができます。もし悪夫さんが太郎さんと花子さんに気づかれずに鍵を入手できたのであれば、悪夫さんが秘密の情報を読んでいることを太郎さんと花子さんは気づくことができません。

暗号鍵を入手した第三者はこの暗号鍵が変わらない限り、ずっと秘密の情報を入手し続けることができます。

改ざん防止

次に、機密情報が改ざんされていないかどうかを確認するために鍵を使うケース、改ざん防止について説明します。

太郎さんから送られてきた情報が本物かどうかを花子さんが知りたい場合を考えます。送られてきた情報の送信元に太郎さんと書かれていたとしても、その送信元の内容は成りすましで、送られてきた情報は偽物かもしれません。そこで、太郎さんが作成した情報であると証明するために暗号鍵を使います。太郎さんはまず自分で作った情報に暗号鍵を使って確認用データ (以降、"署名"と表記) を作ります。次に作成した署名を付与した状態で花子さんに送信します。

花子さんは次の3つの情報を使って、太郎さんが送った本物であることを確認することができます。

• 送られてきた情報
• 署名
• 暗号鍵

第三者が太郎さんが作ったと見せかけた偽物を作ろうとしても、暗号鍵を持っていないので太郎さんの暗号鍵と同じ署名を作ることができません。確認用データである署名は対象の情報が少しでも変わると全く異なる値に変化します。もし第三者である悪夫さんが太郎さんの送信した情報の一部を改ざんした偽情報を作成した場合、太郎さんが作った署名とは一致しない対象データを送ることになるので、花子さんは鍵を使って偽物だと見分けることができます。

もし第三者が暗号鍵を入手してしまうとどうなるでしょうか？

第三者である悪夫さんが太郎さん作成の偽物情報を作ろうとしたときに、太郎さんの暗号鍵を入手できているので太郎さんが作成した場合と同じ署名を作ることができます。この情報を受け取った花子さんは、太郎さんの暗号鍵で確認するとPASSするため、この第三者が作った偽物情報を太郎さんが作成した本物だと判断してしまいます。

このように暗号鍵が第三者に渡ってしまうと、暗号化と改ざん防止のどちらのケースにおいても機密情報を保護することができなくなってしまいます。

暗号鍵のライフサイクル

暗号鍵の管理について説明するため、暗号鍵のライフサイクルを以下の５つに分類します。

1. 生成
2. 輸送・導入
3. 保管・バックアップ・復旧
4. 利用
5. 廃棄

暗号鍵をセキュアに管理するには、ライフサイクルの各ステージに応じたセキュリティ対策を行うことが重要になります。では各ステージについてそれぞれ説明していきます。

1.暗号鍵の生成

暗号鍵を生成するときに最も重要なことは「鍵を推測できない」ことです。これは仕様を決めた開発者や鍵を生成した担当者も含みます。開発関係者や運用関係者が絶対に鍵に関する情報を漏洩しないとはいいきれません。世界中のすべての人が鍵を推測できない仕組みを考えることが基本となります。

鍵を推測されないために注意すべきポイントを３点挙げます。

1. 暗号鍵の生成には乱数を用いること
2. 鍵を生成する人が直接鍵データを読めないようにすること
3. 暗号鍵を管理する責任者を明確にすること

暗号鍵の生成には乱数を用いること

1つ目のポイントは「暗号鍵の生成には乱数を用いること」です。意味のある値（製品名をアスキー文字にしたもの、製造日時、シリアル番号など）を使うと推測されやすいため、暗号鍵は乱数を用いて生成します。

さらに、その乱数の作り方についても注意点があります。乱数を生成するときにはシード値と呼ばれる入力値を使った乱数生成と入力値を使わない乱数生成の２通りがあるのですが、前者のシード値を使う乱数生成では注意が必要です。

シード値を使った乱数生成の場合は、同じシード値を入力したときに、乱数生成の出力は同じ結果が得られる場合があります。つまり再現性があります。例えば、鍵生成したときの現在時刻の情報をシード値とした乱数を生成して鍵を作っていた場合、本来は計算できないほど巨大な鍵パターンがある仕様（例えば、128bit長の鍵なら2の128乗≒3.4x10の38乗）が、もし鍵の生成日付が分かれば24時x60分x60秒=86400の鍵パターンに絞り込むことができます。絞り込んだパターンを総当たりで確認していけば、一つの鍵を推測することができるでしょう。

シード値にハッシュ値を使う場合も注意が必要です。全く仕様を知らない人から見れば、ハッシュ値は一見乱数のように見えるので、セキュリティ上問題ないように考えてしまうかもしれません。しかしこの仕様を知っている人であれば、ハッシュ関数で変換する前の入力情報を入手できれば鍵のパターンを絞り込むことができます。

ではどのように乱数を生成すればよいのでしょうか？

最もよい例としてはシード値を入力しない真性乱数生成器で生成した乱数で鍵を生成することです。真性乱数生成器は入力がありませんので、乱数を推測することができません。

ハードウェアが真性乱数生成器をサポートしていない環境で機能動作させる場合は、疑似乱数生成器を使うことになります。疑似乱数生成器はシード値を入力しますが、シード値には意味のあるデータではなく外部から乱数を取得して使用します。

疑似乱数生成器を使用する場合はもう一つ注意点があります。暗号技術での利用に適した特性を持つ暗号論的擬似乱数生成器であるかどうかを確認するようにしましょう。

例えばJavaコードであればjava.util.Random クラスではなく、java.security.SecureRandom クラス等を使用します。セキュアでない乱数生成器を使った場合、アプリケーションの初期化やシステムの再起動の度にデフォルトのシード値を再利用しており、その特性を使って乱数の値を再現できる場合があります。

鍵を生成する人が直接鍵データを読めないようにすること

2つ目のポイントは「鍵を生成する人が直接鍵データを読めないようにすること」です。

例えば以下の図のように鍵作成ツールを使って鍵生成者が鍵を作って鍵利用者に鍵を渡し、鍵利用者が暗号ツールに鍵を入力する場合を考えます。この場合は鍵作成者も鍵利用者も鍵の情報を見ることができます。鍵を渡すときに漏洩する可能性もあります。

機密情報にアクセスできる人は最小限にすることがセキュリティの原則の一つですので、鍵を読める人は極力減らす工夫が必要になります。

この対策の一つとして、暗号鍵をツールからエクスポートせずにツール内で保管する手段があります。

鍵生成する人は暗号鍵を識別するための鍵IDを設定してツール内部で暗号鍵を作成して保管します。鍵を利用する時は鍵IDを指定して暗号処理します。鍵生成する人も鍵利用する人も鍵IDは知っていますが、暗号鍵の中身を知る必要はありません。鍵情報はツール内部だけで保管するためセキュリティ管理効率もよくなります。

この手段例として、HSM(Hardware Security Module)と呼ばれるセキュリティの機器があります。HSMでは保管する鍵情報は鍵利用者や鍵作成者が読み出すことを制限し、暗号処理をモジュール内で実行できる仕様になっています。

暗号鍵を管理する責任者を明確にすること

3つ目のポイントは、「秘密鍵を管理する責任者を明確にすること」です。

鍵の管理責任者は鍵の作成者なのか、鍵の利用者なのか、クラウドやスタンドアロンPCなどで鍵を保管している人なのかは鍵の運用方法や管理方針によって異なります。管理責任者があいまいだと、鍵漏洩などのインシデントが発生した時の判断が遅れたり、運用中に判明したセキュリティ上の問題点の改善が機能しなくなってしまいます。責任者を一人明確に決めて、その人が主導して暗号鍵をセキュアに管理し続けることが大切です。

鍵管理責任者は、鍵を扱う現場の担当者ではなく、鍵漏洩するなどインシデント発生時に責任を取る立場の人を私はお勧めしています。インシデント発生時の被害を把握できていない人が鍵管理責任者の場合、セキュリティ意識がどうしても弱くなってしまう傾向があります。

2.暗号鍵の輸送・導入

暗号鍵は鍵利用者の環境によって、鍵の輸送が必要になる場合があります。

自分が相手先に秘密の情報を渡すときはどんな手段を使いますか？　電子メール、手紙、ファイル共有サービス、クラウド上のファイルサーバ、USBメモリなどのストレージデバイスを手渡し、など様々な方法があります。「情報を暗号化して送っておけばセキュアだからどんな方法でも問題ないんですよね？」と考える方もいるかもしれません。しかし、暗号化は絶対ではありません。将来、暗号処理性能が上がることによって暗号を解読される可能性があります。

では暗号鍵など機密情報を送付する場合は、どんな手段を使えばよいでしょうか？

暗号鍵の輸送に関するセキュリティ観点の主な要件は以下の２つです。

• 第三者に鍵情報を入手されないこと
• 第三者に鍵情報を入手されてしまった可能性があることが検出できること

メールを使った輸送

例としてメールを使った場合を考えてみましょう。

電子メールの場合のデータの流れを見ていきます。

1. 送信者のPCが送信メールとして鍵情報を含むメールを保存します。
2. 送信者が利用しているメールサーバーが鍵情報を含むメールを保存します。
3. インターネット上のいくつかのサーバーは鍵情報を含むメールを送信します。
4. 受信者が利用しているメールサーバーが鍵情報を含むメールを保存します。
5. 受信者のPCが受信メールとして鍵情報を含むメールを保存します。

この通信経路途中にバックアップ機能がある場合、そこにも鍵情報を含むメールが保存されますし、通信ログを取得しているサーバーがあれば、そこにも鍵情報は残ります。

このように盗まれてはいけないデータであるにもかかわらず、想定していないあらゆるところに鍵情報データが保存されてしまいます。

鍵情報自体を暗号化しておけば直ぐは解読できないかもしれませんが、将来暗号解読できる手段が見つかれば、その保管しているデータを取り出して復号できることになり、暗号鍵の漏洩リスクがありつづけることになります。

さらに要件の2つ目「第三者に鍵情報を入手されてしまった可能性があることが検出できること」も満たすことができません。暗号化された暗号鍵情報はメールなので誰が入手しているかを把握できません。もちろん鍵が推測されてしまったかどうかも把握できません。

暗号鍵の輸送の手段に電子メールを使用することは、この２つの要件を満たすことができないのでセキュリティ上避けるべきです。

手渡しの輸送

次に直接手渡しする場合を考えてみます。ストレージデバイス(USBメモリ、SDカードなど)に暗号鍵データを格納して手渡しするのはどうでしょうか？

この場合は、相手に直接手渡しするので、途中で第三者に情報を盗みだされる心配はありません。

もし手渡しする前後で、移動している最中に紛失したり、泥棒に盗まれた場合ですが、輸送している本人自身が暗号鍵を盗まれてしまったことに気づくことができるはずです。渡そうとしていた鍵はもう使わずに廃棄して、別の鍵を再作成して手渡しをやり直せばよいのです。

移動中に本人に気づかれないように少しの間だけストレージデバイスを盗んで、複製してから元に戻した場合は攻撃が成立してしまうので、データ輸送する人がストレージデバイスを手放さないように気を付ける必要があります。

手渡しの場合は、もう１つ注意点があります。渡す相手を間違えないことです。特に相手が会ったことのない人の場合は、名乗った名前だけで相手本人だと判断するのは危険です。

では手渡しに対する攻撃例を説明します。

1. 鍵情報を手渡しする場所と時間の情報を、第三者が入手
2. 第三者が代理と名乗って、鍵の入ったストレージデバイスを手渡しで入手
3. 第三者所有のストレージデバイスに鍵を複製
4. 第三者が本当に渡す相手にストレージデバイスを手渡しする

この手順の場合、第三者は複製した暗号鍵の情報が手元にあるので、その暗号鍵を悪用できます。手渡しに使ったストレージデバイスは受け渡しが成立していて、中身も改ざんされているわけではないので、第三者に複製を作られている＝データを盗まれていることに気づくことができません。

このような攻撃手法を中間者攻撃といいます。機密データを渡す際にはこの中間者攻撃が成立しないかどうかという観点が、輸送手段を検討するうえで重要なポイントになります。

メールと手渡しの二通りの事例を紹介しましたが、ほかにもファイル共有サーバーやファイル配送サービスを使って、アクセス回数制限やアカウント管理で制限して鍵を配送する方法、VPNネットワークで固定のサーバーでファイル共有するなど、多くの手段があります。利用環境や相手先によって選択する手段は変わります。

セキュリティ有識者でない場合、「暗号鍵輸送は最初の一回きりだから多分大丈夫」というような都合の良い判断をする傾向があるので、鍵の輸送は特に注意が必要です。

活用可能なサービスや手段の中からセキュリティ観点で問題ない方法を選ぶようにしましょう。

3.暗号鍵の保管・バックアップ・復旧

暗号鍵を紛失してしまうと、暗号化したデータは復号できませんし、改ざん検知も正しいかどうか判断できなくなります。そこで暗号鍵をバックアップ保管することになるのですが、バックアップ情報も攻撃者は狙っていますのでセキュアに管理運用する必要があります。また暗号鍵の利用ケースによりますが、システム復旧までの時間がビジネスの損益に大きく影響する場合もあります。暗号鍵を円滑に復旧すること(利便性)と漏洩を防ぐこと(セキュリティ性)のトレードオフ判断が必要になります。

暗号鍵のバックアップのポイントは「通常データと暗号鍵のバックアップデータを分けて管理する」ことです。

セキュリティのことを考えなければ、バックアップは暗号鍵も通常データもまとめて同じ場所で管理したほうが復旧時の作業効率はよくなります。しかしバックアップ情報から暗号鍵情報を取り出されるリスクがあります。逆にセキュリティのことを重視するなら、ネットワークから切り離して暗号鍵は完全に別管理することがおすすめですが、この場合は復旧時に手間がかかります。

どのようにアクセス制限をかけてバックアップデータの管理を分けるかは製品やサービスの特性を考慮して、最適な手段を選択するようにしましょう。

4.暗号鍵の利用

暗号鍵の利用は、その鍵に対してのアクセス制限をどのように設定するかがポイントになります。

• 暗号鍵を利用する人だけがアクセスできる仕組みにする
• 暗号鍵の利用履歴を辿れるようにする

暗号鍵をアクセス制限をかけずに利用すると、誰でも持ち出すことが可能なので、鍵漏洩リスクが高まります。どれだけセキュリティ教育を徹底したとしても、持ち出しリスクは残存することになります。

そこで暗号鍵を利用する際にはアクセス制限をかけることが一般的です。アクセス権を与える手段は様々です。生体認証、暗証番号・パスワード、認証データの発行、アカウントを使った権限許可などが例として挙げられます。認証の仕組みを利用システム上で構築できるか？という観点が必要になります。

もう一つの重要な要件は、暗号鍵の利用履歴を辿れることです。

運用時に不正を働いて鍵や機密情報を盗み出す内部犯の可能性をセキュリティでは考慮しておかないといけません。正確な利用履歴を記録することは、監視されているという意識付けになり不正防止にもつながります。防犯カメラや入退室履歴、アカウントログイン履歴、暗号鍵利用履歴など複数の手段で履歴を保存するようにしましょう。

暗号鍵の利用では、利用環境によってそれぞれ運用する手段とルールの判断が大きく変わってきます。特に影響のある条件は以下の項目になります。

• 鍵を利用する人を特定できるか
• 鍵を利用する場所が離れていないか
• 鍵の利用頻度

鍵を利用する人を特定できるか

「鍵を利用する人を特定できるか」で鍵の運用手段は変わります。

鍵を利用する人が多く入れ替わりの激しい現場だったり、管理運用会社が変わる可能性のある場合だと、鍵へのアクセス権限を変更する必要性が出てきます。担当が変わって権限がなくなった人に対して鍵を利用できなくなる仕組みを考える必要があります。例えば、セキュリティルームの入退室管理ルールによる制限、サーバーのアカウント管理でアクセス権限設定ルールを更新変更する、などの手段が考えられます。

利用者の変更頻度が多い場合は教育が十分浸透しない可能性があるので、運用ルールで制限するのではなく、権限のない人はそもそも利用できないシステムを構築するような運用方針にすべきです。利用者のモラルや良心に頼った運用ではなく、プロセスとして守る必要があります。

逆にセキュリティ教育が行き届くような環境、例えば特定の社員メンバーだけが使用する鍵など、利用人数が非常に限られていて権限の変更もほとんどない状況であれば、管理面も教育面も利用者に意識付けしやすいため、認証を使った厳重なシステム管理をするのではなく、運用ルールで制限するなどの手段も選択肢の一つとなります。

ただしどの手段の場合でも正確な利用履歴を記録する仕組みは必要になります。

鍵を利用する場所が離れているか

次に鍵を利用する場所が離れているかどうかです。

離れた場所の人たちがそれぞれ同じ鍵を利用する場合だとクラウドなどオンラインサーバー上での管理が主な手段になります。それぞれの拠点で鍵を複製して管理するという手段もありますが、その拠点ごとに暗号鍵をセキュアに管理することが必要になること、暗号鍵が漏洩したときにどの拠点から流出したのかの原因究明が難しくなる、責任があいまいになるなどのデメリットもあるので、鍵の複製利用は注意が必要です。

逆に一つの拠点内だけでしか暗号鍵を使用しないケースであれば、インターネット上からアクセスできないような拠点内LANやスタンドアロンPCを使った環境での運用を考えたほうがよいでしょう。リモートアクセスによる漏洩リスクを減らすことができます。

鍵の利用頻度

最後に鍵の利用頻度です。

利用頻度が高い場合はサーバーを使った自動化を検討しましょう。スタンドアロンPCで利用頻度の高い鍵を管理すると、作業効率を上げるために鍵の利便性を重視してアクセス制限を緩和したり、鍵を複製したりなど、作業者の独自判断でセキュリティ運用ルールを守らなくなることが考えられます。あらかじめ作業効率を考慮したサーバーやアプリなどを使った自動化を検討することで、鍵の利用頻度が高くなってもセキュリティ管理の品質を維持しやすくなります。

逆に利用頻度の低い鍵であれば、利用者が手作業で実行する処理があっても大きな影響はないでしょう。

5.暗号鍵の廃棄

暗号鍵を廃棄するのは主に以下の2つのケースです。

• 暗号鍵を利用した機能を使うサービスが終了・停止した場合
• 暗号鍵が危殆化した場合

危殆化とは、暗号鍵の情報が第三者に漏洩、またはその恐れがある場合などセキュリティレベルが低下した状態のことをいいます。

前者の暗号鍵を利用した機能を使うサービスが終了した場合は、鍵を渡した相手やバックアップも含めて、永久に利用できない状態にすることがポイントです。

後者の場合は、今後鍵を使ってはいけないことを鍵の利用者に通知(＝失効通知)が必要です。危殆化していることを通知しないと、その鍵の利用者は、鍵を使って悪用された情報を信じてしまいます。失効通知後に暗号鍵の再発行などの復旧対策を行います。

暗号鍵の漏洩に備えて

脆弱性情報の収集

設計開発段階でセキュリティ対策を実施し、脆弱性が無い状態でシステムをリリースできたとしても、将来的には新たな脆弱性が発見される可能性があります。ここでは脆弱性の一般的なWeb情報からの情報収集の方法について紹介します。

国内外問わず脆弱性情報データベースがあり、日々更新情報を公開しています(例. JVN※など）。この脆弱性データベース情報を見れば、具体的にどこの会社のどの製品でどのような弱点があるのかがわかります。

システム管理者や製品利用者は、この脆弱性情報をみて迅速に自社システムに脆弱性がないかどうかをチェックし対策を実施します。しかし脆弱性情報は守る側だけではなく攻撃者も見ることができるため、攻撃手法を再現実行することができます。脆弱性を放置したままの製品やシステムを攻撃者がターゲットにすれば攻撃が成功します。

暗号鍵を管理しているソフトウェアの脆弱性によって、暗号鍵が漏洩するケースもありますので、脆弱性情報の収集は怠らないようにしましょう。

※JVN は、"Japan Vulnerability Notes" の略です。日本で使用されているソフトウェアなどの脆弱性関連情報とその対策情報を提供し、情報セキュリティ対策に資することを目的とする脆弱性対策情報ポータルサイトです。脆弱性関連情報の受付と安全な流通を目的とした「情報セキュリティ早期警戒パートナーシップ」に基いて、2004年7月よりJPCERT コーディネーションセンターと独立行政法人情報処理推進機構 (IPA)が共同で運営しています。

脆弱性を発見する手段や体制

運用中の製品の脆弱性に対する組織体制を整えていないと、脆弱性を発見しても迅速かつ適切な対応をとることはできません。情報システムはCSIRT（Computer Security Incident Response Team）が自組織の保護や脆弱性の対応を行いますが、自社で開発する製品のセキュリティや脆弱性対応はPSIRT（Product Security Incident Response Team）が行います。PSIRTはCSIRTと同じく情報収集・脆弱性検知・対策を担当しますが、PSIRTでは例えば次のような内容を運用管理します。

• OSS
  CSIRTが管理するPCやサーバと異なり、PSIRTが管理する製品はOSSが利用されていることが多いです。OSSはソースコードが公開されており、利用条件さえ守れば誰でも無償で利用可能です。しかしOSSに脆弱性が発見されると大きな問題になります。 脆弱性を含むバージョンのOSSを製品内で使用していた場合は、アップデートなどの対応が必要になります。リリース済みのすべての製品の対象として、製品内で使用しているOSSのバージョンを脆弱性が判明するたびに逐次チェックすることを手作業で行うのは効率が悪いです。ツールなどを使ってOSSの脆弱性を管理／監視することが有効な運用手段の一つになります。

• 製品出荷後のサポート
  CSIRTはインフラや機器類が自社の管理下にあるため、脆弱性が明らかになった場合には、サービスを停止する必要はありますが、セキュリティパッチで更新するといった対策を行うことができます。 しかし、PSIRTが管理する製品は、ユーザー管理で使用していることが多いです。ユーザー管理下の製品では、セキュリティパッチ更新対策を任意のタイミングで行うことができない場合があります。 さらに出荷製品で使用しているソフトウェアバージョンに違いがある場合、脆弱性の有無もソフトウェアバージョンによって変わってきます。そのため、製品出荷後に脆弱性が判明した際に備えた組織体制や機能が必要になります。 具体的にはログの取得、分析によって攻撃の兆候を捉えることや、新たに判明した脆弱性への対応可否を判断できる体制を用意すること、製品出荷後の暗号鍵更新手段を必要に応じて準備しておくことなどが挙げられます。

おわりに

今回は暗号鍵の運用の落とし穴になりやすいポイントについて、例を挙げていくつかご紹介しました。いかがだったでしょうか？　

セキュリティ運用の注意点は利用環境によって変わります。実経験が少ないとその利用環境に応じた妥当なコストパフォーマンスのよい対策になかなか気づけないものです。過剰なコストをかけた対策になってしまったり、対策が不十分な状態で運用し続けることになります。特に初めて暗号鍵を生成・利用・管理する場合は、経験のある有識者に相談することをお勧めします。

暗号鍵自体は人が見るとただの電子データです。暗号鍵を機密情報として扱うことが直感でイメージできない人もいるかもしれません。暗号鍵の価値はその鍵を使って保護している情報資産の価値と同じだと意識してください。情報資産が奪われた時のワーストケースをイメージしつづけることができれば、きっと暗号鍵をセキュアに管理できるでしょう。

暗号鍵を第三者に悪用されないための手助けとなれば幸いです。