Захист конфіденційних даних від розробників

У мене працює корпоративна програма, яка використовує і сховища даних MySQL та MongoDB . Моя команда розробників має SSH доступ до машини для того, щоб виконувати випуски програм, технічне обслуговування тощо.

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

Мені це здається неможливим, оскільки якщо програма має доступ до бази даних, то розробник, що має доступ до машини та джерела програми, завжди зможе отримати доступ до даних.

Безпека не є чарівною паличкою, якою можна розмахувати наприкінці проекту, її потрібно розглядати та вбудовувати з першого дня. Це не підключення, це послідовне застосування ряду рішень, що застосовуються ітеративно та переглядаються. регулярно як частина цілої системи, яка є настільки ж сильною, як і найслабша ланка.

На даний момент ви позначили стурбованість безпекою, що є хорошим першим кроком. Тепер як мінімум потрібно визначити:

• Які дані ви намагаєтесь захистити?
• Від кого ви намагаєтеся захистити ці дані?
• Кому насправді потрібен доступ до чого (і коли)?
• Який юридичний / фінансовий / діловий вплив на ці дані порушений?
• Яка юридична / фінансова / комерційна потреба людини / групи, що має доступ до даних?
• Який бюджет бізнес готовий призначити стратегії "забезпечитись безпекою та безпекою", коли раніше вона не була вимогою бізнесу?
• Який доступ потрібен системі до даних?
• На чому покладається цей процес та системи, на які поширюється ця програма?
• Що робиться для забезпечення цих середовищ?
• Хто несе відповідальність за його впровадження та перегляд всього процесу?

Поки ви не дізнаєтесь усіх детально, у вас дійсно немає з чим працювати. Ця інформація визначатиме, які пом'якшення тих загроз ви можете (а не можете) застосувати та чому.

Можливо, найкраще зробити це визнати, що у вас немає необхідного досвіду і що було б найкраще залучити когось нового з цим досвідом. Я досить часто чую відповідь про те, що бюджету немає - якщо це вважати справді важливим, тоді бюджет буде знайдений.

Ти правий. Якщо програма може отримувати доступ до вмісту, що зберігається на корпоративних машинах, без того, щоб користувач щоразу передавав додаткову інформацію , програмісти, технічні працівники, системні адміністратори тощо постачальника послуг можуть отримати доступ до цього вмісту. Це принципово неминуче і є головним джерелом невпевненості (Едвард Сноуден був сисадміном, і мав спеціальні привілеї вище "Найпотаємнішого", оскільки просто не існує способу їх надання.)

Єдиний спосіб уникнути цього - вимагати від користувача інформації, яка ніколи не робить її на корпоративних машинах. Це виснажливо і схильне до помилок, оскільки ніхто не може запам'ятати достатньо інформації, щоб сформувати захищений бар'єр доступу, а тому люди негайно почнуть зберігати свої дані в електронному вигляді в якомусь місці, що потім стане новою ціллю атаки (і, можливо, слабша ціль, ніж та, яку ви підтримуєте). Але якщо ви хочете правдиво стверджувати, що "Наші співробітники фізично не здатні отримати доступ до вмісту наших користувачів", це єдиний спосіб.

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

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

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

Багато розробників не захочуть такої відповідальності та інших, просто не будуть "готові" взяти на себе її, і так не повинно бути.

Запитання: Чому ваша команда розробників виконує прямі випуски ?
Я б запропонував, що вам потрібна команда управління випуском (навіть це лише підмножина вашої команди, а також представництво бізнесу, щоб приймати будь-які рішення у день, як-от "Перейти / не-ходити")? Це призведе до зняття великої частини «потреби» для розробників, щоб торкнутися будь-якого Live.

Чи є у вас якісь угоди про нерозголошення / конфіденційність між розробниками та компанією? Це важко, але це може мати певні заслуги.

Проблема полягає у тому, що ваші розробники мають доступ до систем. Якщо їм потрібні виробничі дані для налагодження, тоді дайте їм дамп бази даних, де видаляється вся ця конфіденційна інформація. Тоді розробники можуть працювати з цим дамп.

Розгортання нової версії не повинно залучати жодного розробника - що чисте завдання адміністратора, а ще краще - повністю автоматизоване завдання. Також слід пам’ятати про вивільнення та розгортання двох дуже різних завдань. Якщо ваш процес цього не знає, змініть його відповідно.

Правило №1 безпеки: Якщо хтось має доступ до інформації, він має доступ до цієї інформації

Ця тавтологія дратує, але це правда. Якщо ви надаєте доступ особі, вона має доступ до даних. Для користувачів це зазвичай означає контроль доступу, але для розробників ... ну ... вони є тими, хто повинен записати контроль доступу.

Якщо це головна проблема для вас (і здається, що це є), подумайте про те, щоб забезпечити безпеку свого програмного забезпечення. Поширений зразок - це розробка захищеного програмного забезпечення в шарах. На найнижчому шарі довірена команда розробників розробляє програмне забезпечення, яке управляє самим голим з контролю доступу. Це програмне забезпечення перевірено та перевірено якомога більше людей. Усі, хто розробляє цей код, мають доступ до всього, тому довіра є важливою.

Після цього розробники можуть створити більш гнучкий контроль доступу поверх цього основного шару. Цей код все ще повинен бути V & Vd, але він не настільки суворий, тому що ви завжди можете покластися на основний шар, щоб покрити необхідне.

Візерунок поширюється назовні.

Важкою частиною, справді мистецтвом проектування цих систем, є те, як створити кожен шар, щоб розробники могли продовжувати розробку та налагодження, одночасно забезпечуючи вашу компанію безпекою, яку ви очікуєте. Зокрема, вам потрібно буде визнати, що налагодження вимагає більше привілеїв, ніж ви вважаєте, що це повинно, і спроба заблокувати це призведе до дуже гнівних розробників.

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

Зрештою, і вам, і вашим розробникам потрібно зрозуміти ключовий принцип безпеки: вся безпека - це баланс між безпекою та зручністю використання. Ви повинні досягти власного балансу як компанія. Система не буде ідеально захищеною, і не буде ідеально корисною. Цей баланс, ймовірно, навіть зміниться у міру зростання вашої компанії та / або зміни вимог до розробників. Якщо ви відкриті для цієї реальності, можете вирішити її.

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

Тестова розгортання повинна мати лише дані тесту. Це можуть бути фантазійні дані, створені для цієї мети, або копії виробничих даних, які були анонімізовані, щоб перешкоджати розробникам з'ясовувати реальних людей та особи, які стоять за цими даними.

У двох фінансових фірмах розробники не мали доступу до виробничих машин. Усі запити на модифікацію виробничих машин мали пройти процедуру затвердження, зі сценарієм, і затвердили менеджери. Команда розробників завершила фактичні розгортання. Я припускаю, що ця команда була лише працівниками та пройшла перевірку. Вони також не мали знань для розробників, тому, ймовірно, не могли прислухатися, якщо хотіли. На додаток до цього, ви зашифрували б усі записи бази даних за допомогою секретного ключа, що зберігається в змінних оточення. Навіть якби база даних просочилася публічно, ніхто не міг її прочитати. Цей ключ можна додатково захистити паролем (PBKDF), тому розблокувати його може лише виконавчий директор. Ваша система може вимагати виконавчий пароль під час завантаження (або, швидше за все, делегований dev-ops або диспетчеру dev-ops). В основному стратегія полягає в розповсюдженні знань, щоб критична маса необхідних знань не існувала в однієї людини, і є перевірки і противаги. Ось так Coca-Cola захищає свою формулу. Чесно кажучи, деякі з цих відповідей є копами.

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

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