何年か前に、高速道路の事故を減らすための方法を、交通システムの偉い先生に聞いたことがある。自動車が高速で走っている高速道路は、一般道とは違うさまざまな理由で事故が起こることがある。例えば、高速に目が慣れてしまうために、車間距離が短くなってしまうといったことだ。特に薄暮のころや夜間は危険である。こういった事故を防止するために、高速道路の街灯の明るさを調節するという方法がある。ここで面白いのは、地域によってその調節がまったく逆ということだ。
東京の場合には、街灯を明るくする。そうすれば、路面状況や先の方の自動車まで見えるので、視認性がよくなり事故が減るという理屈だ。反対に大阪の場合には、街灯を少し暗くする。そうすれば、ドライバーは見えにくくなるので、高速道路を注意して走る。そのうえ、電気代まで減らすことができるという理屈だ。
この話が本当で、いまでもそういう対策を採っているのかは知らないが、街灯を明るくしても暗くしても事故対策になるという点が面白い。しかも、そのどちらもある程度の効果を上げているという話だった。
ルールは厳しくする？ 緩くする？
会社ではセキュリティポリシーなどによって社員にコンピュータの使用やネットワークの使用について、何らかのルールを課している。さまざまな会社のセキュリティポリシーやルールなどを知ると興味深いことが見えてくる。ある会社は社員へのルールを厳しく締めることによってある程度の秩序を保っている。また、ある会社は社員へのルールを緩くすることである程度の秩序を保っているというのだ。
ルールを厳しくするか緩くするか、まったく逆のことをしているが、話を聞くとそれぞれに利点があるのが分かる。社内から社外ネットワークへのアクセスという点に絞って見てみよう。
ルールを厳しくしているという会社では、社外へのHTTPとHTTPSのアクセスはプロキシを使用し、一部のWebサイトへのアクセスはURLフィルタリングによって制限している。そのほかのsshやtelnetなどへのリモートアクセス、FTPや外部のメールサーバなどへはすべて許可申請を必要としている。
もう一方のルールを緩くしているという会社では、社内のネットワークはローカルIPアドレスとして、ファイアウォールを設置してログはすべて取得しているが、社内から社外へのアクセスはほぼ制限されておらず、ユーザーが自由にアクセスできる環境としている。
ルールは厳しくても緩くても一長一短
ルールを厳しくしている会社では、ユーザーのアクセスを制限することで不用意なアクセスやネットワークの私的利用が減っていると主張している。しかし、問題もあるという。ルールを厳しくすると、必ずその網を抜けようとするユーザーがいるというのだ。そういうユーザーは、SSH-VPNやトンネルなどを使って制限しているリソースへアクセスしている。SSH-VPNやトンネルもネットワークのアクセス制限で許可されているポートやプロトコルを使ったアクセスであり、しかも通信内容は暗号化されているため、問題を見分けて防ぐことが難しくなっているという。
ルールを緩くしている会社では、ユーザーにアクセス制限を課さない代わりにログを取得することで、ユーザー別のアクセス動向を把握できるため、ピンポイントで対策をすることができるという。問題がある行動をするユーザーに注意を促したり、特定のアクセスだけをそれとなく制限したりするそうだ。アクセス制限をしていないので、ユーザーはSSH-VPNやトンネルなど手の込んだ方法を使うことがないという話である。ログを取得していることを公にすることで、ユーザーの心理に訴えるという方法を採っているのである。こちらの問題点としては、注意をするなどで事後に防ぐことはできるが、事前に防ぐことができないという点である。
厳しくするも緩くするも、どちらも一長一短であり、両者のバランスを取ることは難しい。どちらにするかはセキュリティポリシーを定めるときなどに大いに悩むところであろう。厳しいルールはユーザーが抜け道を探し、緩いルールは無法地帯となる可能性も考えられる。
最初は緩くしてみては？
まだ明確なルールが整備されておらず、これからルール作りをする場合には緩い方から導入してみるのはどうだろうか？なぜならば、緩い方が導入コストと時間がかからずにすぐに始められるからだ。特に最初は心理的なところから始めてみるのがよいだろう。
理想論としては、セキュリティポリシーをしっかりと定めて運用していくのがよいといいたい。しかし、多くの会社では情報セキュリティに対して理解がそれほど深いわけではなく、しっかりとしたセキュリティポリシーを導入・運用していくためのコストや時間を割くことが難しいのが現状である。
例えば、社員のネットワークの私的利用を止めたいという目的ならば、月に一度程度アクセス解析結果などを公開するのもよい。もちろん誰がどこにアクセスしたという詳細は伏せておく。そうすることで心理的な抑制効果が出るはずだ。
どちらも一長一短で選びにくい場合には、コストと時間がかからない方を先に試してみるのがよいだろう。
Profile
上野 宣（うえの せん）
1975年京都生まれ。情報セキュリティを世に広げるべく、講演や執筆活動とさまざまな方面で活動中。近著に「今夜わかるメールプロトコル」、「今夜わかるTCP/IP」、「今夜わかるHTTP」（共に翔泳社）がある。
- 今夜こそわかる安全なSQLの呼び出し方 〜 高木浩光氏に聞いてみた
- 「わざと脆弱性を持たせたWebアプリ」で練習を
- Perl Mongersはセキュリティの夢を見るか？
- 誰がシステムのセキュリティを“大丈夫”にするのか
- 技術は言葉の壁を越える！ Black Hat Japan 2008＆AVTokyo2008（後編）
- 技術は言葉の壁を越える！ Black Hat Japan 2008＆AVTokyo2008（前編）
- キャンプに集まれ！ そして散開！
- 売り上げ重視か、それともセキュリティ重視か!? 「安全なウェブサイト運営入門」
- CeCOS IIにみるネット犯罪のもう一方の側面
- セキュリティ対策の行き着くところは……最終手段？ 京都に究極のセキュリティ対策を見た
- 人はオレを情報の破壊神と呼ぶ せめて、ハードディスクの最期はこの手で……
- セキュリティ社会科見学：インターネット物理モデルでセキュリティを考えた
- セキュリティ自由研究：この夏、グミ指を作ってみないか
- Webアプリケーションを作る前に知るべき10の脆弱性
- セキュリティを教える人に知ってほしい 基本が詰まった1冊
- セキュリティのバランス感覚を養うための1冊
- 暗号化仮想ドライブで手軽にファイルを暗号化
- Windows管理者必携、Sysinternalsでシステムを把握する
- 今夜分かるSQLインジェクション対策
- 「取りあえず管理者アカウントで」という思考停止はもうやめよう
- CSSクロスドメインの情報漏えいの脆弱性「CSSXSS」とは
- 偽装メールを見破れ！（後編）
- 偽装メールを見破れ！（前編）
- メールは信頼できても信用できない
- 危機管理体制を整えよう！ 個人情報漏えい後の対応ガイドライン
- メールアドレスを漏えいから守る方法
- 「Whoppix」を使ってペネトレーションテストをやろう
- 「ぼくはまちちゃん」 ――知られざるCSRF攻撃
- 25番ポートの攻防
- 平田です。届いてますか？
- 魔法の鍵と最後の鍵
- 個人情報保護法を論理的に読み解く
- 安全確保のために東京は明るく！ 大阪は暗く！
- 言論の自由とセキュリティコミュニティ
- 標的にされる無防備なコンピュータ
- セキュリティ担当者には想像力が必要
- 端末を持ち歩くことの危険を意識せよ！ 〜 「ノートPC＝自動車」論 〜
- 脆弱性のあるサイトとセキュリティ技術者の関係
- いまこそ一般教養としてセキュリティを！
- 大事なことは製品でもなく知識でもなく……
- 治安の悪化で改めて痛感したこと
- Blasterがもたらした多くの“メリット”
- 企業でのセキュリティ資格の意味合いは？
- 人はミスをするものと思え、故に事前対策が重要
- オレオレ詐欺に学ぶソーシャル対策
- あらゆる人にセキュリティ教育を
- 猛威を振るうSARSウイルスに思ったこと
- 痛い目に遭って考えた、ビジネス継続性の重要さ
- 責められるべきはMSだけだろうか？
- セキュリティ技術者を「憧れの職業」にするには？
Copyright © ITmedia, Inc. All Rights Reserved.