ランサムウェア対策は？ 基本に忠実なセキュリティ設計でシステム寿命も長くなります

コンピューターが進化し、面倒なアップデートにも付き合い、コストも払っているのになくならないセキュリティ被害、どうしたらいいでしょう。ヒントはコンピューター、ネットワーク技術の基本理解にあります。商用OSのセキュリティの基本的な考え方は、セキュリティソフトをアドオンするのではなく、リスク要素を除きシンプルにしていくものでした。いつの間にか基本がなおざりになった感があります。インターネットが日本で使われだした頃を思い出しながら、基本注意事項をまとめました。20年、30年と使い続けられた設計や技術はシンプルで費用対効果が高く、システムの長寿命化に寄与します。

 

１．管理者権限でログインしない(必須)

Windowsで理解できないのは管理者権限でネットサーフィンが出来ることです。インターネットは自己責任です。相手が国外であれば日本の法律は無力です。交通ルールが定かでない国で運転するのと同じです。ドライブは出来ても安全ではありません。

・管理者権限のないアカウントを作成し、通常のログインはそれを使うようにします。

・アカウントのパスワードは英数字、記号などランダムな16文字以上として紙に書いて保存します。セキュリティ情報はシステムから分離の原則です。

２．セキュリティの高いブラウザを使う(是非)

広告、特に仲介業者を通したアフィリエイト広告が氾濫していて、どこに落とし穴があるか分かりません。安全なブラウザを使うことで、アフィリエイトを抑止できます。表示されない以上、クリックすることもなくなります。フィッシング詐欺対策にもなります。

お天気サイトを閲覧した例

Google chromeの画面、アフィリエイト広告を抑止できない

Firefoxの画面、アフィリエイト広告を抑止できている

３．アプリを入れない・入れさせない(必須)

管理者権限がなければアプリを入れることもできません。利用者がそれと知らずメールやWebでだまされてアプリを入れてしまう事故も起きません、ウィルスやランサムウェアの被害が発生してもはログイン権限の範囲内に留まります。

４．Windows以外のOSを使用する(是非)

ここからはシステムの専門領域ですが現在ではLinuxを選択することが多くなると思います。LinuxはオープンソースでOSの技術情報や運用ノウハウに透明性があります。良いことも悪いことも広く共有され、OSについて知ることの出来ない情報はありません。そのためセキュリティ対策を立てやすく、迅速に対応することができます。

５．ネットワークからログインできないようにする(是非)

セキュリティは流行り、廃りとは関係ありません。機密性の高い情報を扱うシステムは監督者と物理的に近い場所に設置し外部とは遮断します。利便性とセキュリティはトレードオフになります。政府、金融機関等では現在でも普通に行われていることです。

Linuxであってもネットワークからログインできないようにします。サーバというと以前はシリアルポートからの接続が基本でした。シリアルコンソールは導入・運用が容易で費用対効果が非常に高いものです（導入コストはただみたいなもの）。大企業はもちろんのこと、中小企業、スタートアップ企業にこそ導入して欲しい対策です（DDoS対策・ファイアウォール、リアルタイム侵入検知、ウィルススキャン、証跡ログなどどれだけのコストが掛かるでしょう？設定ミスは大規模トラブルの元にもなります。専門知識、専門家の助けも必要不可欠です）。

永島志津夫

全社のシステムを少ない人数で見ていれば時に見落としもあるかもしれません。
オフィスエヌ ショートレビュー5万円から。
連絡先 office.nagasima#gmail.com (#を@に変えてメールをお願い致します）

セキュリティ対策 XSS, CSRF, ポップアップブロック そして・・

サードパーティークッキー・ブロック！

Webサーバーがコンテンツをブラウザーにレスポンスする際、ヘッダー情報にクッキー ( cookie ) というセッション識別情報を付加することがあります。HTTPプロトコルはブラウザーからのリクエストに対してサーバーがコンテンツをレスポンスして終了です。1ページで終わらないようなアプリケーションの場合、継続しているセッションを知る必要があります。HTMLに識別情報を埋め込んでもよいのですが、コンテンツとは別にヘッダー部にセッション識別情報を組み入れたのが cookie です。

その cookie 、長年の問題がありました。ユーザーが意図していないタイミングで受け取ったり、送ったりしてしまうのです。
例えばニュースサイトをみて通販商品のコンテンツがあったとします。そのコンテンツは別のサイトのものだったとします。ユーザーはニュースサイトを見ているつもりですが、通販サイトはユーザーがニュースサイトのどのページをいつ見たかを記録します（できます）。通販サイトへのリンクをたどらずとも記録されます。ニュースサイトに通販コンテンツがあることを事前にユーザーはわかりません。また一度クリックすると別サイトでも同じ商品の広告が出てくるのはサイトを越えてクッキーの使い回しができるからです（事前にユーザーはわかりません）。このリンクが書き換え、悪用されてもそれっきりです。

この例のようなセキュリティの問題をはらむクッキーをサードパーティクッキーといいます。実はブラウザーの設定でサードパーティークッキーの受け取りを拒否することができます。高い、不便、遅くなるで不評のセキュリティ対策としては、例外的にただ、簡単、遅くならない、しかも強力なものです。ただブラウザーのクッキー設定を変更しているユーザーは少ないのではないでしょうか？会社のPCどうですか。

しかし朗報です。Appleは2020年3月に Webブラウザ Safari の初期設定を “サードパーティークッキーの受け取り拒否” としました。サードパーティークッキーの主たる用途は広告宣伝なのです。セキュリティもですが追っかけ広告も鬱陶しいですよね。サードパーティークッキーの濫用というか、そもそもネットマナー、エチケットとしてどうなのかと思っていました。広告宣伝行為として後ろめたさありますよね。会社のマーケティング部門に勤めている知人も個人的にはやりたくないし、自宅のPCはサードパーティクッキーをブロックしているそうです（私もです）。Apple やりますね。マイクロソフト、Google も諦めて欲しいものです。

ブラウザーの設定画面のキャプチャーを貼りました。設定した後は、過去のクッキーをクリアしましょう。クッキー・ブロックは受信拒否であり送信拒否ではありません。過去の設定でブラウザーに保存されているクッキーは有効期限まで送信され続けます。

Chromeの設定

Edgeの設定

サイト運営者、Webエンジニアのみなさま、自主的にクッキーポリシー SameSite=Lax  を明示しましょう。Apache であれば mod_header で append SameSite=Lax とするだけです。 php でも jsp でも HTTPヘッダーに反映されます。簡単です。Apache 知っていると得することまたご紹介します。枯れた技術に宝ありですね。

永島志津夫

全社のシステムを少ない人数で見ていれば時に見落としもあるかもしれません。

オフィスエヌ ショートレビュー5万円から。

連絡先 office.nagasima#gmail.com (#を@に変えてメールをお願い致します）

外部認証 OAuth2 業務サービスのクラウドでは？

外部認証、身近なものでは “Facebookでログイン” とか “Googleでログイン” のことです。ユーザ登録は面倒ですし、パスワードも覚えていられないのであれば使われている方も多いかと思います。OAuth2 なのですがコンシューマ向けと業務サービスでは構成、シーケンスに違いがあります。なぜか？というお話です。

最初に業務サービスのの場合の認証シーケンスの例をご紹介しましょう。

ユーザーは認証サイトBにログインし業務サービスを利用していますが、あるオプション機能はサイトAのものだとします。まだサイトAにログインしていないので、オプションメニューをクリックすると、認証トークンが埋め込まれたサイトAへのログインページがサイトBから返されます。ここがポイントで、サイトAへのログインページをサイトAのセッションで返されると、認証トークンをサイトBから得るセッションがブロックされます。なのでサイトAにログインするページはサイトBから返してもらう必要があります。サイトBは有効なセッションをもつユーザー（ブラウザー）に対してサイトAの認証を代行します。認証OKの場合はトークンを返します。トークンはサイトAから提供された秘密台帳による署名付きです。

ログインページはブラウザーのリダイレクション機能を使って直ちにサイトAにアクセスします。認証トークンはサイトAの秘密台帳で検証されログインが成立、ユーザーはサイトAの提供するオプション機能を利用できるようになります。

さて同じことをコンシューマ向けサービスで出来るでしょうか？サイトBを Facebook 、サイトA を転職情報サイトとでもしましょう。Facebookにログインしているユーザーが転職情報サイトのバナー広告をみてクリックします。しかしここで引っ掛かります。サイトAへのログインページです。Facebookに自由にWebページを配置することはできません。このようなシーケンスになります。

いったん、ただのアンカーリンクでサイトAのページを表示します（ページ要求）。そのページはサイトB（ Facebook ）にリダイレクし認証トークンを受け取ります（ 認証要求(1) ）。ブラウザーは再度リダイレクしサイトAに認証要求(2)、めでたくログインとなります。
１．サイトBページ→サイトA（バナー広告のクリック）
２．サイトAページ→サイトB（リダイレクション、認証要求、トークン発行）
３．サイトBページ→サイトA（リダイレクション、認証トークン検証、ログイン成立）
４．サイトAページ

これが本来のOAuthの流れなのですが、業務系の場合は１と２をセットで行い、３へ行くことができます。被認証サイトへのログインページを認証サイトに配置できるとシーケンスを簡略化、認証処理の開発、テストも簡素化できます。高品質、安定稼働で安上がりです。業務サービス、企業向けクラウドの場合はこれが可能です。ちょっとしたことなのですが一考の価値ありです。

もう一つ。これはどうでしょう？

先に結論を言うとクロスサイトスクリプティングなので、そのままでは動きません（動いてはいけません）。サイトAのセッションの間にあるサイトBとのセッション（Javascriptで張られたセッション）が、サイトA以外にトークンを渡しうるからです。サイトCもしくは別のユーザーからこのトークンで認証要求されてもサイトAにはわかりません。なりすましでサイトAにログインできます。

postMessage による制限つきの処理も可能ではあるのですが、リダイレクションのような安全かつ一般的な手法を採用しない理由を説明できません。一見構成も簡単なのですが postMessage は特殊なケースに限定されると思います。
ITの世界は流行り、廃りが速いので変化にロバストであるよう、一般的な要素でシステムを構成、簡素化するよう心がけています。寿命の長いシステムはエンジニアの誇りです。ユースケースに応じた簡素な設計、費用対効果の高いシステムほど長持ちです。

永島志津夫

全社のシステムを少ない人数で見ていれば時に見落としもあるかもしれません。

オフィスエヌ ショートレビュー5万円から。

連絡先 office.nagasima#gmail.com (#を@に変えてメールをお願い致します）