Шаблон предназначен для организации иерархии доверия элементов в системе таким образом, что доверие множеству элементов на каждом уровне иерархии, кроме первого, основывается на последовательности доказательств целостности и аутентичности элементов предыдущего уровня, а также способности элемента (элементов) предыдущего уровня засвидетельствовать целостность и аутентичность элементов следующего уровня.
Иногда доверие — единственный способ начать организацию безопасности в сети, где каждый шаг считается небезопасным. Однако количество элементов, которым хотелось бы доверять, растет, а выполнять полную проверку безопасности для каждого нет возможности. Шаблон решает эту проблему.
Изначально доверие предоставляется только корню. На практике им часто становится общеизвестный сервер, статически заданный объект, неизменяемый код или другая сущность, безопасность которой подтверждена другими методами. Далее корень доверия путем проверок и анализа делится этим доверием с элементами уровня ниже и тем самым подтверждает их надежность.
Типовые цели безопасности при применении шаблона включают:
Предположения безопасности включают:
Предположения и условия, при которых шаблон не может быть применен:
Элементы системы, реализующей шаблон:
Примечание — характеристики элемента, которые могут засвидетельствовать доверие к этому элементу, обычно представляют собой криптографические примитивы, такие как контрольная сумма или электронная цифровая подпись. Кроме этого, доверие может обеспечиваться гарантиями невозможности внесения несанкционированных изменений в состав программного обеспечения (ПО) элементов, составляющих часть иерархии доверия. Такие гарантии должны быть обеспечены в том числе архитектурой системы и процессами реализации СКИБ.
Требования к технологии разработки элементов системы не предъявляются.
Ограничения на применение шаблона отсутствуют.
Допустимо при принятии решения о доверии для отдельных элементов иерархии доверия основываться также на дополнительных условиях, не связанных исключительно с характеристиками корня доверия.
Допустимость прочих модификаций должна быть обоснована при проектировании архитектуры и формировании требований, предъявляемых к системе на основе целей и предположений безопасности для этой системы.
Подобная схема реализована для проверки сертификатов X.509.
*Справка: Сертификаты X.509 — это часть инфраструктуры открытого ключа (Public key infrastructure, PKI). Он содержит открытый ключ и дополнительную информацию о подписанных данных. Сертификаты X.509 используются в первую очередь для безопасного просмотра веб-страниц, а также для подписание кода, шифрования электронной почты, создания цифровой подписи документов и т.д.
Подлинность веб-сайта, документа или другого объекта должна быть подтверждена третьей стороной. Сертификаты подписываются удостоверяющими центрами. Удостоверяющие центры организованы в иерархию: каждый центр сертифицируется с помощью центра более высокого уровня, что подтверждает безопасность первого. Так продолжается, пока в конечном счете вся цепочка сертификатов не доходит до корневого удостоверяющего центра, то есть центра первого уровня. Обычно это общеизвестные сервера со статично заданными параметрами.
Такое решение не приводит к растущему числу серверов, к которым требуется организовывать доверие, и в то же время распределяет нагрузку, создаваемую постоянным потоком запросов на проверку сертификатов.
Применение сертификатов X.509 — обязательное требование безопасности в сети Интернет. Отсутствие сертификата ведет к общеизвестному баннеру с текстом «Этот сайт может быть небезопасным». Это часто отпугивает клиентов или подрывает репутацию держателей ресурса и тем самым ведет к убыткам.
