Comments 13
Спасибо вам большое за рецепт.
Но проблема шире, большинство ходят на гугл-сервисы из броузера, а там SSL-pinning и даже внесение корпоративного MITM-сертификата в доверенные через групповые политики не помогает.
Ситуация в целом критическая, т.к. все больше и больше хостов, даже тех, где это не нужно по большому счету не поддается декрипту, что сильно снижает уровень ИБ и напрямую нарушает требования некторых отраслевых стандартов ИБ.
Как по мне, броузер должен иметь т.н. "корпоративный" режим, когда контроль на сертификат снимается, и проверка идет через доверенные сертифкаты в ОС.
Кто как решает эту проблему? Может есть сборки броузера с отклченным SSL-pinning?
Ну ssl pinning для того и создавался чтоб его нельзя было ( читай не так просто ) можно было обойти.
Для GooleDrive, Google Table, Google Word точно пининг не используется. Ни в броузере ни в приложениях. По другим приложениям или сервисам не скажу.
Это хорошая и правильная штука для личного испольвоания, что бы правительства не могли перехватывать рпиватную почту например. Но в корпоративной среде совсем другой подход и требуется полный контроль за всем что происходит, ка кна ендпоинте, так и на периметре. Поэтому по моему мнению у броузеров должын быть "корпоративный режим". Вернее он и так уже есть, многие вещи через групповые политики можно настраивать, ограничивать но вот ssl-pinningом управлять пока невозможно.
Не должен, в будущем же нас ждет eSNI ECH который положит конец таким корпоративным исторям (в особенности в связки с DOH).
То что работадатель использует SSL decryption вообщем то показывает его отсталость. т.к сейчас в моде вообще то ZeroTrustNetworks.
Если работадатель хочет все делать по старинке - есть VDI c любыми фильтрами и белым списком ПО, но вообщем то эта практика для 3,5 компаний (например - банки) и то не для всех сред, а только обычно для тех кто работает с продом.
Особая красота наступает в тот момент, когда "для сохранения безопасности" на VDI начинают пересаживать разработчиков.
Обязательным бонусом на VDI будет подмена SSL сертификатов (часть софта после этого просто перестаёт работать сообщая о повреждённом интернет-соединении) и блокировка "сомнительных сайтов-помоек" типа докерхаба и гитхаба (некоторые языки там хранят свои библиотеки). И вдруг оказывается, что половина разработчиков уже ищет новое место работы (где за те же деньги не будет такого ужаса), четверть готова работать в таком режиме и самостоятельно переписывать все библиотеки и даже полезные для работы инструменты (задача вместо рабочего дня будет занимать рабочий месяц, но, как говорится, "любой каприз за деньги работодателя"), а оставшиеся ищут способы обойти ограничения ИБ и в большинстве случаев - успешно их обходят, иногда по незнанию создавая ещё больше уязвимостей, чем было до внедрения "супер-безопасных VDI".
Ну да это из книги вредных советов, чаще всего что можно пересадить на VDI: фронт офис, и (в крайнем случае) отвечающих за настройки CI/CD на проде. (devops) Все остальное конечно лучше не ограничивать никаким VDI а то будет как@vp7написал
разработку вообще лучше выносить в отдельную зону с пониженными ограничениями, ибо нормально работать будет сложно. Диверсифицированное управление рисками никто не отменял.
Сильно снижает уровень ИБ как раз подмена сертификата: шлюз/proxy становится точкой через которую проходят все пароли и прочая конфиденциальная информация проходят в открытом виде. Сам пользователь не в состоянии проверить достоверность целевого сайта. И вообще конечный пользователь перестаёт нести какую-либо отвественность, т.к. в итоге его данные может читать и подменять неопределённый круг лиц обслуживающий эти proxy подменяющие сертификаты.
Что касается удобства разработчиков на макбуках с sudo, упомянутого @shifttstas - вся эта свобода более-менее работает при разработке web-, облачных, всяких saas-сервисов, т.к. лицензии на код много чего позволяют для конечного использования. Если писать ПО для продажи - начинается ад учёта совместимости даже открытых лицензий.
Ещё бы с ЯндексДиском разобрались, вообще цены бы вам не было!
Нашел официальное решение в глубинах https://support.google.com/ поэтому внес измения в текст статьи. никаких лайф-хаков. все по документации!
GoogleDrive with SSL decryption