Як я можу запобігти програмістам захоплювати дані, введені користувачами?

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

security

— Пітер Сміт
джерело

Я б запропонував вам поставити це питання на: security.stackexchange.com/?as=1

— NoChance

«Перешкоджати» - дуже сильне слово. Ви не можете завадити поганим акторам робити погані справи. Що ви можете зробити, це вивчити та застосувати основні принципи безпеки, такі як "найменший привілей", "розділення обов'язків" та "неявне заперечення", архітектуйте речі безпечними способами та наймайте людей, яким ви можете довіряти. Створити дієві плани щодо зменшення шкоди у випадку неминучого врешті-решт.

— Роберт Харві

Технічні умови для технологій, які вам потрібні: хешування та шифрування.

— Роберт Харві

Відповіді:

Це досить просто. Банки роблять це постійно.

У вас задіяно три групи людей. Це групи безпеки. З чіткими дозволами.

Розробники не можуть призначити авторизацію безпеки та не можуть бачити виробничі дані.

Оператори не можуть призначити авторизацію безпеки та не можуть створювати програмне забезпечення.

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

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

— С.Лотт
джерело

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

— Dawood ibn Kareem

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

— Кріс

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

— Мар'ян Венема

@EmmadKareem: Правильно. Людина з безпеки встановлює та скидає групи та паролі, але не може бачити дані. Реальні дані можуть бачити лише оператори. Подумайте про такі дані, як фактичні гроші, якими обробляють фактичні каси. Програмісти не торкаються грошей; тільки каси до. Так само люди з безпеки не торкаються грошей; лише касири торкаються грошей.

— С.Лотт

@EmmadKareem: DBA не є розробниками. Існує дві групи: безпека та дані. Дані ЦБД є особливою частиною "операцій". Вони не повинні мати дозволу на зміну безпеки; вони не можуть написати код; вони, однак, побачать дані, і до них потрібно ставитися як до операторів, а не до розробників.

— С.Лотт

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

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

— Лорд Тидус
джерело