Минкомсвязи начало проверку после сообщений об утечке данных 28 тысяч клиентов Госуслуг Статьи редакции
О возможной утечке из-за неверной конфигурации одного из серверов рассказало издание «Коммерсантъ».
Основатель сервиса DeviceLock Ашот Оганесян рассказал изданию «Коммерсантъ» об утечке персональных данных более 28 тысяч пользователей Госуслуг одного из российских регионов, предположительно Ханты-Мансийского автономного округа.
По его словам, информацию можно было скачать на одном из форумов, специализирующихся на утекших базах данных. Среди выложенных данных — ФИО, дата рождения, СНИЛС, ИНН, номер телефонов, электронная почта, информация о детях и другая персональная информация.
Оганесян проанализировал базу данных и выяснил, что она была получена из-за ошибки в конфигурации Elasticsearch-сервера, в результате которой сервер оказался в свободном доступе. Он был проиндексирован поисковиком Shodan 3-го декабря 2019 года — данные могли находиться в открытом доступе как минимум с этой даты, пишет «Ъ».
Также на сервере находились токены авторизации для доступа в личные кабинеты с мобильных устройств и другая информация.
Представители Минкомсвязи сообщили, что системы работают в штатном режиме, а уязвимость была закрыта. Министерство начало проверку возможного инцидента.
До последнего не хотел регистрироваться на гос.услугах. Понимаю, что в России, данные вообще не защищены и спокойно можно купить любую базу в том числе гос.услуг. Эх, погнался за скидкой на загран.паспорт
Ну на самом деле у эластика с коробки нет авторизации, ее можно только за бабки прикрутить. А используют его очень многие, а платят за платную редакцию очень немногие, так шо по такой логике нигде не нужно регаться. Тут нет косяка государства, это чисто косяк какого-то админа, который зачем-то пробросил сервер с эластиком во внешнюю сеть. Да и если дальше шерудить, то например у стандартной поставки редиса из докера, тоже нет логина/пароля, через костыль надо прикручивать, монгу тоже можно спокойно с пустым паролем использовать.
В ES вообще-то есть как минимум авторизация по логину паролю из коробки. Но уже не раз были подобные инциденты с не настроенной авторизацией, и в тоже время удивительно, что в гос. организациях в принципе во внешку открывают нестандартные 9200, 9300.
У Redis есть --requirepass, который отлично отрабатывает и в docker'e безо всяких костылей... надеюсь вы всеже не сис. админ гос. услуг...
Из коробки она триальная, то ли 30, то ли 45 дней по моему она была, дальше плати. Общепринятая авторизация, это через env когда задаешь, а не мутишь с параметрами запуска, либо ебешься с параметрами конфига очередного сервиса.
Ничего триального там нет, более полу года в Swarm стоит ES без проблем.
И если для вас .env - это максимально допустимый комфортный предел при работе с Docker - то у меня для вас плохие новости.
Потратить минуту на Dockerfile со своими параметрами запуска (если часто развертываете - можно и образ в свой реестр запушить), либо docker-compose (если используете его), либо аргумент в docker run... и всего-лишь что-то из этого на выбор... ну такая себе ебля...
Хех, я специально щас заглулил, там авторизация бесплатна стала совсем недавно, тебе просто повезло. Если загуглишь на эту тему, то найдешь тону постов на тему того как врубить аутентификацию, или как его закрыть в сети. Плюс госуслуги старый сервис, а в еластике начиная с какой-то версии, было сильно переделано api и соответсвенно на новом сидеть не могут, иначе пришлось было сильно много рефачить.
Что касается настройки через env, то по аналогии с аджайл манифестом, есть принципы разработки по, в которых этот момент обозначен, и там же обозначены причины по которым так нужно делать, а не собирать и пушить 100500 сервис, из-за того разработчик не в состоянии довести свой продукт до ума.
Во-первых: если даже отбросить бесплатную авторизацию из коробки - есть вполне рабочий универсальный метод реверс-прокси, которым любой компетентный системный администратор должен владеть (я даже не говорю про devops) - это в случае, если по ряду причин не удается построить изолированную сетевую инфраструктуру.
Во-вторых: пугают в принципе посты с вопросом о том, как закрыть сервис для внешки - таких вопросов быть не должно у сотрудников компаний, которые занимаются хранением и обработкой чувствительных данных пользователей, который тем более попадают под закон о хранении персональных данных - тут уже вопрос компетенций.
В-третьих: Очень хотелось бы увидеть документы с озвученными вами принципами и причинами разработки под Docker с обязательным указанием всех возможных параметров в .env
https://12factor.net/
Тут речь идет о web-app или SaaS к тому же тут явно сделан акцент на облако (Heroku?), что не одно и тоже с Docker.
Я и не отрицал, что если разворачивать на облаке, например том же Heroku какой-нибудь Laravel - то в env необходимые настройки можно (нужно) прописывать.
Но это далеко не тоже самое, что аргументы запуска приложения в контейнере, и что если приложение всего лишь часть огромного стека в docker-compose с общим файлом окружения, и, например, при запуске придется каждый раз перебирать все возможные аргументы, проверять на существование, и клеить в параметры запуска... ну бред же, еще и docker-entrypoint загадится.
Не вижу проблемы запускать самому с нужным параметром исполняемый файл - это на раз-два. Другое дело, как например смена часового пояса в официальном образе MySQL в Docker... вот тут действительно придется потратить время, и матюгнутся в адрес тех, кто его собирал.
О любом, проблемы везде схожи. В общем не парься, с опытом сам какому же придёшь.