Comments 36
RBAC, IAM и другие технологии не имеют смысла без отлаженных процессов безопасности. Это как с дверью, какой-бы замок не стоял, но если не будет человека, который поднимет тревогу в случае попытки взлома замок не спасёт.
Вообще любая ИБ начинается с одной простой вещи - с нормального резервирования данных. В большинстве организаций конфиденциальность информации значительно менее важная характеристика чем целостность. Поэтому если нет бэкапа, то остальным можно вообще не заниматься.
А так история весьма поучительна.
Абсолютно согласен не имеет смысла. Как верно указал amnesiax - это от непонимания и следования моднявым штуковинам. не понимая саму суть. Им сначала нормального Системного администратора раз нет службы ИБ - именно его, того кто по ~~феншую~~ тфу ISO премудростям построит всю систему, который знает как резервирование сделать и всех других помирить и рассадить по клеткам. Но их осталось мало, так как всем нужны Архитекторы, Девопсы, Сетевые инженеры, и т.д. решать одну самую нужную задачу сейчас и пусть каждый ставит свой костыль - потому они вымирают как вид. Вот эта фраза уже ужас - "По счастливой случайности, у одного из сотрудников был сделан бэкап всей базы данных." Это говорит о том - что у них все плохо изначально ну совсем. И Dev-Ops не спасет, систему нужно менять ))
И, как говорится мораль сей басни такова: Она конечно не нова – случайных людей не допускайте к власти, Иначе беды ждут, напасти,
Вывод совершенно не верный.
С вашим подходом и неслучайные люди все сломать могут.
Как выше уже отметили - системный подход, процедуры и резервные копии являются основой, а вовсе не подбор персонала.
Т.е. Злодей спланировал заработать на диверсии - предпринял и настроил заранее средства злодеяний. А за это никак нельзя привлечь через суд?
Можно и нужно. Кроме того - скрины переписки, явные доказательства.
По ст.272 УК как минимум можно привлечь если есть доказательства. От 2 до 7 лет.
Да руководство собрало, как по мне, железобетонные доказательства причастности С. к данному инцеденту. На руках были логи которые четко свидетельствовали о вышеописанных манипуляциях. Обратилось в полицию. Полиция не захотела этим заниматься и дали ответ вроде "Нет состава преступления". Дальше уже никто не стал заниматься этим.
Полиция не захотела этим заниматься и дали ответ вроде "Нет состава преступления".
У полиции разве есть опция "выбора"? А если через 112 заявление сделать? Таких мудаков-"девопсов" 100% нужно наказывать.
Жалоба в прокуратуру на бездействие. Если получаете отписку - жалоба в Генпрокуратуру на действия прокурора. Долбить полицию до тех пор пока не возбудят уголовное дело и вы не получите подтверждение этого.
В отношении бэкапов базы данных. Да конечно же они делались. Но были С. так же уничтожены.
Я себе, так концептуально представляю решение этой проблемы: Должно быть два человека - один отвечает за администрирование серверов (или devops как здесь), второй занимается аудитом, организацией и контролем за документированием и бекапом.
Кроме того, я отказался от попыток делать реестры данных подлежащих бекапу, по тому что, по большому счету, не нужных данных не бывает. По этому был выработан подход тотального бекапа:
- всё находится в proxmox в виде виртуальных машин и контейнерах поверх локальных zfs и zvol на гипервизорах.
- Несколько раз в день данные бекапятся с помощью дифференциального бекапа на основе zfs send-receive
- скрипт бекапа автоматически ищет все виртуальные машины и все контейнеры, которые могут переезжать между гипервизорами, автоматически сопоставляет с подходящим бекапом-назначением и бепапит все харнилища каждой вм или контейнера в режиме pool, т.е. запускается с бекапных серверов.
- бекапные сервера имеют независимую авторизацию, на них нельзя зайти с учетками от любых других серверов. Скрипты с бекапного сервера могут выполнять задачи на остальных серверах, а в обратном направлении - нет.
Скажете дорого? Но если учесть, что поддержание реестров в актуальном состоянии - это тоже работа требующая оплаты и дополнительный риск возникновения неактуальности этих реестров, увеличение сложности всей системы. Отказ от облаков для бекапа с опорой на zfs тоже в разы удешевляет бекап.
Я вижу только одну угрозу. Злоумышленник может настроить прозрачное шифрование, которое длительное время будет работать незаметно. Для этого и должен быть аудитор, который проверяет а что и как там настроено.
Ключевая идея:
разработчики пишут код → DevOps автоматизирует его сборку, доставку, запуск и поддержку.
DevOps → SRE (Critical Boundary)
This is a responsibility boundary, not a tooling boundary.
DevOps is accountable for delivery into production.
SRE is accountable for production behavior over time.
DevOps asks: “Is it deployed correctly?”
SRE asks: “Does it continue to meet SLO under real failures?”
SRE owns SLOs, error budgets, incident response, postmortems and has authority to block releases.
От себя же добавлю что у нас в России - из-за непонимания DevOps-культуры, эта должность имеет более широкое понимание. И охватывает, по сути, все, что связано с теми, кто работает непосредственно с серверами - это в какой-то степени царь и бог для серверов, которые есть у компании
Это из-за низкого уровня компетенций в понимании смысла разделения ролей.
Как пример - буквально сегодня общался с одним маркетплейсом W****s - у них описание SRE-инженера включает в себя следующие роли ниже (ответственность):
- Firmware / BIOS / burn-in ->> Platform Hardware Engineer
- OS / Kernel / FS / Network ->> System Administrator
- Container platform / Application deployment ->> DevOPS
- Reliability / Incidents ->> SRE
Не понимают что,
1. Это принципиально разные роли, с разными требованиями к навыкам, психологическому профилю, уровню компетенций, практическому опыту работы, объемом ответственности перед бизнесом.
2. Из-за списка выше, разница, например, в оплате между Platform hardware Engineer и SRE (высшая степень ответвенности перед бизнесом) может доходить до 50%.
3. Непонимание пунктов 1 и 2 выше-это попытка нанять\заманить человека-паука, который через какое-то время либо выгорит и сбежит, либо просто сбежит.
Выше описанное касается и секьюрити вещей - не просто так придуман код-ревью\секьюрити чеки, продецуры ступенчатого контроля за доступами (апрувы).
Слышал давнюю историю, что пришел хороший админ, все настроил, все засекурил и .... пропал. Совсем. Кажется после зарплаты или там премии квартальной - то есть быстро. По месту жительства не нашли. Ну повзламывать пришлось админские пароли. А потом позвонили из дурки, удивились что работодатель не знал, что это их постоянный клиент. С белочкой - белой горячкой. Потом выяснилось что у него это был цикл: устроился на работу, получил денег, напился, попал в дурку с белочкой, уволили, повторить.
Очень давно это было. Тогда тоже не очень то внимательно с персоналом работали. А алкоголизм среди интеллектуалов - явление распространенное.
Да и ИТ саботаж не так уж и редко встречается, хоть и не в таких острых формах.
Зачем ваш С. к вам на работу то устраивался? В чем была причина конфликта? Налево работал? Судиться, конечно, не стали?
Насчет целей устройства С. на работу не знаю. Конфликтов по сути никогда не было, все было в рамках приличия. Просто поняли что с человеком сложно решать вопросы и решили попращаться. Спокойно без всяких разбирательств. В полне допускаю мысль что работал еще где то так как с доступностью были проблемы, может еще чем то занимался своим.
Насчет судиться, ответил чуть выше.
Вы, конечно же, обратились в полицию и инициировали расследование? А чо нет?
В целом, между строк можно прочитать пару тревожных флажочков (поправьте, если я ошибаюсь):
"Сперва купи картину, а затем рамку" - инфраструктуры, которые появляются раньше, чем нанимают людей, способных осознанно их спроектировать и развернуть, это 99% боль.
Хороший девопс-инженер, это человек, который знает не меньше, а больше среднего разработчика (условные 50% разработки + 100% админства). И получать должен соответствующе - иначе и будут приходить такие вот работнички. Из повествования ощущается, что этого даже близко не было.
"Тимлид решил переехать с Прома на Заббикс" - хотя эти системы концептуально предназначены для разного. Уровень понятен.
У меня бывали очень похожие места работы, где исторически сложилась кривая-косая инфраструктура, которую на заре создания компании развернул какой-нибудь техдир, руководитель разработки или ещё кто. Потом этот человек устаёт поддерживать наговняканное - и компания решает нанять админа (незадорого). Админ приходит, видит всё это, пытается внести рацпредложения и переделать по-нормальному, но "автор" ему не даёт - ведь это будет означать, что он наделал фигню и пошатнёт авторитет. Денег на приведение инфраструктуры в порядок не дают, задачи тухлые - вот и увольняешься через полгода.
Насчет полиции ответил выше коментатору.
А в целом, судя из вашего коментария, наверное, имеете ввиду что проблема не в человеке, а в системе. Хороший DevOps стоит дорого и вообще наверняка компания сама виновата.
Но суть ведь статьи не об этом. Заголовок статьи говорит о том что нужно знать о рисках работы в нашей сфере. И просьба здесь поставить себя на место "клиента" и подумать как нужно защищаться от подобного воздействия. Есть даже термин "Insider threat" и проблема на самом деле не нова. И в качестве исходящих представьте что контора реально классная и идеальная и ЗП хорошая но человек по сути своей разрушитель - выше есть коментарии о подобных личностях
Чтобы выстроить систему, в которой такой разрушитель не приведёт к существенным последствиям - нужны вложения и персонал. Вложения без эффекта, который можно поместить в циферки на презентации топ-менеджменту, мелко-средний бизнес делать не любит, кадры, которые получше, отчалили за последние три года. Крупняк, у кого с этим более-менее - слился с Левиафаном и деградирует по той же траектории.
Я на собеседованиях уже давно стараюсь спрашивать потенциальных работодателей, какой даунтайм в год они считают допустимым и сколько стоит минута его превышения. Там, где такими вещами не заморачиваются - гарантированное болото.
Неправильно, когда за все отвечает один человек. Бэкапы не только для данных требуются.
Так-то С. вот злодеем оказался, а вдруг бы он в ДТП погиб?
И, как говорится мораль сей басни такова: Она конечно не нова – случайных людей не допускайте к власти, Иначе беды ждут, напасти, И пожалеете вы вскоре, Когда от них хлебнете горя!
Так оно не поможет. Проблема в том, что вы МЕЛКАЯ контора, где работает очень мало людей, поэтому у вас нет разделения обязанностей, так как каждый сотрудник вынужден совмещать у себя несколько ролей. По этой же причине у вас нет ни второго DevOps, чтобы исключить bus factor; ни политик безопасности, ни регламентов приёма\увольнения сотрудников и прочего. Вы микроконтора, поэтому вы будете наступать на эти грабли постоянно и вариантов это избежать нет.
Вот когда вы станете больше в размерах, тогда у вас появится несколько DevOps специалистов, позже появятся безопасники. Затем отдельные специалисты по бэкапам, которые будут заниматься только бэкапами. А если станете совсем большими и крутыми, то появится отдел аудита и комплаенса, который будет вам паяльники в одно место вставлять, за то, что провели работы без тикета, либо неправильно этот тикет оформили. Вот тогда наступит полный контроль и безопасность, но взамен вы получите бюрократию и корпоративные войны между отделами в дополнение к политическим интригам внутри компании. Так что всё не так однозначно.
Я как примерно похожий devOPS могу точно утверждать, что человек который вот такое замутил не просто так все это сделал, скарее всего его сначала задолбали, а потом когдаон пришел попросить прибавки ЗП его цинично послали со словами ты тут никто или похожее. Ну вот он и показал кто он. А то такие микро ИП очень любят говорить, что зп зависит от отвественности, а вот поднимать зп они почему то забывают, а отвественность поднимают очень быстро. P.s.: Меня обычно с зп не обижали, но знаю был одной канторе где сделал бы так же, да только лень был ибо знал, что без меня они утонут сами по себе, что в общем то и случилось через пару лет
Ну у вас и фантазия (в хорошем смысле слова). Да это частый сценарий развития событий что вы описали. У вас наверное был похожий опыт работы.
Честно вам скажу как сторонний наблюдатель - контора была в рамках приличия. Люди адекватные хорошие на редкость.
На сторону зла встать легче а вот на стороне "клиента" как бы вы поступили?
Долго работал в найме админом, потом продолжил в формате ИП для нескольких компаний.
И на подобные истории насмотрелся столько раз, что уже сбился со счета. И я никогда не мог понять одного. Как можно делать подобные вещи, которые описаны в статье. Ведь каждый кто идет в найм делает это добровольно, сам выбирает ЗП на которую он идет, знакомится с условиями (коллектив, среда, доход, удобства), сам принимает решение остаться. Но когда меняется среда, или когда реальность не оправдывает ожидания, вместо того, чтобы просто уйти, начинают оправдываться тем, что раз мне "несправедливо платят", то буду также и работать (не работать, вредить).
Это инфантильность или глупость? Ведь вся эта "справедливость" - полная иллюзия, да еще и местами уголовно наказуемая.
Работаю с разными компаниями больше 10 и 15 лет. С одной компанией проходил через отказ от моих услуг (не справлялся из-за перегрузки). Принял это с ответственностью и пониманием, что сам виноват. Сразу предупредил сотрудников, чтобы дали мои контакты новому админу, чтобы я ему все мог передать (что и сделал в подробностях). В итоге закончилось тем, что через год со мной восстановили отношения, работаем с компанией также больше 10 лет.
Конечно, по идее хорошо бы иметь:
и вот мне интересно, как бы это всё помогло, если у товарища всё равно все ключи есть. Ну то есть да, вы его уволили, заблокировали его учётку в один клик. Но он до этого успел создать учётки, которые не входят в эти группы.
Джамп-хост - не позволит войти и запустить задачу, но никак не помешает запуститься запланированной задаче (принцип мёртвой руки).
Ну то есть надо иметь как минимум резерв специалистов, которые после расставания смогут провести аудит безопасности, ну или как минимум сделать бэкап всех систем.
В теории могло бы помочь ленточное хранилище, но опять же при наличии злой воли - можно старые ленты затереть, или настроить так, чтобы ничего важного не копировалось.
В общем - если на какой-то позиции есть один человек, значит тут у вас SPoF. И не очень важно сознательно он решит вам навредить, или просто его машина сбила.
Ну как вариант если бы были изначально применены настройки безопасности и при регистрации нового пользователя, изменении файла cron, добавлении нового ssh ключа и подобные вещи отображались через некий телграм бот в группе где несколько человек из компании подписано. Тогда хотя бы это было сложно сделать незаметно и народ бы встрепенулся а зачем кто то делает вот это.
В первом коментарии @imbasoft специалист по ИБ, дал хороший ответ по этому вопросу.
Наверно мне первый раз захотелось поставить минус статье тут, но кармы нет.
За кликбейтный заголовок, за демонизацию термина devops и применение его к позиции и обязанностям системного администратора, о котором и идет речь этой статье. Ну и за то, что ничего не написали ни про фейлы менеджмента, ни про фейлы HR, которые также могли быть одной из причин результата, описанного здесь.
применение его к позиции и обязанностям системного администратора, о котором и идет речь этой статье
Плюсую, 2 из 3 задач описанных ими я решал в статусе очень начинающего админа.
Про терминологию: в статье я сознательно использую «DevOps» в том виде, в каком эта роль часто существует на практике в небольших компаниях — как совмещение администрирования, эксплуатации и ответственности за прод.
Не хотел и не хочу «демонизировать» DevOps как культуру или профессию, а просто привел пример жизненного опыта и конкретного ожидания со стороны бизнеса. В целом как раз и пишу о том, что такое размытое понимание роли — проблема. Вот цитата "из-за непонимания DevOps-культуры, эта должность имеет более широкое понимание."
Что касается менеджмента и HR — вы правы, их фейлы здесь тоже есть, и немалые. Отсутствие чёткой модели доступа, контроля и разделения ответственности — это управленческая зона, и именно это я считаю одним из ключевых выводов из истории, пусть, возможно, в тексте это не прозвучало достаточно явно.
Про задачи — да, часть из них действительно решается начинающим админом. Но сама история не про сложность задач, а про последствия концентрации критических доступов и ответственности в одних руках без процессов и контроля.
"В отношении бэкапов базы данных. Да конечно же они делались. Но были С. так же уничтожены."
Вот это странно. У нас например можно записать на бакап данные, но стереть оттуда ничего удаленно нельзя. А доступы вы по идее поменяли везде перед его увольнением и доступ был на какой то один продуктовый сервер (я так из статьи понял). Вряд ли у вас всё на одном серваке жило/живёт.
Ваше руководство лопухнулось и речь придется вести с позиции руководителя, а не инженера.
Не будем сейчас тут развивать про РБАК, оно и так понятно... но если у конторы нет денег на РБАК то будет как будет.
Руководство назначило на должность не просто девопса или сисадмина, а фактически ему были делегированы полномочия кусочка CIO и CSO. И это ключевое!
Увольнение таких людей не готовится как "сменили пароли". Увольнение начинается с найма человека который медленно и печально входит в курс всех вопросов и перехватывает все задачи. Это дешевле выйдет чем случайные бекапы искать.
Были ли у вашего С. причины так поступить или просто человечек с червоточинкой здесь неважно, в данном случае это чистой воды просчет руководства конторы, а не результат недостатка бюджета.
Побойтесь ДевОпса, сударь…