[Из Опыта] Информационная безопасность ч.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 их попросит поторопиться.
Вы всегда будете ограничены, в особенности, если хотите сделать что-то новое, что-то, что не было ранее в компании. Потому как это риски на утечку данных, риски на потерю прибыли, репутацию и т.п.
Но это еще куда ни шло. Если вы разработчик, просто хорошо делайте свою работу и выполняйте указания процессов, которые есть в компании, на которую вы работаете. Если вы менеджер, нужно быть связующим звеном между «бизнесом» (тем самым заказчиком), и разработчиками; сделать «уютную» среду для их работы, чтобы не отвлекались и работали постоянно.
Продолжение следует.