  |
はてなキーワード: マルウェアとは
こんなニュースが流れている。
個人的にだが、AndroidもiPhoneも使っている俺としては、Androidのこういった大きな穴は非常に不満がある。
iPhoneはどうかというと、こっちは厳しすぎるのでセキュリティはしっかりしているが融通が利かない。
どちらも一長一短だが安心して利用するという考えならば、やはりiPhoneを選ぶのが正解なんだろう。
ただし価格で言ったら、間違いなくAndroidが正解なのだが。
この系統の話題で多いのが、Android派とiPhone派の醜い争いだ。
こういうセキュリティなんかで問題が発生すると必ずといっていいほどに、片方がもう片方を貶しはじめる。
どちらにも短所が存在する以上、優劣を比べたところでどんぐりの背比べみたいなものだというのに。
この手のやりとりの正解は、こういう諍いを起こすような輩の言葉に耳を貸さず、自分の使いたいスマホを使えという話だ。
ライトなコンピュータユーザを一切合切無視してギークがギークのため情報共有するためのエントリ。
感想ははてブへ、質問はトラバに投げれば誰かが答えるんじゃないか？(他力本願)
セキュリティの懸念があるけれど通常モードはセキュアを維持するため機能制限があるので制限開放のため開発者は初手でデベロッパーモードにするしかない。
利用途中でデベロッパーモードにするとストレージがファクトリーリセットされるので注意。
Webでエンタメを楽しんだりWebツールを中心に利用するのであれば、5万円未満の低性能機で必要十分。
この用途では実質的にタブレットPCのような運用へなりやすいのでフリップする2 in 1機やタブレット機がオススメ。
ただし、Webベースのゲームは楽しめるがAndroid Appレイヤーを用いたゲームは非常に厳しいので諦めたほうが良く、そこそこの負荷の掛かるAndroid Appツールも鈍足でストレスになるのでWeb版があるならそっちを使ったほうが良い。
Core i7クラスのCPUや16GB以上のワーキングメモリ、SSDストレージなど高性能機でChromeOSを使うとその分だけ快適になる。
Android Appレイヤーを用いたゲームも快適に動き、ウマ娘クラスの3DCGなAndroid Appゲームも高速に動く。
しかし、高性能機は空冷ファンを搭載していることが多く、高負荷を掛ければファンは唸るしウルサイ。
Google Play StoreにてAABパッケージがほぼ強制になったとは言え、開発段階でx86_64を意識しないと処理が非効率になりがちのようなので、Android Appレイヤーを中心に運用したいと思っているのであれば素直にARM機を探してきたほうが良い。
1つのIDEで開発をしクロスプラットフォーム対応することが流行っている昨今、自動でガベコレに頼っていてリソース管理経験に乏しい開発者はマジで底辺にしか漂流できないので覚えたほうが良いぞ。
それがWeb系のフロントエンドでもバックエンドでもそうだから底辺から脱したいのであれば覚えろ。
しっかりリソース管理できているChromebook向けビルドはアーキテクチャによらずサクサクなのでクロスプラットフォームなビルドはマジで開発チームの腕が如実に反映される。
ちなみにSnapdragon 8 Gen1なChromebookの公式発表は今のとこ無いのでAndroid Appレイヤーをブンブン回すのは難しい。
メーカーはもうちょっと頑張れ。
Chromebookの大半はタッチスクリーンディスプレイを搭載しているし、Android StudioでAndroidManifest.xmlを何も考えずに生成すると勝手にChromeOSをサポートするので結果的にChromeOSで動くAndroid App数が多くなるという現象が起きている。
Android Studioが雑なのかXcodeが厳密なのかは意見が分かれると思うけど、タッチパッドでiOS App操作というセンスがクソなのは万人が納得するところだと思う。
ARM系のSoCであればワンチャンいける可能性はあるものの、市場に出ているChromebookの大半はx86_64でGPSモジュールを積んでいないのでGPSを使おうと思うとBluetoothあたりでGPSレシーバを接続するしか無い。
当然A-GPSは使えないので精度がそこまでではないから期待し過ぎに注意。
Android AppレイヤーではUSB over MIDIが使えるのでDTMあたりに活用することは可能なものの、iOSと比較してレイテンシがそこそこ大きくDTMに活用しようと思うユーザは不満を持ってしまうかも知れない(ハードにもよるけど0.5msecくらいズレる)。
そもそも既存のAndroid AppなDAWはVSTやLV2などの外部プラグインに対応していないのでAUプラグインが使えるiOSのほうがDTMへ向くんじゃないだろうか？
ただし、DAW単体でDTMを完結するとレイテンシはほとんど気にならなくなるので絶対にAndroid AppでDTMが不可能というわけでもない。
Linuxレイヤー側でDTMをするのはレイテンシが大きすぎるしJackも上手く動作しないのでオススメできない。
ChromeOS向けマルチタスクへ対応していないとAndroid Appはフロントエンド(プライマリ)からフォーカスが外れてバックエンドへ行くとスリープする。
Android Appがスリープされることを考慮しておらず例外処理がされていないとAndroid Appはそのまま落ちる。
まぁAndroid Appがスリープされることを考慮しておらず例外処理がされていないとAndroid Appはそのまま落ちるっていう部分はAndroidスマホで実行しても同じなので正直に言ってスリープされることを考慮しないデバックってAndroid App開発者は何やってんの？とは思う。
ICT教育で日本中の学生がChromeOSを使うようになっているので、ゲームであれツールであれ何であれChromeOS向けのマルチタスクは考慮しておくとスリープしたり落ちたりするAndroid Appよりも支持されるのは間違いないのではないか。
LXC/LXDなのでDockerに慣れ親しんでる人にはわかりやすいかも？
デフォルトのイメージはChromeOS向けにカスタムされたDebian。
別のLinuxディストリビューションへ置き換えることも出来るが一部機能が制限される可能性がある。
ChromeOSで動作するGoogle日本語入力とは別にLinuxレイヤー側で日本語入力を用意する必要がある。
選択できるIMは幅広いのでMozcだろうがSKKだろうが漢直だろうが何でもイケる。
ただ特殊なものを選ぶとChromeOS側と齟齬が発生するのでfcitx-mozcあたりが無難っちゃ無難。
ChromeOSへマウントされたUSB機器、というかシリアル接続された機器はLinuxレイヤー上から認識しない。
見掛け上で接続されているハードのすべてはソフトで仮想接続されているだけなので、一部経路から上手く認識しなかったりする。
つまりLinuxレイヤーではUSB Pass Throughが使えないが、Android AppレイヤーではUSB Pass Throughが使えるということ。
Linuxレイヤーでゲームやろうと思ってもUSBゲームパッド動かないのでマウスとキーボードで完結できるFPSみたいなゲームしか上手くプレイできないぞ。
言うなればAndroid Appレイヤーでスクリーンキャプチャ系のアプリによってLinuxレイヤーで動くGUIアプリをキャプチャしようと思ってもキャプチャできず撮像は暗転している。
ChromeOSがホストでLinuxレイヤーとAndroid Appレイヤーはゲストなのでそりゃそうなんだけど気付かないとハマる。
LXC/LXD on LXC/LXDになるので面倒くさくなること請け合いだ。
どうしても仮想環境がChromebookに欲しいのであればKVMとかのほうが安定している。
ただしゲストOS上へ仮想環境を構築しているという前提は認識しておくべき。
つまりゲストOSの制限はKVMも引き継ぐ。
ただしこれはDockerが導入できないという意味ではない。
自分で解決する気概があるのならばDockerは便利に使える。
CLIツール系は普通に動くのでWeb開発であれば何も意識しないで普通にできる。
ただ、PSD形式みたいなもんは扱いにくいのでWebデザイナーは悲しい思いをするかも知れない。
GIMPやInkscapeなども動くけれどデザイナーはAdobe使いたいんじゃなかろうか？
Android App向けIDEのAndroid StudioはChromeOS向けが存在するのでAndorid App開発が可能。
しかしデベロッパーモードでなければエミュレータや実機デバックに制限が発生するので注意。
UnityやUEを使いたいところだけれど、Linux版のUnityやUEは不安定なのでゲーム向けIDEが欲しいのであればGodotがオススメだ。
ライセンスはMITなので商用利用だってイケる。
3Dのほか2Dゲームもいける上に、最近のIDEよろしくマウスでポチポチとUIを作れるし、軽量動作、物理演算、日本語ドキュメントまで揃っているので中高生もガンガン使える素晴らしいIDEだ。
浅い部分を触っているうちはYoutubeを観たり、プリインストールされているGoogle Play StoreからAndoird Appをインストールして使うみたいな気軽な運用ができる。
言ってしまえばライトユーザの視点ではノートパソコンの形をしたAndorid機がChromebookだと言える。
しかし一度Linuxレイヤーへ手を出すとUbuntuという何でもできるようになったLinuxディストリビューションが存在する中で、昔懐かしい複雑怪奇なLinuxディストリビューションを体験することとなってしまう。
ただ、Chromebookで何でもやろうとするからそうなるだけで、APTからIDEをインストールしてちょっとした開発をするなんて使い方であるならば業務利用でも意外となんとかなる・・・というか何も意識しないで使える。
そもそもHTTP使えるなら今どきの開発は何とかなるので、Chromebookへ対してギークがゴチャゴチャ言うのはほぼ間違いなく不満を言いつつDIYを楽しんでる。
Ubuhtuならばアレができるコレができると言うならば最初からUbuntu使えよって話。
ギークとは不便を見つけてゴチャゴチャ言う、そういう鳴き声の動物なのだ。
少なくともGoogle系エコシステムとしてのChromeOSは非常に完成度が高くなりつつある。
Googleアシスタントは元よりAndoridスマホとの連携もよく、ハードウェアへもそこそこの投資ができるのであれば多くのChromebookではUSIペンが使えるし、USBポートはUSB-Cだ。
そこそこのChromebookは多くの場合HiDPIなIPS液晶でありグレアなのは気に食わないが美しい。
デベロッパーモードにするとセキュアさは下がるが普通に使えばローリングリリースのアップデートを無償で得られ、Gentoo LinuxベースなChromeOSは潜在的なマルウェアの絶対数がそもそもWindowsやMacよりも少ないという利点がある。
Bluetoothイヤホン・ヘッドフォン・ヘッドセットも使えるし、NestスピーカーやNest Hub、Nest Camを持っているのであればGoogleアシスタントからのコントロールが容易なのは想像が付くだろう。Android AppレイヤーはGoogleのホームマネジメントアプリであるGoogle Homeも動く。
大胆にも憎きCapsLockキーをデフォルトで殺し、Everything Buttonキーとして独自キーバインドを与えたのも面白い。
もちろんこれは選択するハードによるものの指紋認証でロックを解除することまでできる。
Googleエコシステムへ浸かっていてGoogleへ個人情報を捧げられるのであればChromebookはアリな選択肢だと断言できる。
敢えて欠点を挙げるのならば、たった一言で欠点を表現することが可能だ。
「Chromebookじゃなくても別に良くね？」
そう、ギークがLinuxを使いたいのであれば別にChromebookじゃなくても良い。
というかギークは別にLinuxじゃなくともHaikuであろうが超漢字Ⅴだろうが喜ぶ生き物だ。OSは別になんだって良い。
このエントリは単にChromebookという新しい沼へギークの皆さんをご案内しているに過ぎないのだ。
＜はじめに＞
読みにくいと題に書きました。この文章を読んだあなたが不快になったとしてもそれは注意書きを読んだ上であなたがあなたの判断によってあなたが読んだ文章によってあなたが不快になったにすぎず、それは完全にあなたの自己責任です。祈りが足りません。毎日もっともっと祈ってください。
＜はじめにおわり＞
ブログを開設して投稿しても良かったのですが、増田で投稿したほうが興味のある人に少しでも多く届くかなと思い増田で投稿することにしました。
先日、TwitterがOnion版サイトに対応したと風のうわさに囁かれました。
https[:]//twitter3e4tixl4xyajtrzo62zg5vztmjuricljdp2c5kshju4avyoid.onion
これがそのURLです。（Chrome、Safari、Edge、インストールした後そのままつかているFirefox、では閲覧することができません。諦めてください）
おそらくTwitter社が想定しているケースは
①何らかの理由によって、Twitterへのアクセスがエラーを吐くようになった。（生IPでのアク禁）
②ユーザーは長年使用してきたTwitterアカウントにログインして情報を得たい、情報を投稿したい。
みたいな意図なのではないかと勝手に想定しています。が、これはあくまで一民間人の主観なので流してください。
①への対策としてVPNが挙げられますが、プライバシー保護を謳う幾多のVPNがこれまで国家権力に屈してログ情報を開示してきた例を見ると（すべてがすべてノーログを謳っていたわけではない）、そこらのVPN会社を利用するよりもTorで多重化した方が少しは安心ではないかという気持ちからTwitter社がOnion版サイトを公開してくれたとしたら、嬉しいことです。
＜本題＞
・個人的に今利用しているアカウントにTorでログインするのは嫌なので、新規登録ができるかどうかを確認する（気になる人は既存アカウントで実験してみてください）
・Tor等を利用したTwitterアカウント作成時との比較を観察する
Torから設定→プライバシーとセキュリティ→セキュリティ（セキュリティレベル）を選び、Torでボタン一つで選択することのできるJavaScript等のトラッキング制限をどの程度選択すればアカウント作成できるかを確認します。
より安全（真ん中のレベル）：アカウント作成できない（自分が確認した環境ではできないだけかもしれません、詳しくは後で記します）
最も安全（３段階で一番上のレベル）：相変わらずいつも通りアカウント作成できない
アカウントを作成した感想としては、正直Onion版サイトを公開したと聞いたときには、他所のOnion版サイトのように「最も安全」でアクセス先のURLに依存したJavaScriptをいくつか許可すればアカウント作成できるのかな、と期待を胸にしていたのですが、現実としては「いつもどおりのhttps[:]//twitter.comへTorを用いてアカウントを作成するとき」と何一つとして変わる点がありませんでした。これには少しがっかりです。
Torを用いてTwitterアカウントを作成するとだいたい1ツイートまではTwitter社の宇宙よりも大きな器によって許されます。
しかし、2ツイート目をしようものなら、時間をかけてアイコンやBIO、ヘッダーを設定しようものなら「reCAPTCHAのパチモンクリア（4問正解で通してくれる神キャプチャ、お前が世界を取れ）」がやってきます。
運が良ければそのまま関門通過。運が悪ければ電話番号登録を強いられます。
今回はセキュリティの「標準」でアカウントを作成したので、ログイン後1ツイートをした後に「より安全」に上げても使えるかな？と上げてプロフィール設定をしているところで電話番号登録を要求されました。
ここ最近のhttps[:]//twitter.comは、ブラウザのセキュリティレベルを「最も安全」「より安全」にしていると「んなんか今日調子悪いわ笑」とログインページやアカウント作成ページを表示しれくれません（国際情勢が関係しているのかな？）。ですが、以前は上で書いた「他所のOnion版サイトのように『最も安全』でアクセス先のURLに依存したJavaScriptをいくつか許可すればアカウント作成できるのかな」の手順でアカウント作成をできた過去があります（セキュリティレベルを上げ忘れたままTorを利用していた可能性があります、「ですが」以降は思い出として読んでください）。
その時ですら電話番号登録まで要求してこなかったというのに、セキュリティレベルを最低まで落として、やっとアカウント作成できたと思ったら、「お前はホモサピエンスか？」とパチモンに聞かれ、全問正解したというのに電話番号まで登録を強いられる。ダルいのでこの文章は放置されている電話番号登録画面を横目に書かれています。
実験結果
ブラウザのセキュリティレベルを最低まで落とすことでアカウントの作成に成功したが、セキュリティレベルを上げて遊んでいたら（これが原因では？？？）電話番号登録を強いられた。
この実験結果からわかるように、新規アカウントへの優遇としてOnion版サイトを公開したとはとても思えず、既存ユーザーに向けたサービス展開と見るべきだと思う。
まず今回やったことはOnion版サイトで行わなくても、https[:]//twitter.comで再現可能だったことであり、2者の差はOnionに対応しているか否かでしかありません（緩くあってほしかった）。
生IPでアクセスできないからTor使うのにそこで電話番号登録を要求したら、電話番号を契約している本人が分かりますよね。
Onion版サイトの展開がどこの誰のためにやっているのか知ったことではないですが（良い子のみんなはソースを探してから口を開こう）、向いている方向とやっていることが少しズレている気がします。
「理不尽な事象により生IPでアク禁された人々がいる、それに対抗するためにOnion版サイトを公開する、がOnion版からであってもアカウント作成はいつもどおりです。」だと仮定すると、現状は今のTwitterが落とし込めるギリギリなのかもしれません。
TwitterくんがFacebookくんに憧れる気持ちはよく分かりますが、Tor関連を冷遇するのところまでしっかり見習わなくても良かったと思います。
腹癒せ
「Onion版サイト公開されたんですか？やったー！」「サイト公開されただけじゃないですかやだー！（少しは優遇されただろうと勝手に思っていた筆者が完全に悪い）」をしたので、初めの方に少し書いたVPNについて少し。ノーログを謳うおすすめの紹介です。VPNを使ってたとしても、画面の向こうにいる人間に配慮しながらインターネットを利用しましょう。もうページを閉じてインターネットに帰っていいですよ。帰りの会は終わりました、事務連絡は済ませたのでここからは雑談です。
Mullvad（有料）
一言：広告を一切していないので、検索して出てくるMullvadの感想はPRを含みません。すげぇ
IVPN（有料）
一言：他所のノーログを謳うVPNサービスは月当たりの通信量の制限があったりしますが、ProtonVPNにはそれがない。そこがすごい。本当にすごい。無料で始めたかったらProtonを使ってください。
OVPN（有料）
一言：2月から#StandWithUkraine https://www.ovpn.com/en/blog/standwithukraine というページを公開し、ウクライナの人への応援をしている。すごい。「ウクライナ人はサポートに連絡したら無料のVPNが用意してあるぞ」と言ってる。かっこいい、抱いてほしい。それはそれとしてOpenvpnの拡張子が.ovpnだから検索結果がOVPNとめっちゃ交じる。マジ卍
個人的には薦めないけれど、生IPよりかは良いんじゃないんですか、有名で使っている人も結構いますよね、好きだったら使えばいいと思います4選（それぞれノーログを謳っています）
NordVPN（有料）
一言：有名、紹介料いくらか知らんけどプライバシー特化おすすめVPN○選！みたいな記事ではいつもいるやつ。ちなみにそいういう記事に限って上の4選の奴らはいません。
一言：買収されて運営会社が変わった。NordVPNを紹介している記事は大体ExpressVPNも紹介している感じのアレ。
PIA（有料）
https[:]//www.privateinternetaccess.com
一言：ﾟ(ﾟ´ω`ﾟ)ﾟ｡ﾋﾟｰア 日本人ではNordとExpressよりは使っている人は少ないんじゃないかな。
AirVPN（有料）
最後に
https://gigazine.net/news/20211015-former-malware-kape-technologies-owns-vpn-services/
家電のシャープがIT業界に進出したってのも驚きだが、いまさら境界セキュリティってのも驚いた。
シャープ株式会社は、攻撃トラフィックを検知・遮断する機能を備えたセキュリティスイッチ「BP-X1PL01」を、1月下旬に発売する。価格はオープン。
BP-X1PL01は、社内のネットワークに侵入したマルウェアなどによる攻撃を遮断し、被害の拡大を抑制するセキュリティスイッチ。社内ネットワークの監視を常時行い、マルウェアなどによるサイバー攻撃を検知すると、発信元の端末をすばやく特定して有害な通信のみをネットワークから遮断する仕組みを備えているため、被害の拡大を抑制できるという。
また、クラウド上の統合管理システムが稼働状況を常時モニタリングしており、異常発生時にはメールによって迅速な通知を行える点も特徴。さらに、複数拠点の状況をクラウドで一元管理できるので、IT管理者の業務を効率化できるのみならず、IT管理者の配置が難しい中小企業やSOHOなどの小規模オフィスにおいても、容易に導入・運用できるとした。加えて、自動セキュリティレポート作成機能を搭載し、脅威の検出状況を数値やグラフで可視化して提示してくれるとのこと。
インターフェイスは、1000BASE-T/100BASE-TX/10BASE-T×8ポート、SFP×2スロットを備えた。スイッチのベースエンジンには、PIOLINK社製のものを採用している。
なおシャープでは、内部対策としてBP-X1PL01を用いる一方で、同社のUTMアプライアンス「BP-X1CPシリーズ」を導入し、出入口対策をあわせて行うことで、より強固なセキュリティ体制を構築可能になるとアピールしている。
gmailを割と早くから使っているので（当時は招待制だった、ほぼ形骸化してたが）、シンプルなメールアドレスを持っている。
そのおかげで身に覚えのないメールが結構な頻度で届いて困っている。
たとえば登録した覚えのないサービスへの登録完了メールやキャンペーン案内メールなど。
スパム通報して迷惑メール登録していたのだが、たまにフィルターをすり抜けてくることもあって鬱陶しいし、自分がそのサービスを利用することになった時に困るのもいやだ。
なのでそういう事態が発生するとメールに心当たりがない旨を送信元に伝えて登録解除しようとするのだが、それが最近難しくなっている。
たとえばメールの本文中に「登録解除はこちら」みたいなリンクがあってもフィッシングやマルウェアのリスクを考えれば迂闊にクリックできない。そういうリンクがない場合もある。
また、送信元を検索サイトで探して申立てするにしても、窓口はチャットボットという場合が多く、会員ではない自分向けの情報になかなか辿り着けない。
有人の対応をしてもらう必要があるのだが、サービス提供元のの電話窓口やメールアドレスなどが記載されてない場合が最近は多い。
だから結局運営会社を検索してインシデント窓口へ通報したりするのだが、この一連のアレコレがなかなか手間なのだ。
VDI（仮想デスクトップ）代替ソリューションの分類や、それぞれの仕組み、検討ポイントなどを解説する本連
載「テレワーク時代のWeb 分離入門」。 第1 回、第2 回でテレワークと Web 分離の方式の特徴を解説しました。
今回のゴール
用途の観点で各方式を分類すると下図のようになりますが、どんな組織にも共通する「おススメの方式」はあ
りません。
（出典：ネットワンシステムズ）
今回は、読者の皆さんが自組織にマッチする方式を選定できる状態をゴールとして、「結局、 どれを選べばいい
のか」という疑問に回答します。
フローチャートで分かる、
VDI 代替ソリューションの分類や、それぞれの仕組み、検討ポイントなどを解説する連載。最
終回は、VDI 代替ソリューションの方式選定における 4 つのポイントを解説して、各方式を比
較します。
（2021 年03 月04 日）
26 →目次に戻る
これまで多くのユーザーと会話してきた経験から、おおよそのケースで次の4 つのポイントに論点が集約されます。
2. データを処理するマシンがローカルマシンで大丈夫かどうか
これらを基に、方式選定に使えるフローチャートを作ってみました。
（出典：ネットワンシステムズ）
「 ブラウジングだけを安全に実行できればよいのか、それともブラウザ以外のアプリも安全に利用させたいのか」
テレワーク用途では、前者でよければセキュアブラウザ方式に、後者でよければそれ以外の方式にふるい分け
できます。Web 分離用途では、前者が仮想ブラウザ方式、後者がそれ以外の方式となります。
27 →目次に戻る
【ポイント 2】データを処理するマシンがローカルマシンで大丈夫かどうか
次に、「 情報漏えい対策をどこまで強固なものにしたいか」という観点での要件です。
プログラムの実行環境が手元のPC となる場合、データも手元のPC に保存されます。つまり、手元のPC を
「 ディスクを暗号化している、生体認証を有効にしている、だから大丈夫」と言い切れるならいいかもしれません
が、「技術の進歩によって将来的に突破されるかもしれない」といった懸念を払拭（ふっしょく）できない場合、仮
想デスクトップ方式やリモートデスクトップ方式のように、遠隔にあるマシン上で作業できる仕組みを導入する必
要があります。
その一方、将来の懸念よりも、例えばコストなど別の部分を重視したい場合は、会社PC 持ち帰り方式（VPN
なお一般的に、リモートデスクトップ方式とVPN 方式はテレワーク用途のみで導入されますが、仮想 デスクトッ
プ方式とアプリラッピング方式は、テレワークと Web 分離、どちらの用途にも利用できます。
【ポイント 3】データを処理するマシンが物理PC で大丈夫かどうか
【 ポイント 2】で「遠隔にあるマシン上で作業させたい」となった場合は、3 番目の検討事項として、業務継続
性を考えるとよいでしょう。
リモートデスクトップ方式の場合、社内の自席にPC が物理的に存在することが前提です。そのため、自席 PC
一方、仮想デスクトップ方式の場合、マシンが仮想化されており、多くの環境において仮想マシンが動作してい
るサーバ群はn ＋1 などの方式で冗長化されています。そのため、非常に強い障害耐性があります。
障害耐性を高めたい場合は、仮想デスクトップ方式がベストです。業務が停止するなどのリスクを運用でカバー
できる場合は、リモートデスクトップ方式を選ぶことになるでしょう。
28 →目次に戻る
【 ポイント 2】で「手元のマシン上で作業させてもOK」となった場合、3 番目の検討事項として、再度情報漏
えい対策について考えます。【 ポイント 2】では、PC ごとデータが盗まれてしまった場合を想定しましたが、ここ
手元のPC でプログラムを実行するということは、つまり「端末の脆弱（ぜいじゃく）性を突いたゼロデイ攻撃
を受けるリスクが存在する」ことです。脆弱性を突いた攻撃を受けると、多くの場合、情報を抜き取られてしまい
ます。
従って、例えば VPN 方式を導入する場合、「EDR（Endpoint Detection and Response）で脆弱性攻撃対
策を実装する」「端末のロックダウン化によってデータを保存させない」「実行できるプログラムを制限する」「屋
外の公衆Wi-Fi を利用できないように制限する」「多要素認証を導入する」などの対策を併せて導入する必要が
あります。
このような徹底した対策を継続して運用できる組織に限っては VPN 方式も有効な選択肢ですが、筆者としては
VPN 方式は安価かつ容易に導入できるので、昨今のテレワーク需要が高まる状況では、多くの組織で上記のよ
うな徹底した対策を取らずに導入してしまったと思います。取 り急ぎの暫定処置としてVPN 方式を導入してしまっ
た場合は、これを機に腰を据えて見直してみてはいかがでしょうか。
• 参考リンク：日本経済新聞「在宅時代の落とし穴 国内38 社がVPN で不正接続被害」
また、国内に限った話ではありませんが、Verizon Communications のレポートによると、やはりVPN トラ
フィックが増加傾向にあるようです。VPN 方式の普及に伴って、悪意ある攻撃者による被害数も増加すると思い
ます。
• 参考リンク：Verizon Communications「Verizon Network Report」
29 →目次に戻る
ここまで、要件をベースとした考え方を記載しました。選定すべき方式が大まかに見えてきたところで、ここか
らはそれぞれの方式を横に並べて、共通の項目に沿って比較します。
この比較によって、方式選定の次のステップとなる製品選定において「見落としがちな落とし穴を見つけて対策
を考える」といった検討を具体的に進めることができると思います。
以降の表の見方を説明しておきます。緑塗りのセルがポジティブな内容、赤塗りのセルがネガティブな内容、黄
塗りのセルはどちらともいえない内容です。また、それぞれの表の下部には、主に赤塗りのセルに関する特記事項
なお単純に、緑塗りセルの多い方式が優れているわけではありません。対象業務の内容やコスト、運用体制、セ
キュリティ、業務継続性など、いろいろな観点からトレードオフで方式を選定することになります。
できる作業
（出典：ネットワンシステムズ）
仮想ブラウザ方式とセキュアブラウザ方式では、例えばファイルサーバの操作といった、ブラウザ以外のアプリ
は使えません。多くの場合、Windows の統合認証など Windows に依存する機能も利用でません。
また、印刷に関しても確認が必要です。製品ごとにサポート内容に差が出るポイントなので、方式選定の次の
30 →目次に戻る
（出典：ネットワンシステムズ）
会社PC 持ち帰り方式（VPN 方式）とリモートデスクトップ方式は、端末のアップデート、故障時の交換など、
端末台数が増えるに従って、それに対応できる人員数を確保する必要があるので、運用コストが増大する傾向に
あります。
その半面、仮想デスクトップ方式は初期コストが高額ですが、メンテナンス対象はマスター OS のみであり、仮
VDI の運用ナレッジが豊富なSIer に依頼することで、作業内容の質を落とさずにコストを圧縮できる効果が期
待されます。
（出典：ネットワンシステムズ）
仮想ブラウザ方式やアプリラッピング方式、セキュアブラウザ方式は、「 Web ページが正常に表示されるかどう
か」などの動作確認を、あらかじめ実環境で実施しておく必要があります。この動作確認は、運用フェーズにおい
また、特に仮想ブラウザ方式は、「 ブラウザタブを開き過ぎるとサーバ基盤の負荷が高騰して Web ページの閲
覧速度が急激に低下する」といったサイジング関連のトラブルが発生しやすくなります。
31 →目次に戻る
（出典：ネットワンシステムズ）
マルウェア対策については、会社 PC 持ち帰り方式（VPN 方式）やリモートデスクトップ方式、仮想デスクトッ
プ方式は、EDR やアンチウイルスソフトの導入などが別途必要です。一方、仮想ブラウザ方式やアプリラッピン
グ方式、セキュアブラウザ方式は、「 利用終了後に環境ごとデータを削除する」「 exe 形式のファイルの実行を禁
重要情報の盗聴については、リモートデスクトップ方式や仮想デスクトップ方式、仮想ブラウザ方式（画面転送
型）は、画面転送型なので、暗号化通信が仮に復号されたとしても、実データが盗聴されることはないという強
みがあります。
最後に、不正アクセスについては、多要素認証システムと組み合わせるなどの対策がどの方式でも必要です。
ログインに関わる操作が増えることで利便性は低下しますが、昨今の状況を鑑みると、多要素認証の導入は必須
といえます。
おわりに
これで 3 回にわたる連載は終了です。いかがだったでしょうか。
セキュリティと利便性はトレードオフの関係にありますが、筆者は「仮想デスクトップ方式」と「仮想ブラウザ
仮想デスクトップ方式と仮想ブラウザ方式は、「 導入によってセキュリティレベルを大きく低下させることはな
い」という点が最大のポイントです。その上で、仮想デスクトップ方式には「従来のクライアント OS と同じよう
に利用できる」という汎用（はんよう）性の高さがあり、これが他の方式より優位な点となっています。一方、仮
想ブラウザ方式は、用途が限定されるものの、ユーザーにとっては利便性が高く、初期コストの観点では仮想デス
「Githubは、めっちゃ怖い」と、言うと「また情報漏洩か」と思われそうなんだけど。
実は、以前、FPSゲームの公式公開されているステータスに関する便利ツールのソースコードが落ちてないか、Githubで「ゲーム名」を検索したことがあるだ…。
そこで、知ってしまっただが…これ闇ですね。
これの件について、英語圏の連中以外知っている奴いるのか？と思って、ググったら、5chの某スレ連中が、ボロボロやべぇこと書いてて、この世の闇を垣間見てしまった気がする…。
ちょっとググってて分かったけど、マルウェアのソースコードが載っていることもあるという記事を見つけて、ひょぇとなったし。
マジ、Github、怖いところだ。
iPhoneが情報を漏らしていた。iPHoneにはマルウェアが標準ではいっている。情報を漏らしている。恐ろしいセキュリティが高い印象操作しているがとんでもない真っ黒だ
Macも漏らしていた。AppleIdでログインしたら漏れた。なんでわかったかというと通信をキャプチャしてわかった。URLとか見てアプリの挙動を見てわかった。
クリーンインストールした状態で試してわかった。MacもiPhoneもWindowsもやばい。通信キャプチャするソフトで試してみればわかる
38 風吹けば名無し＠転載禁止 2014/11/25(火) 20:28:06 ( tor-exit.server6.tvdw.eu )
プログラミングがたいして出来なかったから、ろくなもんになれないと思ったもんで
まあ攻めより受けは圧倒的に楽なもんだよね
サーバーの運用に関してはセキュリティについて結構書かれてる本多いし
解析する方としては、ハード、OSの基本的なシステムとwebやネットワーク関連を身につけたら、
既存のツール活用するだけでフォレンジックの真似事やマルウェア分析ができる
数万相当で売ってたカランサムウェアもちょっと説明つけて検体送ってやれば、半日で役立たず
多段パッカーとかでワンチャンあるかも分からんし、こういうのはいたちごっこだけど。恒心サポートとか付いてくるんかね？ｗ
Cuckoo Sandbox: Automated Malware Analysis
Malwr - Malware Analysis by Cuckoo Sandbox
ttps://malwr.com
k5zq47j6wd3wdvjq.onion
tom3j5jkjl7327oc.onion
ttps://infotomb.com/mn3u8.png
The Exploit Database
