Lazy Diary @ Hatena Blog

PowerShell / Java / miscellaneous things about software development, Tips & Gochas. CC BY-SA 4.0/Apache License 2.0

Internet Explorerでないと満たせない業務要件

「いつまでも あると思うな Internet Explorer」的なことをMicrosoftが言っている こともあり、IEに依存したシステムを作ってしまうのはできるだけ避けたいところ。でも、どうしてもIEじゃないと実装できない要件というのもあるわけです。

もちろん、提案の内容を工夫したり、ユーザ組織内の政治を上手くやることで、要求仕様から外すことができればそれに越したことはない。ただ、そういう調整ができないフェーズまで進んでしまっていたり *1 、そもそも「その機能がIEでしか実装できないなんて知らなかった」という状態だったりすると、もうどうしようもありません。

そこで本記事では「WebアプリケーションにおいてIEでしか実装できない業務機能」の例を示します。誤ってそういった機能を提案に盛り込んでしまうのを防いだり、そういった機能が要求仕様に紛れ込んでいた場合に意見招請で修正を申し入れたりするのに活用できるかと思います。

また、当初の意図とは違いますが、IE依存を顧客に咎められた際に「こういう要求仕様があるからIE依存の実装になっている」と申し開きをする場合だとか、既設システムのIE脱却において顧客に対し「この機能は作り直しになるから追加費用をいただきます」と説得をする場合にも使えるかもしれません。

クリップボードの内容をユーザ操作によらず制御する(たとえば一定時間ごとに削除する)必要がある

たとえばセンシティブな個人情報を扱うシステムなどでは、ユーザの操作による情報漏洩を防ぐために「文字列のコピー禁止」「スクリーンショット取得禁止」が要件として定められていることがある。Webアプリの場合ならJavaScriptでブラウザのイベントを横取りして、コンテキストメニューからのコピーやショートカットキーによるコピーを抑止すれば十分……かと思いきや、抜け道があることは顧客も把握している(そもそもスクリーンキャプチャはJavaScriptで抑止できない、とか)。そのため「0.2秒ごとにクリップボードに空文字をコピーする処理をJavaScriptで実装する」といった対処をして顧客に納得してもらうことになる。ChromeにもClipboard APIがあるが、Clipboard APIはユーザの操作を契機にしか動かせないので、上記の「0.2秒ごとに」のような処理が行えない。

基本的な対策としては、戸籍の不正閲覧防止なんかと同じで、データの参照処理に対して監査証跡ログを取得することで情報漏洩を防止する方針に倒すのがよい。ただし、自前の説明だと「意図をもってクリックしたのとまちがってクリックしてしまったのとをどう区別するか」を顧客が突っ込んでくる場合があるので、たとえば最初に「内閣官房が出している政府情報システムの整備及び管理に関する標準ガイドライン実務手引書 の第10章に、監査証跡を取得するよう記載されています」とか説明して、監査証跡を実装する方向に誘導する必要がある。

ActiveXによる端末側デバイスの制御

これもセキュリティ要件に基づいて作られた業務運用が仕様の根拠で、たとえば認証処理のためにICカードリーダで読んだIDカードなんかの情報をブラウザからサーバへ送信する場合が挙げられる *2ChromeにはWebUSBが実装されているけれど、逆にWebUSBの実装自体にあるセキュリティ上の問題がハードルになる。他にも「デバイス専用のドライバがロードされているとWebUSBから操作できない」という仕様があるから、端末のキッティングが必須になってしまう。キッティングを行うと、「個別の端末への導入作業のコストが抑えられる」というWebシステムのメリットが打ち消されてしまう。

対策としては、単純にType 2 (Something you have) の多要素認証が行いたければ、時刻同期型のワンタイムパスワードなど、ブラウザからデバイスへのアクセスが不要な方式へ誘導する。ただし、ICカードで入退室管理をしている場合など、すでに導入済みのデバイスがある場合はツラいかも。

ActiveXによる印刷制御

これもやっぱり情報漏洩に関する要件。帳票の印刷機能があるシステムでは、どのユーザがどのPCからどのプリンタで何の帳票を印刷したかをログに残すことが要求されたりする *3 。印刷サーバや各フロアに配置するプリンタが調達範囲に入ってて、印刷サーバから出力先の全プリンタを制御する *4 ような場合はともかく、印刷サーバなし、顧客PCのキッティングなし、プリンタも有り物を使うようなシステムでは、ブラウザに印刷機能を持ったActiveXプラグインを入れて、そこから印刷をかけつつログをサーバに送る、というくらいしか現実的な実現方法がない。完全にアウトなのは、印刷枚数をユーザごとにカウントして所属部署に課金するとか、セキュリティのため印刷時にプリンタでユーザ認証が必要だったりする場合。プリンタドライバにパラメタを設定する必要があるため印刷サーバを使う方法は取れず、クライアントに仕込んだプログラム or ActiveXコンポーネントからの印刷一択になる。

対策としては、仕様の調整が可能で、かつ用紙自体に透かしのない事務用帳票しか印刷しないのであれば、システムの操作ログと突き合わせられる情報を帳票全体に地紋として印刷する方式でカバーするのがよい(地紋の内容と操作ログを突き合わせると誰が印刷したか分かる)。ただ、管轄官庁から通達が出ててるとか法定受託事務だったりとかで仕様調整が不可能な場合はアウトだし、用紙自体に透かしのある帳票だと地紋が入れられないからこの方法は使えない。

ブラウザを利用した.NETアプリケーションの配布

.NET製のアプリケーションを各端末に配置・配布する手間を省くために、ClickOnceを使ってWPFなアプリケーションをブラウザから起動している場合。業務端末が日本中に散らばってるとか、客先対応のエンジニアが顧客の端末の面倒まで見切れない、という場合に選ばれたりする。もっとも、ClickOnceはEdgeからも使えるし、この場合IEは単なるランチャーとして使ってるだけなので、どちらかといえば技術的な話かもしれない。

ブラウザ終了時のブラウザキャッシュの削除

この機能も、やっぱり情報漏洩に関する要件に起因して盛り込まれることが多い気がする。IEならWSHからブラウザを立ち上げた上で、ブラウザプロセスの終了を待って RunDll32.exe InetCpl.cpl,ClearMyTracksByProcess 1 (履歴の削除) RunDll32.exe InetCpl.cpl,ClearMyTracksByProcess 8 (Temporary Internet Filesのクリア)とすれば可能。もっともIEは、プラグインなんかのせいで正常に終了できずにプロセスが残存することが多いから、IEが開いてる画面のURLをポーリングした上で実行した方が確実かな。FirefoxChromeではキャッシュフォルダの場所を変更しているとコマンドラインからの削除は難しい。Edgeであればギリギリ可能(2018/11現在のEdgeにはキャッシュフォルダの場所を変更する機能がないため)。

基本的な対策としては、履歴とTemporary Internet Filesに分けて顧客に説明する。履歴については、全リクエストをPOSTにしたうえで「クエリパラメータには特に情報は載せないし、リプレイ攻撃が通らないようにトランザクショントークンを発行する」などの方法をアプリに盛り込んで対処する。Temporary Internet Filesについては、ブラウザのキャッシュ制御(Cache-Control)を厳密に制御したうえで、それでも端末上で見られる情報は「普通にブラウザ上でF12を押せばみられる内容だから、キャッシュだけ削除しても意味がないですよ」とか説明するのがいいのかな。

業務画面の同時起動数制御

起動中のウィンドウで業務システムを開いていたら、新規ウィンドウで業務システムを起動できなくする(ウィンドウをすぐに閉じちゃうとか)。典型的なのは、OLTPのバックエンドがCOBOL製で、端末単位に一時ファイルなんかを制御する処理方式が残っているために、同一端末から複数ログインができない……というケース *5 。これは政治的というより、COBOLのコードの焼き直しに費用がかけられない(単純な焼き直しじゃ資産価値が増えないから)という会計面の制約という色が強いのかな。もしかしたらChromeFirefoxでも実装が可能かもしれないけれど、IEHTAの組み合わせ以外で実装しているケースを見たことがない。

これに関しては、顧客の思いがどうこう言うより、純粋にカネの話になってしまいそうなので、調整は難しいのかな……という気がする。

*1:受入テストを原課でなく調達部門が単独で行う組織なんかで、契約時の要求仕様通りでないと調達部門が検収OKを出せず、結果として原課と受注者双方が合意していたとしても、契約締結後の仕様調整はできない、といったケースなど。詳細はこの記事の範囲を越えるので省略。

*2:余談:バーコードリーダなんかは、バーコードが読み取れない場合にキーボードから手打ちできる必要があるから、デバイスもそれに合わせてHIDのふりをすることが多くて問題になりにくいんだけど、ICカードはさすがに無理。

*3:フォレンジックに関する要件なので、個別システムの仕様どころか、管轄官庁から通達が出てたりする。どこまでを政治で頑張るか、という話になりますね。

*4:業務アプリに印刷先プリンタの選択機能を持たせた上で、印刷サーバに全プリンタの全トレイを別々に登録する。プリンタがバラバラならそれぞれのプリンタドライバも入れないといけないし、プリンタポート用にファイアウォールの設定も変えないといけない。ユーザは座った席に合わせて印刷先を設定し直さないといけない。ユーザも使いにくい上に、設計もめちゃくちゃややこしいぞ!

*5:だけど、そうでない場合でも要求仕様に入ってたりすることがあるのは何でだろう?