CodeZine(コードジン)

特集ページ一覧

初めての省庁系システム開発(技術編第3回)~セキュリティは政府機関の統一基準に従え~

堅牢なシステムを構築・運用するために

  • LINEで送る
  • このエントリーをはてなブックマークに追加
2009/08/17 14:00

目次

技術面でのセキュリティ

 前ページで説明した「統一基準」を念頭に置きつつ、今回は技術編ということで、省庁系システム開発で使用されているセキュリティ技術であるハッシュ関数暗号アルゴリズムを中心に説明したいと思います。また「暗号の2010年問題」に対して、どのような対応を行おうとしているのかについても触れていきます。

 「暗号の2010年問題」について、詳しくは『もう避けられない? 暗号の2010年問題』(@IT)などを参照してください。

ハッシュ関数と暗号アルゴリズム

ハッシュ関数とは

 ハッシュ関数とは、電子署名に用いられる技術で、改ざん防止のために使用されます。本人確認のためには、ハッシュ関数で求められたハッシュ値を暗号化する必要があります。電子化された文書全体を暗号化できればいいのですが、暗号化は大量のコンピュータリソースを消費するため、WebシステムのようにSLAで3秒以内の応答を約束していたり、リアルタイムシステムを採用している場合は、現実的ではありません。

 乱暴な言い方になりますが、ハッシュ関数は電子化された文書を小さなサイズの値に変換するための暗号化よりも速い関数だと考えてください。もちろん、小さくしただけでは、ハッシュ関数とは言えません。Aという文書とBという文書のハッシュ値が同じではだめです。別文書のハッシュ値が同じになることを「衝突」と呼びます。ただし、衝突は非常に低い確率で発生します。いかに低い確率にできるかがポイントとなります。また、同じ文書でも内容を1文字でも変更した場合は、ハッシュ値も違うものにしなければ改ざん防止にはなりません。ハッシュ値から元の文書を復元できてしまってもだめです。

 このハッシュ値を暗号化したものが電子署名と呼ばれています。送信元では秘密鍵で暗号化し、受信先で公開鍵で復号化することで、電子化された文書が本人からのものであること、途中で改ざんされていないことが証明されます。つまり完全性が保証されます

暗号アルゴリズムとは

 暗号アルゴリズムとは、文字どおり世間で言われている暗号を作り出すためのアルゴリズムを指します。情報理論の基礎で学ぶことですが、アルゴリズムの1つの要件は有限時間内に終わるということです。アニメに出てくるように、ある記号や文字列から特定の人しか連想できないような方法で解けるものは暗号とは呼べません。数学的に証明された方法で、暗号化したものを必ず元に戻せるものを暗号と呼びます。数学的な証明を仕様とするなら、それを実装したものが暗号製品と言えます。

 暗号化や復号化するためには鍵が必要となります。本人のみ所有するものを秘密鍵、関係する人に配布する鍵を公開鍵と呼びます。このようなアルゴリズムを公開鍵暗号と呼びます。他に鍵を関係者で共有するアルゴリズムに共通鍵暗号と呼ばれるものがありますが、政府系機関では特に指定されていないので省略します。ハッシュ関数の完全性に対し、暗号化は機密性を保証します

ハッシュ関数と暗号アルゴリズム
ハッシュ関数と暗号アルゴリズム

 公開鍵暗号、共通鍵暗号、ハッシュ関数について知りたい方は当記事の最後に書店で入手できる文献を紹介しているので参考にしていただければと思います。

電子政府で使用するハッシュ関数と暗号アルゴリズム

ハッシュ関数や暗号アルゴリズムは何を採用すべきか

 ハッシュ関数や暗号アルゴリズムで採用すべきものは「政府機関の情報システムおいて使用されている暗号アルゴリズム SHA-1 及びRSA1024 に係る移行方針」(PDF)に基準が記載されています。基本的に、ハッシュ関数はSHA-256以上、暗号アルゴリズムはRSA2048以上の強度を持つものが必要となります。当文書が公表される前は、採用基準が不明確でしたが、「暗号の2010年問題」によって上記以外のアルゴリズムの強度ではセキュリティが破られる可能性が指摘されたため、当文書でその対策が公表されました。

 今後フルスクラッチで開発するシステムに関しては上記の関数やアルゴリズムを採用すればいいわけですが、既存システムの改修や暗号アルゴリズムを移行する場合には綿密な計画が必要となります。ストレージに暗号化して保管している情報をいつどのように変換するのか、複数のバージョンをどのように運用し、最終的に統一基準の関数やアルゴリズムにするのかなど、省庁との調整が必要となります。

 新しい暗号アルゴリズムへの移行のスケジュールについては、まだ案ではありますが、内閣官房情報セキュリティセンターが「政府機関に安全な暗号利用の促進」(PDF)を公表していますので、複数のバージョンの暗号アルゴリズムを運用する可能性がある場合、ご参考になるかと思います。

公的個人認証サービスの暗号方式

 執筆時点(2009年7月)では、公的個人認証サービスのカードに使用されている暗号方式には基準がなく、前ページで説明した統一基準と矛盾する結果となっています。

 この問題を解決すべく、2009年1月に公表された「公的個人認証サービスにおける暗号方式等の移行に関する検討会報告書」(PDF)という報告書で、暗号方式については検討中であることを知ることができます。暗号方式についてはSHA256とRSA2048以上を採用する方向で動いているようです。ただし、現在統一が取れていない公的個人認証サービスの暗号方式をどのように扱うべきかは、非常に大きな問題となります。調達仕様書に暗号方式に関する記述がない場合はプロジェクトが火だるまになるのを防ぐため、できる限り詳細な質問を行い、開発規模を正確に見積もるといった慎重な対応が肝要となります。

認証・認可はどうするのか

 認証とは「そのシステムに入る資格を持っているのか」、認可とは「システム内の特定の機能やリソースにアクセスできるのか」を検証する仕組みのことです。認証・認可についてどのような方法で実現すべきか調達仕様書に明示されていればよいのですが、明示されていない場合は質問しなければなりません。

  • 新たに認証・認可機能を作るのか
  • 新たに認証・認可機能を作るとした場合、既存のディレクトリ・サービスを利用するのか
  • 統合アカウント管理の中に組み込まれるのか
  • SSO(シングルサインオン)の認証・認可機能を利用するのか
  • SSOを使用している場合、SAMLなどの標準に従うのか、あるいはフォーム認証などの簡易な方式でよいのか

 上記以外にも、作るシステムに応じて多くの質問が必要となります。質問を怠ると、せっかく作り上げた認証・認可機能が使用できなくなるので要注意です。統合アカウント管理やSSOにどの技術を採用すべきかについては、技術編第1回で挙げたTRMにもまだ明記されていないため、細かい質問をしなくてはならなくなります。当然のことですが、現在と将来の認証・認可機能を体系立てて質問する必要があります。

参考文献

 ここでは、書店で入手できるセキュリティを理解するために役立つ書籍を紹介します。

  • 『新版 暗号技術入門 秘密の国のアリス』 結城 浩 著、ソフトバンククリエイティブ、2008年11月
    丁寧で分かりやすい解説で有名な著者の例にもれず、入門としては最適な本です。
  • 『Javaで作って学ぶ暗号技術 - RSA,AES,SHAの基礎からSSLまで』 神永 正博・山田 聖・渡邊 高志 著、森北出版、2008年5月
    知識だけでなくJavaで実装しながら学ぶというプログラミング好きにはうってつけの本です。最終章は「ミニチュアSSLをつくってみよう」となっており、非常に楽しい本です。
  • 『PKI公開鍵基盤―電子署名法時代のセキュリティ入門』 Tom Austin 原著、ニューコム 翻訳、日経BP企画、2001年7月
    技術者よりも管理者向けの本です。今やセキュリティは会社の信用を左右する存在であることから管理者といえどもこの本に書かれていることくらいは理解しておく必要があります。
  • 『暗号理論の基礎』 Douglas R. Stinson 原著、桜井 幸一・古屋 聡一・檀浦 詠介・山家 明男・赤星 信博・佐野 文彦・山根 義則 翻訳、共立出版、1996年10月
    暗号理論の基礎を数学を使って解説した本です。数学的素養がないと難しいですが、暗号理論そのものに興味のある方向きの本です。

 今回で、全9回に渡ってお送りした「省庁系システム開発」の連載は終了となります。シリーズを通し、筆者の体験から省庁系システム開発のいくつかのポイントをお伝えしました。省庁系システムの開発に関わる際は、参考にしていただければと思います。



  • LINEで送る
  • このエントリーをはてなブックマークに追加

修正履歴

  • 2009/08/25 23:59 「はじめに」の第6回へのリンクの飛び先に間違いがあったため修正

  • 2009/07/19 19:28 執筆完了しました

バックナンバー

連載:初めての省庁系システム開発

もっと読む

著者プロフィール

  • チャーリー・佐藤(チャーリー・サトウ)

    ここ10数年、プロジェクト・マネージャやソフトウェア・アーキテクトという一見相いれない仕事を繰り返してきました。プログラミングも大好きで、自宅ではいろんな言語を楽しんでいます。 年齢も40過ぎ、徹夜の連続では耐えられないようになってきました。

あなたにオススメ

All contents copyright © 2005-2021 Shoeisha Co., Ltd. All rights reserved. ver.1.5