Приложения Oracle и не только…

В последнее время снова участились вопросы, связанные с приложениями Oracle и защитой хранимых в них персональных данных.

К сожалению, многие эксперты по защите информации не совсем верно представляют о чем идет речь и в большинстве случаев беседы сводятся к тому, что ВАШЕ ПРИЛОЖЕНИЕ ДОЛЖНО БЫТЬ СЕРТИФИЦИРОВАНО и готовы истово доказывать, что это так. Можно до бесконечности дискутировать на эту тему и спорить до потери пульса, но давайте постараемся спокойно и трезво разобраться с данным вопросом.

Основным регулятором, занимающимся сертификацией является ФСТЭК. Весьма полезной будет следующая ссылка на “Государственный реестр сертифицированных средств защиты информации Системы сертификации средств защиты информации по требованиям безопасности информации”. Предлагаю прочитать внимательно, как данная ссылка озаглавлена! Реестр СРЕДСТВ ЗАЩИТЫ ИНФОРМАЦИИ!!! Уважаемые эксперты по безопасности, когда Вы консультируете своих работодателей и заказчиков Ваших услуг, принимайте пожалуйста к сведению, что ФСТЭК сертифицирует средства защиты информации (далее СЗИ), а не бизнес-системы. Бизнес-системы выполняют бизнес задачи, а средства защиты информации должны обеспечивать безопасную работу этих бизнес-систем. Для меня, по крайней мере, это звучит логично.

Резонный вопрос, который может возникнуть после ознакомления с Реестром ФСТЭК. Как же так? Вы говорите, что сертифицируют СЗИ, а вот в реестре есть информационные системы, прошедшие сертификацию. Да, это действительно так. Есть примеры того, что целые информационные системы сертифицированы как СЗИ. С одной стороны замечательно, но есть и другая сторона. Любое обновление и модификация подобной системы автоматически приводит к ситуации, когда требуется ее пересертификация. Я с большим трудом могу представить себе бизнес-систему, в логику которой не вносятся изменения, она не дополняется аналитическими отчетами, в ней не регистрируются новые объекты и т.д. Если ничего из перечисленного не требуется, то наверное да, можно целиком сертифицировать всю систему.

Опять же по закону ФЗ-152 от оператора персональных данных нигде не требуется сертифицировать свою систему, а лишь рекомендуется использовать СЗИ и СКЗИ.

До некоторого времени операторов пугали необходимостью аттестации информационной системы, то теперь и аттестация как таковая не требуется, а возможна проверка (в соответствии с Планом проведения плановых проверок и контроля обеспечения безопасности персональных данных при их обработке в информационных системах персональных данных, который составляется на каждый год и доступен на сайте ФСТЭК). Многие конторы, которые собирались поживиться на оказании “услуг” по аттестации приуныли, т.к. теперь их услуги не окажутся востребованы в полном объеме. Если проверка выявит несоответствие, то появится предписание с замечаниями, которые нужно устранить. В худшем случае, будет предписание и копеечный штраф. Кошмарить и мочить в сортире при этом никого не будут.

Итак. Возвращаемся к бизнес-приложениям компании Oracle. Все осталось неизменным. Oracle CIS продолжает работы по сертификации своих СЗИ. На сегодняшний день, в качестве средств защиты информации, которые могут быть использованы совместно со всеми основными бизнес-приложениями Oracle (E-Business Suite, Siebel CRM, JD Edwards, People Soft, Fusion Applications и т.д) и обеспечить выполнение закона ФЗ-152, сертифицированы ФСТЭК:

1) Oracle Database 11G – сертификат N1849, выдан до 25.05.2012 – обеспечение защиты ПДн до 2 класса включительно;

2) Oracle Identity Access Management Suite 11G – сертификат N2238, выдан до 23.12.2013 – обеспечение защиты ПДн до 1 класса включительно.

Oracle CIS также сертифицировал Oracle IRM и Oracle SSO, которые можно дополнительно использовать для защиты персональных данных.

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

В очередной раз хотелось бы напомнить, что выполнение требований закона ФЗ-152 связано не только с техническими мерами в отношении информационных систем, но и требует выполнения некоторых организационных формальностей. Как минимум с сотрудниками организации следует заключить соглашение по обработке персональных данных, которое необходимо оформить либо в виде дополнения к трудовому договору, либо в качестве заявления/согласия на подобную обработку. Формулировка может быть любая. Проще всего вставить фразу,

“даю свое согласие на обработку моих персональных данных в необходимом объеме и в соответствии с федеральным законом 152-ФЗ“.

Либо подробно описывая, какие возможные действия будут производиться с персональными данными. Как например во фрагменте следующего заявления.

AppsTech, JDEdwards, OEBS, Security, Владимир Коханов

Демонстрация интеграции Oracle Agile PLM c Oracle E-Business Suite с использованием технологий AIA и PIP-а. Демо проводилось для одного из Заказчиков. Язык демонстрации русский.

Agile PLM, AppsTech, MDM, OEBS, Вячеслав Александров

Вопрос о защите персональных данных сейчас актуален и задается регулярно. Относительно бизнес-приложений, хотелось бы дать некоторые комментарии и разъяснения.

Корпорация Oracle предлагает на рынке великое множество приложений в которых могут обрабатываться конфиденциальные данные, в том числе и набившие оскомину в последние два года, ПДн (персональные данные).

Так или иначе задается один и тот-же вопрос. Сертифицировано то или иное приложение или нет. Для России ответ на сегодняшний день – НЕТ. При этом необходимо дать некоторые комментарии относительно сказанного НЕТ. Если обратиться к нашему законодательству в данной области, можно почерпнуть для себя, что для защиты персональных данных следует использовать СЗИ (средства защиты информации), а для данных определенных классов – СКЗИ (средства криптозащиты информации). Исходя из данных требований, Oracle в РФ приняло решение сертифицировать некоторые из своих продуктов как средства защиты информации. С учетом, что большинство бизнес-приложений Oracle использует в качестве хранилища данных СУБД Oracle, последняя и была сертифицирована в ФСТЭК как средство защиты информации, обеспечивающее защиту персональных данных до 2-ого класса включительно (Сертификат соответствия №1849 от 25.05.2009 – действителен до 25.05.2012). Таким образом, используя СУБД Oracle 11G в работе своих бизнес-приложений, можно выполнить все требования по защите персональных данных в информационных системах до 2-ого класса включительно.

Резонный вопрос, а что делать с 1-ым классом персональных данных? До последнего времени рекомендовалось использовать сторонние средства защиты информации, прошедшие соответствующую сертификацию. Некоторые из таких средств уже хорошо зарекомендовали себя при работе (например с E-Business Suite) и успешно эксплуатируются. Основное – архитектура большинства бизнес-приложений Oracle позволяет осуществлять встраивание сторонних СЗИ и СКЗИ, тем самым предоставляя свободу выбора владельцам информационных систем в вопросе, чем и как защищать свою информацию.

Возвращаясь к защите ПДн 1-ой категории, хочу привести ссылку на статью, размещенную в блоге экспертов по безопасности Oracle о сертификации Oracle Identity & Access Management Suite 11g. Данный программный продукт теперь может быть использован как средство защиты от НСД в автоматизированных системах класса 1Г и ПДн до 1 класса!!!

Подводя некоторый итог. На сегодняшний день обеспечить защиту персональных данных любых классов в бизнес-приложениях Oracle, можно как средствами защиты информации корпорации Oracle (СУБД Oracle для защиты ПДн до 2-ого класса и/или Oracle Identity & Access Management Suite для 1-ого класса), так и применяя СЗИ и СКЗИ сторонних производителей.

AppsTech, OEBS, Security, Владимир Коханов, Новости

Если кто-то не читает Стивена Чана (которого категорически рекомендую всем тем, кто занимается технологиями EBS), привожу ссылку на нелицеприятный материал о работе последнего java-плагина Sun JRE 1.6.0_22 (он же JRE 6u22, он же 1.6.0_22-b04) с OEBS.

ССЫЛКА

AppsTech, OEBS, Владимир Коханов

Сегодня, после очередного обсуждения сайзинга под ERP систему, решил изложить мою версию процесса выбора и приобретения оборудования в письменной форме.

Мотивы и цели IT-директора или руководителя проекта внедрения информационной системы всегда понятны и прозрачны. С самого начала имеется желание знать, а во-сколько обойдется внедрение той или иной системы (и вопрос покупки «железа» возникает чуть ли ни сразу).

Предлагаю разобраться.

Процесс внедрения системы обычно делится на несколько этапов, а именно:

1. Предпроект
2. Концепт
3. Прототип
4. Тестирование
5. Пилот
6. Эксплуатация

Этапов проекта может быть сколь угодно много, но основные именно эти. По моим наблюдениям, на большинстве проектов вопрос покупки «железа» под промышленную систему встает на самых ранних фазах. Я отлично понимаю, что перед стартом проекта высшее руководство требует вполне конкретного и обоснованного бюджета и мало кому понравится, когда проект начинает вылезать за рамки утвержденных сумм. И если несколько человеко-дней на консалтинг в плюс или в минус к бюджету не столь критичны, то, например, неправильно выбранное и закупленное серверное оборудование — достаточно серьезная головная боль.

Как снизить риски при выборе оборудования и заложить необходимые суммы в бюджет?

Все начинается с дизайна технической архитектуры системы. Большинство систем имеет трехзвенную архитектуру и т. д. и все такое прочее. Обладая этими знаниями рисуется определенная картинка с серверами баз данных, серверами приложений, концентраторами, шкафами, источниками бесперебойного питания и т. д. Выясняются требования бизнеса к системе, а именно, сколько система может простаивать на профилактике, лимиты на восстановление системы, время отклика при работе с системой и много другое, что может повлиять на количество и мощь оборудования. Если бизнес требует 24×7x365, то встает вопрос о резервном центре и возможности/невозможности использования его мощностей при работе в штатном режиме. В результате число серверов может увеличиться вдвое.

Приведу схемку 24×7x365

С одной стороны, все понятно, вот они все наши «железяки», бери и считай. Но! Не все так просто. Предположим, что у нас имеется необходимость вести разработки и их где-то тестировать (на самом деле и предполагать не нужно, без этого не обходится ни один проект). Сразу встает вопрос о системном ландшафте, включающем в себя системы разработки, тестирования и саму промышленную систему. А ведь это тоже оборудование, которое следует иметь ввиду и без которого нельзя, но его нет на схеме, представленной выше. А резервное копирование? А средства коммутации, серверные комнаты, шкафы под оборудование, энергоснабжение, кондиционирование?

Предположим, что под разработку и тестирование у нас имеется старое оборудование, сетевая инфраструктура вполне устраивает и нам действительно необходимо «железо» только под промышленную систему.

Итак, процесс закупки оборудования:

1. У нас есть схема системы (например, которая приведена выше).

2. Мы выбрали «железного» вендора, к которому больше душа лежит или продукция которого является стандартом нашей организации.

3. Мы (предположительно) знаем количество пользователей, которые будут работать в системе и их системные роли (кадровики, коммерсанты, производственники, бухгалтера и прочие финансисты).

4. Имея на руках перечисленные выше данные, обращаемся к «железному» вендору за расчетом и коммерческим предложением. У крупных вендоров имеются специализированные конфигураторы для популярных промышленных информационных систем, которые на основе заполненных опросников (обычно заполняются совместно с «железным» вендором), произведут выбор оборудования, составление спецификации и ее расценку.

5. Цифры, полученные пункте 4, следует внести в бюджет, защитить его и на этом успокоиться.

6. Начать проект и настройку системы на том оборудовании, которое было выбрано под эти цели (из имеющегося или закупленного специально для начальных стадий проекта). Согласитесь, чтобы настраивать систему силами нескольких консультантов (даже десятков), супердома от известных «железных» брендов не требуются.

7. Один из самых важных пунктов. Система настроена и начато тестирование. Именно в этот период можно получить реальные цифры. Узнать сколько ресурсов потребляют пользователи и смоделировать нагрузку, с которой придется справляться промышленной системе.

8. Имея на руках расчеты из пункта 7 можно возвращаться к спецификации вендора и смотреть, насколько мы ошиблись. Ошиблись в большую сторону, хорошо. Сэкономим. В меньшую, тоже неплохо, потому как приобрети мы оборудование на ранних фазах проекта, что бы мы с ним в дальнейшем делали? Ситуация неприятная, но на самом деле не фатально критическая. Все таки «железо» можно масштабировать по вертикали (добавляя процессоры и оперативную память), а современные информационные системы масштабируются горизонтально (за счет добавления серверов приложений или узлов в кластер серверов баз данных).

9. Приобретаем «железо» для промышленной системы.

10. Запускаем систему в промышленную эксплуатацию на приобретенном оборудовании.

Еще один аргумент, почему не следует спешить с покупкой серверного оборудования. Сколько в среднем идет проект внедрения системы? Год! В течении этого года многое может измениться. Как минимум, выбранное оборудование несколько морально устареет и скорее всего подешевеет. Плюс ко всему, на рынке может появиться более интересное «железо».

AppsTech, Владимир Коханов