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月時点のもの