1 задание. Вадим Алджанов итархитектура от а до Я Теоретические основы. Первое
 Скачать 8 Mb.
|
|
Этапы выбора ИТ решения Можно определить следующий порядок действий по ИТ проекту. На первом этапе: •Сбор требований со стороны бизнеса – инициатора проекта (бизнес требования) •Добавление технических требований со стороны департамента Безопасности •Добавление технических требований со стороны ИТ департамента На втором этапе: •Поиск решений, без ограничений по стоимости, архитектуре и т п. •Сбор заявленных возможностей решения На третьем этапе: •Анализ решений (со стороны бизнеса) на соответствие бизнес требованиям •Анализ решений (со стороны ИТ департамента) на соответствие требованиям, архитектуре и т п •Формирование «короткого» списка решений удовлетворяющих всем требованиям. При необходимости проводится обращение к департаменту Снабжения для получения предложений На четвертом этапе: •Детальный анализ решения, выбор архитектуры, производителя, определение бюджета и т п •Принятие решения по бюджету, срокам (со стороны бизнеса) •Формирование технического задания для проведения тендера •Формирование плана внедрения (частичное, полное и т п) •Выбор «короткого» списка победителей •Уточнение последних изменений и дополнений •Финальный тендер (по необходимости) для «короткого» списка компаний На пятом этапе: •Закупка •Подготовка к внедрению •Внедрение •Корректировка •Сопровождение •Обновление и улучшение •Вывод из эксплуатации Метод Покупки Готового Решение (COST или «OFF-the-SHELF») COST или («OFF-the-SHELF» коробочное готовое решение) – Одним из подходов является покупка готовых решений. При покупке такого программного обеспечения организация должна: •понимать достоинства и недостатки этого подхода; •формализовать процесс выбора наиболее эффективного готового решения; •определить процесс для эффективной интеграции и настройки готового решения; •определить функциональные требования на приемлемом уровне; •сформировать перечень управленческих и операционных требований; •определить требования к продукту и поставщику; •определить требования к интеграции услуги. При покупке решения остается необходимость в: •кастомизации (customization) – адаптация продукта под требования клиента, первоначальное конфигурирование, настройка интерфейса, изменение бизнес процессов и т п, •локализация (localization) – язык интерфейса, перевод печатных форм и т п. Основные преимущества – Покупка готовых пакетов программного обеспечения более экономична, часто более быстрое решение при выборе и внедрении. Может быть представленная клиенту как действующая «модель» или «прототип». Клиент уже на этапе выбора решения может иметь полную картинку возможностей и внешнего вида конечного продукта, имеющиеся ограничения и т п. К недостаткам можно отнести – менее гибка, чем разработка собственных решений. Концепция Информационной Безопасности Общие Положения Данный раздел содержит основные принципы архитектуры и информационной безопасности которые должны быть приняты во внимание. Раздел основывается на международных стандартах и практиках в области информационной безопасности, таких как серия ISO/IEC27000, ISO/IEC27001, ISO22301:2012, ISO15408, ISO17799 (BS7799), NIST серии 800-хх, Information Security Forum (ISF). Диаграмма Концепция «Defense in Depth» Задачи Информационной Безопасности Обеспечения информационной безопасности способствует решению следующих задач: •определение целей обеспечения информационной безопасности компьютерных систем; •создание эффективной системы управления информационной безопасностью; •расчет совокупности детализированных не только качественных, но и количественных показателей для оценки соответствия информационной безопасности заявленным целям; •применение инструментария обеспечения информационной безопасности и оценки ее текущего состояния; •использование методик управления безопасностью с обоснованной системой метрик и мер обеспечения разработчиков информационных систем, позволяющих объективно оценить защищенность информационных активов и управлять информационной безопасностью компании. Необходимо определить приоритеты по критериям (Confidentiality, Integrity and Availability CIA): •Конфиденциальность (Confidentiality) •Целостность (Integrity) •Доступность (Availability) Данные приоритеты требуется определить, как для организации в целом, так и для каждой ИТ системы. Классификация информации и ИТ активов Все ИТ активы и информация должны быть классифицированы с точки зрения безопасности по уровню конфиденциальности. Обязательные требования для обеспечения конфиденциальности: •Классификация данных. •Наличие политики определяющий уровни доступа. •Наличие процедур по работе с данными каждого класса. Классификации данных может быть построена на основе следующих условий: •Требования устанавливаются регулирующими органами. •Требования определяются внутри компании. •Классификация данных установленных регулирующими органами не может быть понижена •Доступ к данным предоставляется по принципу «минимальных привилегий» Классификация данных по уровню доступа: Общего доступа – Могут быть опубликованы за пределами компании (например, перечень товаров и услуг, цены и т п) Внутреннего использования – Документы предназначенные для сотрудников компании. Утечка данных за пределы компании не наносят ущерба компании (процедуры, принятые в компании и т п) Конфиденциальные – Данные содержат информацию, разглашение которой может нанести ущерб компании (репутации, финансовые потери и т п). Контроль за данными не регламентируется внешними контролирующими органами, но являются важными с точки зрения руководства компании (пароли к системам, контактные данные руководителей и т п). Секретные – Данные регламентируются внешними контролирующими органами и разглашение которой наносит ущерб компании (репутации, финансовые потери и т п). к ним можно отнести финансовые данные клиентов и т п. Классификацию данных необходимо проводить с представителями бизнеса и функциональных департаментов компании. Для определения информационных потоков и уровня интеграции данных необходимо провести классификацию данных информации по ряду атрибутов: Зона покрытия – Данные локального значения и представляющие ценность для одной компании. Как пример; заказ столиков, обслуживание официантом в разрезе столиков/клиентов. Данная информация может быть интересна для одной компании (отеля) и не представляют ценность для других компаний компании, наиболее востребованные комнаты, меню и т п может быть интересна для портфеля и т п Зона видимости- Кому предназначены данные. Например, финансовые данные портфелей и компаний могут видеть только представители финансового департамента компании и правление, но представитель портфелей не видят информацию другого портфеля. Тип данных – Бизнес информация или же техническая. Владелец данных – подразделение или лицо, отвечающее за работу с информацией (целостность и доступность). Необходимое контактное лицо для получения дополнительной информации и данных по процессу и т п Классификация данных по ИБ – (коммерческая тайна, внутреннего пользования и т п). Данные по клиентам, которые могут быть переданы компаниям компании или нет. (контактные данные клиентов отелей могут быть интегрированы в единую систему управления клиентами (CRM) и в дальнейшем использоваться в маркетинговых целях для поиска потенциальных клиентов и т п) Происхождение данных – Данные являются первичными, извлечены из бизнеса системы или же являются производными после проведения аналитических вычислений. Как пример имена, и контактная информация клиентов (Hospitality) может рассматриваться как первичные данные, а список потенциальных клиентов для Retail Group проанализированный в системе (Hospitality) по ряду показателей (платежеспособность, количество потраченных средств, поведения клиента и т п) может рассматриваться как производные данные. Источник данных – Веденный вручную оператором и наименование системы. Уровень достоверности данных – данные внесены из установленных источников или являются предположениями и умозаключениями. Для контроля информации можно ввести «Маркер безопасности» – буквенно-цифровой идентификатор, определяющий уровень конфиденциальности документа. Определение потоков данных Потоки данных должны быть описаны для каждой категории информации с указанием дополнительных атрибутов. Идентификация пользователя Все пользователи ИТ сервисов уникально идентифицированы в системах (учетная запись пользователя домена, почтовой системы, пользователь бизнес приложения и т п). Доступы к ИТ активам должны предоставляться на уровне групп. При проведении расследований инцидентов или нарушения информационной безопасности опираются на учетную запись пользователя. Все действия, связанные со сменой прав доступа или атрибутов учетной записи (пароля и т п) должны фиксироваться. Пользователь несет ответственность за любые действия, связанные с активностью его учетной записи. Классификация по группам доступа и ролям Все пользователи ИТ сервисов должны быть сгруппированы по группам и ролям. Доступы к информационным системам и сервисам предоставляется на уровне групп. Доступы сотрудников ИТ департамента также должны быть разграничены по группам, в зависимости от выполняемых действий и привилегий. Процесс предоставления прав доступа и членства в группах должен быть соответственно организован и документирован. Принцип Минимальных Привилегий При предоставлении права и доступов всем пользователям ИТ систем и сотрудникам ИТ необходимо руководствоваться правилами «минимальных привилегий». Использование лицензионного программного обеспечения Использование лицензионных программных продуктов в «рабочей» среде является обязательным требованием для всех без исключения функций и подразделений организации. Организация процесса Информационной Безопасности Ключевые компоненты В процессе управления Информационной Безопасности учитываются следующие ключевые показатели и определения: •Должны участвовать как минимум Бизнес департаменты компании, департамент Внутренний Аудит, департамент Безопасности, Финансовый департамент, департамент Управления Рисками, департамент Отдел Кадров и ИТ департамент или подразделения исполняющие их функции. •Организационная структура компании должна должным образом управлять «конфликтом интересов» департаментов •Бизнес департаменты определяют классификацию информации в соответствии с бизнес процессами •Департамент Рисков проводит оценку рисков •Департамент Безопасности предоставляет рекомендации по вопросам Информационной Безопасности •Департамент Управления Кадрами обеспечить обучение и ознакомление работников с информацией касательно Информационной Безопасности •Департамент Внутреннего Аудита проводит анализ на соответствие нормам и процедурам, а также необходимый мониторинг •Департамент Безопасности обеспечивает физическую защиту ИТ активов •Департамент Безопасности ведет мониторинг активности, связанной с ИБ •ИТ департамент обеспечивает защиту и управление ИТ активами •ИТ департамент разрабатывает необходимую документацию Разделения Обязанностей в рамках организации Различают различные принципы и подходу к разделению обязанностей между департаментом Безопасности и ИТ, например, департамент Безопасности выполняет непосредственное управление, внедрение и сопровождение сервисов информационной безопасности ИТ инфраструктуры. Можно выделить следующие модели разделения обязанностей: •Департамент Безопасности непосредственно управляет системами информационной безопасности. К ним может относится системы защиты периметра, предоставления доступа в интернет, защиты почты и т п. ИТ департамент непосредственно управляет ИТ системами. •Департамент Безопасности непосредственно управляет частью функций в системах, связанных с информационной безопасностью. К ним можно отнести настройка правил и политик на фаервола, активация и деактивация пользователей и т п. ИТ департамент непосредственно управляет ИТ системами и системами ИБ. •Департамент Безопасности и департамент ИТ совместно непосредственно управляют системами информационной безопасностью и ключевыми ИТ сервисами. Реализация возможна как административными действиями: одна учетная запись – две части пароля у разных департаментов, или же с помощью специализированных средств. Для большинства организаций может подойти следующий подход: •Департамент Безопасности – является «владельцем» ИБ. Обеспечивает физическую безопасность ИТ активов, определяет требования к системам безопасности в целом и информационной безопасности, политики ИБ и т п. Выполняет контрольные функции в отношении надлежащего и своевременного исполнения ИТ департаментом требований ИБ. Непосредственно управляет такими системами безопасности, как система контроля доступа (физическая), система видеонаблюдения, системы оповещения о пожаре и проникновении. По отношению к ИТ департаменту в вопросах безопасности является «головой». ИТ департамент – в рамках информационной безопасности, является «управляющим» информационных систем, комплекса информационной безопасности. Сотрудники ИТ департамента выполняют непосредственное конфигурирование, внедрение и сопровождение компонентов инфраструктуры информационной безопасности. Предоставляют доступ «только для чтения» для сотрудников подразделения ИБ и передачу логов активности компонентов ИТ инфраструктуры. Оказывают техническое содействие департаменту безопасности по внедрению и сопровождению систем безопасности. В зависимости от количества и сложности решений, в составе ИТ департамента может существовать подразделение ИТ Безопасности, отвечающее за сервисы обеспечивающие информационную безопасность. По отношению к департаменту Безопасности является «руками». Департамент Внутреннего Аудита – в составе комитета, формирует требования по организации взаимодействия департаментов, проводит контроль соответствия деятельности департаментов безопасности и ИТ требованиям руководящих документов. По отношению к департаментам Безопасности и ИТ по вопросам информационной безопасности является «глазами». Преимущества данного подхода: •Нет необходимости держать значительный штат в департаменте Безопасности, который по сути дублирует действия ИТ. При внедрении и сопровождении любого ИТ сервиса или информационной системы, вопрос по обеспечению информационной безопасности – обязательный. •Простота разграничения прав и ответственности. «Безопасность» говорит, «ИТ» выполняет, «Безопасность» контролирует исполнение. Особенности большинства Информационных систем – ролевой доступ и наличие «Административного» доступа с максимальными привилегиями. Наличие двух администраторов в одной системе может приводить к конфликтам интересов, разбирательствам таким как кто-то что-то изменил, в логах не отражается и т п. •Наличие цепочки контролей и взаимный мониторинг. ИТ имеет максимальные возможности к информационным системам. За обладателями таких возможностей необходим надлежащий контроль. Фактически эта роль возлагается на департамент Безопасности, по принципу «Вы следите за всеми – мы следим за вами». Все действия ИТ отслеживаются и передаются за пределы ИТ департамента. В тоже время, ИТ отслеживает действия департамента Безопасности в рамках «обычных пользователей» систем. Каждая модель имеет свои преимущества и недостатки. Выбор модели зависит от требований бизнеса, возможностей систем, политики компании и ее возможностей. Модели Информационной Безопасности и защиты данных Для обеспечение Информационной Безопасности в целом, и ИТ безопасности в частности применяются различные модели защиты конфиденциальности, целостности и доступности. Обычно применяются смешанные модели Информационной Безопасности. В качестве основных моделей можно выделить следующие: Bell La Padula – модель защиты конфиденциальности Bell La Padula – модель (многоуровневой) защиты конфиденциальности. Построенная на модели «информационных потоков». Модель конечных автоматов, которая реализует аспекты защиты конфиденциальности на основе матрицы «Субъект-объект» с применением трех основных правил: Simple Security Rule: Субъект НЕ МОЖЕТ ЧИТАТЬ данные на более высоком уровне. Star Property Rule: Субъект НЕ МОЖЕТ ЗАПИСАТЬ данные на более низком уровне. Strong Property Rule: Субъект МОЖЕТ ЧИТАТЬ и ЗАПИСАТЬ данные только на своем уровне. Biba – модель защиты целостности Biba – модель защиты целостности. Построенная на модели «информационных потоков». Модель использует сетку целостности. Основные принципы модели: Integrity Axiom: Субъект НЕ МОЖЕТ ЗАПИСЫВАТЬ на верх Simple Integrity Axiom: Субъект НЕ МОЖЕТ ЧИТАТЬ данные находящиеся на нижнем уровне Invocation property: Субъект НЕ МОЖЕТ ЗАПРАШИВАТЬ обслуживание (call) у другого субъекта, находящегося на более высоком уровне. State Machine Model State Machine Model – модель защиты безопасности, основанной на состояниях (state). Information Flow Model – модель защиты данных Clark Wilson – модель защиты целостностью Clark Wilson – модель защиты целостностью. Выполняет три основные цели: •Предотвращает изменения не авторизованного пользователя •Предотвращает выполнение не корректных изменений •Обеспечивает согласованность «правильные транзакции» Вводит понятия: «Пользователь», «Transformation Procedure TP», «Constrained Data Item CDI», UDI, IVP и т п. Access Triple: «Субъект – программа TIP – объект CDI» Внесение изменений только через TIP. IVP поддерживает внутреннюю и внешнюю согласованность и разделение обязанностей. Модель «не влияния» – управление целостностью Модель «не влияния» – модель управления целостностью. Действия, происходящие на верхнем уровне, не влияют на сущность внизу. Обеспечивает защиту от «Interference Attack» атак. |