1 задание. Вадим Алджанов итархитектура от а до Я Теоретические основы. Первое
 Скачать 8 Mb.
|
|
Модель сетки «Lattice» Модель сетки «Lattice» – модель защиты, построенная на основе групп. Brewer & Nash «Китайская стена» Brewer & Nash «Китайская стена» – модель управления доступом и защиты конфликтов интересов. Построенная на модели «информационных потоков». Основной принцип: Если пользователь имеет доступ к данным «А», то автоматически запрет на доступ к данным «Б» Модель Graham – Denning – управление целостностью Модель Graham – Denning – модель управления целостностью. Опирается на набор прав (8 команд), которые субъект может выполнить над объектом. Список команд: •Create object •Create subject •Delete •Read rights •Provide & delete rights Модель Harrison Ruzzo Ulman Модель Harrison Ruzzo Ulman – модель управления правами доступов субъектов. Дискретное Управление Доступом (Discretionally Access Control DAC) Дискретное Управление Доступом (Discretionally Access Control DAC) – управление доступом на основе списков управления доступом (ACL). Обычно является задачами администратора. Относительно простое в плане администрирования. Требует высокий уровень формализации организации. Мандатное Управление Доступом (Mandatory Access Control MAC) Мандатное Управление Доступом (Mandatory Access Control MAC) – управление доступом на основе меток доступа. К таким меткам могут относится метки «секретно», «конфиденциально», принадлежность к проекту или функции и т п. Обычно управляется владельцем. Относительно простое в плане реализации и безопасности. Сложно управлять в централизованной модели и требует высокий уровень осведомленности владельцев ресурсов. Основаны на модели защиты конфиденциальности «Bell La Padula». Ролевое Управление Доступом (Role Based Access Control RBAC) Ролевое Управление Доступом (Role Based Access Control RBAC) – управление доступом на основе ролей и членства в группах. Обычно управляется администратором. Является наиболее распространённым в различных современных системах корпоративного управления. Гибкая (гранулярная) система предоставления доступов. Один из недостатков, наличие супер-администратора, с полным доступом к ресурсам и необходимости детальной проработки ролей. Атрибутное Управление Доступом (Attribute based Access Control ABAC) Атрибутное Управление Доступом (Attribute based Access Control ABAC) – Представляет из себя предоставление доступов, на основе статических или динамических правил, связанных с атрибутами (времени суток, расположения, членства в группе и т п) объекта и субъекта доступа. Основной недостаток – сложность реализации и контроль за состоянием доступа. Наиболее передовая с точки зрения обеспечения информационной безопасности. Также может называется Динамическим Управлением Доступом (Dynamic Access Control DAC). Уровни доступа Для управления ИТ активами используется преимущественно модель на основе предоставления контроля по Ролям (Role Based Access Control (RBAC). Такой подход реализован практически во всех ИТ системах. Уровни доступа к Информации Используется комбинированная модель на основе предоставления контроля по Ролям (Role Based Access Control (RBAC)) с Дискретным Распределением прав (Discrete Access Control (DAC)) к файловым ресурсам. Такие возможности реализованы практически во всех современных ИТ системах. Уровни доступа к Информации (дополнительный) Для обеспечения более избирательного и доступа к информации и контроля может понадобится дополнительный специфические ИТ решения с использованием модели (MAC), метки уровня доступа и категорий, а также правил ABAC. Матрица Контроля Доступов (Access Control Matrix) Матрица контроля доступов, а также классификация и категоризация объектов (информации) является ключевыми элементами обеспечения Информационной Безопасности. Требование к процессу управления данных Различают три основных состояния данных: •Данные в покое (Data at rest) – должны хранится в дата центре компании. Данные должны быть зашифрованы и готовы к использованию в соответствие с матрицей доступов. Должно обеспечиваться надежное хранение, резервирование и архивирование данных. •Данные в перемещении (Data in motion) – должны быть должным образом зашифрованы при передаче на конечные системы •Данные в использование (Data in use) – должны использоваться только на соответственно подготовленных устройствах и авторизированными пользователями или системами. Потоки движения информации Движение информации можно разделить по следующим типам: Вертикальная (North-South) — Данные перемещаются между уровнями, к примеру, от компании в портфель, из портфеля в компания. Горизонтальная (West-East) – Данные перемещаются в пределах одного уровня, к примеру, между одной компанией в другую в одном портфеле. С низу в верх (Button-Up) – Направление движения данных с низу в верх, к примеру, от компании в портфель, от портфеля в компания. С верху в низ (Top-Down) – Направление движения данных с верха в низ, к примеру, от портфеля в компанию, от компании в портфель. Зоны доверия (Trust Zone) – формируются как логические зоны в пределах одной компании (доверительная зона компании), в пределах одного портфеля (доверительная зона портфеля) или компании (доверительная зона компании) или же внешняя (за пределы компании) зона. Зоны доверия могут быть как «горизонтальные» (несколько филиалов одной компании), так и «вертикальные» (несколько компаний одного портфеля). В зависимости от уровня конфиденциальности (публичные, секретные и т п) определены основные критерии и ограничения: Данные «Общего доступа» могут передаваться от компании в портфель, за пределы компании как горизонтально, так и вертикально в обоих направлениях. Данные «Внутреннего использования» могут передаваться от компании в портфель, как горизонтально, так и вертикально в обоих направлениях в пределах информационного пространства компании (корпоративная почта, информационная система и т п). Данные «Конфиденциальные» могут передаваться: горизонтально – внутри компании в обоих направлениях (работник – руководитель при наличии у обоих соответствующего уровня доступа «Конфиденциальные») вертикально – в обоих направлениях от компании в портфель, в пределах одной зоны доверия (компания входит в состав портфеля) и наличия соответствующего уровня доступа «Конфиденциальные» у обоих пользователей. вертикально – в направлении с низу вверх от компании в портфель, в пределах одной зоны доверия (компания входит в состав портфеля) и наличия соответствующего уровня доступа «Конфиденциальные» у пользователя портфеля. Данные «Конфиденциальные» не могут передаваться: горизонтально – между компаниями одного портфеля (доверительная зона портфеля) даже при наличие соответствующего уровня доступа «Конфиденциальные» у обоих) Вертикально – внутри компании в направлении с верху в низ (руководитель – работник при отсутствии у последнего соответствующего уровня доступа «Конфиденциальные») вертикально – в направлении с верху вниз, в пределах одной зоны доверия (доверительная зона портфеля) при отсутствии соответствующего уровня доступа «Конфиденциальные» у пользователя в компании. Данные «Секретные» могут передаваться по указанным для каждого конкретного типа документа порядка следования. Это связано с особыми условиями данного класса документов, перемещение и доступ к которым регламентируется внешними регуляторами. Если конкретно не указан порядок следования, и отсутствует требования со стороны внешних регуляторов, то данные перемещаются в соответствии с правилами, как и для Конфиденциальные». Порядок развертывания ИТ инфраструктуры с позиции ИБ При проектировании, внедрении и сопровождении ИТ сервисов можно рассмотреть следующую модель поведения: Диаграмма Сценарии ИБ Базовый сценарий «Базовый сценарий» – внедрение решения и его конфигурация в соответствии с практиками. Основная мысль – соблюдение принципов «Парето» (20 процентов усилий решают 80 процентов задач). Рассматривается как основной при внедрении ИТ сервисов. Оптимальный сценарий «оптимальный сценарий» – в процессе внедрения и сопровождения, можно оптимизировать решение как с точки зрения информационной безопасности, так и с точки зрения оптимизации стоимости. Параноик «параноик» – сценарий, при котором делается максимальный уклон в сторону информационной безопасности, даже в ущерб таким важным критериям как стоимость, доступность и управляемость сервиса. Упрощенный сценарий «Упрощенный сценарий» – сценарий, при котором некоторые базовые настройки изменяются, что ведет к незначительному снижению информационной безопасности в угоду значительному снижению стоимости или повышенному уровню доступности и управляемости. Дуракам везет «дуракам везет» – сценарий, при котором, по каким-либо причинам явно нарушены основные принципы информационной безопасности. В ИТ системах возможны случаи, когда одна и та же система, при одинаковой стоимости, может быть настроена в соответствии со всеми пятью сценариями. В этом случае процесса развертывания по сценариям (готовые сценарии), должен рассматриваться как механизм реагирования на угрозы информационной безопасности. Для этого создается несколько сценариев готовности всех ИТ сервисов, и при повышении на пример уровня активности хакеров или общего фона ИБ, все системы ИТ инфраструктуры переходят с «базового» сценария на «оптимальный». Условия совершения компьютерных преступлений При проектировании и анализе Информационной Безопасности рекомендуется учитывать совпадения следующих условий, необходимых для совершения преступления: Мотив (Motive – WHY) Мотив (Motive – WHY). Мотивация для совершения преступления. В качестве мотиваций может служить недовольство сотрудников, получение финансовой прибыли и т п. Как пример, можно предположить недовольство системного администратора условиями работы и т п. Условия (Means – HOW) Условия (Means – HOW). Наличие необходимых условий, для совершения преступления. Подразумевается наличие технических возможностей для совершения действий. Так, например, системный администратор имеет возможность по смене пароля пользователя и затем просмотр его почты. Наличие мотива и условий, не достаточны для совершения преступления. Возможности (Opportunity – WHEN+WHERE) Возможности (Opportunity – WHEN+WHERE). Совпадение благоприятных условий для совершения преступления. Так для нашего примера, отсутствие политик по смене пароля, профилактика, отсутствие систем сбора и обработки логов и т п. Система мониторинга и отчетности должна быть внедрена на всех стадиях процесса управления данными. Контроли управления по защите информации Общие положения Для успешного внедрения комплекса решений по информационной безопасности, не менее важным аспектом является внедрения контролей управления. К таким контролям можно отнести следующие категории: Административные (Administrative) – административные меры по обеспечению информационной безопасности •Наличие документов в области информационной безопасности •Соблюдение требования информационной безопасности •Проведение обучения и семинаров для сотрудников организации Физические (Physical) – физические элементы по обеспечению информационной безопасности •Физическая безопасность помещений дата центра •Физическая безопасность серверов •Физическая безопасность рабочих компьютеров Технические (Technical/Logical) – технические аспекты по обеспечению информационной безопасности •Контроль за физическими носителями информации (шифрование носителей), •Включение персонального фаервола •Установка средств антивирусной защиты Механизмы обеспечения информационной безопасности •Превентивные (Preventive) – механизмы, призванные предотвратить инциденты ИБ •Восстановительные (Reductive) – механизмы, принятые заранее, что может минимизировать риски •Детективные (Detective) – механизмы, призванные как можно скорее определить, что инцидент имел место •Репрессивные (Repressive) – механизмы, применяемые в ответ на повторяющиеся или продолжающееся инциденты •Корректирующие (Corrective) – механизмы восстановления и т п Контроли (активные меры противодействия) могут быть разбиты на следующие функции (фазы): •Директивный (Directive) – команды и информирование по предотвращение появления угроз (плакаты, предупреждения). •Превентивные (Preventative) – обеспечивают предотвращение появления угроз. •Сдерживающие (Deterrent) – создают сдерживающие факторы, предотвращающие появление угрозы •Детективные (Detective) – определяю угрозу, имеющуюся в вашей системе •Корректирующие (Corrective) – обеспечивают снижение воздействия угрозы •Восстановительные (Recovery) – обеспечивают восстановление элементов безопасности. Как пример наличие отказоустойчивости и т п •Компенсирующие (Compensatory) – обеспечивают снижение воздействия угрозы, если она все же имела место. На приведенной таблице показаны основные четыре фазы и какие меры и технические решения можно отнести к какой из них: Кроме этого необходимо оценивать контроли по следующим атрибутам: •Сложность (Complexity) – какова сложность обхода контролей. В качестве сложностей могут выступать технические, физическая, материальная и т п сложность. •Доступ (Access) – Какие доступы необходимо получить для обхода контроля •Привилегии (Privilege) – какие привилегии (возможности) получит преступник, при обходе контроля. Методы проведения теста на проникновение Проведение теста на проникновение позволяет оценить состояние информационной безопасности организации, как с технической точки зрения, так и с точки зрения готовности сотрудников и процессов организации. Тестирование может проводится для проверки как конкретного решения (интернет банкинга, сайта и т п), готовность сотрудников департаментов ИТ и Безопасности (Red Team Testing), или всей организации. Обычно проводится с привлечением компаний, имеющих опыт по проведению данных тестов, классифицированный персонал, методику и технические средства. В качестве методик проведения теста на проникновение могут быть использованы: OISSG OSSTMM NIST Guideline on Network Security Testing ISACA Testing IT Systems Security Cybersecurity VAMs OWASP Testing Guide Собственные методики Основные десять видов угроз по спецификации OWAST top 10: Injections Broken Authentication & Session Management CSS / XSS Insecure Direct Object References Security Misconfiguration Sensitive Data Exposure Missing Function Level Access Control CSRF / XSRF – Подделка межсайтового запроса Using components with known vulnerabilities Invalidated Redirects & Forwarding Резервное копирование и архивирование данных Политики резервного копирования и архивирования одни из важнейших элементов защиты данных в организации. Классическое правило резервного копирования и архивирования данных известное как «3-2-1» подразумевает: •Наличие трех (3) копий данных расположенных в разных местах •Наличие двух (2) форматов / состояний данных •Как минимум одна (1) копия данных располагается за пределами офиса Следующее важное правило, которое необходимо соблюдать: •Тестирование целостности файла резервного копирования или архива •Тестирование возможности восстановления на целевой системе Для грубого расчета объема для резервного хранилища можно принимать соотношение «Дата – Бэкап» 1:3. Существуют следующие стратегии ротации резервных носителей при создания резервных или архивных копий: Пользовательский (Customer) Пользовательский (Customer) стратегия резервное копирование – выполняемое вручную обычно полная копия. Используется обычно перед внесением изменений. Требуется одна операция (создание или восстановление). «Дед – отец – сын» («Grandfather – Father – Son» GFS) «Дед – отец – сын» («Grandfather – Father – Son» GFS) стратегия резервное копирование – выполняемая автоматически или полуавтоматически. Используется обычно по расписанию. «Сын» – Ежедневная полная резервная копия данных на один носитель (файл, контейнер). Период защиты данных – дата последней резервной копии. Требует один носитель (контейнер) информации. «Отец» – Предполагает наличие недельной полной резервной копия данных и ежедневных дифференциальных или добавочных копий данных. В качестве периода защиты выбирается двух недельный период. Требует наличие минимум шести (6) носителей (контейнер) информации. Позволяет восстановить данные каждой недели (2) и ежедневные данные последней недели (4). Стратегия может быть рассчитана на месячный цикл. Для этого понадобится восемь (8) носителей информации: Позволяет восстановить данные конца месяца (1), еженедельные данные месяца (3) ежедневные данные последней недели (4). «Дед» – Предполагает наличие месячной и недельной полной резервной копия данных и ежедневных дифференциальных или добавочных копий данных. В качестве периода защиты выбирается годовой период. Требует наличие минимум девятнадцати (19) носителей (контейнер) информации. Позволяет восстановить данные каждого месяца (12), еженедельные данные последнего месяца (3) ежедневные данные последней недели (4). Ежедневный полный (Daily Full Backup) Ежедневный полный (Daily Full Backup) стратегия ежедневного полного резервного копирование данных с последующим сохранением. Требует наличие порядка (365) носителей (контейнер) информации или по количеству рабочих дней. Обычно применяется в финансовых организациях. «Ханойская башня» («Tower of Hanoi») «Ханойская башня» («Tower of Hanoi») стратегия резервное копирование – выполняемая автоматически или полуавтоматически. Используется обычно по расписанию. Требует наличие нескольких наборов носителей данных. Количество наборов не регламентируется, но принимается обычно пять шесть комплектов. «Стратегия 10 наборов» «Стратегия 10 наборов» – стратегия резервное копирование – выполняемая автоматически или полуавтоматически. Используется обычно по расписанию. Требует наличие десяти наборов носителей данных из расчета сорока (40) недельного периода обращения. За каждым набором закрепляется один день недели. С каждым циклом происходит сдвиг наборов (например, если набор N1 закреплен за понедельником, набор N2 за вторником, то при смене цикла набор N1 сдвигается на вторник и т п). Последние две стратегии используются редко, в связи со спецификой работы и поддержки со стороны систем резервного копирования. Основная причина их использования была продиктована неравномерностью использования ленточных носителей информации, имеющих ограниченное количество операций записи-чтения. При применении Систем Резервного Хранения Данных (СРХД) на основе дисков, данная проблема потеряла актуальность. Еще одним из важных моментов политики резервирования и архивирования является совместное использование политик резервного копирования и архивирования. Возможные варианты комплексного подхода: •Каскадная – соблюдается последовательность: «Рабочий каталог – Резервная копия – Архивная копия» •Независимая – рабочий каталог может являться одновременно источником для резервного копирования, так и архивирования. Независимая модель позволяет соблюдать правило «3-2-1». Данные одновременно хранятся в двух разных местах и в различных форматах. Например, резервная копия хранится жестких дисках системы резервного хранения данных, а архивная копия на ленточных носителях. К недостаткам данной модели можно отнести необходимость более длительного окна для создания сначала резервной, а затем архивной копии. Каскадная модель позволяет уменьшить время работы с рабочими данными, делая только резервное копирование. Архивирование может происходить в рабочее время, не затрагивая рабочие каталоги данных. Кроме этого происходит два процесса с одними данными, что увеличивает вероятность ошибки как при создании, так и при восстановлении, а также требует совместимость систем. Порядок восстановления данных может быть одинаковый. Кроме всего выше сказанного, необходимо отметить следующие аспекты: •современные системы хранения позволяют переносить редко используемые данные на более дешевые носители информации, тем самым уменьшая объем рабочего каталога, что ведет в свою очередь к уменьшению как времени резервирования, так и требуемых объемов. •Продумать отказоустойчивость самих систем резервирования и архивирования. Политика резервного копирования и восстановления данных (Backup & Recovery Policy) Политика резервного копирования одна из важнейших элементов защиты данных в организации. Для формирования грамотной политики резервного копирования необходимо определить ряд входных параметров: Источник данных Тип данных •Состояние системы, сервиса или сервера •Конфигурация •Данные •Логи событий или аудита Объем данных – максимальный объем данных Утилизация данных •используемый объем данных, •характер поведения •прирост данных за определённый период Объем изменений – характер изменений данных и предполагаемый объем измененных данных Окно для проведения резервного копирования – отрезок времени для выполнения резервного копирования Требуемые характеристики: •Объект Восстановления (Recovery Point Objective RPO) – целевая точка восстановления, определяющая объем данных или времени допустимый для потери (дневные изменения и т п) •Время Восстановления (Recovery Time Objective RTO) – целевое время восстановления, определяющее время, необходимое для восстановления данных или сервиса. •Уровень Восстановления (Recovery Level Objective RLO) – целевой уровень восстановления, определяющий на каком уровне необходимо восстановить данные или систему (например, восстановление состояния сервера или сервиса, восстановление данных СУБД или файлов, частичное или полное восстановление). •Триггер срабатывания – механизмы включения резервного копирования: по расписанию, по изменениям. На основе входных данных можно выбрать правильное техническое решение. Существуют следующие опции создания резервных копий: Полное (Full Backup) резервное копирование – обеспечивает резервное копирование всей информации. Характеризуется долгим временем создания и восстановления. Требуется одна операция (создание или восстановление). Резервное копирование накопленных изменений (Differential Backup) – обеспечивает резервное копирование информации изменившейся с момента создания полной резервной копии. Характеризуется относительно коротким временем создания и восстановления. Требуется две операция для восстановления (восстановление полной версии и изменений). Резервное копирование добавочных или дневных данных (Incremental or Daily Backup) – обеспечивает резервное копирование информации изменившейся с момента создания последней резервной копии изменений. Характеризуется коротким временем создания и восстановления. Требуется 1 + N операций для восстановления (восстановление полной версии и последовательное восстановления всех изменений до необходимого момента). Полная копия (Full Copy Backup) резервное копирование – обеспечивает резервное копирование всей информации, без изменения атрибута архивирования файлов. Характеризуется долгим временем создания и восстановления, но требуется одна операция (создание или восстановление). Производится в любой момент времени и не влияет на организацию процесса резервного копирования. Композитное (Composite Backup) резервное копирование – обеспечивает резервное копирование изменений с возможностью создания полной резервной копии на любой момент времени. Характеризуется быстрым временем создания и восстановления. Обычно является функциональной возможностью специализированных программно-аппаратных решений по резервному копированию. Политика резервного копирования должна обеспечивать выполнение следующих требований: •Тип и частота резервного копирования зависит от бизнеса требований и функциональных особенностей сервиса •Тип и скорость восстановления зависит от бизнеса требований и функциональных особенностей сервиса •Ежедневное резервное копирование данных сервиса. Может включать в себя различные уровни такие как резервное копирование целиком виртуальных машин, так и/или данных. Политика восстановления данных (Recovery Policy) Политика восстановления данных описывает организацию обратного процесса, а именно, восстановления данных. Политика должна описывать триггеры, запускающие процесс восстановления, уровень восстановления данных (на уровне сервера, приложения и т п), тип восстановления (полное или частичное). Кроме этого должны быть определены методы и временные рамки. Пример расчета объема резервной копии данных Полезный объем характеризует возможность восстановить данные за последнюю неделю. Полный объем характеризует возможность восстановить данные за месяц и необходимое для этого пространство. Рабочий объем характеризует коэффициент заполнения диска на 60%. Резервная копия виртуальной машины по умолчанию выполняется по схеме: 5 Last Days (Differential) +1 Last Week (Full) + one Current Month (Full) Дневной (D) – Различный (Differential Backup) 5 дней (понедельник-пятница): 5 х 1MB = 5MB один сервер. Еженедельный (W) – Полный (Full Backup) 1 день (суббота): 1 х 60 GB = 60 GB один сервер. Ежемесячный (M) – Полный (Full Backup) 1 день (конец месяца): 1 х 60 GB = 60 GB один сервер. Полный объем резервной копии сервера за месяц: 25D +5W +1M = 75MB+300GB+60GB = 435GB Полный Рабочий объем резервной копии с коэффициентом заполнения диска 60%: 435GB х 0.6 = 261GB Полезный объем резервной копии сервера: 5D +1W +1M = 5MB+60GB+60GB = 125GB Полезный Рабочий объем резервной копии с коэффициентом заполнения диска 60%: 125GB х 0.6 = 75GB Резервная копия данных по умолчанию выполняется по схеме: 5 Last Days (Incremental) +1 Last Week (Full) + one Current Month (Full) Для расчета на каждые 100GB данных при 10% изменениях (10GB) и 60% заполнением диска: Дневной (I) – Различный (Incremental) 5 дней (понедельник-пятница): 5 х 10GB = 50GB один сервер. Еженедельный (W) – Полный (Full Backup) 1 день (суббота): 1 х 100 GB = 100 GB один сервер. Ежемесячный (M) – Полный (Full Backup) 1 день (конец месяца): 1 х 100 GB = 100 GB один сервер. Полный объем резервной копии сервера за месяц: 25I +5W +1M = 250GB+500GB+100GB = 850GB Полный Рабочий объем резервной копии с коэффициентом заполнения диска 60%: 850GB х 0.6 = 510GB Полезный объем резервной копии сервера: 5I +1W +1M = 50GB+100GB+100GB = 250GB Полезный Рабочий объем резервной копии с коэффициентом заполнения диска 60%: 250GB х 0.6 = 150GB Для восстановления данных необходимо 390GB, для хранения резервных копий данных необходимо 590GB. Общий полный рабочий объем пространства для хранения резервной копии сервера и данных 261GB+510GB = 771GB Общий полезный рабочий объем пространства для хранения резервной копии сервера и данных 75GB+150GB= 225GB Политика архивирования данных (Data Archiving Policy) Политика архивирования данных является дополнительным элементом защиты данных. Должна обеспечивать возможность долговременного хранения данных и безапелляционно подтверждать, что данные не были модифицированы с момента их создания. Решение может обеспечивать архивирование резервных копий, или же самостоятельное создание резервной копии с последующим архивированием данных. Политика архивирования данных должна обеспечивать выполнение следующих требований: •Тип и частота архивирования данных зависит от бизнеса требований и функциональных особенностей сервиса •Архивные копии данных должны быть зашифрованы. •Безапелляционно доказывать неизменность данных с момента создания •Обеспечивать долгосрочное хранение информации •Обеспечивать возможность хранения вне организации, и вне ИТ инфраструктуре (внешние носители) Пример расчета объема архивирования данных Архивирование резервных копий серверов в течении 3 месяцев. Архивирование по умолчанию выполняется по схеме: 2 Months (previous months Full Backups) Полный Рабочий объем пространства для хранения архивной копии виртуальной машины 2 х 72GB+261GB = 405GB Полный Рабочий объем пространства для хранения архивной копии данных 2 х 60GB+510GB = 630GB Полезный Рабочий объем пространства для хранения архивной виртуальной машины 75GB +2 х 36GB = 147GB Полезный Рабочий объем пространства для хранения архивной копии данных 150GB +2 х 60GB = 270GB Общий полный рабочий объем пространства для хранения архивной копии сервера и данных 405GB+630GB = 1035GB Общий полезный рабочий объем пространства для хранения архивной копии сервера и данных 147GB+270GB= 417GB Политика устаревания активов (Retention Policy) Политика устаревая активов описывает организацию процесса удаления данных и списания ИТ активов. Основные цели политики: •высвобождение мощностей хранилищ данных •вывод из эксплуатации сервисов, сопровождение которых не целесообразно и не отвечающих требованиям бизнеса •поддержка актуальных данных и сервисов и оптимизация процесса управления ИТ сервисами •высвобождение вычислительных мощностей для новых технологий и сервисов Политика должна обеспечивать классификацию активов, описывать процесс определения устаревания активов, безопасное удаление данных в установленные сроки и надежными методами. Технические аспекты Информационной Безопасности Общие положения Система защиты информации является комплексным / много уровневым решением, обеспечивающим защиту информации и ИТ активы компании. Для успешного обеспечения информационной безопасности необходимо ввести понятия классификации информации и ИТ активов (уровень конфиденциальности), наличие политик и процедур, средств мониторинга, обучения персонала и т п. Системы могут включать весь требуемый функционал в одном программно-аппаратном решении (бюджетный вариант) так и разнесенным по разным устройствам. Выбор рения зависит от требований, особенности работы и финансовых возможностей организации. К системам защиты информации относятся следующие системы и компоненты: Системы защиты периметра: Брандмауэр (Firewall) Системы Аутентификации и контроля доступа (ACL) Система фильтрации веб трафика (Web Security Gateway) Прокси сервер (Forward Proxy Server) Обратный прокси сервер (Reverse Proxy Server) Система обнаружения / предотвращения вторжения (IDS/IPS) Системы защиты от вирусов и зловредных программ (Antivirus) Системы защиты почтовых систем от спама (SPAM filter) Системы защиты веб контента (WAF) Система балансировки нагрузки (Load Balancer) Система сканирования на поиск уязвимостей (Vulnerability Scanner) Системы предотвращения утечки данных (DLP) Система Управления Правами Доступов (Right Management System) Система Идентификации Пользователей (Identity Management System) Системы защиты конечных устройств (Personal Firewall/Antivirus): Персональный Брандмауэр (Personal Firewall) Системы защиты от вирусов и зловредных программ (Antivirus) Системы шифрования жестких дисков и съёмных носителей (BitLocker, NTFS/EFS) Отсутствие «Административного» уровня доступа для всех пользователей систем, принцип «минимальных» привилегий Системы контроля приложений Компоненты информационной безопасности могут являться как функциональными элементами фаервол, так и отдельными решениями. Требования к защите локальной сети и систем Департамент Безопасности должен обеспечивать физическую защиту ИТ активов, как дата центра, так и системы конечных пользователей. Для каждой компании и портфеля могут формироваться свой дополнительные требования и методы защиты с учетом конкретной реализации. Данная задача является ключевой для подразделения Информационной Безопасности. Физический уровень Ограничивается доступ к ключевым элементам сети (коммуникационные шкафы, сетевое оборудование и т п) Не используемые рабочие точки конечных пользователей блокируются (либо не подключаются к коммутатору, либо блокируются на коммутаторе) Физическая изоляция гостевой сети беспроводного соединения (Guest Wi-Fi isolation). При использовании персональных устройств (телефонов, планшетов и т п) в корпоративной сети, обязательно включение механизма 802.1Х и WPA2-Enterprise. Использовать средства мониторинга сети на предмет работы «не авторизированных» DHCP серверов по специфике отклика и значению TTL. Контроль или блокировка локальных портов и устройств серверов и конечных пользователей. Использование пароля на доступ к BIOS серверов и конечных пользователей. Шифрование устройств хранения данных (дисков) серверов и конечных пользователей. Канальный уровень Сегментирование сети на канальном уровне (Виртуальные сети) Обеспечивается защита портов коммутатора (Port Security). На каждый порт коммутатора привязывается аппаратный адрес устройства (MAC address) или группы устройств, имеющих возможность, подключатся. Или статическая таблица на коммутаторе (CAM) Включается связка сервера динамической раздачи сетевых адресов (DHCP snooping). Явное указание на коммутаторе на каком порте отвечает авторизированный DHCP сервер. Инспекция механизма разрешения адресов (ARP inspection). Контроль и мониторинг связки сетевого адреса и аппаратного адреса устройства (MAC address – IP address). Защита источника (Source Guard). Дополнительный механизм защиты, обеспечивающий привязку MAC address – IP address к интерфейсу коммутатора. Сетевой и транспортный уровень Контроль маршрутизации и настройка доступов по правилу «только разрешено» Использовать для обращения в сети только имена ресурсов (FQRN) вместо сетевых адресов. Тем самым принудительно инициируется использование Kerberos протокола для систем на базе Microsoft Windows. Блокировать использование протоколов и механизмов ниже чем NTLM v2. Возможно использование групповых политик для выполнения данных задач Блокировка механизма WPAD. Для реализации необходимо через групповые политики запретить авто-обнаружения прокси и протокола LLMNR, или же назначение статической записи. Установить «заглушку» в DNS сервере на WPAD запись (WPAD.domain.name). Отключение протокола NetBIOS. Отключение скрытых ресурсов ADMIN$, C$, D$ и т п для систем на базе Microsoft Windows. Возможно через групповые политики. Активировать возможности систем безопасности на серверах и конечных устройствах (антивирус, фаервол и т п) Отключение на системах конечных пользователей систем на базе Microsoft Windows сервиса «Предоставления файлов и печати для совместного пользования» Не создавать локальные учетные записи администраторов через механизм групповых политик для систем на базе Microsoft Windows. Использовать доменные учетные записи для локальных групп администраторов для систем на базе Microsoft Windows. Требования к пропускной способности (минимальная, максимальная, ожидаемая) управления адресами сети Контроль трафика Шифрование трафика критически важных приложений и систем Ведение лога активности Корпоративная сеть отделена от публичной сети (интернета) по средствам Демилитаризованной зоны (DMZ) Корпоративная сеть защищена по периметру техническими средствами и решениями, такими как фаервол (Next Generation Firewall (NGFW)) При необходимости фаервол защиты веб приложений (Web Application Firewall (WAF)) Системы Обнаружения и Предотвращения Вторжения (Intrusion Detection and Intrusion Prevention Systems (IPS/IDS)) должны быть соответственно настроены Ресурсы публикуемые наружу должны быть размещены в Демилитаризованной зоне (DMZ) Корпоративная сеть должна быть правильно сегментирована с учетом уровня портфелей и компаний Сетевые устройства настроены с учетом безопасности для периферийных устройств, и с учетом производительности для внутренних устройств Только необходимые сервисы должны быть запущены, и разрешенные протоколы и порты настроены на данных устройствах Трафика между клиентом и сервером должен шифроваться Все сетевые устройства должны быть своевременно обновляться При необходимости развернут комплекс мер по Защите от Утечки Данных (Data Leakage / Loss Prevention (DLP)) Необходимый мониторинг активности и состояние сети должен вестись с возможностью предоставления отчетности Требование к серверам и инфраструктуре виртуализации и систем хранения Все сервера должны быть своевременно обновлены (обновления, прошивки) На всех серверах должны быть включены и настроены локальные фаерволы На все сервера должны быть установлены средства антивирусной защиты Корпоративная сеть должна быть правильно сегментирована с учетом уровня портфелей и компаний Серверный сегмент отделен от сегмента клиентов Только необходимые сервисы должны быть запущены, и разрешенные протоколы и порты настроены на данных устройствах Трафика между клиентом и сервером должен шифроваться При необходимости развернут комплекс мер по Защите от Утечки Данных (Data Leakage / Loss Prevention (DLP)) Необходимый мониторинг активности и состояние серверов должен вестись с возможностью предоставления отчетности Требование к системам конечных пользователей Все системы конечных пользователей должны быть частью леса На все системы конечных пользователей должны входить с учетными данными леса Локальные диски всех систем конечных пользователей должны быть зашифрованы Порты ввода / вывода (DVD, USB etc.) всех систем конечных пользователей должны быть под контролем или же деактивированы Все системы конечных пользователей должны быть своевременно обновлены (обновления, прошивки) На всех системах конечных пользователей должны быть включены и настроены локальные фаерволы На все системах конечных пользователей должны быть установлены средства антивирусной защиты На все системах конечных пользователей должно быть установлено только разрешенное программное обеспечение Пользователи не должны знать или использовать учетные записи с повышенными привилегиями Только необходимые сервисы должны быть запущены, и разрешенные протоколы и порты настроены на данных устройствах Трафика между клиентом и сервером должен шифроваться При необходимости развернут комплекс мер по Защите от Утечки Данных (Data Leakage / Loss Prevention (DLP)) Необходимый мониторинг активности и состояние систем конечных пользователей должен вестись с возможностью предоставления отчетности Все системы и компоненты информационной безопасности должны по возможности тестироваться на возможность выполнения атаки, с использованием различных инструментов, в том числе и выделенных инструментов таких как «Ixia Breakpoint». Уровень приложений Не выключать механизма UAC для систем на базе Microsoft Windows. Не предоставлять права локальных администраторов пользователям. Использование «сервисных» учетных записей для запуска сервисов и служб для систем на базе Microsoft Windows. Запрет на установку программного обеспечения локально, и из папок TEMP, TMP, App Data. Производить установку программного обеспечения только через групповые политики или специализированные решения. Внедрение групповой политики RESTRICTED GROUPS для членов группы локальных администраторов. Переименование учетных записей администраторов. Внедрение механизма AppLocker для систем на базе Microsoft Windows. Внедрение механизма EMET для систем на базе Microsoft Windows. Внедрение механизма LAPS для систем на базе Microsoft Windows. Включение параметров «Force GPO to reapply settings during refresh» для систем на базе Microsoft Windows. Отключение не используемого функционала и служб. Отключение механизма «Net Session Enumeration» для систем на базе Microsoft Windows. Отключение механизма «Windows Browser Protocol» для систем на базе Microsoft Windows. Отключение механизма WSH для систем на базе Microsoft Windows. Отключение возможности локальных администраторов аутентифицироваться по сети «Prevent Local Admins (RIP500) to authenticate over network» для систем на базе Microsoft Windows. Блокировка не доверенных шрифтов для систем на базе Microsoft Windows. Внедрения механизма «Credential Guard» для систем на базе Microsoft Windows. Внедрение механизма «Device Guard» для систем на базе Microsoft Windows. Отключение или контроль возможностей «Macros» и «OLE» in Microsoft Office». Настройка механизма аутентификации «Restrict Unauthenticated RPC client» для клиентов для систем на базе Microsoft Windows. Настройка механизмов «классификации файлов и данных» файловых серверов и систем на базе Microsoft Windows. Внедрение механизмов контроля привилегий (Privileges Access Management PAM) и его элементов: достаточности привилегий (Just Enough Administration JEA) и ограниченности по времени (Just In Time Privileges JIT). Таблица угроз и видов атак Denial of Service DoS Dynamic Denial of Service DDoS Flood – «Затопление». Различаются SYN Flood, ICMP Flood, DNS Flood Bonk, Teadrop, Pong – Фрагментированные пакеты больших размеров приводящие к переполнению буфера и отказу систем. SMURF – Ошибки реализации стека протокола TCP/IP. Ping of DEATH (Jolt, SSPing) UDP Storm – Шторм пакетов, настраивается как пересылка пакетов между двумя открытыми портами. UDP Bomb – Некорректный UDP пакет. LAND – Отправка пакета на определённый порт, но отправитель указывается тот же самый. Mail Bombing Sniffing – Прослушивание сети. IP Hijack – Физическое или логическое «врезание» в канал связи. Dummy DNS Server – Ложный DNS сервер. Fuzzy – Подделка пакетов. Puke – Фабрикует пакеты ответа ICMP unreachable на клиенте. Fake unreachable – Тоже самое, что и Puke, но направлен на сервер. Host spoofing – Подмена хоста Password crack – Атаки направленные на взлом или перебор пароля. Back connect / Pipes /Reverse Software Vulnerabilities Buffer Overflow – Использование ошибки переполнения буфера. Shatter Nuke – Атака на протокол NetBIOS (TCP, UDP 137, 138, 139). Cross User Attack CGI Attack SQL Injection – Инжекция в SQL запросы HTTP Resource Splitting (HRS) Cross User Defacement Web Cache Poisoning / Browser Cache Poisoning Hijacking Pages Cross Site Scripting / Exchange Site Scripting (CSS / XSS) SQL Injection CSS (CIXSS) SQL Injection HTTP Resource Splitting (SiHRS) NULL Bute (Perl) – Специфика атак с использованием Perl Include bute, PHP Include bute – Специфика атак на PHP Hidden Fields Man in the Middle Attack (MITM) – Атака через посредника. Man in the Browser Attack (MITB) – Атака на Интернет банкинг Заключение К сожалению, на практике достаточно часто бизнес считает, что вопросами информационной безопасности должна заниматься только IT. Еще хуже, когда бизнес не понимает, зачем вообще нужно уделять внимание информационной безопасности. Создание эффективной системы защиты информации влечет за собой большие затраты, которые должны быть понятны руководству, так как именно оно принимает решение о финансировании. При этом важно соблюдать баланс – обеспечение информационной безопасности не должно стоить больше самой защищаемой информации. Концепция Информационной Безопасности должны принимается в расчет на всех этапах построения и сопровождения ИТ, будь то управление проектами, управления ИТ сервисами, управления качеством. Приоритеты (доступность или конфиденциальность) должны быть определены на начальном этапе и на самом высоком уровне организации. Порядок взаимодействия ИТ и Безопасности также должны быть описаны на уровне Архитектуры Предприятия. В целом, статистика который год однозначно показывает, основные инциденты и угрозы информационной безопасности, в более чем семидесяти процентах случаях, происходили не по техническим причинам, а из-за ошибок сотрудников, недостатка знаний и квалификации, намеренных действий «инсайдеров», а также не соблюдений требований информационной безопасности сотрудниками организаций. Поэтому главные аспекты обеспечения информационной безопасности: •жесткая дисциплина •непрерывное обучение и периодическое тестирование всех сотрудников организации без исключения •контроль за изменениями Концепция Управления ИТ Сервисами Основные определения Данный раздел содержит основные принципы управления ИТ сервиса на всем жизненном цикле сервиса. Концепция основывается на стандартах COSO, ITAF, Balanced Score Card, COBIT, ITIL, ISO 20000, ISO27000, ISO 17799, ISO9000, MOF. За основу взята «сервис ориентированный» подход к управлению ИТ. Процессный подход предполагает представление основных деятельностей ИТ в виде процессов, состоящих из действий. Процесс – структурированный набор видов деятельности, спроектированный для достижения определенной цели. В общем, процесс представляет собой набор процедур, на которые оказывает влияние политика организации и процедур, происходящих из других источников, в том числе процессов. Процессы имеют четкие, обусловленные бизнесом, причины возникновения, ответственных владельцев, должностные обязанности, связанные с наполнением процесса и средства измерения эффективности. Процессы имеют следующие характеристики: •Процессы измеряемы, то есть можно измерить процесс каким-либо подходящим методом. Менеджеры стремятся измерить в первую очередь стоимость и качество, а практикующие пользователи – продолжительность и продуктивность процесса. •Процессы служат для достижения конкретных результатов. Причина существования процесса – предоставление конкретного результата, который можно идентифицировать и посчитать. •Процессы имеют потребителей – каждый процесс предоставляет свои результаты потребителям или другим процессам. Потребители могут быть внутри или вне организации, но процессы в любом случае должны удовлетворять их ожиданиям. •Процессы состоят из действий. Действие (Activity) – основные виды деятельности, предпринимаемые в рамках процесса. Не менее важным понятиями являются: •Владелец сервиса (service owner) – роль или структурное подразделение организации, который занимается постановкой целей, принимает решения и управляет финансированием по сервису. •Менеджер сервиса (service manager) – роль или структурное подразделение организации, который занимается выполнением целей и задач, поставленных владельцем сервиса, обеспечивает развертывание и сопровождение сервиса. Любой менеджер знает, что одна из самых сложных задач управления – построить и заставить работать процессы. Без налаженных процессов получить результаты – это подвиг. Подвиги достойны уважения, если совершаются в первый раз. Постоянные подвиги вызваны управленческой слабостью и ведут к проблемам, стрессам, текучке и плохим результатам. С ростом организации это приведет к гибели компании. Вся деятельность ИТ департамента разбита на процессы. Краткое описание сервисов приводится в данной главе. Требования бизнеса Требования бизнеса являются ключевым драйвов при внедрении ИТ решений. Любой сервис должен быть рассмотрен с точки зрения бизнес-ориентирования. •Бизнес сервисы, имеющие непосредственное влияние на бизнес должны обладать первичным приоритетом. •Технические сервисы (Корневые, первичные, вторичные и вспомогательные) нацелены на поддержание бизнес сервисов и приложений на надлежащем уровне. При проектировании систем компании следует руководствоваться: •Определить и следовать цепочке требований: доступность, безопасность и целостность. •Бизнес сервисы имеют первичный приоритет. •Технические сервисы (корневые и первичные) имеют первичный приоритет, и рекомендуется рассматривать в контексте максимальной доступности и надежности. •Технические сервисы (вторичные и вспомогательные) имеют вторичный приоритет, и рекомендуется рассматривать в контексте минимальных расходов. Фазы жизненного цикла ИТ сервиса Согласно ITIL v3 определены следующие этапы (5) управления ИТ сервисами с использованием (26) процессов, (6) функций, а также (2) направления. Модели ИТ архитектуры ИТ архитектура организации может строится по нескольким моделям: •«Децентрализованная» – Вычислительные мощности расположены по портфелям или компаниям организации. •«Централизованная» – Вычислительные мощности расположены в дата центре холдинга, на периферии остаются «front-end» решения и службы поддержки пользователей. •«Облачная» – Вычислительные мощности переносятся в «облако». •«Смешанная» – Вычислительные мощности расположены как в дата центре холдинга, так и в облаке. Модели предоставления ИТ сервисов ИТ департамент компании ориентирован на предоставление различного уровня услуг. Определены следующие модели: •Совместное размещение (Co-location IT assets) – ИТ ресурсы компаний размещены в дата центре. ИТ службы компаний самостоятельно управляют данными ИТ ресурсами. •Инфраструктура как Сервис (Infrastructure as Service (IaaS)) – ИТ департамент предоставляет вычислительные ресурсы и инфраструктуру, которая включает в себя, но не ограничивается сеть, виртуализация, доступ в интернет, хостинг и т п. ИТ службы компании самостоятельно управляют ИТ ресурсами, расположенными на данных инфраструктурах. •Платформа как Сервис (Platform as Service (PaaS)) – ИТ департамент предоставляет вычислительные ресурсы, инфраструктуру и платформу, которая включает в себя, но не ограничивается, хостинг, ERP платформа и т п. ИТ службы компаний самостоятельно управляют ИТ ресурсами, расположенными на данных платформах. •Программы как Сервис (Software as Service (SaaS)) – ИТ департамент предоставляет вычислительные ресурсы, инфраструктуру, платформу и сами сервисы, которая включает в себя, но не ограничивается, корпоративная почта, Интрасети и т п. Компании являются пользователями данных услуг. Диаграмма предоставления ИТ сервисов Типы предоставления сервисов Типы предоставления сервисов определяются как на стратегическом этапе для ИТ стратегии в целом, так и для каждого сервиса в отдельности. Так в частности, при проектировании бизнес систем необходимо определиться с вопросом «купить» или «разрабатывать». Основные типы предоставления сервисов (Service Delivery Models) можно определить, как: Insourcing Insourcing – самостоятельная разработка, используя внутренние ресурсы организации на всех этапах жизненного цикла сервиса. Преимущества: •Прямой контроль •Свобода выбора •Быстрое создание прототипа и передовое обслуживание •Удобные процессы и процедуры •Применение специфики организации Недостатки: •Ограниченные ресурсы •Может быть затратная в плане стоимости и времени выведения продукта на рынок •Зависит от возможностей и уровня компетенции ресурсов организации Outsourcing Outsourcing – использование внешних ресурсов организаций, как полностью, так и частично на этапах жизненного цикла сервиса Преимущества: •Экономия масштаба •Приобретение опыта и знаний •Помогает организации сфокусироваться на основной деятельности •Удобна при выполнении не системных задач •Более формальный процесс тестирования новых продуктов Недостатки: •Меньший уровень непосредственного контроля •Ограничения по выходу из проекта или изменению задач •Риски, связанные с поставщиком продукта (платежеспособность, готовность продукта и т п) •Неизвестность об уровне компетенции поставщика •Более сложная модель организации •Увеличивает долю проверки и соответствия продукта Co-sourcing Co-sourcing – комбинированное использование первых двух моделей Преимущества: •Снижает время выхода продукта на рынок •Уверенность в уровне компетенции за счет выбора поставщика •Высокий уровень контроля Недостатки: •Возможная сложность проекта •Вопросы по защите интеллектуальной собственности •Проблемы коммуникации в связи с различным уровнем культуры организаций |