Международный стандарт iso 17799
жүктеу/скачать 0.79 Mb. Pdf көрінісі
|
- Бұл бет үшін навигация:
- ISO/EIC 17799:2000 © ISO/EIC 2000 © Перевод компании Информзащита 2004
- 8.1.5 Разделение областей разработки и эксплуатации
| 8.1.4 Разделение полномочий
Разделение полномочий – это метод, позволяющий уменьшить риск случайного или намеренного неправомерного использования системы. Следует рассмотреть возможности разделения полномочий по управлению или выполнению определенных действий, либо областей ответственности, чтобы ограничить возможности для несанкционированного изменения или неправомерного использования информации или сервисов. В небольших организациях реализовать этот метод может оказаться сложно, однако сам принцип рекомендуется применять при каждой возможности. Если разделить полномочия сложно, рекомендуется подумать о введении других мер, например, о мониторинге деятельности, аудиторских записях и наблюдении со стороны руководства. Аудит безопасности обязательно должен оставаться независимым. Необходимо обеспечить, чтобы никто не смог совершить мошенничество в области своей ответственности, не будучи замеченным. Совершение действия должно быть отделено от получения разрешения на него. Рекомендуется рассмотреть следующие меры: a) Необходимо разделить области деятельности, которые требуют сговора для совершения мошенничества, например, размещение заказа на приобретение и проверка получения товаров. b) Если существует опасность сговора, меры защиты должны быть реализованы так, ISO/EIC 17799:2000 © ISO/EIC 2000 © Перевод компании Информзащита 2004 38 чтобы участие в действиях должны были принимать несколько человек. Это поможет снизить вероятность тайных действий. 8.1.5 Разделение областей разработки и эксплуатации Чтобы добиться разделения полномочий, важно отделить друг от друга области разработки, тестирования и эксплуатации. Необходимо разработать и задокументировать правила передачи программного обеспечения из разработки в эксплуатацию. При разработке и тестировании могут возникать серьезные проблемы, например, нежелательное изменение файлов и системного окружения и сбои в работе системы. Необходимо рассмотреть вопрос о том, какой уровень разделения между средами эксплуатации, тестирования и разработки необходим для того, чтобы избежать проблем при эксплуатации. Подобным образом следует отделить друг от друга деятельность по разработке и тестированию. В данном случае для проведения осмысленного тестирования необходимо создать известную и стабильную среду, доступ к которой разработчики не смогут получить без особой необходимости. Если специалисты, занятые разработкой и тестированием, имеют доступ к эксплуатируемой системе и хранящейся в ней информации, они могут иметь возможность ввести в систему неразрешенный и непротестированный код или изменить рабочие данные. В некоторых системах эта возможность может быть использована для мошенничества и для размещения непротестированного или злонамеренного кода. Непротестированный и злонамеренный код может вызвать серьезные проблемы в работе. Кроме того, специалисты, занятые разработкой и тестированием, представляют угрозу для конфиденциальности рабочей информации. Действия, связанные с разработкой и тестированием, выполняемые в одной и той же компьютерной среде, могут привести к непредусмотренным изменениям информации и программного обеспечения. Таким образом, рекомендуется разделить области разработки, тестирования и эксплуатации, чтобы снизить риск случайного изменения или несанкционированного доступа к рабочему программному обеспечению и данным организации. Рекомендуется рассмотреть следующие меры: a) По возможности средства разработки и программы, используемые в основной работе организации, должны работать на отдельных компьютерных процессорах или в разных доменах или каталогах. b) Действия, связанные с разработкой и тестированием, должны быть как можно больше отделены друг от друга. c) Компиляторы, редакторы и другие системные средства не должны быть доступны из рабочих систем без необходимости. d) Для рабочих и тестовых систем необходимо использовать различные процедуры входа в систему, чтобы уменьшить вероятность ошибки. Пользователям рекомендуется выбирать для этих систем разных пароли. В меню должны выводиться соответствующие идентификационные сообщения. e) Специалисты по разработке должны иметь доступ к паролям рабочей системы только при наличии средств выдачи паролей для поддержки рабочих систем. Эти средства должны обеспечивать смену подобных паролей после использования. жүктеу/скачать 0.79 Mb. Достарыңызбен бөлісу:
|