AIM for Business Flows
Руководство аудитора
Oracle Hyperion
Автор: Евгений Расюк
Дата создания: 19.05.2014
Последнее изменение: 19.05.2014
Контрольный номер: DO.080.1
Версия: 1.00
Управление документом
Изменения
Дата | Автор | Версия | Содержание изменения |
27.10.2013 | Расюк Евгений | 1.00 | Новый документ |
Рецензенты
Фамилия Имя |
Содержание
Управление документом 2
Изменения 2
Рецензенты 2
Содержание 3
Введение 4
Назначение документа 4
Границы документа 4
Описание терминов 4
Проектная документация 5
Системное окружение 6
Функциональное окружение 7
Настройка безопасности 8
Интеграционное взаимодействие 9
Трансформация и корректировка отчетности 10
Разработка и сопровождение системы 11
Процедуры восстановления системы при аварии 12
Контроль над несанкционированными изменениями 13
Корректность использование базового функционала 14
Открытые и закрытые вопросы 15
Открытые вопросы 15
Закрытые вопросы 15
Введение
Данный документ публикуется на правах лицензии BSD (можно использовать без указания источника). Все замечания и дополнения отправляйте на адрес *****@***ru
Назначение документа
Этот документ призван помочь в проведении процесса аудита внутренними силами компании, что бы максимально подготовится к внешнему аудиту на соответствие стандарту SOX
Границы документа
TODO
Описание терминов
Риски
Высокий - неприемлемый уровень риска, управление ситуацией требует пристального внимания, и принятия срочных мер по устранению риска и его последствий;
Средний - существует вероятность возникновения сложностей в результате риска, необходимо организовать постоянный контроль риска и принять меры по его уменьшению / устранению;
Низкий - минимальное воздействие, срочное вмешательство не требуется, рекомендуется периодический контроль риска.
Приоритет
Высокий – внедрение рекомендаций в первую очередь;
Средний – внедрение рекомендаций до начала до промышленной эксплуатации системы;
Низкий – внедрение рекомендаций, как только появятся необходимые возможности/ресурсы.
Проектная документация
В данной процедуре проверяется не только наличие документов описывающих систему, но и соответствие их сделанным настройкам и актуальность состояния. Позволяет выявить
- нерегламентируемые изменения пробелы в описании функционала системы определить качество проделанной работы
С точки зрения управления проектами по Oracle AIM, проектный пакет документации должен состоять из следующих глав (каждая из которых должна детализироваться одним или более документом)
Наименование | Риск | Приоритет |
00.PM. Устав проекта и план работ | ||
01.BF. Отображение бизнес-процессов | ||
02.RD. Требования к системе | ||
02.TA. Техническая архитектура | ||
03.MD. Разработка приложений | ||
05.TE. Тестирование системы | ||
06.PT. Тестирование производительности | ||
07.AP. Адаптация и обучение | ||
08.PM. Переход в эксплуатацию | ||
10.CV. Интеграция приложений |
Системное окружение
Проверка системного окружения, призвана выявить риски связанные с физическим размещением серверов и действиями системных администраторов.
Здесь выделяются следующие объекты для контроля
Наименование | Риск | Приоритет |
Соответствие системного ПО рекомендациям вендора | ||
Наличие регламентируемого доступа к серверам | ||
Процедуры обновления системного программного обеспечения | ||
Наличие защиты от вредоносного ПО | ||
Наличие контролируемого доступа к внутренним и внешним сетям | ||
Проверка состава административных групп | ||
Наличие регламента по согласованию административного доступа к серверам | ||
Проверка доступа к разделяемым файловым ресурсам | ||
Проверка системных настроек на соответствие рекомендациям вендора | ||
Наличие сред разработки, пользовательского тестирования, и промышленной эксплуатации | ||
Проверка отсутствия доступа разработчиков к промышленной среде | ||
Проверка настроек безопасности для стандартных учетных записей | ||
Не используемые сервисы отключены или недоступны | ||
Проверка доступа к файлам резервного копирования и функциональным выгрузкам | ||
Функциональное окружение
В данном разделе определяются контроли над настройками функционального окружения, которые позволяют контролировать риски связанные с действиями пользователей и функциональных администраторов
Здесь выделяются следующие объекты для контроля
Наименование | Риск | Приоритет |
Выполнены настройки логирования изменений данных в системе | ||
Выполнены настройки логирования доступа к системе | ||
Настройки конфигурационных файлов соответствуют рекомендациям вендора | ||
После изменения конфигурационных параметров есть стандартные отчеты по консистентному состоянию системы | ||
Доступ к временным объектам системы (текстовых файлов выгрузок) регламентирован и ограничен | ||
Выполнены технические настройки производительности для приложений | ||
В приложении бизнес-логика параметризируема, в коде нет явного кодирования процессов. (нет хард-кода) | ||
Аналитическая модель соответствует бизнес требованиям. Нет избыточных уровней и измерений. | ||
Пользовательский интерфейс понятен и прозрачен. Настроены списки задач, в формах есть комментарии | ||
Выполнение отчетов и расчетов занимает ожидаемое время. | ||
Настройка безопасности
Здесь выделяются следующие объекты для контроля
Наименование | Риск | Приоритет |
Существуют регламенты добавления пользователей и администраторов в систему | ||
Пользовательские учетные записи контролируются внешней специализированной системой | ||
В конфигурационных файлах и в интеграционных скриптах нет в открытом доступе паролей и учетных записей | ||
Матрица безопасности актуальна и соответствует настройкам системы | ||
Пользователи имеют доступ только к требуемым объектам системы | ||
Группа администраторов минимальна и содержит только технических сотрудников | ||
От имени администратора нет событий по изменению данных и запусков расчетов | ||
Количество учетных записей соответствует лицензионному соглашению | ||
Стандартные учетные записи переименованы, и (или) пароли изменены |
Интеграционное взаимодействие
Данный раздел призван выявить целостность передачи данных между системами
Здесь выделяются следующие объекты для контроля
Наименование | Риск | Приоритет |
Определение состава внешних и внутренних интерфейсов и способа их взаимодействия | ||
Наличие отчетов по выверке данных между целевыми и исходными системами | ||
Наличие документов описывающих настройки интерфейсного взаимодействия | ||
Наличие логов по использованию интерфейсных процедур. (запуск, время работы, количество обработанных записей) | ||
Проверка учетных записей и способа авторизации | ||
ToDO |
Трансформация и корректировка отчетности
Выполнение данных контролей, позволяет достоверно утверждать о целостности системы
Наименование | Риск | Приоритет |
Наличие автоматических и ручных контролей проверки целостности и качества данных (%<100) | ||
Наличие автоматических и ручных контролей проверки целостности и качества метаданных | ||
Наличие отчетов выверки данных между интерфейсами и системами | ||
Наличие отчетов проверки трансформации и реклассификации | ||
Наличие отчетов проверки ручных и автоматических корректировок | ||
Наличие механизмов блокировки рассчитанных и консолидированных данных | ||
Наличие функциональных правил по проверке качества данных ( актив==пассив ) | ||
Проверка корректности стандартных алгоритмов (ВГО, консолидация, РБП) | ||
Проверка корректности стандартных отчетов | ||
Объем и значения в интерфейсном объекте однозначно соответствует загруженным данным. |
Разработка и сопровождение системы
Здесь контролируются риски несанкционированных изменений разработчиком и (или) функциональным администратором
Здесь выделяются следующие объекты для контроля
Наименование | Риск | Приоритет |
Наличие стандартов и руководства разработчиков | ||
Выделенные среды разработки, тестирования и пром. эксплуатации | ||
Регламенты и процедуры переноса (клонирования) промышленной среды на среды тестирования и разработки | ||
Проверка ограничений доступа разработчиков к промышленной среде | ||
Процесс согласования изменений | ||
Артефакты, подвергшихся регламентному изменению (Присутствие системы контроля версий) | ||
Регламенты аудита разработки, проверка влияния на уже существующий функционал | ||
Регламент пользовательского тестирования и переноса разработки в промышленную среду | ||
Процедуры изменений исправлений программного обеспечения ( «патчевания») | ||
Наличие механизмов проверки состояния системы (артефактов) на определенную дату | ||
Наличие системы реверсного тестирования, по выявлению влияния на уже закрытые периоды |
Процедуры восстановления системы при аварии
Данный контроль призван обеспечить достоверность системы после работ по восстановлению системы из резервных копий
Наименование | Риск | Приоритет |
Наличие регламентов резервного копирования | ||
Целостность и достоверность резервных копий | ||
Процедура восстановления информации из резервной копии на определенную дату | ||
Регламент действий системного администратора в случае аварии | ||
Регламент действий функционального администратора в случае аварии | ||
Наличие регламентных процедур по проверке действий администраторов в случае аварий |
Контроль над несанкционированными изменениями
Наименование | Риск | Приоритет |
Наличие логов аудита доступа к системе | ||
Наличие логов аудита изменение данных в системе | ||
Наличие логов расчетов и консолидации | ||
Проверка соответствия доступа матрице безопасности | ||
Наличие систем оповещений или блокировок в случае несанкционированного доступа | ||
Наличие контролей над административными учетными записями. | ||
Логи доступны и защищены от изменений |
Корректность использование базового функционала
Наименование | Риск | Приоритет |
Наличие функционального описания реализуемого решения | ||
Наличие документации по кастомизации базового функционала |
Открытые и закрытые вопросы
Открытые вопросы
№ | Вопрос | Решение | Ответственность | Намеченная дата | Дата выполнения |
Закрытые вопросы
№ | Вопрос | Решение | Ответственность | Намеченная дата | Дата выполнения |
