Памятка по обращению с секретами

Введение

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

Компрометация - это не только факт доступа третьего (постороннего) лица к секрету, но и подозрение на такой доступ.

В человеческой среде невозможно в полной мере гарантировать сохранность секретов от компрометации. Но это не значит, что не нужно стараться минимизировать риски.

Целью данного документа является обозначение некоторых правил работы с секретами, объяснение и рассмотрения практических кейсов.

Правило №1

Сразу отказывайтесь от использования скомпрометированных секретов. Оповещайте заинтересованных лиц о факте компрометации.

Это значит, что если был скомпрометирован пароль, то его следует сменить в системе, для которой он был предназначен.

Если это приватный ключ, то, соответственно, следует выпустить новый ключ. И так далее. Делать это следует незамедлительно.

Заинтересованными в оповещения лицами могут быть:

Те кто предоставил вам этот секрет
Создатель секрета
Пользователи секрета
Служба безопасности

Чтобы осознавать риски и понимать, в каких случаях может произойти компрометация, выделим два типа секретов:

санкционированная компрометация - ситуация когда сотрудник, который владел предоставленными ему секретом, уволился, либо по другой причине этот сотрудник больше не должен владеть этим секретом в связи с утратой разрешений. Как правило такая компрометация предсказуема и к ней можно подготовиться.
несанкционированная компрометация - более опасная компрометация секрета, когда передача секрета осуществляется не санкционировано, например, в результате ошибки, безответственности, атаки или взлома. Компрометация в таком случае может быть спровоцирована безответственным хранением секретов на стикерах, на бумажных носителях выброшенных в урну или хранения секретов в сторонних системах, например, мессенджерах, облачных сервисах, таких как Google Docs, менеджеров паролей, таких как 1Password, и даже браузерах.

Ниже представлены 5 примеров компрометации . Красными стрелками отмечены факты несанкционированной компрометации, серой - санкционированные.

Давайте коротко опишем каждый из случаев:

Петя хранил пароли в Гугл. Но однажды, из-за сбоя систем безопасности Гугл, ряд учётных данных пользователей был слит в интернет, где злобный Анонимус их приобрёл за гроши - секрет скомпрометирован.
Света всё время забывала пароль от Passbolt и записала учётные данные на стикер, который чуть позже выкинула в урну. В результате доподлинно неизвестно, где этот пароль и может ли он быть кем-то использован - секрет скомпрометирован.
Женя случайно оставил секрет на компьютере друга когда был в гостях, а он занятный троль, зашел на наши сервера и удалил все деплои наших приложений - стоит говорить, что секрет был скомпрометирован.
Веня пользуется только WhatsApp, в результате чего злой ФСБ-шник Анонимус похитил пароль сразу, как только создатель пароля решил им поделиться с ним - секрет скомпрометирован.
Петя ранее предоставлял доступы Коле - менеджеру команды разработки "Софтина" для интеграции по API. Коля в свою очередь предоставил его Асе, разработчику клиента API. Наша компания больше не работает с "Софтина", но Коля и Ася до сих пор имеют доступы к нашему бэкенду - секрет скомпрометирован.

Случаев может быть множество, здесь выделены самые распространённые.

Стоит отметить что 1 и 4 случай особенно сложно распознать. Поэтому если вы пользуетесь менеджером паролей в браузере, то знайте, что такие браузеры как Chrome дополнительно умеют сканировать ваши пароли и искать их в базах утечек паролей, предупреждая о новых утечках. А сервис https://monitor.firefox.com/ позволяет искать вашу почту как логин в базе утечек и находить скомпрометированные учётные данные.

Правило №2

Используйте корпоративные системы для работы с секретами.

Чтобы минимизировать риск случаев 1 2 4 и иметь возможность быстро устранять случаи 3 5 используйте корпоративную систему хранения и предоставления секретов.

Для сотрудников Digital Clouds развёрнут версия системы Passbolt CE (pass.dclouds.ru).

Преимуществом этой системы является:

Использование сложного ключа с парольной фразой для доступа к системе.
Авторизироваться с ключом можно только имея доступ к электронной почте, которая указана в аккаунте пользователя.
Возможность создавать секреты, указывая дополнительную информацию (комментарии, URL)
Возможность делиться секретами с другими пользователями и группами
Браузерное расширение с авто-подстановка паролей в поле ввода учётных данных
Возможность пользоваться генератором паролей настраивая сложность пароля
Пароли хранятся на сервере в зашифрованном виде
Администратор не видит ваши секреты
При удалении вашего пользователя (например в случае утери доступа), администратор может выбрать приемника для секретов из лиц и групп которым ранее вы предоставили доступ к секрету.

Недостатком этой системы является:

Невозможно самостоятельно зарегистрироваться
Невозможно создавать группы не имея прав администратора
При удалении вашего пользователя, секреты, которыми вы ни с кем не поделились, удалятся.
Невозможно восстановить доступ при утере ключа шифрования

Давайте рассмотрим новую схему

Демиург разместил секрет в системе Passbolt и предоставил доступ к группе
Петя Group Manager решил предоставить доступ к секрету Зине.
Для этого Петя попросил Админа добавить Зину в систему
Админ добавил Зину. Регламент добавления пользователя в Passbolt отдельно прописан
Зина получила инвайт на почту и завершила регистрацию в системе. Теперь Зина может видеть пользователей системы и группы, но не секреты.
Петя видит, что Зина в системе и предоставляет ей доступы
Зина успешно пользуется доступом к секрету. И другим секретам, которыми с ней поделились
А что же насчёт Мирона, который улетел в Калифорнию работать в Apple? Доступ к Passbolt ему ограничивается, Демиург меняет пароль.
Все, включая Ксюшу, которая вообще не была в курсе происходящего, получают доступ к обновлённому секрету.

Passbolt упрощает управление секретами в команде. Благодаря одному каналу получения секрета, у Анонимуса меньше шансов его украсть. Теперь Анонимусу нужно целенаправленно атаковать Digital Clouds или сотрудников. Раньше это тоже было возможно, но теперь только это и возможно. Он не найдет пароль в урне, не сможет купить его на чёрном рынке после массовой утечки, а если все участники будут соблюдать чистоплотность, то некоторые секреты вообще никогда нигде не скомпрометируются.

Правило №3

Меняйте секреты для профилактики, особенно если приходилось делиться им вне системы.

К сожалению жизнь есть жизнь. И вам наверняка придётся отправить какой-нибудь секрет в чат Telgram или WhatsApp.

По идее, отправка секрета в чат Telegram уже является компрометацией, но в рамках данного документа, такое действие считается действием с повышенным риском компрометации, но не её фактом.

Для снижения риска компрометации некоторые могут использовать сервисы "шпионских записок", которые "сгорают" сразу после прочтения. В том же Telegram есть секретные чаты с авто-удалением сообщений. Однако риск компрометации остается всегда. Даже если вы доверяете сервису, вы не сможете знать наверняка, не было ли между вами и вашим собеседником Анонимуса.

Для этого я разработал простой сервис. https://notes.dclouds.ru - это максимально простой сервис, который шифрует записку и генерирует для неё секретный урл URL. При этом, на всякий, случай записка хранится на сервере в зашифрованном виде, чтобы немного выиграть время в случае обнаружения факта компрометации сервера. Для расшифровки записки используется правая часть URL (после точки). Серверу этот пароль неизвестен, он генерируется на клиентской стороне.

Вот пример секретного URL

Как только ваш собеседник получит секрет, секрет будет сразу же удалён из базы данных. Часто мессенджеры следуют по ссылкам, чтобы отобразить превью, для этого контент записки подгружается по AJAX.

Если ваш собеседник откроет ссылку, а записка будет уже недоступна, то он сообщит вам об этом. Это будет обозначать, что ваш секрет кем-то прочтён, а значит скомпрометирован.

Безопасность и стек сервиса вероятно будет доработаны. Но уже сейчас он позволяет отказаться от использования такого сервиса как privnote, который никак не гарантирует, что ваш секрет никто кроме вас и собеседника не прочтёт.

Правило №4

Проверяйте разрешения, подтверждайте разрешения.

Самое сложное - это контролировать распространение секретов в человеческой среде. Человек может скопировать секрет и не системно его распространять. При таком подходе компрометация секрета - дело времени. А вот обнаружение факта компрометации вопрос сложный.

Давайте рассмотрим ситуацию, когда Гриша, например, не владеет ключом от API, но он заинтересован в исполнении задачи которую поставил Гале. Он знает, что Федя владеет этим ключом и отправляет Галю к Феде.

Федя, в свою очередь, озадачен. К нему обратилось за последние 5 минут два человека, которые просят у него ключ API - Галя и Анонимус. Конечно, вы скажете, если соблюдено правило №2, то Галя бы попросила Федю поделиться ключом в Passbolt, а Анонимус был бы сразу вычислен. Однако могут возникать случаи, когда Анонимус необязательно злоумышленник, но любопытный или инициативный сотрудник, который и запросил секрет для своих нужнд у Феди в Passbolt, но доступ к этому секрету не желателен для этого сотрудника или вовсе запрещён по NDA. Федя не зря озадачен. Ему следует как-то уточнить разрешения этих персон относительно ключа и убедиться, что они не являются третьими лицами.

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

Федя всем отказывает и правильно делает.

На самом деле такой ситуации не должно происходить. Третье лицо не может распоряжаться секретом заочно, отправляя за ним сотрудников к другим сотрудникам. Лицо либо владеет секретом и несёт за него ответственность, в том числе по NDA, либо нет и тогда этому лицу следует позаботиться получении секрета.

Поэтому, чтобы Гриша имел полномочия управлять секретом - он должен им владеть и нести за него ответственность, решая все вопросы с предоставлением ключа Гале самостоятельно.

На схеме Гриша согласовывает с Демиургом предоставление доступов себе и Гале.

Правило №6

Будьте строги к паролям

Зачастую секреты - это пароли. Для ведения паролей существуют различные рекомендации и практики. Здесь приведены 10 требований, соблюдение которых весьма желательно:

Не используйте повторяющиеся пароли, чтобы раскрытие пароля одной учётной пары не повлекло за собой раскрытие пароля других пар.
Не используйте шаблоны создания паролей. Например "SuperPassword1", "SuperPassword2", "KomputerVBane139", "KomputerNaResepshene139".
Не используйте лексемы в паролях. Например SuperPasswordOfAnyTyme
Не используйте свои личные пароли. Это не безопасно и для фирмы и конкретно для вас.
По возможности используйте локальные генераторы паролей которые позволяют настраивать сложность. Добавляйте к сгенерированным паролям несколько случайных символов самостоятельно (от руки).
В случае если кто-то предоставил вам пароль к вашей учётной записи (например администратор сервиса), то немедленно смените его на свой.
Не храните пароли в незашифрованных файлах, на стикерах, блокнотах и тд.
Не пишите пароли в документациях и инструкциях.
Не добавляйте пароли в исходный код.
Инициируйте смену паролей при изменения состава вашей команды (ухода сотрудника, прекращение полномочий члена команды).
Периодически меняйте пароли. В среднем пароль должен меняться 2 раз в течение года.

P.S. Документ может быть дополнен, исправлен.