Метод построения архитектуры информационной безопасности, которая исходит из рисков и требований бизнеса. Не заменяет другие стандарты безопасности и не конкурирует с ними, а даёт надстроечную рамку, под которую они встраиваются. Шесть слоёв на шесть вопросов дают матрицу 6 × 6, и белая книга прямо называет её заполнение сутью метода: «a process of populating all of these thirty-six cells».
Есть межсетевой экран, MFA, DLP и ежегодный аудит, но никто не может ответить, какой бизнес-риск закрывает каждая мера и что случится, если её убрать. Защита выросла из закупок, а не из требований.
Так получается почти у всех: безопасность строят по каталогу — аудитор потребовал, вендор предложил, инцидент напугал. Через несколько лет есть десятки контролей, бюджет на их поддержку и ни одного ответа на вопрос бизнеса: «зачем партнёру три уровня проверки, если он видит только свои заказы?». Служба безопасности отвечает словом «политика», бизнес политику обходит, и обе стороны по-своему правы. Причина не в людях: у мер защиты нет прослеживаемости до того, что и почему нужно защищать.
SABSA переворачивает порядок. Сначала бизнес: какие активы, какие риски, какие процессы, кто отвечает, где и когда. Потом концепция защиты, логическая архитектура, физическая реализация, компоненты и, наконец, эксплуатация. Шесть слоёв на шесть вопросов дают матрицу из 36 ячеек, и белая книга называет её заполнение сутью метода. Каждая мера в нижнем слое прослеживается вверх до бизнес-требования, а каждое требование видно, чем и как оно выполнено. Это архитектура безопасности в том же смысле, в каком у здания есть архитектура, а не список стройматериалов.
В этой раздатке — все 45 карточек страницы реестра, матрица 6 × 6 с учебными ячейками партнёрского портала, пять шагов первой недели и ответы на вопросы тех, кто уже живёт по ISO 27001 и не понимает, куда ставить SABSA. Реестр относит её к разделу «Около корпоративной архитектуры»: она целиком лежит в одном домене — безопасность и риски, — но устроена как полноценная архитектурная рамка со своим жизненным циклом и процессом.
Мера защиты имеет право на существование, только если от неё можно провести линию вверх — к риску и бизнес-требованию. SABSA — способ провести и сохранить эти линии.
Исследуйте основные части: у каждой свой вопрос, смысл и место в примере.
| Уровень / вопрос | Что | Почему | Как | Кто | Где | Когда |
|---|---|---|---|---|---|---|
| Контекст | ||||||
| Концепция | ||||||
| Логическая архитектура | ||||||
| Физическая архитектура | ||||||
| Компоненты | ||||||
| Эксплуатация |
Выберите элемент схемы — откроются объяснение и пример.
Определяем бизнес-контекст и потребность в защите. Предмет учебной ячейки: риск раскрытия клиентских сведений.
Риск раскрытия клиентских сведений. В партнёрском портале это решение должно прослеживаться до исходной бизнес-потребности и риска.
Учебное заполнение матрицы SABSA для партнёрского портала. Содержание ячеек — авторское; ссылки ведут к базовым понятиям соответствующего вопроса, а не объявляют пример нормативным требованием.
Авторский учебный пример. Организация и решения придуманы для объяснения подхода; это не обязательный порядок работ из стандарта.
Определяем, что означает безопасная и удобная работа партнёра, и связываем ожидания с рисками.
У требований к защите есть понятное бизнес-основание.
От контекста переходим к правилам, сервисам безопасности и способам их реализации.
Каждая мера связана с требованием, а не выбрана по привычке.
Проверяем выдачу, пересмотр и прекращение доступа на реальных сценариях.
Видны доказательства выполнения требований и оставшиеся риски.
Архитектура безопасности, управляемая политиками: рамка и шаблон, а не перечень контролей. Два блока — Security Governance (принципы, политики, стандарты и процедуры, принуждение, постоянная оценка) и Security Technology Architecture. Парная школа к SABSA в том же домене.
Сначала определите бизнес-потребность и сценарий риска. Технический компонент без такого основания может усложнить работу, не решив нужную проблему.
Перед проработкой согласуйте вопрос: Какие бизнес-решения требуют защиты? Ответ должен быть понятен участникам рассматриваемой работы.
Пройдите весь пример от исходной ситуации до результата: Видны доказательства выполнения требований и оставшиеся риски.
Общие оси — нейтральные названия частей предприятия: деятельность, данные, приложения, инфраструктура и другие. Здесь показано, какие элементы подхода сопоставлены с этими осями и насколько совпадает их охват.
Есть сопоставление с 1 осью из 17
| Ось реестра | В SABSA | Сопоставление | Пояснение |
|---|---|---|---|
| Безопасность и риски | Contextual Security Architecture · Conceptual Security Architecture · Logical Security Architecture · Physical Security Architecture · Component Security Architecture · Security Service Management Architectureслой | С осью пересекается частично. | Слой абстракции внутри домена безопасности: SABSA целиком лежит в этом домене, а её шесть слоёв делят его по уровню детализации, а не по предмету. |
| Безопасность и риски | What · Why · How · Who · Where · Whenось | С осью пересекается частично. | Столбец матрицы SABSA (активы, мотивация, процессы, люди, размещение, время). Вопросительная ось внутри домена безопасности, а не самостоятельный домен. |
Полное описание предприятия — работа на месяцы. Первый полезный результат получается за пять рабочих дней, если не пытаться описать всё сразу.
Не «безопасность компании», а конкретный случай: партнёрский доступ к заказам, удалённая работа бухгалтерии, обмен с подрядчиком. Ответьте на шесть вопросов контекста: какой актив, какой риск, какой процесс, кто владелец, где проходят границы, когда действует. Результат — одна заполненная строка матрицы.
Спросите владельца процесса, что для него значит «безопасно и удобно»: доступно круглосуточно, видны только свои заказы, история изменений сохраняется. Каждое ожидание — атрибут; к атрибуту — как его измерить и какой риск его нарушает. Это сердце SABSA, без него нижним слоям не на что опереться.
Из атрибутов и рисков выведите цели управления риском, стратегию доверия, области доверия и их границы. Затем логический слой: информационные активы, политики, сервисы идентификации и авторизации, сущности и отношения доверия, логика срока разрешения. Пока без названий продуктов.
Существующие меры — MFA, роли в системе, сегменты сети, расписания проверок — разложите по физическому и компонентному слою. Каждая должна найти сервис из третьего дня, который она реализует. Мера без сервиса — кандидат на пересмотр; сервис без меры — разрыв, который нужно закрыть.
Кто ведёт учёт активов, кто и как часто пересматривает доступ, куда попадают нарушения, когда доступ отзывается. Оцените, какой риск остаётся после всех мер, и покажите владельцу процесса вертикаль от его требования до проверки. Это первое доказательство выполнения требований — то, к чему ведёт весь метод.
Тридцать шесть ячеек — карта, а не план работ. Для одного сценария риска достаточно провести одну вертикаль: от актива и риска в контексте до компонента и проверки в эксплуатации. Полная матрица нужна, когда таких вертикалей набралось несколько и их пора сверить между собой.
Нижний слой — управление сервисами безопасности — чаще всего пустует: доступ выдан, а кто и когда его пересматривает и отзывает, не записано. Между тем именно здесь копится остаточный риск, и SABSA не случайно держит для этого слоя отдельную матрицу, выровненную по ITIL.
ISO 27001 — стандарт системы менеджмента: требования, которым организация должна соответствовать, и каталог контролей. SABSA — архитектурный метод: как из бизнес-требований и рисков вывести, какие контроли и почему нужны именно вам. Авторы прямо пишут, что SABSA не конкурирует с другими стандартами безопасности, а даёт рамку, в которую они встраиваются: контроль из приложения к ISO 27001 занимает ячейку в нижних слоях, а верхние объясняют, зачем он там.
Устройством — почти ничем, и авторы это признают: шесть слоёв SABSA близко следуют модели Захмана, адаптированной под взгляд безопасности. Разница в предмете: Захман классифицирует описания всего предприятия, SABSA — только защиты. И у SABSA есть то, чего у Захмана нет: жизненный цикл, процесс разработки, профиль бизнес-атрибутов и отдельная матрица управления сервисами.
Матрица масштабируется вниз лучше, чем кажется. Для компании в сто человек одна вертикаль на главный риск — например, доступ подрядчиков к клиентским данным — займёт пару страниц. Ценность та же, что у крупных: каждая трата на защиту получает причину, которую понимает директор. Полная матрица и профиль зрелости (SMP) — для тех, у кого таких вертикалей десятки.
20 страниц: что это и чем не является, устройство подхода, 45 карточек словаря, учебный пример и план первой недели.
Пришлём ссылку сразу после отправки формы
Дословные выписки из стандарта с переводом. Строки с пояснением простыми словами отмечены.
Подходы для одной области — безопасность, производство, ИТ-функция — и стандарты о том, как вообще описывать архитектуру: требования, правила, принципы.
Белая книга подписана Джоном Шервудом, Эндрю Кларком и Дэвидом Лайнасом; копирайт SABSA Limited охватывает 1995–2009 годы, и год начала работ назван прямо: команда SABSA Limited работает над моделью и методологией с 1995 года.
Главное влияние объявлено самим документом: шестислойная модель SABSA близко следует работе Джона Захмана по модели архитектуры предприятия, адаптированной под взгляд безопасности. Отдельная матрица управления сервисами выровнена по ITIL v3.
Реестр процессов, архитектурное рабочее пространство, связи между системами и процессами — те самые артефакты, только про вашу организацию.
Это же в StormАрхитектура систем и интеграцийБаза знаний и викиРеестр процессов
