С точки зрения службы техподдержки, что позволяет как можно быстрее и проще удовлетворить заявку пользователя — то и хорошо. С точки зрения Службы Безопасности — это совсем нехорошо, а нужно делать максимально безопасно.
Беда в том, что чем выше требования к безопасности, тем больше неудобств для пользователя. В результате служба поддержки и пользователи начинают изобретать «обходные пути», а СБ — ещё больше закручивать гайки. Всё это выглядит как змея, проглотившая свой хвост. Если ничего не делать, то можно в итоге прийти к полностью неработающей системе.
В свою очередь, если одна из служб получает карт-бланш, она начинает «грести под себя». Любой перекос в ту или иную сторону отрицательно сказывается на бизнес-процессах и существовании организации в целом.
Как избежать подобных проблем и как выстроить работающую схему взаимодействия между этими, казалось бы, противоречивыми подразделениями?
Не работает, зато в безопасности
Когда представители СБ хотят показать «кто в доме хозяин», это вполне житейская ситуация. Но если это стремление поддерживает руководство — нормальную работу бизнес-процессов организовать достаточно трудно.
Обратите внимание, что несмотря на поддержку со стороны руководства, СБ демонстрирует полный отрыв от целей и задач бизнеса, и такая политика в итоге рано или поздно вступает в противоречие с линией руководства. Хотя, если честно, «тащить и не пущать» — это уже не политика, а прямое вредительство.
Разумеется, как бы не хотели представители СБ, никто не даст просто взять и самолично перекрыть те или иные ресурсы, потому что такая «забота о безопасности» на деле приведёт к коллапсу бизнес-процессов. Однако там, где нельзя перекрыть, можно создать невыгодные условия, чтобы сотрудники лишний раз побоялись заикнуться о расширении возможностей.
Одна из типичных проблем конфликта между СБ и техподдержкой — длительный процесс получения доступа к необходимым ресурсам. Всё делается для того, чтобы пользователь, столкнувшийся с раздутой бюрократической процедурой, отказался от своей затеи.
В итоге стремление СБ «всех поставить на место» просто душит полезную инициативу, заставляет сотрудников прекратить даже задумываться над новыми идеями и перспективами для развития. Потому что лишний раз иметь дело с раздутой бюрократической процедурой никто не хочет.
Пример из жизни:
В одной российской компании, если требуется открыть порты на шлюзе, например, для доступа к облачному сервису, необходимо заполнить длинную форму, содержащую полное доменное имя рабочей станции (FQDN), точную версию операционной системы, MAC адрес сетевой карты, IP адрес, маску подсети и шлюз по умолчанию, имя пользователя, имя домена, номер порта, тип протокола, точное наименование сервиса и другие сведения технического плана.
Если интерфейсов несколько, то подобную информацию нужно представить по всем интерфейсам, вне зависимости, будут ли они участвовать в установке соединения.
При этом заурядное открытие портов называется не иначе как «спецдоступ», пользователь обязан распечатать и подписать специальное «Заявление на предоставление спецдоступа» и подписать её не только у своего руководителя, но и «этажом выше», так сказать у «начальника начальников».
Разумеется, обычный офисный пользователь не всегда может собрать требуемые сведения. В итоге эта работа ложится дополнительным грузом на техподдержку. Высшее руководство тоже не всегда готово принять рядовых сотрудников по таким «личным» вопросам. В итоге всё как в басне Крылова: «… а воз и ныне там»
Если это коммерческая компания, то она потихоньку сохнет, вянет и сдаёт позиции. Но если бизнес достаточно большой, то его разлагающееся тело ещё долго может плыть по течению, производя впечатление живого организма.
В погоне за KPI
Иногда руководство стремится максимально оптимизировать затраты на ИТ, вводя поминутный контроль за рабочим временем сотрудников ИТ департамента.
Например, объявляется, что время исполнения заявки не должно превышать 7 минут.
«И ведь хороший показатель! Почему это пользователь, который приносит деньги, должен чего-то ждать?»
Такие драконовские меры подталкивают техподдержку именно к самым примитивным решениям. Например, у пользователя не открывается подозрительный сайт по причине блокировки на шлюзе. Но, вместо того, чтобы писать заявку и разбираться, почему заблокирован тот или иной Интернет-ресурс, поставим пользователю Tor-браузер и научим пользоваться. А что, дёшево и сердито!
Заблокировали USB порты на компьютере, строжайше запретили выносить любую информацию на съёмных носителях — не беда, есть сервисы вроде Filedrop, просто и удобно. Пользователю же работать надо!
И так во всём. «Быстрее! Ещё быстрее! Время пошло! С каждой минутой ускользает драгоценная премия всего отдела!»
Если руководство компанией одновременно требует закрутить гайки в плане безопасности и кошмарит техподдержку на предмет «повышения клиентоориентированности», то ситуация будет только ухудшаться.
Случай из жизни:
В одной банковской структуре один из топ-менеджеров побывал на банковском форуме и увидел, как его коллеги просматривают почту с корпоративного Exchange прямо с мобильного телефона через специальное приложение (это важно!).
И конечно, возжелал того же у себя. Однако его устаревший смартфон не был предназначен для таких вещей. Но на все возражения что, для этого устройства нет проверенного клиента Exchange, а найденный на «левых сайтах» программы небезопасны и вообще не факт, что будут стабильно работать, что настроена OWA и ранее от СБ стояла задача всё закрыть по максимуму, прозвучал такой аргумент: «А за что я вам тогда плачу деньги? Я к этой мобиле привык, менять не собираюсь! Всё, время пошло!» При этом дать обратную связь по итогам проверки на своём смартфоне категорически отказался. Как хочешь, так и настраивай вслепую.
По воспоминаниям руководителя отдела поддержки: «… Мы тогда после этого «наезда» в панике немало «дырок» на ISA Server проковыряли, мало понимая, что вообще делаем. Хватило бы на всех «юных хакеров» и ещё бы осталось про запас… Про безопасность никто даже не заикался».
Один за всех, но не все за одного
Самая интересная ситуация возникает, когда в организации есть только один системный администратор, он же специалист по безопасности. То есть и за безопасность, и за поддержку пользователей на 2 линии отвечает 1 человек.
Примечание. Ситуация, когда в компании нет выделенного отдела СБ, а за безопасность отвечают те же люди из отдела ИТ, что и за техподдержку 1-2 линии — такое встречается сплошь и рядом. Поэтому «разбор полётов», описанный ниже, подходит и для ИТ департаментов и подразделений, состоящих из нескольких человек со схожим набором задач.
Такой хороший парень!
Если админ склоняется в сторону «клиентоориентированного подхода» и намерен обеспечить работу пользователей любой ценой по принципу «цель оправдывает средства», то степень дырявости системы прямо-таки зашкаливает.
Времени и сил не хватает даже на простые действия для защиты системы. Например, обновить прошивку на единственном Интернет-шлюзе ему просто некогда. Да что там шлюз, даже до элементарной подстраховки вроде резервного копирования жизненно важных файлов «просто не доходят руки».
Причём делает он это совершенно не специально, он просто за ни за чем не следит. В итоге уязвимости копятся… пока не случится реальный серьёзный инцидент. И тогда все почему-то забывают, какой это замечательный бескорыстный человек и скольким людям он помог, зачастую в ущерб своему личному времени. Наш хороший парень в глазах начальства и остальных сотрудников превращается в безответственного разгильдяя, прощелыгу и просто лузера.
Встречайте антихакера
Другая крайность — когда админ воображает себя крутым «антихакером» и все силы, время и ресурсы тратит на выстраивание защиты из серии «чтобы мышь не проползла». В результате вся IT инфраструктура, кроме, элементов ИБ, таких как Интернет-шлюз, приходит в плачевное состояние. Пользователи не могут отправить электронную почту, распечатать файл на сетевом принтере и даже просто нормально залогиниться в домене AD.
Даже простой запрос о создании общей папки внутри сети выглядит в его глазах как вредительское стремление «понаделать дыр в защите».
Если организации потребуется беспроводная сеть WiFi, то такой «супер-безопасник» будет с пеной у рта доказывать, как это вредно и плохо, и вообще это бесполезная и ненужная технология, которая предназначена только для того чтобы сидеть со смартфонов в соцсетях.
В итоге пользователи всё равно находят способ обменяться файлами, отправляют письма клиентам с личных бесплатных почтовых ящиков (для этого бегают через дорогу в ближайшее кафе, где есть WiFi), переносят часть работы домой — просто админу про это не говорят.
Пример из жизни:
В небольшую компанию: офис на 110 пользователей, плюс региональная сеть из 5 филиалов приходит новый системный администратор. При подборе HR менеджер руководствовалась полным набором клише: молодой, энергичный, амбициозный, готовый работать сверхурочно по ненормированному графику и расти вместе с компанией.
Первой его реакцией было: «Тут всё «дырявое» и надо переделать!» Поначалу руководство с энтузиазмом отнеслось к его инициативе: «Ну надо, так надо, давайте обезопасим нашу компанию, хуже не будет». Но вот дальше началось самое интересное…
Амбициозный и энергичный системный администратор понимал под словом «безопасность» довольно специфичную программу действий. В первую очередь снёс исправно работающий шлюз на FreeBSD с IPF и установил на этом же «железе» новый, на базе Fedora Linux. Неопровержимые аргументы: «FreeBSD, фу, отстой» и «Fedora c iptables гораздо круче».
Естественно, он не сохранил конфигурационные файлы со старого шлюза, которые хоть немного, но могли бы помочь перенести уже «выстраданные» файервольные правила и, тем более, не проводил аудит, не составлял какого-либо плана и т. д. Ему хотелось всё настроить за один вечер после работы.
В результате установка и настройка затянулись на всю неделю, включая выходные, а новый шлюз так толком не заработал, так как его создатель хотел всенепременно настроить с максимальным уровнем безопасности, а разбираться с открытием портов для каждого сервиса ему не хотелось. Проще было всё перекрыть и ждать, пока кто-нибудь прибежит со скандалом по поводу очередного неработающего сервиса, потом искать по форумам, как это «починить».
Следующим его деянием была ликвидация файл-сервера на Windows, являющегося членом домена Active Directory с работающими политиками и настройкой доступа, потому что: «Винда — это небезопасно». Взамен был установлен Fedora Linux, для доступа к файлам использовалась Samba. Авторизации в домене не было, поэтому техподдержке теперь было нужно создавать пользователей не только в домене AD, но и на на сервере Samba. При этом по замыслу создателя такой «хитрой схемы» было необходимо отслеживать, чтобы пароли AD и Samba на Linux совпадали.
И третьим подвигом нашего героя был снос корпоративного антиспама на базе коммерческого продукта и установка SpamAssasin. Всё размещалось на том же шлюзе с Fedora Linux.
Называется, «сэкономил деньги компании».
Надо отметить, что лицензии на коммерческое ПО в полном объёме у компании уже были куплены, но этот факт совсем не волновал яростного борца с «небезопасным наследием».
Пока совершались «подвиги», следить за состоянием инфраструктуры абсолютно не было времени. Позже все ресурсы уходили на устранение появившихся ошибок и сбоев.
Новый антиспам безжалостно резал письма от клиентов. Тем временем из-за полного отсутствия контроля кончилось место на почтовом сервере Exchange, и он попросту рухнул из-за нескольких раздутых ящиков особо креативных пользователей. В итоге весь отдел продаж перешёл на бесплатные ящики на публичных почтовых сервисах.
У бухгалтерии была масса вопросов по поводу перебоев в работе их СУБД и системы бухучёта в целом.
Резервного копирования тоже не было. Точнее, сама система СРК досталась от прошлого админа в рабочем состоянии, но за ней никто не следил. И когда бухгалтерия попросила откатить базу данных на пару дней назад, сделать это было невозможно.
В итоге руководство, устав от жалоб пользователей, приняло решение об увольнении «крутого антихакера». На прощание он бросил фразу: «Вы ещё обо мне вспомните, когда тут всё взломают!»
Вместо него приняли другого системного администратора, не такого энергичного и амбициозного, скорее малость ленивого, о чём свидетельствовали лишний вес и неторопливая походка вразвалочку.
Новый админ ещё некоторое время разгребал завалы в супер-безопасной системе, но в итоге всё заработало как часы. В последствии его тоже уволили, но уже с аргументом: «Зачем ты нам тут нужен, если всё работает?» Кстати, благодаря наследству «ленивого админа» так никто ничего и не взломал.
Раздвоение личности
Самый же безумный вариант, когда админ в одиночку пытается честно исполнять обе функции: ИБ и техподдержка. Тут возможны совершенно разные ситуации: от когнитивного диссонанса до раздвоения личности. Самое простое, что может быть — частые смены настроения. Сегодня он не выспался и поэтому вживается в роль «крутого безопасника», чтобы всех «жучить». Завтра, пребывая в отличном расположении духа, этот же человек в глазах пользователей будет выглядеть добрым волшебником, который легко решает любые проблемы простым взмахом руки.
Такая ситуация порождает просто изумительные по противоречивости решения. Например, нестандартное изменение схемы Active Directory с написанными вручную скриптами контроля и тут же единственное правило «any to any» на файерволе Интернет-шлюза.
Как надо
Обозначить проблему и не указать пути решения — значит потратить время зря. Но в то же время нужно отдавать себе отчёт что не существует универсальных рецептов, особенно когда дело касается человеческих взаимоотношений.
Поэтому возможно определить несколько общих принципов, соблюдение которых поможет избежать описанных проблем.
Основные принципы здорового взаимодействия
1. Коллегиальный характер работы с выработкой общей стратегии.
Обратите внимание, что это именно взаимодействие коллег, равных по статусу, а не «взятие под козырёк», потому что кто-то главнее.
И техподдержка и СБ должны иметь равные права и мнение каждого должно учитываться. Конечное слово в разрешении споров принадлежит руководству.
2. Минимум бумажной волокиты.
Бесполезно проводить какие-либо реформы, если они тонут в море бумажной волокиты. Окружить себя регламентами, формулярами и прочими «документами под роспись» — любимая тактика СБ. Вот только вреда от этого гораздо больше, чем кажется. Лучшая тактика в организации документооборота — здравый смысл и здоровый минимализм. Например, если по имени рабочей станции можно определить IP адрес, а по IP — MAC адрес, не говоря уже про маску подсети, то нет смысла кошмарить пользователя сбором всех подробностей.
3. Мониторинг и автоматизация. Использование инструментария.
Мониторинг, помимо отслеживания нарушителей, помогает понять, какие меры безопасности являются действительно эффективными, а какие — «для галочки». Например, SecuReporter позволяет формировать подробные отчёты по состоянию «здоровья» в плане ИТ безопасности. Использование специальных приложений типа Application Patrol позволяет выработать гибкую политику безопасности для защиты работы офиса. Вообще, использование скриптов, применение политик и другие средств автоматизации позволяют снять бремя рутинной работы с ИТ персонала в том числе при обеспечении мер безопасности.
4. Разъяснительная политика среди пользователей.
Идею нельзя победить запретами. Можно только противопоставить другую идею. Поэтому если кто-то до сих пор вывешивает пароль на бумажке возле монитора или открывает фишинговые письма — это значит, что с разъяснительной работой среди пользователей дело обстоит не так хорошо.
И добиться понимания и доброжелательного участия проще именно сотрудникам техподдержки, так как они больше взаимодействуют с пользователями и знают их характер и привычки. Поэтому сотрудничество между ИБ и поддержкой всегда выгодней сепаратизма.
Так что делать если системный администратор работает в одиночку?
Рекомендуется время от времени заказывать сторонний аудит, чтобы ликвидировать уязвимости, которые не успел ликвидировать сисадмин.
Внимание! Аудит — это НЕ репрессивная мера и НЕ показатель для «оценки персонала ИТ» с целью лишения премии и экономии на зарплате. Это ещё одна проверка «на всякий случай». А случаи бывают разные.
