Я согласен, что бремя оправдания должно быть на тех, кто требует доступа. Обычно в среде, где я консультировался, у меня был доступ к производственным системам, где это была небольшая среда, и я был специалистом по поддержке. У меня был доступ к резервным копиям и т. Д., Где мне оказывали поддержку, и косвенный доступ (через выделенного разработчика поддержки) к рабочим данным.
Самое главное: вам нужен этот доступ, когда вы находитесь на крючке, чтобы все работало гладко, и вы должны ответить на вопрос финансового сотрудника о том, что что-то не работает. В этом случае вы не всегда можете работать даже с данными за день. С другой стороны, чем больше доступа, тем хуже. Обычно, как консультант, я стараюсь избегать такого рода доступа, если только он не нужен. Поскольку я работаю с финансовыми базами данных, последнее, что я хочу, - это обвинение во вводе моих собственных счетов :-D.
С другой стороны, если вам не нужен доступ, у вас его не должно быть. Я на самом деле не покупаю аргумент конфиденциальных данных, так как разработчик, вероятно, на крючке, чтобы убедиться, что он обрабатывается правильно (и очень трудно проверить, не глядя на то, что на самом деле было сохранено, когда приходит отчет об ошибке). Если вы не можете доверять разработчику просматривать данные, хранящиеся в приложении разработчика, вам не следует нанимать разработчика для написания приложения. Есть слишком много способов, которыми разработчик мог бы запутать данные и отправить их по электронной почте, и вы никогда не можете быть уверены. Здесь помогают элементы управления MAC, но они все еще довольно сложны для реализации.
Большая проблема с моей стороны связана с доступом для записи. Если у разработчика нет доступа, то тем более у разработчика нет прав на запись. Если вы хотите проверить целостность книг, вы хотите сохранить доступ к записи как можно меньшему количеству людей. Журналы аудита гораздо проще проверить, если у разработчиков нет доступа. Если у разработчика есть права на чтение, то у вас всегда возникает вопрос, было ли какое-либо присоединение с эскалацией привилегий, которое может дать доступ на запись (возможно, внедрение SQL в хранимой процедуре?). Я часто имел полный доступ к платежной информации клиента, когда у меня был доступ к промежуточной среде. Если есть промежуточная среда, которая работает, я обычно буду активно просить не иметь доступа к производству, если это не необходимо.
Так что это не идеально, конечно. Разработчик может по-прежнему встраивать в приложение «черные двери», которые могут быть нелегко обнаружить, но этот подход является разумным подходом, учитывая тот факт, что резервные данные доступны за день до этого, и мне кажется, что это их проблема.
Надеюсь это поможет.
Изменить: просто добавив, что в более крупных средах, в которых я работал, у меня был доступ к полному резервному копированию данных, часто варьирующемуся от нескольких дней до нескольких месяцев для финансовой системы. Это всегда было достаточно хорошо для моей работы, и единственные случаи, когда это ломалось, были, когда финансовым парням требовалась возможность проверять новые данные, чтобы они могли сопоставляться с производством.