Обновление конфигурации и требования безопасности
Добрый день!
Коллеги, прошу поделиться опытом и помочь советом, по возможности.
Ситуация такая:
Есть рабочая база, в которой работают пользователи. Находится на полной поддержке без возможности редактирования, обновляется через релизы. Есть базы разработчиков, разработка с использованием хранилища, эти базы не имеют физической связи с рабочей базой. Есть пустая база для подготовки релизов обновления рабочей базы, физически никак не связана с рабочей, не связана с хранилищем.
Организация периодически проходит проверку аудиторами. Есть требование аудиторов отделить рабочую базу от разработки. Я так понимаю, потому что среди пользователей с полными правами в рабочей базе есть тот же самый человек, что является пользователем и в разработческих базах, участвует в разработке.
Апеллируют к тому, что этот разработчик имеет техническую возможность что-то такое хитрое и зловредное накодить и в рабочую базу применить, а затем и замести следы.
Вопрос:
Как соблюсти требование аудторов и разграничить рабочую базу от разработчиков?
Вариант, передать функцию обновления другому человеку, не умеющему программировать не подходит.
Я думал в сторону дать только право "Обновление конфигурации" некой специальной роли и завести пользователя с этой ролью, чтобы он мог только обновлять конфу и не более. Но, для того чтобы указать файл обновления нужно открыть дерево конфигурации, а чтобы его открыть, надо дать право Администрирование, которое автоматически позволяет снять конфу с поддержки, а значит является потенциальной уязвимостью.
Других идей пока нет, прошу помощи. )))
Спасибо!
Коллеги, прошу поделиться опытом и помочь советом, по возможности.
Ситуация такая:
Есть рабочая база, в которой работают пользователи. Находится на полной поддержке без возможности редактирования, обновляется через релизы. Есть базы разработчиков, разработка с использованием хранилища, эти базы не имеют физической связи с рабочей базой. Есть пустая база для подготовки релизов обновления рабочей базы, физически никак не связана с рабочей, не связана с хранилищем.
Организация периодически проходит проверку аудиторами. Есть требование аудиторов отделить рабочую базу от разработки. Я так понимаю, потому что среди пользователей с полными правами в рабочей базе есть тот же самый человек, что является пользователем и в разработческих базах, участвует в разработке.
Апеллируют к тому, что этот разработчик имеет техническую возможность что-то такое хитрое и зловредное накодить и в рабочую базу применить, а затем и замести следы.
Вопрос:
Как соблюсти требование аудторов и разграничить рабочую базу от разработчиков?
Вариант, передать функцию обновления другому человеку, не умеющему программировать не подходит.
Я думал в сторону дать только право "Обновление конфигурации" некой специальной роли и завести пользователя с этой ролью, чтобы он мог только обновлять конфу и не более. Но, для того чтобы указать файл обновления нужно открыть дерево конфигурации, а чтобы его открыть, надо дать право Администрирование, которое автоматически позволяет снять конфу с поддержки, а значит является потенциальной уязвимостью.
Других идей пока нет, прошу помощи. )))
Спасибо!
По теме из базы знаний
- Конфигурация "Весовая ред. 3.0" для Платформы 8.3
- Как создать бронебойную систему кибербезопасности на базе 1С
- Исправление ошибки обмена Управление торговлей 11 - Бухгалтерия предприятия, редакция 3.0 (3.0.67.х, расширение конфигурации)
- Управление сборкой. Расширение для конфигурации СППР
- Учет сведений о предприятии и о сотрудниках в конфигурации 1С:Производственная безопасность. Охрана труда
Найденные решения
Александр, добрый день!
Требование выполнено.
Исключите доступ этого человека к рабочей базе. Если аудиторы призывают к изолированности рабочей базы от средств разработки - выполните их требование. Взаимодействие группы разработки с заказчиками (хозяевами бизнес-процессов) организуйте через ЭДО с контролем исполнения.
Для обновления рабочей базы - заключите договор со сторонним франчайзи, с хорошей репутацией. Поручите ему, дополнительно, проверку и анализ вносимых изменений. Тогда, имеем:
1. Разработку проводит группа, которая никаким образом не задействована в рабочей базе.
2. Анализ и внесение разработанных изменений проводит независимый аналитик без прав самостоятельного изменения.
3. За Вами остается функция контроля сроков разработки и сроков внесения изменений., координация между разработкой, аналитиками и заказчиками.
Есть базы разработчиков, разработка с использованием хранилища, эти базы не имеют физической связи с рабочей базой.
Есть требование аудиторов отделить рабочую базу от разработки.
Есть требование аудиторов отделить рабочую базу от разработки.
Требование выполнено.
Среди пользователей с полными правами в рабочей базе есть тот же самый человек, что является пользователем и в разработческих базах, участвует в разработке.
Апеллируют к тому, что этот разработчик имеет техническую возможность что-то такое хитрое и зловредное накодить и в рабочую базу применить, а затем и замести следы.
Исключите доступ этого человека к рабочей базе. Если аудиторы призывают к изолированности рабочей базы от средств разработки - выполните их требование. Взаимодействие группы разработки с заказчиками (хозяевами бизнес-процессов) организуйте через ЭДО с контролем исполнения.
Для обновления рабочей базы - заключите договор со сторонним франчайзи, с хорошей репутацией. Поручите ему, дополнительно, проверку и анализ вносимых изменений. Тогда, имеем:
1. Разработку проводит группа, которая никаким образом не задействована в рабочей базе.
2. Анализ и внесение разработанных изменений проводит независимый аналитик без прав самостоятельного изменения.
3. За Вами остается функция контроля сроков разработки и сроков внесения изменений., координация между разработкой, аналитиками и заказчиками.
Остальные ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
Александр, добрый день!
Требование выполнено.
Исключите доступ этого человека к рабочей базе. Если аудиторы призывают к изолированности рабочей базы от средств разработки - выполните их требование. Взаимодействие группы разработки с заказчиками (хозяевами бизнес-процессов) организуйте через ЭДО с контролем исполнения.
Для обновления рабочей базы - заключите договор со сторонним франчайзи, с хорошей репутацией. Поручите ему, дополнительно, проверку и анализ вносимых изменений. Тогда, имеем:
1. Разработку проводит группа, которая никаким образом не задействована в рабочей базе.
2. Анализ и внесение разработанных изменений проводит независимый аналитик без прав самостоятельного изменения.
3. За Вами остается функция контроля сроков разработки и сроков внесения изменений., координация между разработкой, аналитиками и заказчиками.
Есть базы разработчиков, разработка с использованием хранилища, эти базы не имеют физической связи с рабочей базой.
Есть требование аудиторов отделить рабочую базу от разработки.
Есть требование аудиторов отделить рабочую базу от разработки.
Требование выполнено.
Среди пользователей с полными правами в рабочей базе есть тот же самый человек, что является пользователем и в разработческих базах, участвует в разработке.
Апеллируют к тому, что этот разработчик имеет техническую возможность что-то такое хитрое и зловредное накодить и в рабочую базу применить, а затем и замести следы.
Исключите доступ этого человека к рабочей базе. Если аудиторы призывают к изолированности рабочей базы от средств разработки - выполните их требование. Взаимодействие группы разработки с заказчиками (хозяевами бизнес-процессов) организуйте через ЭДО с контролем исполнения.
Для обновления рабочей базы - заключите договор со сторонним франчайзи, с хорошей репутацией. Поручите ему, дополнительно, проверку и анализ вносимых изменений. Тогда, имеем:
1. Разработку проводит группа, которая никаким образом не задействована в рабочей базе.
2. Анализ и внесение разработанных изменений проводит независимый аналитик без прав самостоятельного изменения.
3. За Вами остается функция контроля сроков разработки и сроков внесения изменений., координация между разработкой, аналитиками и заказчиками.
(2) Здравствуйте!
Благодарю за развернутый ответ.
Позвольте все же уточнить один момент.
Вы пишете:
Согласен с этим пунктом в теории, но на практике столкнулись с проблемой
Не получается стороннему человеку дать такие права, чтобы он и обновить мог и не мог внести изменения. Как соблюсти это условие? Допустим это будет человек, который не входит в команду разработки, но все равно мы не можем технически сделать так, чтобы у него была возможность обновления конфигурации, но не было технической возможности вносить изменения.
Как быть?
Спасибо.
Благодарю за развернутый ответ.
Позвольте все же уточнить один момент.
Вы пишете:
2. Анализ и внесение разработанных изменений проводит независимый аналитик без прав самостоятельного изменения.
Согласен с этим пунктом в теории, но на практике столкнулись с проблемой
Но, для того чтобы указать файл обновления нужно открыть дерево конфигурации, а чтобы его открыть, надо дать право Администрирование, которое автоматически позволяет снять конфу с поддержки, а значит является потенциальной уязвимостью.
Не получается стороннему человеку дать такие права, чтобы он и обновить мог и не мог внести изменения. Как соблюсти это условие? Допустим это будет человек, который не входит в команду разработки, но все равно мы не можем технически сделать так, чтобы у него была возможность обновления конфигурации, но не было технической возможности вносить изменения.
Как быть?
Спасибо.
Апеллируют к тому, что этот разработчик имеет техническую возможность что-то такое хитрое и зловредное накодить и в рабочую базу применить, а затем и замести следы.
- читаю, и не могу понять таких людей...это требование, ИМХО, сильно походит на то, что надо показать какие мы Могу накидать пару десятков уязвимости любой настраиваемой системы, начиная с ОС, на которых это всё крутится (первый раз шок был, когда во время преддипломной практики читал бумажку ДСП о недокументированных командах MS DOS, среди которых, неоджиданно, была команда, дающая права супервизора).
На
Выход один - закрыть всех причастных к системе в герметичном бункере)))))))))))))))
Не получается стороннему человеку дать такие права, чтобы он и обновить мог и не мог внести изменения.
Вмените обновление в обязанность ответственному за программу ( бухгалтерия - ГБ или зам.ГБ), УПП - главный инженер или его замы и т.д. У меня, на прошлой работе, к АИИСКУЭ в серверной - только главный энергетик подходил.
У Вас ИМЕННО СЕЙЧАС (потом будет поздно) есть мощнейший административный рычаг - требования аудита. Пишите регламент по обновлению, отдавайте на согласование СБ и ГД.
P.S. У нас все виды аудита проводил Делойт &Туш. Любая хотелка решалась упиранием именно в то, что это требование аудита. Если Ваш регламент официально "зарубят" - повесьте его в рамочке на стену и показывайте всем, у кого возникнет нездоровый интерес
(6)
Доводилось ли решать задачу логирования изменений конфигурации рабочей базы?
Аудиторы хотят видеть какие именно изменения в программный код (или объекты метаданных и т.п.) вносились при обновлении рабочей базы.
Мол, хотим видеть какие именно изменения по сравнению с предыдущим состоянием конфигурации были внесены в программный код именно при обновлении именно рабочей базы. Отчет по изменениям из хранилища не предлагать. ))
Сработает ли, допустим, такой вариант:
Мы пишем регламентное задание, которое ищет в журнале регистрации событие изменения конфигурации по моменту времени после последнего зарегистрированного. И если обнаруживает то выгружает конфу в некую внешнюю систему контроля версий (например Git). А дальше уже средствами этой системы сравниваем версии, формируем отчет о различиях.
Как думаете?
Доводилось ли решать задачу логирования изменений конфигурации рабочей базы?
Аудиторы хотят видеть какие именно изменения в программный код (или объекты метаданных и т.п.) вносились при обновлении рабочей базы.
Мол, хотим видеть какие именно изменения по сравнению с предыдущим состоянием конфигурации были внесены в программный код именно при обновлении именно рабочей базы. Отчет по изменениям из хранилища не предлагать. ))
Сработает ли, допустим, такой вариант:
Мы пишем регламентное задание, которое ищет в журнале регистрации событие изменения конфигурации по моменту времени после последнего зарегистрированного. И если обнаруживает то выгружает конфу в некую внешнюю систему контроля версий (например Git). А дальше уже средствами этой системы сравниваем версии, формируем отчет о различиях.
Как думаете?
(9)
Они работают по трехколенной схеме - хранилище разработки, база подготовки релизов обновления, рабочая база, обновляемая через релизы. Поэтому, полные и инкрементальные архивы - это способ защиты от потери данных, и уж никак не хранения изменений конфигурации. А сравнение конфигураций, на 2-х последних этапах, это только лишние вопросы аудита, но уже по план-факту разработки.
Они работают по трехколенной схеме - хранилище разработки, база подготовки релизов обновления, рабочая база, обновляемая через релизы. Поэтому, полные и инкрементальные архивы - это способ защиты от потери данных, и уж никак не хранения изменений конфигурации. А сравнение конфигураций, на 2-х последних этапах, это только лишние вопросы аудита, но уже по план-факту разработки.
Аудиторы хотят видеть какие именно изменения в программный код (или объекты метаданных и т.п.) вносились при обновлении рабочей базы.
Они дали формат отчетности, утвердили сроки ?
Если - нет, то лучше начинать именно с этого, иначе потом это превратится в вечный двигатель. Т.е. вначале пишем и согласовываем регламенты.
На предмет автоматизации по ЖР, это - как решите сами.
Я оформляла отчет по выставленному заданию, избавляет от дальнейшей необходимости пояснять отчего и зачем. Да и после 2-х первых отчетов им стало понятно, в какую трясину они могут залезть , беспрестанно требуя новых детализаций по действиям.
"Электрон так же неисчерпаем, как и атом, природа бесконечна" В.И.Ленин
Использовали Hummingbird (корпоративный ЭДО), там это неплохо организовано.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот