Модель безопасности StarVault

Модель безопасности StarVault очень важна в силу специфики самого хранилища StarVault и конфиденциальности данных, которыми управляет. Цель модели безопасности StarVault — обеспечить конфиденциальность, целостность, доступность, контроль и учет, а также аутентификацию.

Это означает, что хранимые и передаваемые данные должны быть защищены от перехвата и искажения. Чтобы получить доступ к данным или вносить изменения в политики, клиенты должны надлежащим образом аутентифицироваться и авторизоваться. Каждое взаимодействие можно проверить и однозначно проследить до исходного объекта.Система должна быть устойчивой к преднамеренным попыткам обойти средства контроля доступа.

1. Модель угроз

Ниже показано, что входит в модель угроз StarVault:

Перехват любого взаимодействия с StarVault. Взаимодействие клиента c StarVault, StarVault с бэкендом хранения и между узлами кластера StarVault должно быть защищено от перехвата.

Искажение хранимых или передаваемых данных. Если обнаружено искажение, то StarVault прерывает обработку транзакции.
Доступ к данным или средствам контроля без аутентификации или авторизации. Все запросы обрабатываются в соответствии с применимыми политиками безопасности.
Бесконтрольный доступ к данным или средствам контроля. Если ведется журнал аудита, то запросы и ответы регистрируются до того, как клиент получит какие-либо секретные материалы.
Конфиденциальность хранимых секретов. Любые данные, которые StarVault оставляет в бэкенде хранения, должны быть защищены от перехвата. На практике это означает, что все хранимые данные должны быть зашифрованы.
Доступность секретных материалов в случае сбоя. StarVault может работать в конфигурации высокой доступности, чтобы избежать потери доступности. Перечисленное ниже не входит в модель угроз StarVault:
Защита от получения произвольного контроля над бэкендом хранения. Злоумышленник, имеющий возможность выполнять произвольные операции с бэкендом хранения, угрожает безопасности разными способами, от которых трудно или невозможно защититься. Например, злоумышленник может удалить или повредить все содержимое бэкенда хранения, что приведет к полной потере данных для StarVault. Контроль операций чтения позволит злоумышленнику сделать снимок в хорошо известном состоянии и откатывать изменения состояния, если это будет ему выгодно.
Защита от утечки информации о существовании секретных материалов. Злоумышленник, способный читать данные из бэкенда хранения, может узнать о факте существования и хранения секретных материалов, даже если те хранятся с соблюдением режима конфиденциальности.
Защита от анализа памяти работающего StarVault. Если злоумышленник способен проверить состояние памяти работающего экземпляра StarVault, то конфиденциальность данных скомпрометирована.
Защита от недостатков внешних систем или служб, используемых StarVault. Некоторые методы аутентификации или механизмы секретов делегируют конфиденциальные операции системам, внешним по отношению к StarVault. Если злоумышленник скомпрометировал учетные данные или иным образом эксплуатировал уязвимость в этих внешних системах, то конфиденциальность или целостность данных могут быть нарушены.
Защита от вредоносных плагинов или выполнения кода на базовом хосте. Если злоумышленник получил права на выполнение кода или на запись на базовом хосте, то конфиденциальность или целостность данных могут быть нарушены.
Защита от недостатков клиентов или систем, которые обращаются к StarVault. Если злоумышленник способен скомпрометировать клиент StarVault (например, систему или браузер) и получить учетные данные этого клиента в StarVault, то может получить доступ к StarVault с уровнем прав, выданных этому клиенту.
Защита от администраторов StarVault, предоставляющих вредоносные конфигурационные данные или данные, которые сделают конфигурацию уязвимой. Любые данные, предоставляемые административным конечным точкам StarVault в качестве значений конфигурации (например, конфигурации механизмов секретов), или файлы конфигурации StarVault должны проверяться. Если злоумышленник сделает запись в конфигурацию StarVault, то конфиденциальность или целостность данных могут быть нарушены.

2. Обзор внешних угроз

Архитектура StarVault охватывает три различные системы:

Клиент: обращается к StarVault через API.
Сервер: предоставляет API и обслуживает запросы.
Бэкенд хранения: используется сервером для чтения и записи данных.

Между клиентом и сервером StarVault нет взаимного доверия. Клиенты используют TLS для проверки удостоверений сервера и организации безопасного канала связи. Серверы требуют, чтобы клиент предоставлял токен клиента для каждого запроса, который используется для идентификации клиента. Клиент, который не предоставляет токен, делает только запросы на вход в систему.

Весь серверный трафик между экземплярами StarVault в пределах кластера (т.е. высокая доступность, или встроенное хранилище) использует взаимно аутентифицированный TLS для обеспечения конфиденциальности и целостности передаваемых данных. Узлы аутентифицируются до добавления в кластер с помощью запроса на распечатывание или одноразового токена активации.

Используемые StarVault бэкенды хранения также изначально не являются доверенными. StarVault использует защитный барьер для запросов к бэкенду. Защитный барьер автоматически шифрует данные, поступающие из StarVault, 256-битным шифром по стандарту Advanced Encryption Standard (AES) в режиме счетчика Галуа (GCM) с использованием 96-битных одноразовых чисел. Одноразовое число генерируется случайным образом для каждого шифруемого объекта. Когда данные считываются с защитного барьера, тег аутентификации GCM проверяется во время расшифровки, позволяя обнаружить искажения.

В зависимости от используемого бэкенда StarVault может взаимодействовать с бэкендом по TLS, обеспечивая дополнительный уровень безопасности. Иногда, например, в случае файлового бэкенда, это неприменимо. Поскольку бэкенды хранения не являются доверенными, злоумышленник получит доступ только к зашифрованным данным, даже если взаимодействие с бэкендом будет перехвачено.

3. Обзор внутренних угроз

В системе StarVault первостепенное внимание уделяется защите от попыток неавторизованного доступа к секретным материалам. Если злоумышленник уже получил некий уровень доступа к StarVault и может аутентифицироваться, то это – внутренняя угроза.

При первой аутентификации клиента в StarVault метод аутентификации проверяет удостоверение клиента и возвращает список связанных политик контроля доступа на основе ACL. Связанные политики задаются операторами StarVault заранее. Например, пользователи LDAP из команды «engineering» могут быть сопоставлены с политиками StarVault «engineering» и «ops». Затем StarVault генерирует клиентский токен, который представляет собой случайно сгенерированное сериализованное значение, и сопоставляет со списком политик. Этот клиентский токен затем возвращается клиенту.

При каждом запросе клиент предоставляет этот токен, после чего StarVault убеждается, что токен действителен и не был отозван или просрочен, и создает ACL на основе связанных политик. По умолчанию StarVault использует строгую стратегию "все, что не разрешено, запрещено". Это означает, что, если связанная политика не допускает определенное действие, то оно будет запрещено. Каждая политика определяет предоставленный уровень доступа к тому или иному пути в StarVault. При объединении политик (если с клиентом связано несколько политик) используется наивысший разрешенный уровень доступа. Например, если политика «engineering» дает права доступа на чтение/обновление к пути «eng/», а политика «ops» дает права доступа на чтение к пути «ops/», то пользователь получает сразу и первые права и вторые. Политика сопоставляется с самой детализированной политикой, которая может быть точным соответствием или шаблоном поиска (glob) с самым длинным префиксом. Дополнительную информацию см. в разделе «Синтаксис политики».

Определенные операции разрешают только root-пользователи — отдельная политика, встроенная в StarVault. Это похоже на концепцию root-пользователя в Unix-подобных системах или администратора в Windows. В случаях, когда клиентам предоставляются root-токены или задана связанная root-политика, StarVault поддерживает понятие привилегии «sudo». В рамках политики пользователям могут быть предоставлены привилегии «sudo» для определенных путей, чтобы они могли по-прежнему выполнять операции, критичные с точки зрения безопасности, но при этом у них не было глобального root-доступа к StarVault.

Наконец, StarVault поддерживает использование правила двух лиц для распечатывания с помощью схемы разделения секрета Шамира. StarVault запускается в запечатанном состоянии. Это означает, что ключ шифрования, необходимый для чтения и записи из бэкенда хранения, еще не известен. Для распечатывания нужно предоставить корневой ключ, чтобы получить ключ шифрования. Риск передачи корневого ключа заключается в том, что один злоумышленник, имеющий к нему доступ, может расшифровать весь StarVault. Вместо этого метод Шамира позволяет разделить корневой ключ на несколько частей. Количество частей и необходимое пороговое значение настраивается, но по умолчанию StarVault генерирует 5 частей, и для воссоздания корневого ключа достаточно предоставить любые 3 из них.

Метод разделения секрета позволяет избежать ситуации, когда держатель корневого ключа пользуется абсолютным доверием, и позволяет вообще не хранить корневой ключ. Корневой ключ можно получить только путем воссоздания его из частей. Сами части используются только для распечатывания, для выполнения каких-либо запросов к StarVault они бесполезны. После распечатывания для всех запросов используются стандартные механизмы ACL.

Если провести аналогию, банк помещает сейфовые ячейки в хранилище. У каждой ячейки есть ключ, а дверь хранилища закрыта и ключом, и комбинацией. Хранилище сделано из стали и бетона, так что попасть внутрь можно только через дверь. Аналогия с StarVault заключается в том, что криптосистема — конструкция из стали и бетона, защищающая данные. Конечно можно пробурить туннель в бетоне или подобрать ключи шифрования, только это займет слишком много времени.

Для открытия банковского хранилища требуются два фактора: ключ и комбинация. Аналогично, StarVault требует предоставления нескольких частей для воссоздания корневого ключа. Даже после вскрытия хранилища открыть каждую сейфовую ячейку можно лишь ключом, который предоставляет владелец, и аналогичным образом система StarVault ACL защищает все хранящиеся секреты.