Как вы осуществляете доступ программистов к исходному коду и персональным данным пользователей?

Question

[Kolger]

Привет!

У нас есть несколько проектов: пара инет-магазинов, небольшая соц.сеть. Разрабатывалось это мной и людьми, которым я всецело доверял. Поэтому в разработке (на dev-сервере и локальных машинах) мы, как правило, использовали реальные данные пользователей, т.е. использовали дамп с продакшн-сервера в повседневной работе.

Сейчас в проект хочется взять еще удаленных сотрудников и давать доступ первому встречному к этим данным никак не хочется. Да и, оглядываясь назад, совсем не секьюрно использовать данные пользователей в разработке. Не говоря уж о том, что можно попасть под фейл — типа отправки письма пользователю с dev-сервера :)

Как вы в вашей компании решаете эту проблему?

Я пока что нашел два пути решения проблемы:

• Использовать какой-нибудь генератор данных. Для разработки требуется полная база данных, но эти данные вполне можно просто генерировать.
• Использовать дамп с продакшн-сервера, но заменять в нем персональные данные (ники, email'ы, например). Естественно, все в автоматизированном режиме, с помощью, например, fabric.

Расскажите, как поступаете вы в своей компании. Заранее спасибо за ответ!

Answer 1

[soroktu]

Второй вариант — с заменой персональных данных на фиктивные значения. Меняется ФИО и название нас. пункта. Но защита не от недобросовестных сотрудников, а от варианта когда нагрянут с проверкой (а лицензии и согласия на обработку персональных данных — нет)

Answer 2

[wersoo]

Обфускация и депересонализация реальных данных.

Answer 3

[Wott]

Смотря для чего:
На ранних стадиях разработки — генератор данных или рыба.
На стадии саппорта — обезличенные реальные данные, потому что юзеры придумывают такое что нормальные люди предусмотреть могут не всегда.

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

Answer 4

[Алексей Скахин]

Есть доступ ко всему, но каждые 2 года проходим детектор лжи.

Comments

[karenishe]

интересно, какой у вас детектор?

[Kolger]

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

Answer 5

[karenishe]

в свое время развлекались с такой «надстроечкой» над php, которая позволяла давать каждому программисту доступ к своим личными директориям: одна доступна из веба, другая — только для php.

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

доступ к файлам: при помощи chmod.

по поводу доступа к БД: как и во многих фреймворках была база для разработки и база для продакшена. ко второй имели доступ пара по-настоящему доверенных технарей.

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

Comments

[karenishe]

еще один плюс: ни один из программистов не имел доступа к ядру движка.

Answer 6

[Дмитрий]

Подписание nda, и аналогичных соглашений.

Comments

[karenishe]

бесполезно в России для среднего бизнеса. суд обойдется дороже.

[Kolger]

Именно. Плюс, не работает, когда исполнитель в Украине, например.

Answer 7

[akral]

можно попасть под фейл — типа отправки письма пользователю с dev-сервера :)

Я однажды так на новой работе запустил рассылку, будучи увереным, что это дев-сервер и дальше не пойдёт.
Ну так после того раза теперь стоят-таки настройки переводящие всю почту *@* на мой адрес. :)
И вам рекомендую.