Наблюдение за бытом больших корпораций вгоняет меня в депрессию. Это дикая паранойя и одновременно жуткие, зияющие дыры в безопасности. Впрочем, возможно эти вещи как раз связаны — ведь параноик сфокусирован на определенных вещах, и легко может проглядеть очевидное. Он может выйти на улицу, отчаянно шурша фольгой, в которую завернулся с ног до головы, и быть сбитым автобусом.



Мне доводилось наблюдать фирму, где закрыли профиль USB data storage для VDI машинок, но при этом не закрыли профиль USB Hub, то есть можно было воткнуть USB Hub, а потом в него уже флешку. Кстати, компы там были завирусованные. Тем не менее отнюдь не сон, а активное бодрствование разума безопасников направлено не на починку дыр, продолжает рождать чудовищ. Одно из этих чудовищ называется

Data Encryption at Rest

Ладно если это делает storage system при записи на свои диски: небольшая расплата по CPU, и все. Хуже если encryption делается уровнем выше — тогда эта encryption убивает deduplication уровнем ниже. Не удивлюсь, если заставят делать и третий уровень — допустим, шифровать данные аппаратно на самих дисках, и только такие диски и сертифицировать, или требовать шифровать диски виртуалок. Три шапочки из фольги работают лучше, чем одна!

Но скажите, какой жизненный сценарий вы пытаетесь предотвратить? В datacenter пробрался злобный хакер и выкрал диск и работающего NetApp, получив в руки кашу от data striping неизвестно чего? Как вы себе это представляете? В том datacenter, где я был, были даже бетонные надолбы от тарана броневиком.


Вы видите на фото хакера с кусачками слева в нижнем углу? Я тоже не вижу.

Разумеется, использованные диски нельзя выбрасывать, только уничтожать. Это как бы стандарт, и для этого есть сертифицированные фирмы с сертифицированными бульдозерами для давли санкционки. Ладно, шифруйте это один раз transparently на уровне storage, я не против, но дальше то зачем? Больше всего от data encryption at rest пострадала

AWS

Потому что RDS на SQL Server Express Edition шифрование не поддерживает, и надо как минимум Standard Edition в N раз дороже. А зачем — если там только тестовые таблицы с фейковыми данными? А потому! Потому что Policy. Это послано свыше



и не обсуждается. В итоге использование AWS для DEV оказалось нецелесообразным.

Вообще, с AWS грусть. Человек видит, как с помощью пары кликов на интерфейсе AWS можно сотворить инфраструктуру, его рука тянется к мыши, но следует окрик:
— Мы создаем все только через Terraform!
— Хорошо, давайте я создам файл…
— эээ, нет, у нас тут DevOps team, мы там определили кучу переменных, там все хитро, вы не справитесь, у нас и так каждый день трехчасовой митинг по git merge requests для terraform code
— Но когда будет готово я запущу?
— Нет, разумеется. Все запускается только через Jenkins job
— А где это?
— Вас все равно туда не пустят. При создании EC2 надо корректно указывать инвентаризационный код, код проекта, фискальный код для бухгалтерии, вы всего этого не знаете, не лезьте, есть специальные люди.
В итоге с развитием DevOps девелоперы оказываются все дальше и дальше от Ops.

Network

В сети мы тоже любим шифровать. Ну конечно туннели между офисами зашифрованные. Внутри шифрованных каналов шифрованные соединения, всякие https. Но вот завтра митинг — будет шифроваться еще чтото! Им все мало…

Опять таки, как вы себе представляете взлом? Вот так?



Я нашел только эту картинку, но искал другую. В каком то военном фильме, который я смотрел в детстве, военные разведчики втыкали иголки в провода и подслушивали разговоры противника через наушники. Почему то представляется ночь, вьюга, и все черно-белое. Но серьезно, шифрованный тоннель это каша из кучи пакетов в разбивку, что вы с этим будете делать? То же, что и Яровая?

Пароли и доступ

О да, это прекрасная тема. Сколь ни пишут, что регулярная смена пароля — это зло, воз и ныне там. А как вам 12 (да, двенадцать!) разных домен эккаунтов с паролями разной длины, разным временем устаревания и несовместимыми правилами, касающиеся их сложности?
На некоторые сервера надо пробиваться так: под одним экааунтом выходим на Terminal (Jump) server, оттуда прыгаем RDP на другой, под другим эккаунтом, далее иногда на третий. На каждом уровне погружения замедляется скорость перерисовки, часто уменьшается размер окна, вся эта цепочка начинает требовать повторного ввода пароля (copy/paste запрещен) или вообще закрываться через небольшое число минут в idle, поэтому приходится очень быстро бегать в туалет, причем исключительно «по маленькому»

Я сильно подозреваю, что все эти вещи типа таймаутов и отсутсвия копи-пасты делаются просто, чтобы было неудобно. Pure evil. Не всякий DBA долетит до продакшн сервера. Впрочем, всегда можно сделать еще хуже, и уже внедряют какую то систему для zero-touch production, которая, говорят, еще на порядок неудобнее.

Аудиторы

Конечно, зачастую все эти меры не являются чистым злом, а «проверенными временем» (типа требованиям к паролям) решениями для аудиторов. При этом реализуется известный принцип «don't ask — don't tell» — мы догадываемся, как 80% сотрудников хранят пароли. Но мы как бы все сказали, правила изложили, бумажки подписаны, а если у кого листочки на монитор наклеены, то это уже мы не виноваты.

Тем не менее, даже с этим пониманием я со страхом открываю почту — можно натолкнуться на очередное письмо про их излюбленный «hardening» — русский перевод «закручивание гаек» и гадать, что еще станет хуже. Можно подумать, мне этого в жизни не хватает! Кажется, забота о безопасности давно переросла в паранойю. Иногда настоящую, иногда напускную — ради аудиторов. Еще вспоминается 13е путешествие Йона Тихого на некогда пустынную планету, которую обводнили, потом превратили в океан и все не могли остановиться, пока все не утонули…

Буду рад комментариям.