消費税増税で忘れられていること

消費税が5%から8%、そして将来は10%になるという法案が政府によって進められています。現在、年間12兆円の消費税収入があるらしいのですが、いろいろな議論が巻き起こっているのも周知の通りです。その中でまったく議論が出てこないのが「免税業者」についての話です。

現在は、すべての取引(ただし非課税のものをのぞく)に消費税の徴収が義務とされているはずです。私は2005〜2008年は会社員だったのですが、その期間の前は、「あなたは免税業者ですか」と聞かれてから請求金額が決まるという会社が多かったことが思い出されます。免税業者なら5%付加しない金額で請求書を書き、その金額が払われてたのですが、会社員をやめてフリーになって改めて調べると、免税業者に対する支払いでも消費税を付加するのが必要という記述を税務署のサイトなんかで見つけました。世の中わかりやすくなったものです。会社員以前の消費税話もいろいろあるのですが、今現在の話をしましょう。

では、現在、免税業者になっている個人や法人はその付加された5%をどうしているかというと、単にその人や法人の収入になっています。免除されているので国に対して払う必要がなく、収入なわけです。つまり、借受消費税は単に収入としてあつかっていいことになっています。現在、免税業者としてメジャーなのは年間で1000万円以下の収入のある業者です。それから、会社設立してからの一定期間も免税業者です。零細企業の支援の側面もあるのかもしれませんが、比較的多いと思われるのが、サラリーマンをしながら副業でちょこっと儲けているような人も、その副業部分が免税業者扱いになっているのが多いのではないでしょうか。これは統計がないのでわかりませんが、会社員しながら1000万を超える売り上げがある人はかなりの強者であり、その方は副業でも課税業者になりますね。まあ、普通はそこまでかせげないでしょう。

2001年頃に、免税業者の基準が売り上げ3000万円から1000万円に引き下げられました。免税業者数は368万人から231万人になり、免税業者は全体の40%になるという数字が発表されています。それまでは消費税を払っていない業者の方が数で多いという結果だったのです。当時は「うちは株式会社ですから」みたいな理由で課税業者を名乗っていた人もいましたが、おかしな理屈であり、都市伝説としか言いようがなかったですね。まあ、それはいいでしょう。

私は、1000万円以下という免税業者という施策自体を再検討する必要があると考えます。税金の公平な負担という原則があるのなら、収入に関係なくルールに従って支払うべきです。消費税は、収益に正比例するきわめて公正な税金です。消費者にはあますところなく支払わせるのなら、業者も同様じゃないでしょうか。全業者の支払い義務があるとした上で、優遇措置を検討するべきです。

収入を500万円、そしてさらに中間の250万円を平均的な収益としたら、精算した支払い税額はその5%として12.5万円です。非課税業者が200万人としたら、2500億円となります。全体の税収12兆円の中でみれば少ないのですが、それでも2%程度の増収となります。もちろん、収入額の平均値はもっと少ないとも言えますが、でかくもなく、少なくもない規模ではないかと思います。ただ、徴収のための手間というか、経費が増えるとも言えるのですが、簡易的な計算方法を導入しつつ、オンライン化により、さほどの費用はかからないと思います。

大昔の3000万円のライン、1000万円のライン、いずれも「政治的な判断」とされていて、確固たる基準がありません。これを撤廃すると、必ず「零細企業を苦しめるのか」的な意見が出てきますが、苦しめているのではありません。本来、消費者が国に対して払ったと思っているお金を、自分のところにとどめないようにしましょうというだけのことです。本来の収入ではないものを「自分のもの」として扱うフィーリングが正しくありません。そして、少なくとも、サラリーマンの副収入、つまり生活の糧は本業の給料で得られている人にまで非課税を適用するという点は、過剰な優遇としか言いようがありません。

税の公平は絶対に守られていないといけないと思います。増税の話題で免税業者のことが出てこないことに、やっぱりどこか「選挙対策」が見え隠れしている気がします。

「気付き」という言葉について考えてみた

最近というか、ここ4、5年前から「気付き」という言葉がよく使われます。古い人間として、やや違和感があり、自分ではあまり使わない言葉ですが、やっぱり気持ち悪いと思う人もいるようです。

当然ながら、気付くは動詞、気付きは名詞です。しかしながら、気付きは「気付いた事」という以上に、自分自身がその事柄を所有している意識が強い単語と考えます。つまり、気付いた上でその背景を理解し、その事柄を別のことにも活かせるという意味を示すために使われているのではないでしょうか。しかしながら、気付いて、理解して、解釈してということもみんな動詞です。動詞って単なるプロセス的にとらえられることもよくあります。「早く起きるのは大変です」「起きるのは当たり前だろう」、つまり、起きて会社に行くのは当然というプロセスの中の動作が「早く起きる」ことなのです。一方「早起きは大変です」となるとどうでしょう。やっぱり「当たり前だろう」と思うかもしれませんが、「早く起きること」自体が成果になっているニュアンスが若干あります。うがった見方をすれば、「早起きして遅刻しないで出社できたという成果があった」という心理があるのではないでしょうか。

つまり、何かが起これば「気付く」のは当たり前だし、そういう状況になったら誰でもできるだろう、やるだろうという考えがあります。一方「気付き」というのは、その人が気付き理解したという成果を強調していることなのです。何でも成果を求められる昨今、イメージとして成果っぽい言葉が頻繁に使われるのはよくわかります。

しかしながら、この「気付き」は自分の成果だけでなく、自分が所属する組織に対する貢献を、暗黙に示す言葉でもあると考えます。お店に注文したとき、商品がないとき、「お取り寄せましょうか」と聞かれますが、「お取り置きしましょうか」という言い方もよく言われます。前者は、お客の注文だから仕入れるのは当然というニュアンスもありますが、後者はお店として顧客の要望に応えましたという成果の強調が感じられます。名詞化することで、自分の成果となり、組織の成果となる。そうなれば、言葉は自然に根付き、となるわけです。

さらに、動詞は続きを求めます。「お客様のお言葉に気付きました」「で、何を気付いたの?それでどうしたの?」となります。ところが「お客様のお言葉に気付きがありました」となると、もちろん、それはどうなのと聞きたくなりますが、何となく完結感漂う言い方となり、あまり突っ込めない雰囲気を作っています。よく、「悟る」と「悟り」が引き合いにだされますが、「悟り」と言ってしまえばそれ以上突っ込めません。「気付き」と言ってしまう事で、ある種の遮断、つまり言葉のやり取りの遮断が発生します。何かを報告するときになるべく上司に突っ込まれないようにしたいという気持ちが「気付き」という言葉を引き出すのかもしれません。

気付きという言葉に違和感があるとしたら、そのときのコンテキスト(文脈)において、成果を暗黙的に強調しているからだと考えました。その上で、深堀を暗黙に否認する感覚を聞いた人にもたらします。本来は、気付くことによって、他のことに応用できるわけですが、気付きだけを強調すると、本当に応用しているのかという疑問も湧きます。そして、応用できないのなら、ほんとに気付いているのかという疑問にもつながります。そして、その確認を遮断するのです。少なくとも「気付き」は悪い言葉ではありませんが、その結果、何ができるのか、何ができたのかを同時に伝えることで、違和感はなくなるのではないでしょうか。

JavaScriptのeventではまる

キーコードを取るkeyCodeや、シフトキーを押しているかどうかを確かめるshiftKeyというプロパティが「event」で使えることになっている。そこで、

document.onkeydown = function(e) { .. }

とすれば、常にキーを押したことを拾えるが、この場合は仮引数eがイベントを参照しており、e.keyCodeでキーコードが拾える。

ところが、次のように、onclickに関数を書いた場合、ブラウザ間の非互換性が発生する。

function clickThis(target) { … }
:
<div onclick=”clickThis(this)”></div>

clickThis関数内で「event.keyCode」と書いて動いてると思っていたら、Firefoxのみうまく動かなかった。つまり、eventというキーワードで、直前のイベントを取得するのはFirefoxではできなかったということである。Safariではできた。

しかしながら、以下のようにすると、Firefoxでも稼働した。関数clickThis内部では、ev.keyCodeなどによってイベントのプロパティに参照する。

function clickThis( target, ev ) { … }
:
<div onclick=”clickThis( this, event)”></div>

つまり、Firefoxでは、「event」によって、直前のイベントを参照できるのはローカルな範囲だけということになる。他のブラウザで、「event」という記述が使えるのは「window.event」というウインドウに直前のイベントを参照できるプロパティが存在しているからである。Firefoxにはそういうプロパティは存在しないが、JavaScriptの規約では存在しないので正しいらしい。

[IM]INTER-Mediatorの認証フレームワーク(2)

少し前に書いた記事「INTER-Mediatorの認証フレームワーク」でのプロトコルでは、中間者攻撃に弱いのが分かったので、最初に1回やりとりを増やしました。

cd573

こうすれば、中間者が得られるデータは、un、ch、h(ch, h(pw))となります。しかしながら、正しいリクエストでは、h(ch, h(pw))の計算におけるh(pw)つまりパスワードにハッシュをかけたデータが必ず必要になります。中間者はそれを持っていないので、正しいリクエストを生成できません。(当然ですが、ハッシュなので、h(ch, h(pw))からその計算の元になっているh(pw)は求められないという前提があります)

また、チャレンジは毎回異なる(確率的に同一である可能性は0とみなせる)とすれば、毎回チャレンジの値が変わり、「以前と同じチャレンジが生成されるまで待つ」という手段もとれなくなります。また、毎回チャレンジが変わることで、同じ通信内容でも生成したデータが異なることになり、過去のデータをため込むことでの一致を見つける手法もほとんど役に立たないと思われます。

これで、クライアントとサーバの間の通信経路のセキュリティはとりあえずクリアできたとします。

アプリケーションの実行する上では、クライアントのJavaScriptはある意味、プログラムを勝手に実行されて変数の値などを取り出されたり設定できる可能性があります。その状態で懸念されるのは、他人への成り済ましです。自分のアカウントでログインをした後、javascript:…でユーザ名の変数を書き換えて、アクセスが成立すると問題です。特にその方法で他人に成り済ますのは重大なセキュリティの問題になります。

上記の方法では、仮にユーザ名を変えることができても、チャレンジとユーザは対応関係があるため、ユーザ名の変更をしてしまった後では必ず認証エラーが出るはずです。

開発者が意図したテーブル以外にアクセスできるか…ですが、データベースのアカウントはサーバから移動しないので(ただし、デバッグモードで見える事もある)クライアントで参照はできない。つまり、データベースの直接続は無理です。リクエストのテーブル名を変更する事もできません。定義ファイルに記述したテーブルとそれへのアクセスしかできないので、たとえば、一般には見せていないユーザ管理テーブルを参照することも不可能です。

さて、また、少し塩漬けします(笑)。

[IM]INTER-Mediatorの認証フレームワーク

INTER-Mediatorはだいぶんと実用的になってきました。そろそろ、先のアーキテクチャを考えはじめています。認証のフレームワークをどうするか、いろいろ考えています。要は、AJAXでの認証となると、単にHTTPでの処理と同じという情報しか得られませんでした。それでもいいのですが、Webアプリケーションでの苦労をもう一度行うことになります。認証は確かにできるのですけど、その後、アクセス権の管理をアプリケーションに組み込まないといけません。たとえば、ユーザごとに参照できるレコードが決まっている場合、認証結果からクエリのパラメータを調整するなどの処理が必要になります。下手をすると、ユーザ名をうまく切り替えたら他人になってしまえるようなものになってしまいかねません。

つまり、認証とアクセス制御をフレームワークで処理をすることによって、アプリケーション作成の上で、安全確実に認証をすることを考えたいと思いました。

とは言え、独自にプロトコルを組むというのも大変な話です。ここで、AWSのやり方をヒントにして、ハッシュをリクエストに入れて認証をするという方式を利用してみることにします。

前提は、データベースがあって、ユーザ、ハッシュしたパスワード、チャレンジ、チャレンジの発行タイムスタンプを持つテーブルを利用するとします。これらはフィールド名は決め打ちにしてしまうつもりですが、他のフィールドは自由に作成できます。その上で、以下のようなシーケンスを考えてみました。h( ) はハッシュを求める関数のつもりです。48623

現在、テーブルは自由に利用できますが、たとえば “security” という属性を作り、そこにフィールド名を記述すると、そのフィールド名に、ユーザ名と同じデータしか取り出さないようにするという仕組みにしたいと思います。たとえば、personテーブルがあれば、

“name”=>”person”,
“security”=>”accessibleusername”,…

のように定義ファイルを作ります。WHERE句で、accessibleusername = ユーザ名、という条件を常に付ければいいかと思います。なお、”security” 属性をたとえば、”__im_authonly” にすると、認証が通ればすべてのデータを参照できるといったような仕組みも入れておこうかと思っています。

あと、ユーザデータベースの保護についても考えないといけませんね。まあ、でも、定義ファイルにあるテーブルしか処理できないという仕組みを徹底させればいいのかなと思ったりします。何か穴があれば、ぜひともご指摘ください。

計画停電サイトtden.me運営者の意見

計画停電検索サイトtden.me (msyk.net/blackout) 運営者としての見解を記載しておきます。

2011年3月11日に発生した東日本大震災により、電力供給元の福島の原子力発電所が大きな被害を受け、発電できなくなるという事以上に放射能を自然界に放出してしまったという最悪の事態にまでなっていることはみなさんがよくご存知のことです。震災直後より、東京電力では「計画停電」(当初は輪番停電)として、電力供給不足に対処してきました。私の住んでいる地域は何度も計画停電による停電が発生し、うち、何回かは夜の停電でした。もちろん、さまざまな不便はありますが、状況を考えれば仕方ないと考えていました。

計画停電が実際に実際されたのは概ね3月中です。4月以降、電力需要が下がることもあってか停電は実施されていません。しかしながら、夏の電力需要が高まる時期に、停電が起るかもしれないということで、東京電力よりさまざまなアクションがなされています。節電の呼びかけと同時にどうしても供給が足りない場合には計画に従った停電を行うというものです。

こうした東京電力の姿勢について「原子力発電の必要性を暗黙に理解させるための茶番である」といった批判がメディアを中心にしてなされています。「計画停電検索サイト」はそうなると、東京電力のそうしたプロバガンダに協力するものかと思われるかもしれません。

しかしながら、当サイトの管理者として、東京電力の原発プロモーションに協力するものではないことを強く主張します。停電といった今まではほとんど起らなかったことがまさに目の前で起こり、今後も起ろうとしています。避けられないことなのであれば、その情報を提供することによって、事前になるべく知っておくということが非常に重要なことだと考えます。極端に言えば、停電も私たち生活者にとっては一種の災害です。しかしながら、それを知っておく事で、食事の時間をずらすとか、コンピュータを終了しておいたりといったことができるわけです。計画停電に賛同するわけではありません。そうではなく、発生する不便に対する対処をするための情報提供をしたいということです。

原子力発電所については、政府や関係機関は、口を揃えて「安全だ」と言ってきました。すでにそれは嘘だったことが明るみになっています。以前より、私は「安全なら大手町や永田町に原発を作るべきだ」と言ってましたが、今やそれはジョークにもならない状況です。おそらく危険だからという理由で都会から遠く離れたところに作ったのでしょうけども、大事故のために広い範囲に被害が及び、発達した流通網によってその影響は遠方にも及ぶのです。CO2の排出の問題は大きいですが、もっと重要なことは放射能を排出しないことであり、今、放射能が自然界に大量に放出されている事実を認識しなければなりません。

停電は不便ですし、いろいろやっかいないことばかりです。しかしながら、停電が起こりまた取りざたされるということから、放射能を大量に排出するという自然環境のみならず人間社会の破壊が進んでいることを強く意識せざるを得ません。それは人間社会で起った小さな失敗が積み重なったものでもあるわけです。停電によってそのことを多くの人がより強く意識し、どうすれば復旧できるのかということを意識する契機になることを願います。

Appleテクノロジーの5年周期

今日の未明に、次期Mac OS X Lionが発表されました。巷ではAirの方に注目が集まっているようですが、Lionの方がこの世界で仕事をしている者にとってはマジなネタです。

2011年、Mac OS X Lionがリリースされるわけですが、大きなポイントは、iOSのエクスペリエンスの統合です。これは、新たなOSが出てくる事に匹敵する程の変化と思われます。しかも、来年夏のアップデートを今からアナウンスするというのは、開発者のアダプテーションが必要だからと考えられます。ということは、単なる見栄えの違い以外にもさまざまな根本的な変化があるのではないかと思われます。

そのように予想するのは、Appleのテクノロジー的な大きな変化は、5年周期のサイクルがあると考えられるからです。Mac OS Xのリリースは、2001年です。Macを取り巻くここからの流れを見ると、アップデートが続き、それぞれ特筆すべき点は多々ありますが、次のジャンプは2006年からのIntel CPU搭載です。1年以内にすべてのラインナップがPowerPCからIntelに切り替わりました。そこまでちょうど5年、そして次の5年目が2011年です。2011年に発生する大イベントは「Mac OS X Lion」であることはもはや疑いのないこと…と考えられませんでしょうか?

一方、iPod〜iOSへの流れを見てみます。デバイスうんぬんについては5年周期はあまり見えないですが、iTunes Music Storeが2003年、App Storeが2008年です。オンラインとの連携がビジネスのキーであるAppleの携帯デバイスなので、ここの5年周期は意味深な気もします。iPodは2001年ですが、2006年にはApple TVが出ています。ここはちょっと判別しにくいのですが、初期のApple TVは「OS X」なるOSが搭載されていました。iPodについては諸説有りAppleの発表がないのでOSは判断しにくいのですが、携帯デバイスのインターナルな世界では、2001年からの初期のOS、そして2006年からのMac OS X系列のOSへと5年周期で変化しています。

90年代にもこうした周期があるのかどうかですが、1996年末に事実上NEXTSTEPを次期OSとして決定していて、そこから5年の2001年に正式リリースになっています。68kからPowerPCへの移行は1993年、そして1998年にはiMacの登場ということもあります。

いろいろなエポックメイキングなAppleのテクノロジーの変化を見る限りは、5年周期は至る所で見られます。従って、Mac OS X Lionは大きな変化をもたらすマイルストーンと考えられます。現状、発表された内容は、エクスペリエンスのiOS化であり、Mac版のApp Storeの開始ということもありますが、きっと全貌はこれだけではないでしょう。こんな次期に発表するだけに、今後デベロッパーが対処しないといけないような何かがあって、機密ベースで少しずつ公開されるものと思われます。そして、2011のWWDCで全貌を明らかにし、夏の発売でいきなりブレーク!というのがAppleのシナリオのような気がします。

ということで、想像ですが、iOSとMac OS Xの違いがかなりなくなるのではないかと考えられます。もともと主要なフレームワークはかなり近いのですが、それを可能な限り近づけるということです。Mac OS Xは高機能ながら複雑で巨大なOSでもあります。そのための使い勝手の悪さや管理の大変さもあるわけです。現在のCocoa Touchのフレームワークで作ったアプリケーションがMacでも動くように拡張をしつつ、Macの側ではファイルというものを意識しないでもいいくらいにまで、iOS的な操作体系になるのではないかと予想されます。

DHCPセキュリティ弱い説:続編

先日、このブログに、「DHCPはセキュリティが低い!?」を書いたところ、けっこう反応がありました。現状、「セキュリティが弱い」というコンセンサスがないにもかかわらず、固定IPで運用しているという場面は決してない訳ではないということで、Twitterでもレスポンスをいただきました。

しかし、そんな情報がどこから出て来たのだろうかとふと疑問に思い、いろいろ検索をしてみました。まずは、マイクロソフトの「DHCPのセキュリティ情報」です。最初に『DHCP と関連プロトコルでは、次のようなセキュリティ上の問題が判明しています。』と前置きをして、以下のようなことが記載されています。タイトルだけ抜粋します。

  1. DHCP が認証されていないプロトコルです。
  2. DNS サーバーに対するサービス拒否攻撃を、DHCP サーバーを介して実行できます。
  3. 承認されていない Microsoft 以外の DHCP サーバーが DHCP クライアントに IP アドレスをリースできます。

1の認証を経ないプロトコルであるというのはその通りです。ただし、認証を行う方法はあります。これは後で説明をします。2については、一般的なDHCPの問題ではなく、ホスト名とIPアドレスの対応をActive Directoryにレコードとして追加するダイナミックDNS特有のセキュリティ問題です。一般のDHCPには関係ありません。3についてはADに承認したDHCPという仕組みを利用できますが、当然ながらADとは関係ないDHCPを立てる事は可能なのです。文章を読むと、別に誤解をさせることは何も書いていません。しかしながら、前置きのところだけを見て、それだけで判断してしまう人もいるんじゃないでしょうか。

日本の学会誌についても、検索してみました。たとえば、「IPアドレス自動割り当て方式(DHCP)におけるセキュリティの実現方法」網淳子, 岡本利夫(1995年電子情報通信学会総合大会 B-829)という論文があります。この論文は、認証なしにIPアドレス配給ができるDHCPのニセモノサーバの存在を検知する方法を提案しています。その部分を引用すると『ところが、現状のDHCPはセキュリティの面で不充分であり、権限のないサーバーが勝手に立ち上がって誤ったアドレスや経路の情報を流したり、悪いホストが他のホストになりすまして情報の横取りをする可能性が高い。』となっています。省略すると「DHCPはセキュリティ面で十分じゃない」となるかもしれませんが、この論文はニセサーバの問題を論じているのです。固定IPで運用するべきとはどこにも書いていません。

他に見つかったのは「特集 モバイルコンピューティングを支えるシステム技術/移動透過な通信を実現するプロトコル(寺岡文男)」(電子情報通信学会誌 Vol.80 No.4 pp.344-349)というものがあり、ABSTRACTの引用をすると『DHCPはネットワークパラメータの自動設定を行うプロトコルである。Windowsにも実装されて広く利用されているが、認証の機構がなく、セキュリティに問題がある。』と書かれています。この記事では場所を移動する状況での通信方式についてのことが書かれていますが、DHCPのセキュリティについて論じたものではありません。認証をしないという仕組みについての喚起として記載されています。

いずれも間違えたことはもちろん書いていません。しかしながら、断片的に読んで結論を出してしまう人にかかれば、「DHCPはセキュリティ的に問題がある」ということになってしまいます。

ちなみに、現在において、DHCPの認証はできるかどうかというと、「簡単に」できます。1つはDHCPサーバに応答してもいいホストのMACアドレスを登録する方法です。ワイヤレスでも使われる場合もあります。使うPCのMACアドレスを逐一設定しないといけないので、管理の手間はかかりますが、確実な方法として使われています。ただ、MACアドレスの登録なんてどうやるの?と思う方もいらっしゃるでしょうけど、現在はいちばん安物のブロードバンドルータでも、管理ページを開けばこの設定は出てくるのじゃないでしょうか。サーバOSでのDHCPでは設定できて当然です。この機能が使えないという状況は、実際には皆無に等しいでしょう。

さらにより確実な方法として、802.1Xという手法があります。ただし、認証のためのサーバの設置や、場合によってはデジタル証明書の発行などの作業が必要になり、簡単には行きません。しかしながら、高いレベルのセキュリティを使うところでは利用されているソリューションです。

では、認証をしないDHCPで、どんな工夫があるのかも紹介しましょう。会社などでは、カードキーで社員証にもなっているカードをリーダに読み込ませないと、オフィスに入れない環境ならば、「オフィスにいるのは社員あるいは承認された人である」という理屈が成り立ちます。それがほぼ100%実現されるのであれば、認証をしないDHCPでも問題はないでしょう。

カードキーがないようなところでも、前に書いたように、普通は基本的なセキュリティ、つまりよそ者が簡単には入れないようになっているので、概ね問題ないと考えるのが一般的です。よそ者がネットに簡単につなげるようなところでは、ネットワーク以前に財布や家具がなくなります。また、検索して見つけた記事で「我が家のインターネットはDHCPではセキュリティ的にまずいでしょうか」という答えに「ネットの心配をする前にまずは鍵を直しましょう」という回答がありましたが、まさにその通りですね。

DHCP危険説は一種の都市伝説かもしれません。もちろん、プロトコル的な問題点はあるのですが、これまでにも説明してきたように、それらの問題点は実際には問題にはなっていませんし、認証をさせるという解決策もあります。おかしな伝説がまことしやかに流れることがないように願う次第です。

DHCPはセキュリティが低い!?

このところ、「うちは固定IPです」というのをよく聞きます。ネットワークの設定を業者に依頼したときに、「DHCPはセキュリティ的に問題があるから固定IPにしましょう」と言われるそうです。もちろん、買ってきたマシンのセットアップが面倒ということもありますが、ところによっては、パソコンが増えるたびにIPアドレスを業者に指定してもらって設定しているとか。どうも、それでメンテナンス料を取っているのじゃないかと思われる節があります。

いくつかのサイトを見たところ、DHCPが脆弱であるという理由は、次の通りです。

  • どんな機材にでもIPアドレス等インターネット接続に必要な情報を渡すため、誰でも接続できる。
  • 不正アクセス時に誰がアクセスしたか分からない。

前者は、「悪意を持った人が簡単に接続できる」みたいな書き方をしていれば、まあ、みなさん、恐れるのは無理も無いかもしれませんが、よく考えると、この理屈には問題があります。

一般に、ネットワークと言えば、ワイヤレスないしはEthernetでしょう。ワイヤレスは接続自体にパスワードをかけるのが現状では一般化しているので、「社内の人しか使えない」みたいに言えなくはありません。まあ、そこも突っ込みどころありますが、ここではEthernetにフォーカスしましょう。

仮に、ある事務所で、EthernetでDHCPを使っていたとします。そうすると、もちろん、事務所外の人がそこにPCを持ち込み接続すると、インターネット接続できます。DHCPの問題点はそこだというわけですね。これは、Microsoftの技術文書にも書いてあります。

もちろん、MACアドレス(Ethernet ID)をDHCPサーバに登録するという方法で、外部の人の接続は阻止できますし、Active Directoryは確かにDHCPやDNSとの連動で阻害はできるので、いわゆる普通のDHCPより安全であることは言えるでしょう。では、一般的なDHCPが安全ではないと決めつける事ができるのでしょうか?

一般の事務所で、部外者が勝手に入ってきて、Ethernetにつなぐという行為があったとき、事務所の人は無視をしますか? 普通、どなたですか? ご用事はなんでしょうか? くらい聞きますよね。人の出入りが激しく部外者がいつでも出入りしている…というところがあったとしても、それは、Ethernetを設置するのが間違いで、普通はワイヤレスだけにします。部外者がEthernetを勝手に使えるような事務所があったとしたら、きっと、普通の悪者は「インターネットにつなごう」と思う前に、「財布を盗もう」とか「家具をぱくってやれ」くらい考えるでしょう。知らない人が入ってきて、勝手にお茶をわかそうとしたら、普通は排除しますよね。それと同じで一般には事務所のEthernetは人の目で監視されているはずです。そうではないとしたら、ネットワークのセキュリティ以前の問題です。

しかし、それでも、例えば、深夜に忍び込んでアクセスできるということもあるかもしれません。ネットワークを勝手に使ってデメリットはあるでしょうか? 勝手にファイルサーバの中身を盗まれたり、消されたりするという心配もあるでしょう。しかしながら、これは「すべてのサーバはユーザ名とパスワードの入力が必要」としておくことで、防ぐことができます。面倒臭いからと言って、誰でも読み書きできるファイルサーバを立てていれば、もちろん危険ですが、そういうサーバ管理はDHCP以前の問題で、そういう運用自体が危険です。重要な情報はともかく認証が必要としておけば、何も心配することはありませんし、不正アクセス自体をほぼ100%排除できるわけです。排除できれば、誰がやったのかを調べる必要はありません。これはDHCP以前に、ネットワークのセキュリティを確保するために必要なことです。

そうしたら、深夜に忍び込んだ悪者は、単にインターネットでGoogle検索するくらいしかやることはありません。月額固定の通信料だとしたら、ほとんど被害はないでしょう。だいたい、それ以前に、椅子とかロッカーとか盗まれますね。

さらにさらに、固定IPにすれば、インターネット接続できないと思っている人も居るかもしれませんが、固定IPのネットワークにつないで、ある程度ルータやDNSのアドレスに目星をつける事もできます。Mac OS Xだと、とりあえず可能なようです。やり方は、「ping 10.255.255.255」「ping 192.168.255.255」といった末尾が255のグローバルPINGでいろんなネットワークアドレスを試します。その後に「arp -a」とすれば、だいたい、応答があったホストのIPは分かります。後は、経験と勘でどれがルータか分かりますし、DNSサーバのホストもポートスキャンで分かります。不正アクセスしようという輩は、この手の手法はよくご存知でしょうから、「固定IPにしたら、インターネット接続できない」ということ自体間違いです。

思うに、こういう「DHCPはだめ」というのは、後々のメンテナンス費用で稼ごうとしている業者の作戦なのではないかと考えます。DHCPでちゃんと動けば、後は何もしなくてもOKとなると、メンテナンス費用をかせげません。IPをつどつど業者からアサインしてもらう上では、確かに業務としては発生しますが、なんだか、倫理的にぎりぎり、あるいは一線を超えてないでしょうか。

そういうわけで、DHCPは便利ですから、DHCPを使いましょう。言い換えれば、DHCPを取り入れたネットワーク管理ができるようになりましょう。家庭で当たり前のように使われているDHCPですが、事務所で使えないことにもっと疑問を持つべきです。

それでも、不安と思う方は、次のように考えてみてください。固定IPにしたときの設定の手間やIPアドレスの管理といった仕事が増えるコストは、DHCPにすることによるその損失(仮にあるとすれば)より、高くなっていませんか? 典型的な、セキュリティにかける費用が損失を上回る失敗プランなのです。いわば、保険金の払い過ぎってイメージでしょうか。

[IM]Enclosure/Repeaterの展開

INTER-Mediatrorの再構築はいいところまで行きそうなところで、実はつまずきました。Enclosure/Repeater/Linked Elementという階層を考えていたのですが、EnclosureでありLinked Elementなもの、RepeaterでありLinked Elementであるものもあります。そこを考慮していなかったので、少し戻らないといけなくなってしまいました。まずは図を書いて考えます。

45781

 

また、実際のタグと展開パターンをまとめておいて、再検討に入ります。こう考えると、3種類のオブジェクトに分離しているのは、表だけですね(苦笑)。

 

形態 Enclosure Repeater Linked Element
TBODY TR any elements
汎用 DIV._im_enclosure DIV._im_repeater any elements
番号リスト OL LI LI itself or inside of LI elements
箇条書き UL LI LI itself or inside of LI elements
ポップアップ、リスト SELECT OPTION OPTION itself
ラジオボタン、チェックボタンリスト DIV._im_enclosure INPUT [@type=readio or check] INPUT itself