Пароль «123456» открыл базу 8,8 млн человек
В Дании хакер вошёл в госреестр населения, введя пароль «123456» у небольшого ИТ-подрядчика. Утекли данные почти 9 млн человек.
Небольшая датская ИТ-компания имела авторизованный доступ к реестру населения страны. Защита её систем держалась на пароле «123456». Хакеру хватило подбора: через подрядчика он дошёл до госплатформы и выгрузил персональные данные нынешних и бывших граждан.
Мораль не в том, что «датчане расслабились». Слабое звено в таких историях почти всегда не сам реестр, а подрядчик с доступом к нему. Вы можете выстроить идеальную защиту у себя, а ключи будут лежать у внешней компании, где пароль не меняли годами.
Чем это грозит бизнесу
• Данные клиентов и сотрудников попадают в чужие руки, а отвечать за утечку придётся вам, а не подрядчику.
• Бизнес встаёт, пока разбираются, что именно украли и как давно.
• Клиенты уходят: доверие после утечки возвращается дольше, чем закрывается дыра.
Что делать и что изменится
1. Составить список всех подрядчиков и сотрудников с доступом к вашим системам. Было: никто не знает, кто и куда имеет доступ. Стало: вы видите всю картину и закрываете лишнее.
2. Включить двухфакторную защиту на всём, что смотрит наружу. Было: подобранный пароль равен полному доступу. Стало: украденный или угаданный пароль сам по себе ничего не открывает.
3. Запретить простые пароли и хранить их в менеджере паролей. Было: «123456» и один пароль на всё. Стало: у каждого сервиса свой пароль, который не подобрать.
4. Закрывать доступы сразу при завершении работы с подрядчиком или увольнении сотрудника. Было: учётки живут годами. Стало: бывшие подрядчики и сотрудники ничего не открывают.
Эти четыре шага не требуют отдельного отдела безопасности: обычно хватает пары дней и одного человека, который доведёт дело до конца. Для сравнения: цена утечки несопоставимо выше стоимости такой проверки.
· 14.10
Ну, это же элементарно. Дополнительное соглашение к договорам с подрядчиками - Раз в месяц владелец в интересах безопасности и т.д. обязует менять доступы или они будут меняться автоматически. Кто забудет, свяжется с владельцем и после авторизации получит доступ обратно. А против человеческого фактора ничего сделать нельзя. Да и AI уже не дремлют.
Да и доступ обеспечить не по паролю, а по сертификату, сложнее подделать и проще отозвать для плановой смены. Ну, и как писал автор, двухфакторная аутентификация - вариантов вагон и маленькая тачка 🙂.
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
коммент удалён
· 14.10
Николай, смена доступов по регламенту и сертификаты вместо пароля — рабочая связка, согласен. Сертификат действительно закрывает главную дыру из поста: его не подберёшь перебором, как «123456», и отозвать проще, чем менять пароль везде вручную.
Но тут есть нюанс из практики именно таких историй: регламент «раз в месяц меняем доступы» часто живёт только на бумаге, пока кто-то конкретный не отвечает за его исполнение. В кейсе с оптовой фирмой из разбора учётка уволенного менеджера была активна девять месяцев — то есть формально регламент мог существовать, а по факту никто не проверял его выполнение. Поэтому в моём списке шагов на первом месте не технология доступа, а ревизия: кто и куда имеет доступ прямо сейчас. Сертификаты и автоматическое протухание доступов — это следующий, уже более зрелый уровень поверх этой ревизии.
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён