Новому сисадмину дают полный доступ к серверу — обязательно ли проводить проверку безопасности?

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

Не давайте именной root-доступ никому. Вход только через аппаратные 2FA-ключи, а все вызовы через «sudo» должны мгновенно улетать на централизованный сервер логов, где записи нельзя стереть или подделать. Админ должен четко понимать: каждый его шаг оставляет неизгладимый след в аудите. Такая мера дисциплинирует лучше любых проверок.

С первого же дня не давайте человеку полный доступ. В Германии законный испытательный срок (Probezeit) как раз лучший инструмент для таких проверок на доверие. Первые полгода открывайте доступы постепенно: сначала дайте тестовые и dev-контуры а к проду подпускайте только в паре с тимлидом.

В ваших договорах SLA или соглашениях об обработке данных (AVV) с клиентами есть конкретные обязательства по проверке персонала? Иногда корпоративные клиенты прямо требуют наличия определенных сертификатов безопасности у сотрудников или прохождения ежегодных тренингов.

Десять лет назад из-за похожих опасений мы так зажали гайки новому сисадмину, что он на второй месяц уволился со словами «если вы мне не доверяете, зачем вообще нанимали». И был абсолютно прав. Теперь мы вместо всяких проверок безопасности очень глубоко копаем рекомендации при найме. Личный разговор с его прошлыми руководителями о том, как он ведет себя в кризисных ситуациях, дает куда больше инфы, чем любые бумажки.

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

P.S.: вопрос уже задавали ниже, ответ во втором сообщении.

Чтобы обезопасить инфраструктуру, внедрите три вещи: 1) Ограничьте прямой доступ к базам данных прода через VPN и привязку к IP. 2) Введите обязательное правило четырех глаз для критических изменений конфигурации. 3) Разверните единый IdP, чтобы при увольнении сотрудника все доступы отзывались в один клик.

Хорошо что вы создали эту тему.

Расскажу, что было у меня, вдруг пригодится. Безопасность не бывает абсолютной; цель — сделать атаку нецелесообразной.

Пишите, если есть вопросы, отвечу по мере возможности.

Спасибо, что написали об этом, это действительно так. Главное не цифра, а то, на основе чего она получена.

Главное не цифра, а то, на основе чего она получена. Если напишете результат здесь, это поможет и другим.

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

На этом всё, извините, если затянул.

Спасибо, что написали об этом, это действительно так. Непроверенная резервная копия — не резервная копия.

Я бы пошел этим путем.

Именно так, и при этом об этом мало кто знает. Безопасность не бывает абсолютной; цель — сделать атаку нецелесообразной.

у нас было так. при принятии решений записывайте и худший сцеенарий а не только лучший.

если на один вопрос вы получаете три разных ответа, вопрос задан неправильно но исправьте, если я ошибаюсь.

Буду рад, если напишете о результате.

Об этом много говорят, но у нас так никогда не было. Если делаете впервые, начните с малого, масштабирование потом.

Пишите, если есть вопросы, отвечу по мере возможности.

Сведу тему в кучу, так как ответов было несколько разных. Большинство инцидентов начинается не с уязвимости, а с украденного пароля.

Если делаете впервые начните с малого, масштабирование потом. Конечно если ваша ситуация отличается, всё меняется.

Полностью согласен. Ответ сильно зависит от отрасли, универсального правила нет.