- Главная
- Технологии
- Теневая зона подрядчиков: как бизнес теряет контроль над доступами
Теневая зона подрядчиков: как бизнес теряет контроль над доступами
Эксперт назвала три самых распространенных сценария
Автор: эксперт в области информационной безопасности, руководитель Target
Information Security Лаура
Тлепина
Киберриски в бизнесе чаще всего связывают с внешними угрозами, но на практике одна из самых дорогостоящих и недооцененных зон риска - это подрядчики - интеграторы, разработчики, сервисные инженеры, аналитики, аутсорс-поддержка. Они получают доступ быстро, часто «временно» и шире, чем это действительно необходимо для задачи. После окончания проекта доступы, ключи, технические учетки существуют гораздо дольше, чем срок самого договора. В итоге компания теряет не только контроль над тем, кто заходит в систему, но и над тем, как это расследовать и доказать.
Для бизнеса Казахстана это уже не вопрос хорошей практики, а вопрос зрелости. Закон о персональных данных предъявляет к конфиденциальности и защите требования не только к собственникам и операторам, но и третьим лицам, получающим доступ. Единые требования к информационно-коммуникационным технологиям (ИКТ) и информационной безопасности (ИБ) предусматривают присвоение и управление правами доступа, журналирования и мониторинга, а для негосударственных систем, интегрированных с госсистемами, действует отдельный контур мониторинга. Итог простой - работа с подрядчиками должна быть построена на именованных аккаунтах с ограниченными по времени правами, отдельном подрядном контуре.
Главная ошибка многих компаний - считать подрядчика «своим человеком, только не в штате». С точки зрения современной архитектуры доверия - это не так. Для бизнеса это означает: подрядчик - не «гость в системе», а внешний субъект с внутренними правами.
Если подрядчик заполучил доступ к персональным данным, сфера регулирования становится еще более жесткой. Закон о персональных данных определяет третье лицо как лицо, которое не может считаться субъектом, собственником или оператором, но связано с ними соответствующими отношениями; он же возлагает на собственника, оператора и третье лицо обязанность предпринимать необходимые меры по защите персональных данных. Более того, доступ к персональным данным должен быть запрещен, если собственник, оператор или третье лицо отказываются принимать на себя обязательства по охране конфиденциальности. И если произошло нарушение безопасности персональных данных, уполномоченный орган надо уведомить в течение одного рабочего дня с момента его обнаружения.
Именно этим и опасны подрядчики... Не в эмоциональном смысле, а в инженерном. Случается, они работают в привилегированном контуре: настраивают интеграции, ходят в прод, видят журналы, управляют сертификатами, могут подключаться к шлюзам или к базам и т.д. Если такой доступ выдан через VPN-профиль или общий API-ключ, то есть через механизм, который не задействует прозрачность действий, компания теряет именно базовую вещь - учет действий пользователей. А без отслеживания действий любой инцидент превращается в спор о версиях, а не расследование. Единые требования как раз требуют отдельной идентификации, управления доступом, регистрации событий и мониторинга действий пользователей.
Как показывает практика, серьезные инциденты почти никогда не случаются разово, они состоят из маловажных, временных решений. Ниже приведу три самых распространенных сценария.
Первый сценарий. Это общий административный доступ «на время внедрения». Подрядчику прямо выдается одна техническая учетка, потому что так быстрее. Проект закончен, учетку не деактивировали, несколько человек знают пароль, а через полгода уже и сама запись в системе не позволит выявить явной связи конкретных измений и конкретного исполнителя.
Второй сценарий. Подрядчик заходит как свой сотрудник. Подрядчику дают удаленный доступ в систему - через VPN. Дальше он работает почти так же, как обычный сотрудник. На первый взгляд это удобно, то есть можно быстро подключиться и все настроить. Но риск заключается именно в том, что если у подрядчика заражен компьютер или его данные попали к другим людям, в систему заходит уже не подрядчик. И тогда злоумышленник оказывается внутри - как будто он сотрудник компании.
Третий сценарий. «Это же просто тест». Чтобы все работало правильно, подрядчику дают реальные данные - клиентов, базы, персональную информацию. Логика простая - на «живых» данных легче настроить систему. Но проблема в том, что эти данные уходят в тестовую среду, где защита обычно слабее. И в этот момент происходит главное - данные выходят за пределы контроля.
Практические выводы просты. В контрактах с подрядами полезно фиксировать не только NDA, но и рабочую механику контроля: вписывать именованные учетные записи, запрещать передачу доступа коллегам и субподрядчикам без письменного согласования, требовать ключи и устройства, оговаривать работу с боевыми тестовыми данными, право заказчика получать логи и участвовать в расследованиях, уведомлять об инциденте, подтверждать удаление по окончании. Если подрядчик имеет доступ к персональным данным, то нужно связывать это с его статусом третьего лица и обязанностью принимать меры по защите данных, иначе договор красивый, а защита - факультативная.
Безопасность подрядчиков - это не война с людьми и не стремление усложнить жизнь бизнесу. Это способ вернуть управляемость в те моменты, когда компания растет, интегрируется, цифровизируется и больше зависит от внешних команд. Когда бизнес не может за один день назвать всех подрядчиков с доступом и отозвать его точно так же - это говорит не только о проблемах в ИБ, но и о слабом управлении процессами. Начинать стоит не с новой платформы, а с короткого аудита подрядных доступов, ключей, журналов. Это один из немногих проектов в информационной безопасности, который окупается еще до того, как успеет надоесть.
Краткий анализ подрядного контура можно вплотную начать с решения шести задач. Есть ли у вас полный список подрядчиков с действующим доступом к продакшену? У каждого ли именован аккаунт? Существует ли срок действия доступа и автоматическое отключение? Происходит ли вход через VPN, а не напрямую? Есть ли разделение человеческих и сервисных доступов? Уходят ли логи подрядного контура в SIEM? Если хотя бы на два вопроса ответ «нет» или «не знаю», проблема уже не только техническая, но и управленческая.
Читайте также
Биометрия без ошибок: как бизнесу внедрить новые требования и не создать риски
Государство требует от компаний более зрелого отношения к защите больших массивов персональных данных
При работе с материалами Центра деловой информации Kapital.kz разрешено использование лишь 30% текста с обязательной гиперссылкой на источник. При использовании полного материала необходимо разрешение редакции.
Вам может быть интересно
Читайте Kapital.kz в
