【特集】つぎはぎシステムを防ぐセキュリティアーキテクチャ

佐藤慶浩
日本ヒューレット・パッカード株式会社
2004/4/29

セキュリティ要件の5つのA

　セキュリティの要件について体系立てる方法は、いろいろな切り口があるが、ここでは、以下の5つのAを紹介する。

●Authentication：真正確認（正当な本人であることを確認すること）

●Access Control：アクセス制御（あらかじめ許可を与えたアクセスだけに制御すること）

●Administration：権限管理（上記2つのAについて管理すること）

●Auditing：監査（上記3つのAの記録を証跡として保全すること）

●Assurance：保証（上記4つのAの要件を満たしていることの保証を得ること）

※注 この5つのAは、筆者の持論であるが、最初の3つのAは一般的な項目である。ただし、これらについては、以下本文の解説と全く同じ内容を、（1）Authentication、（2）Access Control、（3）Authorization,としたり、（1）Authentication、（2）Authorization、（3）Administrationとしたりする場合もある。Authorizationが、異なる2カ所に現れることが少し分かりにくいため、本稿では、Authorizationを使わずに解説することにする。

　5つのAについて、以下に解説する。

真正確認（Authentication）

　1番目の真正確認では、システムにアクセスする者が、名乗っている識別（identification）どおりの正当な本人であるかを確認する。

注： Authentication の日本語訳には、「認証」が多く使われている。しかし、認証とは、何らかの証を求める者と、証を示そうとする者がいるときに、第三者がその証の正当性を認めることで、両者の要求をかなえることである。認証は、第三者を前提とするが、Authentication は、必ずしも第三者を必要としない。実際に、その役割を担う Certification Authority の訳として、「認証局」が使われる。認証局との用語の混同を避けるため、本稿では、Authentication を「真正確認」と表すものとする。

　真正確認の実現可能技術としては、一般的には、知識確認（本人しか知り得ない情報を知っているかを確認する：パスワードなど）、所有確認（本人しか持ち得ない物の所有を確認する：磁気カードなど）、生体的特性確認（本人しか示し得ない生体的な特性を確認する：指紋、声紋、筆跡など）の3要素があるとされている。

　真正確認の強度は、それぞれの要素の厳密性を高めるか、あるいは、それらの要素を組み合わせることなどによって決定される。暗証とともに用いるICカードは、知識確認と所有確認の2つを組み合わせた、2要素確認方式に分類され、技術的な観点では、一般的に高い強度があると認識されている。

　正当な本人以外の者が、その識別（IDなど）を用いる問題を、なりすまし、あるいは、詐称という。これらの問題を防ぐための十分な措置が講じられなければならない。

　パスワードのリセット（再設定）やICカードの発行に際しては、その要求をしている者が、正当な本人かの確認方法をあらかじめ確立しておく必要がある。

　サーバについては、本人確認情報の取り扱いに配慮する必要がある。サーバ内にそれらの秘密情報を格納するとすれば、そのリスクは高い。サーバが攻撃を受け、その制御が奪取されることで、本人確認情報が盗まれる可能性があるからである。これを解決するには、PKI（Public Key Infrastructure：公開鍵暗号基盤）などを活用する必要がある。それにより、サーバに真正確認のための秘密を保持することなく、確認を行うことができるからである。PKIをシステムで真正確認のために使用する利点は、サーバ側に秘密情報を保持しないことである。

アクセス制御（Access Control）

　2番目のアクセス制御では、真正確認済みの者に対して、どのような情報へのアクセスが許可されているかを確認のうえで、アクセスを制御する。

　一般に不正アクセスと称される問題は、無許可アクセス（Unauthorized access）と、許可の乱用（Abuse of authorization）という質の異なる2つの問題を含んでいる。これらを、不正アクセスとして一緒に取り扱うと問題の整理ができなくなる。2つに区別することが必要である。無許可アクセスへの対策は、許可されていないアクセスをシステムが許してしまうことのないようにするもので、主として技術的な対策を施す必要がある。

　許可の乱用への対策は、許可を得た者が、その範囲外で許可を行使することのないようにするもので、技術的な対策は困難となる。なぜなら、業務上の必要があって、その許可を与えているのであるから、それを制限することは業務に支障が生ずることになる。そこで、許可の乱用への技術対策としてできることの1つに、最少特権機能がある。これは、許可の範囲を可能な限り限定するように、許可を細分化して精度を上げることである。例えば、ある情報にアクセスする必要があったとしても、それを深夜に行う必要がなければ、アクセスの時間帯を制限するなどということが、許可範囲の精度を上げることになる。あるいは、その傾向を把握して対処するために、変則アクセス（anomaly access）への制限や検出機能の導入も効果的である。例えば、ある人が通常は、1日100件程度のアクセスをしているのに対して、突如、1000件以上のアクセスをするようなことを「変則」と見なして制限や検出通知するというものである。

　システム設計の際に、これらのことが実現できるような仕組みを作りこんでおくことが必要となる。従って、許可の乱用に対しては、技術対策に加えて、主として制度的な対策を施す必要がある。例えば、罰則や監視の強化などが、制度的な対策の一例である。

　このほかに許可の誤用（misuse of authorization）が考えられるが、許可の乱用が悪意によるものであるのに対して、誤用は誤解や過失である点が異なるだけで、許可を受けた者が引き起こす問題という意味では同じである。許可の誤用への制度的な対策は、教育や訓練を加えることになる。

権限管理（Administration）

　3番目の権限管理では、1番目の真正確認における各人の識別情報（IDなど）と各人の本人確認情報（パスワードなど）の設定、および、2番目のアクセス制御における許可情報の設定を管理する。

　ここでは、真正確認情報の機密性（confidentiality）と、アクセス制御情報の完全性（integrity）を守るための技術が最低限必要であり、それに加えての対策も考えなければならない。

　例えば、これらの管理の任に当たる管理者にまったくの性善説を唱えるのでは、セキュリティ対策が十分とはいえない。性善説だけでは、これらの者からの不正アクセスを防ぐことはできないからである。保護すべき情報の重要度が高くない場合には、運用費用との兼ね合いで、ここでの性善説をリスクとして受け入れる場合もある。

　このリスクを回避することは困難であるが、軽減するために、アクセス制御で紹介した、最小特権機能方式を利用することができる。

　そのほかに、デュアルロック機能などが用いられる。デュアルロック機能とは、行為に対して、少なくとも2名の者が操作しなければ、その行為を完遂できないようにする方式のことである。デュアルロック機能を使っても、これら2名が共謀すれば不正なアクセスはできることになるので、技術的には防止できないが、だれかと共謀しなければ単独では不正をできないという抑止効果がある。

　新規ユーザー登録で、デュアルロック機能を用いる場合を図3に示す。この単純なモデルによって、本人も含めて単独では、不正なユーザー登録ができなくなることを検証するとよい。デュアルロック機能はセキュアOSで用いられているものであるが、アプリケーションで、この仕組みを採用するだけでもセキュリティが強化される^＊2。

＊2 セキュアOSの詳細については、http://yosihiro.com/go/secure-osを参照いただきたい。

図3 デュアルロック機能による新規ユーザー登録

　このことは、管理のために管理者用IDを設けることが好ましくないということを示唆している。例えば、UNIXでのrootユーザー、Windowsでのadministratorユーザーなどである。システムにアクセスするすべての者は、個人として特定されるべきである。UNIXにおいて、一般ユーザーでログインした後にsuコマンドで、特権ユーザーになることは、その次善策として考えることができる。管理者であっても例外ではない。その理由については、次の監査で説明する。

監査（Auditing）

　4番目の監査では、真正確認や、アクセス制御、権限管理の記録を証跡として保管する技術が求められる。ここでは、監査をどう行うかではなく、監査を可能とするための技術を考察するということである。

　徹底した監査の下で、真正確認とアクセス制御、権限管理の記録が、確実に保管されれば、それを監査証跡として用いることができる。

　監査証跡の保全は、万が一、事故が発生した際に、その原因やアクセス者を特定することに必要である。また、システムへのアクセス（いつ、誰が何をしたか）の記録が確実に保全されるということが分かっているシステムにおいては、不正アクセスに対する最大の抑止効果となる。

　システムのセキュリティ強度は、その監査証跡の保全性の強度であると考えることもできる。

　強度を上げるためには、セキュアOSの強制アクセス制御によって監査証跡ファイルを保護することが検討できる。強制アクセス制御を利用することができないシステムでは、ファイルに電子署名を行うことで改ざんを検知できるようにしたり、ファイルをリモートの別のシステムに送信してローカルでの改ざんを防いだりすることなどを検討できる。

　これもまた、防止のための対策ではなく、証拠を確実なものにすることで、「悪いことをすれば、後でばれる」ということによる心理的な抑止効果にもなる。

　監査証跡が確実なものになれば、後でばれては困る者が「そもそも悪いことをしなくなる」という構図を作り出すことができるのである。後でばれて困る者とは、概して、無許可の者ではなく、許可の乱用をする者となるであろうから、彼らへの抑止になるということも興味深い。つまり、技術的対策が困難であるところの許可の乱用への抑止が、監査証跡を守る技術によって確立するのである。これについては、コンピュータ・フォレンジクス（computer forensics：コンピュータ法科学、コンピュータ証拠論、コンピュータ犯罪調査論などと訳される）^＊3として関心が高まっている。

＊3 コンピュータ・フォレンジクスについては、＠police（http://www.cyberpolice.go.jp/）の第3回セキュリティ解説の「コンピュータ・フォレンジクス」も参考としていただきたい。

　監査を確実なものとするためにも、真正確認と権限管理が非常に重要である。それらが不十分であると、監査証跡の信頼性が低下する。それが低下すると、不正アクセスへの抑止効果が働かない。その監査証跡の完全性はアクセス制御によって守られる。という、互いに依存し合う密接な関係を4つのAが持っている。

　技術的に、セキュリティ被害の回避が不可能だとしても、それに対する十分な抑止効果があれば、結果的に被害の発生をかなり軽減できることになるのである。逆に、抑止効果がないシステムは、常に攻撃にさらされることになり、むしろ危険である。

保証（Assurance）

　5番目の保証では、真正確認・アクセス制御・権限管理・監査が、それらについて定めた基準どおりに機能していることを保証する。保証についてのほとんどは、制度・運用面のことであるが、システムに関する基準については、計測可能（measurable）にするための技術をシステムに組み込む場合もある。

　一般的には、保証の対象とするシステムが、構築されるより以前に、基準が定められており、その基準に沿って設計・開発・導入されなければ、それらを後から取って付けることで保証するのは極めて困難である。

　また、保証により、絶対的な安全性を検証することは困難と考えた方がよいであろう。セキュリティにおける保証とは、定めた基準のとおりになっているかを保証することであり、その基準に網羅性があり十分条件になっていることを保証するものではない。

　この点は、絶対的な安全を求める要望を満たすものではないが、絶対的な安全が保証されるということがあり得るのかを考えれば、自明であろう。絶対的な保証を得るのではなく、セキュリティ対策の実施状況を計測することで、継続的な改善に役立てられると位置付けることが保証をうまく使う方法である。

　冒頭でセキュリティの定量化が困難であると述べたが、その評価に、ISO/IEC 15408（JIS X 5070）が使える可能性があるものの、ITアーキテクトの観点ではあまり現実的ではない。

　ISO/IEC 15408では、要件仕様として、PP（Protection Profile）という記述様式を持っているが、一般の発注者がこの様式に沿った記述ができるようになるには、まだ時間がかかると思う。しかしながら、認定取得を行わずとも、ISO/IEC 15408のPPやST（Security Target）の様式を使うことはセキュリティ要件の定量化には役立つはずなので、ITアーキテクトを行う者としては、その内容を理解しておくことは有益である。

　以上の5つのAを意識しながら設計すると、体系立てたセキュリティの要件整理ができることになるだろう。

アイデンティティ・マネジメント 　（Identity Management）

　5つのAの説明から、1番目のAである真正確認が、すべての基礎であり、重要であることを紹介した。真正確認が不確かであると、それ以降のAはすべて不確かなものになってしまうからである。そのこともあって、ここ最近、この問題は、アイデンティティ・マネジメントとしてあらためて取り扱われている。

　従来との違いは、個人としての本人を特定することに重点を置いていることである。いい換えれば、従来の情報システムが関知しているのは、そのアクセスに使われるIDまでである。従って、ある情報にアクセスしたログなどから分かるのは、例えば、佐藤さんに発行したIDによってアクセスされたということであり、そのため、「佐藤さん」である可能性が高いということである。その意味では、厳密には、それがだれなのかを特定できていなかった。これを完全に解決するのは困難であるが、例えば、同じユーザーIDからのログインが、東京と大阪で同時刻に起こっていれば、そのうちの1つかそれ以上は、本人ではないことは明白である。そのようなことを順番に解決することで、より本人を特定しようというのが、アイデンティティ・マネジメントである。

　いうなれば、従来のものは、単にIDマネジメント（Identification Management）であったといえよう（図4）。

図4 従来との違いは、個人としての本人を特定することに重点を置いている

　アイデンティティ・マネジメントの確立には、従来とは異なる設計の考え方も必要である。例えば、先の例では、本人が東京でログインしているときに、別の何者かが大阪からのログインを試みた場合に、双方にその事実を警告する仕組みなどが必要である。もし、大阪からのログインを拒否するだけならば、大阪の何者かに、別の誰かがログインしていたことだけを知られてしまうことになる。定められた真正確認に合致するのであれば、大阪からのログインを認め、その事実を東京と大阪の双方に警告する。なぜ、大阪にも警告するのか？ それは、その時点でどちらが正当な本人かをシステムは判別できないからである。双方に警告することにより、正当な本人は、自分の真正確認が不当に使われていることを知り、不当な何者かは、それが本人に見つかったことを知ることになり、何らかの措置を講じることができるようになる。アイデンティティ・マネジメントの観点で重要なのは、真正確認が脅かされないことに加えて、万が一、それが不確かになった場合には、そのことを本人が知る機会を得ることができるようにすることなのである。

　これらのことから分かることは、アイデンティティ・マネジメントでは、技術的な仕組みづくりに加えて、システムの利用者本人がより厳重に、真正確認のための情報や装置を適切に管理する必要があることである。

プロビジョニング（Provisioning）

　仮に、強力な真正確認ができたなら、次に重要なことは、そもそもの真正確認の設定などの権限管理をどのように安全なものにするかである。この課題は、プロビジョニングと呼ばれ、重要視されている。英単語としてのプロビジョニングの意味は、旅立つ者に対して、旅に必要な資材を必要の都度ごとに与え続けることである。このことから、情報システムにアクセスする者に対して、それに必要な識別情報（ユーザーID）やアクセス許可などを付与することを、プロビジョニングと呼んでいる。プロビジョニングが適正に実施されなければ、その後の真正確認がいくら技術的に強力でもアイデンティティ・マネジメントは確立しないことになる。

　このことは、「管理者に悪意があったら仕方ない」では、済まされない場合が多くなっていることを意味している。プロビジョニングでは、管理者を最小限にして、不必要な人の介在をなるべくなくすことなどで、人為的なセキュリティの事故を防ぐようにすることも重要である。このことは、運用コストの低減にもなることがある。ただし、最後の末端には必ず人が存在するので、その部分についてはデュアルロックなどで対応するしかない。

　このように、アイデンティティ・マネジメントとアクセス制御、プロビジョニングは密接な関係にあり、これらをうまく連携して機能させることでセキュリティ対策を頑強なものにできる。そのため、最近では、これらを統合して、アイデンティティ・アクセス・マネジメント（IAM：Identity & Access Management）としてアーキテクトするようになってきている。

◇

　5つのAについて、主として情報へのアクセスを中心に紹介した。セキュリティ要件を体系的にとらえる方法は、ここで紹介したようなセキュリティとしての階層化構造だけではない。例えば、情報はアプリケーションによって処理され、アプリケーションはサーバマシン上で実行され、サーバマシンはネットワークでクライアントPCと接続され、クライアントPCを通じて人にアクセスされる。というような、情報を取り巻く空間的な体系を考えることもできるため、それらアプリケーション、サーバマシン、ネットワーク、クライアントPCのそれぞれでの5つのAに、どのような対策を講じるべきかを組み合わせてアーキテクトすることができる。また、セキュリティの対策は、インシデント（事故）が発生することを想定する必要もある。インシデントへの対応で考えると、例えば、不正なアクセスから保護するようにして、保護が破れていないかを検出して、検出されたことに対応する。というようなセキュリティ侵害の時系列での体系を考えることもできる。すると、空間的なコンポーネントのそれぞれにおいて、保護、検出、対応などに必要なソフトウェア設計の要件を洗い出すことができる。

　このように、5つのAでの考察手法を、システムやコンポーネント、あるいは、システム全体などさまざまなところで使って、設計する際の基本的な枠組みとして使うとよい。ここに挙げた5つのAの考え方が、ITアーキテクトにおけるセキュリティのアーキテクチャを構築することに役立てば幸いである。

---

2/2

Index
つぎはぎシステムを防ぐセキュリティアーキテクト
	Page1 ITアーキテクトでのセキュリティの位置付け SLAに見るセキュリティの位置付け
	Page2 セキュリティ要件の5つのA アイデンティティ・マネジメント プロビジョニング

Profile

佐藤慶浩（さとう　よしひろ） 1990年、日本ヒューレット・パッカード（株）入社。新製品のテクニカル・マーケティングとして、OSF/1、分散環境コンピューティング技術、マルチメディア技術、ハイアベイラビリティ技術、インターネット技術をHP社の製品提供と相応して順次担当。現在は、セキュリティなどのコンサルティング活動のほか、JPCERT/CCのヒューレット・パッカード対応窓口を担当。また、FISC（金融情報システムセンタ）、JISA（情報サービス産業協会）、JUAS（日本情報システム・ユーザー協会）、システム監査人協会や各種セミナーにて情報セキュリティポリシーに基づく情報セキュリティ対策の方法論や個人情報保護対策などについての講演をしている。ホームページは、http://yosihiro.com/business/

Security&Trust記事一覧

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）