Размышления на тему ИБ
... Бывают случаи, когда дополнительная "безопасность" ни к чему не приводит. Например, условный Вася устанавливает в свою квартиру сейфовую дверь с тремя замками разной конструкции с целью защитить свое имущество от воров. Получается, что Васе каждый день приходится дольше открывать и закрывать замки. Вместе с тем, домушнику может оказаться проще залезть через форточку или разломать гипсокартонную стену рядом с этой дверью. И более того, просто само наличие такой двери может указывать на то, что в этой квартире есть чем поживиться, тем самым привлечь потенциальных грабителей. Так попытки "усилить безопасность" приводят ровно к обратному эффекту.
Я настолько часто сталкиваюсь с похожими идиотизмами в IT-сфере, что просто не могу молчать постоянно задумываюсь о том, что все эти "бизапасники" не просто приносят компаниям дополнительные издержки и усложняют работу инженеров, а более того, эту самую "безопасность" только ухудшают.
... Рассмотрим пример. Есть некая техническая площадка, на ней пусть будет к примеру PostgreSQL, в котором хранятся какие-нибудь чувствительные данные. Приходит такой "бизапасник" и постановляет: "Всё, ограничиваем круг допущенных к этой площадке лиц, разработчиков на неё больше не пускаем, им тут делать нечего!" С одной стороны, выглядит как будто разумно.
С другой стороны, в ходе эксплуатации выявляется какая-то проблема. По словесному описанию разработчик предполагает, что затык мог произойти в той самой базе данных и хочет проверить свою версию. До "бизапасника" он бы подключился по SSH к PostgreSQL-серверу, прогнал тестовые запросы, выкатил фикс. Теперь же он просит эксплуатирующего инженера снять дамп и прислать ему, чтобы потом развернуть этот дамп на стенде и оттестировать.
Получается, что этот относительно секретный дамп базы данных с чувствительной информацией появляется по цепочке сразу в нескольких местах: исходный сервер в папке пользователя, ноутбук инженера, почтовый ящик инженера, почтовый ящик программиста, ноутбук программиста, тестовый стенд в папке пользователя, тестовый стенд в базе данных. И разумеется, кто-то из них обязательно забудет потом подчистить за собой "хвосты". Вот и получается, что у потенциальных хакеров появляется куда больше возможностей спереть ценные данные. Что, неужели от запрета ходить разработчику на production-сервер стало "безопаснее"?
Да, вы можете возразить, что в таком случае надо "закручивать гайки" и дальше. Навесить всякие там PAM, Jump Host, запретить выносить любые данные из production-контура и так далее. М-м-м-м, вполне возможно что задача защиты данных и будет таким образом решена, вопрос только какой ценой. Если утрировать, то дешевле может оказаться просто выключить сервер из силовой розетки. "Нет сервиса - нет проблемы".
... В теплотехнике есть такое понятие: критическая толщина теплоизоляции. Допустим, по улице идёт труба центрального отопления и мы хотим снизить потери драгоценного тепла из неё. Обматываем слоем стекловаты. О, круто, потери снизились. Обматываем ещё слоем. О, ещё снизились. Воодушевляемся, продолжаем в том же духе и замечаем, что начиная с какой-то толщины потери начинают наоборот возрастать. Почему? А потому что с увеличением количества слоев теплоизоляции растет и площадь наружной поверхности...
... Один заказчик потребовал на все виртуалки с сервисом в его контуре накатить антивирус. Непонятно на хуа он там вообще нужон, ибо сервис никакими файлами в принципе не оперирует и реализует строго определенный протокол взаимодействия в жёстких рамках спецификации вида "XMLку туда, XMLку сюда". Но хозяин - барин, кто мы такие чтобы спорить с заказчиком.
В процессе выяснилось, что у "бизапасников" лапки, они не знают что такое SSH-ключи и потребовали им создать отдельную учётку с суперпользовательскими правами и входом по паролю. Который, к гадалке не ходи, разошелся по всевозможным перепискам между менеджерами, исполнителями, да ещё и где-нибудь в тикетнице "осел". Зато на виртуалках будет установлен к***ерский, который там на **й никому не впердолился. Безопасность!
... Другой заказчик выдал доступ в свой контур по хитро***ой схеме с Cisco AnyConnect и PAM. Проблема только в том, что пароли от того и от другого со временем протухают, и никак между собой не синхронизированы. То есть вот ты продолбил момент когда пришла пора эти пароли менять и потерял доступ к площадке. Восстанавливают они эти пароли неделями в ходе душных переписок. А за это время случается авария, но ты ничего сделать не в состоянии, потому что не можешь пролезть к машинам с сервисом. Безопасность!
... К третьему заказчику всю жизнь ходили через IPSec-тоннель по SSH-ключам. В какой-то момент он решил, что это "небизапасна". Начал городить какую-то очередную **алу с VDI и персонифицированными учетками, выдаваемыми под роспись. При том, что он находится в другой стране, и даже если что-то случится, кому он будет эти соглашения с подписями предъявлять, для меня большая загадка. Но сервис поддерживать будет кратно труднее, это факт. Зато безопасность!
... Четвертый заказчик дико ссытся, что подрядчик может у него с3.14*дить список его базовых станций с геокоординатами, поэтому выстраивает кучу анальных загородок и выкатывает тонну бюрократических формальностей. Я вот думаю... ну предположим что я к старости рехнулся окончательно и таки стырил у них этот список. Что я с ним дальше-то буду делать? Конкурентам продам что ли? А им он на хрена, тем более что в той стране всеми операторами связи владеет фактически одна и та же семья / клан. Безопасность!
... Тут вот опять очередная новость. Опять пытаются решать социальные проблемы техническими мерами. Снова всем затруднят жизнь, удорожают связь, но реально добьются примерно ничего. Безопасность!
Дорогой Санта, подари мне пожалуйста другой глобус. И чтобы без топчущих его клинических дебилов, ну пожа-а-а-алуйста!