素朴な疑問なんだが、みんなメールサーバはどうしているのだろう?

素朴な疑問なんだが、みんなメールサーバはどうしているのだろう?

メールアカウントのパスワード漏洩などといったインシデントに備えるなら、認証ログの監査は絶対に必要になると思うのだが、認証回りのログを提供してくれるインターネットメール運用サービスが見当たらない。SMTPは無くもないけど、POP/IMAPの認証ログを公開してくれるところが本当に見当たらない。国内向けサービスだとカゴヤジャパンとGMail、Office365ぐらいしか見つけられないんだけど、みんなどうしているの?

実はみんなGMailやOffice365に移行済みだったりする?
実はカゴヤジャパンは隠れた独占企業だったりする?
実はメールサーバぐらい自前で完璧に運用できて当然だったりする?
実は何処の会社もPOP/IMAPは塞いでてWEBメール以外使っていなかったり・・・いやいや、POP/IMAP無効なんてオプションサービスも、殆ど見かけないぞ。

Excelのパスワードを解除する方法

Excelのパスワードを解除する裏技を求めて、当WEBに来る方が少なくない。 「ブックの保護を強制的に解除する」は保護をすることで安全に隠せている気になっている記事への警告の意味で書いたので、パスワードが分からなくて困っている人へと補足情報を載せておこうと思う。

避けては通れない法律的な話し

まず法律的なことを覚えておいて欲しい。

何らかの方法でパスワードを調べたり、調べたパスワードを保管したりする行為は「不正アクセス行為の禁止等に関する法律」に抵触し、刑事罰の対象となる。例えファイルの中味を閲覧しなかったとしても、パスワードを調べたり、保管しているだけで処罰の対象となる。

裏技などを使ってパスワード(技術的利用制限手段)を迂回したりする行為は「著作権法」に抵触し、これまた刑事罰の対象となる。 著作権侵害の多くは親告罪だが、技術的利用制限手段の回避は非親告罪となる。

また裏技をつかってパスワード (技術的利用制限手段) を迂回するためのツールを提供する行為は「不正競争防止法」に抵触する。平成30年からはツールを提供するだけではなく、依頼を受けて役務を提供する事も処罰の対象となる。

以上のような法律があるので、いくら探しても「パスワードを解除して欲しい」という依頼を受けてくれる人は見つからない。Excelのファイルを解析してパスワードを解除するようなツールも見つからない。仮に技術的かつ予算的に可能であっても、家族や親友からの依頼でも無い限り、リスクが大きすぎて受けられないのだ。

とはいえ、パスワードが分からなくて途方に暮れている様もよく分かる。解決方法はただひとつしかない。技術的な知識と、法律的な知識を自ら身につけ、自らの手で作業するしかないのだ。

裏技による迂回方法

ブックやシートの保護パスワードや、VBAのソースコード閲覧パスワードなどは裏技的な方法で解除できる。実際に解除する方法は「Excel の各種パスワードを突破する方法まとめ」に良くまとまっている。新たに追記することはしない。

読み取りパスワードの解除

読み取りパスワードだけは総当たりで解除するしかない。だが、辞書に載っているような単語だけであるとか、あるいは6~7文字程度のパスワードであれば、解除できなくもない。

パスワードの解析によく使われるのは「John the Ripper password cracker」と言うツールだ。

私の使っている20万程度のパソコンでもGPUを使うと3,000パスフレーズ/秒程度のスピードで解析を進めてくれる。英数だけで構成される5文字程度のパスワードなら、最悪でも60時間程度で解析が終わる計算になる。辞書に載っているような単語、十万語程度を対象とするならば、数分で終わってしまう。

最高スペックのGPUを使うなら1桁程度は早くなる。IaaSで高速なサーバを複数台レンタルするなら2桁程度は早くなる 。6文字程度のパスワードなら総当たりでも 数日程度で 割り出すことが出来るし、そのために発生する費用は10万円にもみたない。

Postscript #1

そんな分けだからパスワードの分からなくなったファイルのことはキッパリと諦めて、ファイルをゼロから作り直すことを第一選択肢として考えたほうが良い。

Postscript #2

いまどき7文字程度のパスワードしか設定していないのは、実効性が無いので止めておいたほうが良い。無駄な仕事を増やしているだけに過ぎない。

Access Runtimeをインストールしようとしたら32bit版も64bit版もエラーになる

Access Runtime 2016 64bit版のインストールを行おうとすると「次の32ビットバージョンのOfficeプログラムががインストールされているため、64ビットバージョンのOfficeはインストールできません:Office 16 Click-to-Run Extensibility Component」とのエラーになる。

この環境は32bit版だったかと思い直し、 Access 2016 Runtime 32bit版のインストールを行おうとすると 「次の64ビットバージョンのOfficeプログラムががインストールされているため、32ビットバージョンのOfficeはインストールできません:Office 16 Click-to-Run Extensibility Component」とのエラーになる。

・・・どうしろとorz

Access Runtimeインストールの基本制約

Office 2016(2019にも)にはClick-to-Runインストール版 (以下C2R版) とMSIインストール版(以下MSI版)がある。ライセンス上はどちらをインストールしても構わないが、それぞれインストール方法が異なる。プレインストールの場合、昔はMSI版が多かったが、最近は C2R版が入って居ることが多い。そしてC2R版とMSI版には、それぞれ32bit版と64bit版がある。

Access RuntimeにもC2R 版とMSI版がある。C2R版はOffice 365 Access Runtimeと言う名称で、MSI版はAccess 2016 Runtime (ないし2019)と言う名称で提供されており、それぞれ32bit版と64bit版がある。

Access RuntimeをインストールするにはC2R版かMSI版か、32bit版か64bit版かの区分が完全に一致している必要がある。さらにMSI版の場合には2013と2016、2019は混在できないのでバージョンを統一する必要がある。

過去にプレインストール版が入っていた

当該環境はプレインストール版(C2R版)でインストールされていたため、アンインストールしてMSI版を入れ直していた。だが、どうもC2R版の残骸が残ってしまっているのが原因のようである。

アンインストールが完全に行われていないためにトラブルが発生することが度々あるようで、Microsoftのホームページに完全にアンインストールするための方法が書かれている。

PC から Office をアンインストールするの「オプション 2 – アンインストール サポート ツールを使用して Office を完全にアンインストールする」に従って、アンインストール補助用の実行プログラムをダウンロードして、実行することで残骸も含めて消せるようである。無論現在インストールされているMSI版も含めてアンインストールされてしまうのであろうけど・・・

余り褒められた話しではないが、作業時間も押してきているので、Access Runtime 2010のインストールでお茶を濁してしまった。でも恐らくは上記手順でOffice 2016の残骸を削除すればインストール出来るものと思われる。

TP-LinkのWiFi機器を使ってみた覚え書き

比較的安くて、法人向けの機能があって、障害発生時にも強そうなメッシュネットワーク対応のWiFi機器、TP-LinkのAC1200 MU-MIMO( EAP225-Outdoor )とか使ってみたので、これから買おうとする人のために覚え書き。

Omada Controler サーバー

メッシュネットワークを使うには Omada Controler をインストールしたサーバーを用意するか、 Omadaクラウドコントローラー (OC200 )を用意する必要がある。アクセスポイント単体ではメッシュネットーワーク機能を利用できない。(ただのアクセスポイントとして使う事は出来る)

TP-LinkのホームページからOmada Controlerが提供されており、これをWindowsかLinux(Ubuntu)にインストールすると、Omadaクラウドコントローラ相当の機能を使える。 OC200 はサーバーを設置できない場合の代替手段として 提供されているものなので、サーバーを用意できるならOC200を購入する必要はない。

Omada Controler は同一サブネット内に存在するOmada対応WiFi機器を自動的に検出してくれる。逆に言うとサブネットの外、ルーターを超えた場所にあるアクセスポイントは検出してくれない。ルーター超えて複数のサブネット内に存在するWiFi機器を検出するにはEAP Discovery Toolをインストールしたサーバー/パソコンを、それぞれのサブネット内に配置しておく必要がある。

わたしはUbuntu 18.04 LTS上にOmada Controlerをインストールしたが特筆することは何もない。導入自体は非常に単純で特筆すべき事が無い。sudo gdebiコマンドでダウンロードしたdebファイルからインストールした。デーモンとしては常駐しないのでログイン後にsudo /usr/bin/tpeap startとして起動する必要がある。

EAP225-Outdoor本体

EAP Discovery Toolを使ってIPアドレスを特定した後、アクセスポイントのWEB画面からログインして設定変更等を行う事も出来るが、 Omada Controlerを使うのであれば特に設定は必要ない。・・・と言うのもOmada Controler の制御下に入った時点で、パスワード以外はIPアドレスも含めて初期設定に戻ってしまうのだ。パスワード変更も含めた全ての設定はOmada Controler を経由して行う事になる。

あとはOmada ControlerのWEB画面から設定を行うだけである。独特の用語には全てToolTipで説明が表示されるので、本当に迷うことなく設定出来る。よく出来ている。

台湾製品だと電源周りが不安になるかと思うが、潔いというか電源はPoEのみとなっている。PoEから電源供給するためのACアダプタも同梱されているが、問題が起こったらサードパーティーのPoEユニットを使うという手もあるので、むしろ安心できる。

SOHO向けバックアップの在り方

RAID対応のNASにデータを集約する

もし各パソコンにデータを保有させていたり、パソコンをサーバー代わりに使っているなら、まずはRAID対応のNASを導入してデータを一箇所に集約する事をお勧めしたい。データが各パソコンに分散していると、バックアップにかかる手間もパソコンの台数分に発生する。またパソコンをサーバー代わりにしている場合、耐久性や信頼性の面でどうしても劣るからだ。

またRAIDを構成する場合には、以下の条件を満たさない限りRAID1以外・・・RAID0やRAIDO5、6、10を選択してはならない。
・24時間365日対応のオンサイト保守サービスを契約している
・1台のHDDでは実現できない容量のパーティションを必要としている、または1台のSSDでは実現できない速度を必要としている。

困ったことに一部のメーカーはRAID5やRAID6、時にはRAID10が高い信頼性と性能を誇るかのようにカタログに載せている。確かにRAID5やRAID6、RAID10なら信頼性を維持しつつ、性能を高める事が出来る。だが信頼性はRAID1と同程度、保守性の面ではRAID1より低下している。

またHDDではなくNASの本体が故障した場合には、RAID5やRAID6、RAID01を使用しているとデータの復旧が困難になる。ちょっとパソコンに詳しい程度ではお手上げだろう。専門のデータ復旧業者に依頼する必要があり、最短でも数日の時間と数十万円の費用を必要とする。RAID5やRAID6、RAID10を使うなら、24時間365日のオンサイト保守サービスを契約していて、直ぐに本体を修理して貰える事が必須要件となる。

これがRAID1なら適当にパソコンにLinuxをインストールしてNASから取り出したHDDを接続すればデータを取り出せる可能性が高い。ちょっとパソコンに詳しい人なら自力でもデータを取り出せる。

NASのデータをクラウドにバックアップ

画像や動画などの大容量のデータについては、AWSやAzureといったクラウドのオンラインストレージにデータをバックアップすることをお勧めしたい。最近のNASであれば、クラウド上にデータをバックアップする機能を提供していることが多い。容量単価を考えた場合、Google DriveやOne Driveの容量単価に比較して、AWSやAzureのオンラインストレージの方がはるかに安上がりになる。

小さいデータならOffice365やGSuiteを活用

比較的容量の小さいWordやExcelのファイルなら、Office365やGSuiteの有料プランを購入することをお勧めしたい。独自ドメインのメールサーバとして使ったり、取引先との大容量ファイルの交換に使ったりと、使用する範囲は広い。それらを個別に用意することを考えたなら、有料プランを契約しても、そう高い買い物ではないはずだ。

ちなみにOffice365やGSuite等のクラウド上においたデータをマスターとするなら、逆にクラウドからHDD等に定期的なバックアップをしておくことを忘れないように気を付けたい。クラウドサービス事業者側の事故でデータが失われることも、皆無ではない。また障害により一時的に利用できなくなることもある。業務を止めないためには、手元にもデータの複製を置いておくことを忘れないようにしよう。

個人向けのバックアップのあり方

台風で多くの水害が発生した。

災害の発生の度に憤りを覚えるのは、多くのユーザーがバックアップをとれていない事だ。

バックアップには以下の三要素を満たしていることが望ましい。

1.通常の利用権限で上書きされない。
2.遠隔地に保管されている。
3.最新版だけではなく、過去の履歴も保管されている。

以前は個人でこれを満たすのは相応にコストが発生していたが、今はクラウドサービスのおかげで、ほぼ無料で実現できる。

・Google PhotoやAmazon Photoの活用

Google Photoは16メガピクセルまで(動画はフルHDまで)と画像サイズの制限があるが、私的な利用には十分な品質の画像のはずだ。無料で容量無制限にクラウド上に画像データをバックアップすることが出来る。
Amazon Photoはプライム会員になっていれば容量無制限で写真データをアップロードできる。
またファイル名が同じでも内容が異なっていれば別のファイルとして扱われる。ランサムウェアなどによってファイルが壊されていたとしても、クラウド上のファイルが上書きされてしまうことを心配する必要はない。

・Google DriveやOne Driveの活用

私的な利用なら写真や動画を除けば容量はそれほど大きくならないと思われる。Google DriveやOne Driveの無料枠であっても、そうそう容量を使い果たすことはないはずだ。仮に容量を使い果たすようならば、素直に有料プランに移行するのが良いように思う。
こちらもファイルが更新される毎に、更新前のファイルは別に保管されている。したがってランサムウェアなどによってファイルを壊されても、壊される以前のファイルを得ることが出来る。
GoogleDriveならファイルを選択して「版を管理」を選択すれば、最新版に更新される以前のファイルをたどることが出来る。OneDriveも「バージョン履歴」という機能で、同様のことが出来る。

いずれも日々のバックアップ操作を意識することは少ない。専用のアプリをインストールしておけば、バックグラウンドで処理を実施してくれる。

災害に限らず、故障やランサムウェアへの感染などによりデータを読み出せなくなる危険は常に存在している。最低限度のバックアップはリテラシーとして身に着けてほしい。

DELLのセキュリティー事件簿

元記事:実態調査が示すセキュリティー事故の最新動向

DELLのもうちょっと良い事例は無かったのだろうか?
インシデント(セキュリティー事故)が発生するのは仕方ないにしても、あまりにも稚拙な対策が混じっていて失笑を禁じ得ない。

CASE1、CASE2・倫理観低下が招いた事故

論理感等という曖昧なものに原因を求めてはならない。分からない言語のメールだからそれを無視したり、業務効率向上の為のチャットソフト利用を拒絶する事が、論理感の高い行動とは言わないだろう。

根本的な原因は、恐らくはリスクのある外部サービス利用に対する過度な制限や、外部サービス利用承認プロセスの不備、ネットワーク利用状況の監視体制の不備にあると推測する。下手な利用制限がかかっていなければメジャーな翻訳サイトを避けて稚拙な翻訳サイトを使ったり、適切な監視がなされていればチャットソフトの利用に気がつかないと言うことはないからだ。

制限、許可、監視のバランスがとれていないことが根本の原因にあるなかで、制限だけを増やすのは問題の解決には至らない。制限を回避する新たな方法を編み出すようになり、従業員との信頼関係が損なわれる結果が目に見える。

CASE3・CASE4・ランサムウェアに感染

そもそもバックアップを取れていないことが致命的に問題だ。バックアップがとれていればデータが失われても1日分程度の話しであり、データを失うと言う致命的事態には陥らない。バックアップは一般ユーザーの権限ではアクセス出来ない(最低限で書き込めない)場所に、過去4~5日分(気がついたときには上書きされていたら意味が無いので、夏期休業などの最長休業期間より長い日数分)をバックアップしていれば良い。

標的型メールを模倣する訓練において開封率の低下を目指すことに意味は無い。本来なら開封した場合のエスカレーションが確実に行われることや、開封によって感染したことをセキュリティ監視チームが発見できる事が重要になる。なぜなら100人中1人でも開封すれば被害に繋がるし、またどんなに訓練を重ねたところで、文面などから完璧に不正なメールを判断するのは不可能に近いからだ。

CASE6・CASE7・基本的な対策を怠った

CASE6のすべてのPCのOSを最新に するのは確かに必要な処置だろう。だが起こった問題「商談情報を撮影して個人のPCにメールで送ったりしていた」に対する対策としては「機密情報の撮影を禁止」と言うルールを設けただけである。いかにルールを作っても、ルールが守られていることを監視監督する等の運用面が苫なわなければ、仕事のためにルールを無視する事が必ず起こる。

CASE6の根本的な原因は、メールの送信先や送信元に対する監視が機能していない事にある。個人で取得していると思われるメールに対する送信だけでも監視していたなら、問題が発生する前に警告する事が出来たはずだ。

CASE7についてはログが無い以上、今後調査が進展する可能性もない。「漏洩した情報を特定できない」という報告をする以外にない。

セキュリティ上、クラウドサービスを業務に使ってはならないとき・・・

「オンプレミスに比較して、クラウドはセキュリティが心配・・・」と言うユーザーに対して「クラウドベンダーと御社とどっちのセキュリティが上だと思ってるの?」というのは昔から良く話しとして見かける。実はクラウドサービスのセキュリティで気をつけるべき視点がひとつある。インシデント発生時に速やかな対応が可能か否かだ。

一流のクラウドベンダーならユーザー側に起因するインシデント発生時の対応も考慮されている。だが、二流三流のクラウドベンダーとなるとかなり怪しい。ユーザー側の原因でインシデントが発生した時に、影響範囲特定に必要なログ等の提供を受けられない可能性がかなり高い。例えば以下のシナリオのような状況が考えられる。

インシデントシナリオ#1
自社のWEBサービスがSQLインジェクション攻撃を受けた。この場合は影響範囲の調査にデータベースサーバの監査ログが重要な役割を果たす。もしこの時、ベンダーの提供するデータベースが他のユーザー企業とインスタンスを共有している場合、監査ログには他のユーザー企業の発行するSQL文まで含まれてしまう。ベンダー企業が監査ログをユーザー企業ごとに分割するような対策を事前に取ってない限り、迅速な対応は期待できない。

インシデントシナリオ#2
メールアカウントのユーザーIDとパスワードが漏洩して第三者が閲覧した可能性がある。この場合にはメールサーバーの認証ログを閲覧して、不自然なな時間帯や接続元からの認証、認証エラーの有無を確認したい。もしこの時、ベンダーの提供するデータベースが他のユーザー企業とインスタンスを共有している場合、そこには他のユーザー企業のログも含まれている。さらには通信事業者には通信の秘密を守る義務が課せられている。通信時間帯や接続元IPアドレスは通信の秘密に含まれるため、頑なに開示してもらえない可能性がある。こうなると被害届をだして事件化しないと、影響範囲の特定も出来なくなってしまう。

無論、きちんとしたベンダーは回答を用意している。AWS AuroraDBやSQL Azureには監査ログの機能がある。オブジェクトストレージのS3はアクセスログを提供している。GSuiteやOffice365も認証ログを提供している。

対して国内ベンダーに目を向けると、大手ベンダーでもその辺りがかなり弱い。

例えばさくらインターネットがS3互換としているオブジェクトストレージにはアクセスログの機能が無い。

あるいはNTT Communicationのメールホスティングサービスにはメールの送信ログに対する検索機能はあるが、認証ログの提供はない。法的な問題もあるので提供が難しいのは分かるが、せめて認証成功のログ程度はないとインシデント発生時に対応出来ない。

ベンダーの多くは電気通信事業者として「通信の秘密」に関する義務をおっている。何時何処と通信をおこなったかは「通信の秘密」に含まれるため、電気通信事業者としては安易にログを開示する事は出来ない。ユーザー企業に公開できるのは、ユーザー企業の管理下にあるシステムのログだけになるが、事前に準備を整えていない限り共有部分のログ提供には時間がかかる。

クラウドサービスを採用するにあたっては、セキュリティ監査に耐えるだけのログ出力機能があるか否かは確認した方が良い。もしそれらのログ出力機能が無く、インシデント発生時に相応の対応が必要なら、契約に調査対応への協力義務を盛り込む程度のことは検討しなてくはならない。

※クラウドベンダーの対応状況は2019年9月時点のもの

Linux上のClosedXMLで画像データを扱うときにSystem.DllNotFoundExceptionが発生する

Linux(Ubuntu 18.04)環境に.NET Core SDK 2.2をインストールし、ClosedXmlで画像を含むExcelファイルを扱おうとしたところ、下記の様な例外が発生して実行出来ません。

System.TypeInitializationException: The type initializer for 'Gdip' threw an exception. ---> System.DllNotFoundException: Unable to load shared library 'libdl' or one of its dependencies. In order to help diagnose loading problems, consider setting th
 e LD_DEBUG environment variable: liblibdl: cannot open shared object file: No such file or directory at Interop.Libdl.dlopen(String fileName, Int32 flag)
     at System.Drawing.SafeNativeMethods.Gdip.LoadNativeLibrary()
     at System.Drawing.SafeNativeMethods.Gdip..cctor()
     --- End of inner exception stack trace ---
     at System.Drawing.SafeNativeMethods.Gdip.GdipLoadImageFromDelegate_linux(StreamGetHeaderDelegate getHeader, StreamGetBytesDelegate getBytes, StreamPutBytesDelegate putBytes, StreamSeekDelegate doSeek, StreamCloseDelegate close, StreamSizeDelegate size, IntPtr& image)
     at System.Drawing.Image.InitFromStream(Stream stream)
     at ClosedXML.Excel.Drawings.XLPicture..ctor(IXLWorksheet worksheet, Stream stream)
     at ClosedXML.Excel.Drawings.XLPictures.Add(Stream stream)
     at ClosedXML.Excel.XLWorkbook.LoadDrawings(WorksheetPart wsPart, IXLWorksheet ws)
     at ClosedXML.Excel.XLWorkbook.LoadSpreadsheetDocument(SpreadsheetDocument dSpreadsheet)
     at ClosedXML.Excel.XLWorkbook.LoadSheets(Stream stream)

.NET Core Runtimeインストール時に依存関係が処理されていないことが原因です。下記のコマンドを実行してGDI+関連のライブラリをインストールすると解決します。

sudo apt install libc6-dev 
sudo apt install libgdiplus
cd /usr/lib
sudo ln -s <a rel="noreferrer noopener" target="_blank" href="http://libgdiplus.so/">libgdiplus.so</a> gdiplus.dll

環境によってはLD_LIBRARY_PATHの設定も必要になるようです。

ASP.NET COREを使ったWEBサービス作成(習作)

習作としてASP.NET COREを使用したWEBサービスを作成してみた。
もちろんLinux(Ubuntu 18.04)上で動作している。

Excelファイルをアップロードすると、適当な文字列部分をバーコード画像に置き換えてくれる。

https://barcode.code-lab.net/