スキップしてメイン コンテンツに移動

暗号化ZIPでなにが悪いの?

 emotetが切っ掛けだとは思ってるけど,暗号化ZIPに逆風が吹きまくっていますね。

無駄とか,意味がない,面倒とか色々言われている暗号化ZIPですけど,これらを解決する代替ソリューションってあるんですか?

確かに,暗号化ZIPはセキュリティ面から見ても強度不足だし,技術的には可能なマルウェア検索も出来ないってのは有名?な話だけど,ほかの暗号化アプリケーションでそれが改善されるのか?といえば大差ない。

ファイアウォールやウィルス対策ソフトを日頃運用管理している立場からいうと,暗号化したファイルはすべて検査対象外。emotetが社内に入り込むのを防ぐのははっきり言って無理。複合化された際に検出できれば良いと割り切るしかないのです。そもそもHTTPSが当たり前の時代にUTMなどでマルウェア検知すること自体が微妙な感じです。

暗号化する環境がクリーンであることを証明できない限り暗号化ファイルのリスクは減らない。

面倒って話は,送信側って添付ファイルを自動暗号化する仕組み整えているのでは?と思う。特に大企業や官公庁の場合は送信者は意識して操作してないと思うよ。
仮に,すべてが手動だとしても,暗号化ZIP以外の仕組みを使っても結局暗号化の操作は必要だし,複合化の作業も必要。OpenPGPって歴史もあり安全な暗号化が普及しなかったのも面倒ってこと。そもそも受信者に複合化手順を説明する,ソフトウェアを使わせることなんてほんと面倒。その点,暗号化ZIPはパスワードを伝えれば,ほとんどの場合複合化できるんじゃない?

意味がない。暗号化されたファイルを送るとともにパスワードを伝える。あて先間違えばセットで送るだけなので,面倒な手続きを加えただけで届いたものは開ける。うん意味ないよね。でもほかの方法でも結局間違えたときの対策なんてほとんど機能しない。送った人が間違いってことを気が付かなければ何やっても一緒。

はっきり言って精神面以外の効果はどの方式でも期待できないと思うよ。
面倒な作業を行うことでセキュリティ意識(安心させてしまう面は問題)を維持しやすい。

「意味ないからやめようよ!」って発言にも,「セキュリティ面からもそうだけど,これが無かったらそういうこと考えないよね」って答えると,セキュリティ意識を維持させてる効果があるんだ~と感じてもらえるかもしれない。

リングヒットは意味がないとジムに通っている人が言うけど,引きこもりにとってはすごく効果がある。人それぞれの立場によって効果は変わるんだよね。

だからさ,暗号化ZIPを辞めようっていうなら,OpenPGPや独自方式強制しちゃうよ。どうする?って対抗してやるんだ。

コメント

このブログの人気の投稿

SharePoint アイテム保管ライブラリをのぞいてみよう(2023年1月改訂)

※アカウント移行に失敗し画像を失ったので再度取得し改訂しました。 Office 365 Advent Calendar 2021  の12月16日投稿です。 警告: 個人的な理解に基づく内容、表現です。疑いを持って取り扱ってください。 SharePoint と OneDrive の保持の詳細 - Microsoft 365 Compliance | Microsoft Docs SharePoint Onlineをご利用の方にとっては普通?の機能ですが、SharePoint Server 2010以前から利用している方にとっては2013からの新機能「インプレース保持」で使われる「アイテム保管ライブラリ」をちょっとのぞいてみようという内容です。 Exchangeのインプレース保持とSharePointの保持は違うよ~ Exchange のインプレース保持はごみ箱から消えたメッセージを含むすべてを保持することができるのですが、SharePointでは対象外アイテムが存在しますし、編集についてはバージョン履歴に依存しています。また、情報管理ポリシーの「ごみ箱に移動する」が動作しなくなるなど利用者への影響もありますので注意が必要です。また、保持してることを内緒にしたくてもサイト管理者にはバレバレな点は認識しておかないとね。あとE3相当以上の方はExchangeは容量無制限ですけど、SharePointはしっかりと契約容量に含まれているので上司の方から説明のたびに叱られる可能性がありますね。 SharePointの保持は、Exchangeが連携して利用する大容量添付ファイル送信やTeamsメッセージの添付ファイルを保持する目的のために存在する機能なのかな~という感じがします。SharePointの情報調査や監査という意味では、バックアップ製品などでこまめに世代管理する必要があると感じます。 SharePointで削除されたアイテムは各サイトの「アイテム保管ライブラリ」にコピーされ設定期間保持されます。 各サイトというのがミソですね。しかも、サイト管理者から参照可能な場所に保持されるため、保持について理解のないサイト管理者はこのライブラリのアイテムURLを見ることができないユーザーに渡すなど困った行動を起こす可能性があります。 それでは保持を確認するために保持されるアイテムを準

あけまして

コロナから始まり、コロナに終わる。 今年は別の話題で終わると良いですね。 モーそろそろアフターコロナになりたいな〜と思います。  今日は何人でした。とかね、なんか昭和最後の年末年始をちょっと思い出す。 なんだかな〜って感じですね。

ADMXがあればIntuneでもグループポリシー配布できるもん

一番信頼できる情報源としては docs を読むのが正解なんだけど,不安を感じたことを書き留めておくね。 1.ADMXファイルをインストールする必要がある  オンプレだと "\\{Domain Server}\SYSVOL\{Domain name}\Policies\PolicyDefinitions" にADMXとADMLを保存したら展開が始まるけどIntuneの場合はデバイスの構成プロファイルを使って配布する。  OMA-URIにADMXの内容を設定するんだけど,OMA-URIってなに?って感じだけど細かいことはDocsを読んでね。  OMA-URIは次の値を設定するよ。 ./Vendor/MSFT/Policy/ConfigOperations/ADMXInstall/ {AppName} /{SettingType}/{FileUid or AdmxFileName} ここで重要なのは {AppName} だけといってもよさそう。 {SettingType}は「Policy」で決定しているし,{FileUid or AdmxFileName}は同じ{AppName}内で競合しなければなんでもよさそうだったのでファイル名が無難ですね。 構成プロファイルを配布をするとレジストリに次のようなキーが2か所に作成される。「HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PolicyManager\AdmxInstalled\{UID}\ {AppName} \Policy\{FileUid or AdmxFileName}」 「\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PolicyManager\AdmxDefault\{UID}\ {AppName} ~Policy~{CategoryName}~{SubCategoryName}」 必要なのは二つ目のキー。実際のADMXファイルを例にすると・・・    < categories >      < category   displayName = "$(string.googlechrome)"   name = "googlechrome" >        <