[Из Опыта] Информационная безопасность ч.1

С течением времени информационная безопасность, методы её преодоления, выстраивание защиты, тесты, а так же внутреннее устройство корпоративной ответственности и иерархии меняются из года в год и преобразовываются в нечто структурированное.

Сегодня я вам расскажу без раскрытия названий конкретных компаний и серьезных деталей как они устраивали свою политику информационной безопасности.

Первым делом, вы должны понимать, что довольно быстрая тенденция в информационной безопасности была достигнута всеми западными компаниями в ключе разделения общих доступов и ответственности.

А конкретно, есть глобальные роли в компании:

  • full-time employee, это работники, которые работают непосредственно на компанию, они прошли целиком и полностью процессы от Службы Безопасности, работают в тех же странах, где расположены офисы компании, платят налоги и т.п.
  • contractors, это работники по найму, которых специально наняла та же самая компания для выполнения своих задач на определенный срок, но из-за того, что это контракторы, компания, в двух словах, экономит на них.
  • 3rd party employees, или service employees, это «чернорабочие»; компания нанимает стороннюю компанию для привлечения дополнительных ресурсов в области разработки или сопровождения.

Влияние и ответственность обычно делится так:

Full-time > contractors > service

А на деле, между контракторами и сервис работниками чуть ли не пропасть. Но об этом могу рассказать в комментариях.

Теперь подробнее про информационную безопасность.

Тут очень все различается от компании к компании.

В серьезных компаниях, таких как X, не бывший Твиттер, (занимающейся электронным документооборотом законов в разных странах и областях, книг, статей и многим другим), вы обязаны будете подписать NDA, который будет в силе еще 2 года после прекращения работы с заказчиком.

Далее, как разработчик, вы получаете указания, что делать и куда заливать код. Все. Решения? Это не ваша обязанность. Идеи? Выразить можете, но вас никто не будет слушать, потому как вы всего лишь service employee (в простонародье - coding monkey). Единственный шанс, это протолкнуть какую либо идею даже не через своих руководителей, и не через контракторов (потому как они на себя такой риск никогда не возьмут, ибо своих задач хватает), а только через full-time employees, и то, если они будут заинтересованы так же как и вы в данном решении.

Доступы? Нужны запросы, которые обрабатываются единой системой и проверяются днями, даже если менеджер из full-time employees их попросит поторопиться.

Вы всегда будете ограничены, в особенности, если хотите сделать что-то новое, что-то, что не было ранее в компании. Потому как это риски на утечку данных, риски на потерю прибыли, репутацию и т.п.

Но это еще куда ни шло. Если вы разработчик, просто хорошо делайте свою работу и выполняйте указания процессов, которые есть в компании, на которую вы работаете. Если вы менеджер, нужно быть связующим звеном между «бизнесом» (тем самым заказчиком), и разработчиками; сделать «уютную» среду для их работы, чтобы не отвлекались и работали постоянно.

Продолжение следует.