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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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