Защита конфиденциальных данных от разработчиков

61

У меня запущено корпоративное приложение, которое использует хранилища данных MySQL и MongoDB . У моей команды разработчиков есть SSH- доступ к компьютеру для выполнения выпусков приложений, обслуживания и т. Д.

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

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

Клинтон Бош
источник
30
Пользователи должны хранить конфиденциальные данные только в зашифрованном виде. Не должно быть большой проблемы, если разработчики могут получить доступ к зашифрованной форме, если соответствующие ключи защищены от них должным образом.
MSalters
3
@Clinton У вас есть отдельные команды администраторов и разработчиков? Администратор сервера всегда может прочитать данные, и шифрование не помогает, поскольку они могут легко получить ключ.
CodesInChaos
14
Честно говоря, это сложный вопрос, и для его правильного выполнения требуется большой опыт в области безопасности данных. Даже если вы точно знали, что делать, вы столкнетесь с оппозицией бизнеса, политическими и техническими препятствиями. Я настоятельно рекомендую вам пригласить консультанта по безопасности данных. Они не только знают, что делать здесь, высшее руководство, как правило, больше доверяет тому, когда третья сторона говорит им измениться. Высшее руководство обычно не уделяет должного внимания тому, что говорят им его внутренние эксперты.
maple_shaft
3
Возможно, стоит спросить об обмене информацией по стеку информационной безопасности. Есть некоторая связанная информация по этому вопросу
paj28
23
Почему люди касаются сервера и разворачивают код?
Уайетт Барнетт

Ответы:

89

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

В его нынешнем виде вы отметили проблему безопасности, которая является хорошим первым шагом. Теперь, как минимум, вы должны определить:

  • Какие данные вы пытаетесь защитить?
  • От кого вы пытаетесь защитить эти данные?
  • Кому на самом деле нужен доступ к чему (и когда)?
  • Каково юридическое / финансовое / бизнес-влияние этих данных, которые подвергаются риску?
  • Какая юридическая / финансовая / деловая необходимость для лица / группы, имеющих доступ к данным?
  • Какой бюджет бизнес может выделить для стратегии «получить безопасность, оставаться в безопасности», если раньше это не было требованием бизнеса?
  • Какой доступ нужна системе к данным?
  • От чего зависит этот процесс и системы, на которые опирается это приложение?
  • Что делается для защиты этих сред?
  • Кто будет нести ответственность за его реализацию и проверку всего процесса?

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

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

Джеймс Снелл
источник
33
Вау ... это делает звук безопасности ... нетривиальным. (Извините за сарказм; я видел много людей, удивленных этим.)
Пол Дрэйпер
4
Я верю, что многие люди думают, что есть волшебная make-application-secureкоманда, которую им просто нужно выполнить.
TMH
27

Ты прав. Если приложение способно получать доступ к содержимому, хранящемуся на корпоративных компьютерах, без того, чтобы пользователь каждый раз передавал дополнительную информацию , тогда программисты, сопровождающие, системные администраторы и т. Д. Поставщика услуг могут получить доступ к этому содержимому. Это в принципе неизбежно и является основным источником незащищенности (Эдвард Сноуден был системным администратором и имел особые привилегии выше «Совершенно секретно», потому что просто не существует способа их не предоставлять).

Единственный способ избежать этого - потребовать от пользователя предоставления информации, которая никогда не попадет на корпоративные машины. Это утомительно и подвержено ошибкам, так как никто не может вспомнить достаточно информации, чтобы сформировать безопасный барьер доступа, и поэтому люди сразу же начнут хранить свои учетные данные в электронном виде в каком-то месте, которое затем станет новой целью атаки (и, вероятно, более слабая цель, чем та, которую вы поддерживаете). Но если вы хотите правдиво заявить, что «наши сотрудники физически не способны получить доступ к контенту наших пользователей», это единственный способ.

(Обратите также внимание, что такая бизнес-модель, по-видимому, становится политически несостоятельной. Службы безопасности вытеснили предприятия из-за попыток сделать именно это. Я понимаю, что предоставление гарантий конфиденциальности имеет деловую ценность, но не может иметь больше ценность бизнеса, чем основная цель остаться в бизнесе.)

Килиан Фот
источник
6
Можно спроектировать аппаратное обеспечение таким образом, что физически невозможно получить доступ к определенным данным без создания постоянной записи такого доступа, который не может быть уничтожен без сотрудничества нескольких независимых людей и который даже при таком сотрудничестве не может быть уничтожен не оставляя четких доказательств умышленного уничтожения. Однако обновление таких систем для удовлетворения меняющихся требований может оказаться очень дорогостоящим по сравнению с обновлением программных систем безопасности.
суперкат
5
Вы правы, я совершенно забыл упомянуть возможность аудита как возможную альтернативу хостингу с нулевым уровнем знаний. Это несколько легче достичь и достаточно часто для бизнес-кейса.
Килиан Фот
Ваш последний абзац. Вы имеете в виду истории типа LavaBit? Я не совсем понимаю.
jpmc26
1
@supercat Вы также должны верить, что создатели аппаратного обеспечения заставили его делать то, что они сказали, что он делает.
user253751
2
@immibis: Да, но я бы хотел, чтобы разработка и производство защищенного оборудования могли проверяться несколькими независимыми людьми. Кроме того, в обычной системе «подлый» кусок кода может что-то сделать, а затем удалить себя без следа, но если на части безопасного оборудования не предполагается наличие доступного для записи хранилища элементов управления, такая вещь было бы невозможно. Либо хитрый код должен постоянно находиться в хранилище управления, либо хранилище управления должно иметь постоянно модифицированные средства модификации, которые могут быть обнаружены после факта.
суперкат
15

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

With great power comes great ... opportunity to really, *really* foul things up. 

Многие разработчики не захотят эту ответственность и другие, просто не будут «готовы» удержать ее, и поэтому не должны были бы этого делать.

Вопрос: Почему ваша команда разработчиков выпускает живые релизы ?
Я бы посоветовал вам нуждаться в «команде» по управлению выпусками (даже если это всего лишь часть вашей команды, плюс представительство в бизнесе, чтобы принимать какие-либо «ежедневные» решения, такие как «Go / No-Go»)? Это устранит большую часть «потребности» разработчиков касаться чего-либо вживую.

Есть ли у вас какое-либо соглашение о неразглашении / конфиденциальности между разработчиками и компанией? Это тяжеловесно, но у этого может быть некоторая заслуга.

Фил В.
источник
Что по-прежнему не остановит решительного злоумышленника от сокрытия бэкдора в приложении, но оно уменьшает возможности, которые делает вор.
Ян Худек
Да, это не вся команда разработчиков, а группа управления подмножеством / выпуском. У нас, безусловно, есть пункт в трудовом договоре о слежке за данными, которыми вы не должны быть, это преступление, подлежащее увольнению.
Клинтон Бош,
@JanHudec Тем более, что при добавлении кода приложение оставляет следы в управлении версиями.
CodesInChaos
@CodesInChaos: Хороший программист может заставить бэкдор выглядеть честной ошибкой. Вы будете подозревать их, но вы никогда не будете обвинять их. Но да, это другая линия обороны.
Ян Худек
@Jan: Именно поэтому все изменения кода должны быть рассмотрены и подписаны, прежде чем они будут допущены в ветку релиза.
SilverlightFox
9

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

Развертывание новой версии не должно включать какого-либо разработчика - это чисто административная задача или, что еще лучше, полностью автоматизированная задача. Также следует помнить о том, чтобы выпустить и развернуть две совершенно разные задачи. Если ваш процесс не знает об этом, измените его соответствующим образом.

SpaceTrucker
источник
1
Нам не нужны производственные данные для отладки, для этого у нас есть очищенный дамп данных, но иногда для развертывания требуются различные миграции данных и т. Д., Которые выполняются некоторыми разработчиками в группе управления релизами (но они все еще являются разработчиками)
Клинтон Бош,
2
@ClintonBosch Тогда вы четко не разграничили роли администраторов и разработчиков. Тогда еще один вопрос, который вы должны задать себе: как мы можем быть уверены, что выпущенное программное обеспечение действительно развернуто? Вам нужно будет подписать релиз и разрешить развертывание только подписанных пакетов на производстве. Также снова автоматизация - ваш друг. Миграции не должны требовать каких-либо ручных шагов.
SpaceTrucker
4
@ClintonBosch Определите, какие поля данных являются строго конфиденциальными, и зашифруйте их. Убедитесь, что вы установили безопасность производственной ОС, чтобы вы могли получить доступ к тому, какие идентификаторы пользователей читают файл ключа, чтобы убедиться, что никто, кроме пользователя приложения, не делает этого. Не давайте разработчикам пароль пользователя приложения. Сделайте им sudo, чтобы получить права на производство и записать, что они делают. Это, вероятно, самый безопасный способ убедиться, что вы присматриваете за теми немногими людьми, у которых был бы доступ, и чтобы они не могли случайно или случайно увидеть данные, которые они не должны.
maple_shaft
6

Правило № 1 безопасности: если кто-то имеет доступ к информации, он имеет доступ к этой информации

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

Если это серьезная проблема для вас (и, похоже, так и есть), подумайте о том, как встроить безопасность в свое программное обеспечение. Распространенным примером является разработка безопасного программного обеспечения по уровням. На самом низком уровне команда разработчиков, которым доверяют, проектирует программное обеспечение, которое управляет самым голым из контроля доступа. Это программное обеспечение проверено и подтверждено как можно большим количеством людей. Любой, кто разрабатывает этот код, имеет доступ ко всему, поэтому доверие необходимо.

После этого разработчики могут построить более гибкий контроль доступа поверх этого основного уровня. Этот код все еще должен быть V & VD, но он не такой строгий, потому что вы всегда можете положиться на базовый уровень, чтобы покрыть все необходимое.

Шаблон распространяется наружу.

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

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

В конце концов, и вы, и ваши разработчики должны понять ключевой принцип безопасности: вся безопасность - это баланс между безопасностью и удобством использования. Вы должны найти свой баланс как компания. Система не будет идеально защищена и не будет полностью использована. Этот баланс, вероятно, даже будет изменяться по мере роста вашей компании и / или изменения требований к разработчикам. Если вы открыты для этой реальности, вы можете обратиться к ней.

Корт Аммон
источник
3

Настройте два развертывания приложения, которые также используют отдельные развертывания базы данных. Одним из них является производственное развертывание, а другим - тестовое развертывание.

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

Philipp
источник
Да, это именно тот сценарий, который у нас есть. Но в какой-то момент кому-то нужно поработать над производственной средой, чтобы облегчить развертывание / миграцию данных
Клинтон Бош
3

В двух финансовых фирмах разработчики не имели доступа к производственным машинам. Все запросы на модификацию производственных машин должны были пройти процедуру утверждения с использованием сценария и были одобрены менеджерами. Команда разработчиков завершила фактическое развертывание. Я предполагаю, что эта команда была только сотрудниками, и прошла проверку данных. У них также не было знаний разработчика, поэтому, вероятно, они не могли бы подглядывать, если бы захотели. В дополнение к этому вы должны зашифровать все записи базы данных, используя секретный ключ, хранящийся в переменных среды. Даже если базы данных публично просочились, никто не сможет их прочитать. Этот ключ может быть дополнительно защищен паролем (PBKDF), так что только руководитель может разблокировать его. Ваша система может потребовать пароль администратора при загрузке (или, скорее, делегировать его разработчикам или администратору разработчиков). По сути, стратегия состоит в том, чтобы распределить знания таким образом, чтобы критическая масса требуемых знаний не существовала в одном человеке и имелись проверки и противовесы. Так Coca-Cola защищает свою формулу. Честно говоря, некоторые из этих ответов являются отговорками.

Хлоя
источник
-1

MongoDB имеет ограниченные меры безопасности и зависит от безопасной среды. Привязка к конкретному ip и порту (и ssl начиная с 2.2) и грубая аутентификация - вот что она предлагает. MYSQL добавляет GRANT o ON db.t TO ... Данные в состоянии покоя не шифруются, и ssl не используется по умолчанию. Создать забор. Для отладки достаточно доступа только для чтения к файлам журналов приложений. Автоматизируйте жизненный цикл приложения.

Ansible помог нам автоматизировать стандартные операции (развертывание, обновление, восстановление) во многих средах с одним владельцем, используя отдельные зашифрованные хранилища для хранения важных переменных среды, таких как узлы, порты и учетные данные. Если каждое хранилище может быть дешифровано только разными ролями и только на хосте-бастионе для зарегистрированных операций, то возможность аудита обеспечивает приемлемую безопасность. Если вы предоставляете SSH, пожалуйста, используйте selinux, чтобы избежать подделки ключей, используйте хост-бастион с аутентификацией ldap / kerberos для администрирования и используйте sudo с умом.

bbaassssiiee
источник