WEBVTT

00:00:00.160 --> 00:00:04.980
Представьте себе такую ситуацию. Вы создаете приложение, и вам нужен API-ключ для подключения к сервису,

00:00:05.080 --> 00:00:08.720
пароль от базы данных или ключ учетной записи хранения. Вы добавляете его прямо в код,

00:00:08.920 --> 00:00:12.580
например, в файл конфигурации или переменную окружения. Все работает отлично,

00:00:12.840 --> 00:00:16.500
пока вы не отправляете этот код на GitHub или не делитесь ноутбуком с коллегой.

00:00:16.600 --> 00:00:20.900
И в этот момент ваш секрет перестает быть секретом. Если этот код попадет в чужие руки,

00:00:21.140 --> 00:00:25.600
вся ваша система окажется под угрозой. Azure Key Vault — это инструмент, который решает данную

00:00:25.600 --> 00:00:29.480
проблему. Он предоставляет безопасное место для хранения секретов, чтобы они никогда не попадали

00:00:29.480 --> 00:00:33.560
в ваш код. Но вот в чем большинство людей ошибается. Простое наличие Key Vault не делает вас

00:00:33.560 --> 00:00:37.820
защищенными автоматически. То, как вы его настраиваете, контролируете доступ и назначаете права,

00:00:37.960 --> 00:00:41.680
имеет такое же важное значение. К концу этого выпуска вы узнаете, что такое Key Vault,

00:00:41.880 --> 00:00:45.960
что в нем можно хранить, как работает доступ и в чем главная ошибка, из-за которой ваши секреты

00:00:45.960 --> 00:00:51.180
могут оказаться открыты. Все простыми словами, без жаргона, только самая суть. Итак, что же такое

00:00:51.180 --> 00:00:56.820
Azure Key Vault? Что такое Azure Key Vault? Вот самое простое определение. Azure Key Vault — это облачный

00:00:56.820 --> 00:01:01.080
цифровой сейф для ваших секретов. Это управляемый сервис от Microsoft для хранения API-ключей,

00:01:01.180 --> 00:01:05.340
паролей BD, строк подключения, ключей шифрования и сертификатов в одном централизованном месте.

00:01:05.500 --> 00:01:08.360
Вам не нужно беспокоиться об инфраструктуре, потому что Azure берет на себя исправление,

00:01:08.540 --> 00:01:12.400
время бесперебойной работы и безопасность. Вы просто им пользуетесь. Представьте себе офисные

00:01:12.400 --> 00:01:16.420
здания. У вас есть рабочие места, переговорные и шкафы для документов, но где-то в подвале есть

00:01:16.420 --> 00:01:21.360
защищенное хранилище, где лежат важные вещи. Мастер-ключи, наличные, юридические документы. Никто не

00:01:21.360 --> 00:01:24.760
войдет туда без разрешения и аутентификации. И каждый раз, когда кто-то открывает дверь,

00:01:24.880 --> 00:01:28.840
это фиксируется в журнале. Это и есть Key Vault — защищенная комната в подвале вашей

00:01:28.840 --> 00:01:33.960
архитектуры Azure. А теперь сравните это со старым методом. 20 лет назад, если вам нужен был пароль

00:01:33.960 --> 00:01:38.700
от базы данных, вы жестко прописывали его в конфиг-файле, переменное окружение или, что еще хуже,

00:01:38.860 --> 00:01:43.900
оставляли в открытом виде в исходном коде. Если кто-то получал доступ к серверу, у него было все. И если

00:01:43.900 --> 00:01:48.040
вам нужно было сменить пароль, приходилось обновлять его повсюду. В каждом файле конфигурации,

00:01:48.040 --> 00:01:52.980
каждой среде, каждом развертывании. Это был настоящий кошмар. Key Vault меняет все это. Вместо того,

00:01:53.100 --> 00:01:57.160
чтобы разбрасывать секреты по коду и конфигам, вы храните их в одном центральном месте. Ваши

00:01:57.160 --> 00:02:00.880
приложения запрашивают их во время выполнения, только когда они им действительно нужны. А поскольку

00:02:00.880 --> 00:02:04.780
все централизовано, вы можете обновить секрет в одном месте, и каждое приложение, которое его

00:02:04.780 --> 00:02:08.860
использует, автоматически получит новое значение без изменения кода или повторного развертывания.

00:02:09.020 --> 00:02:13.480
Но вот в чем дело. Key Vault — это не просто менеджер паролей для ваших приложений. Это ключевая служба

00:02:13.480 --> 00:02:17.480
безопасности. Любая служба Azure может интегрироваться с ней. App Service, функции,

00:02:17.480 --> 00:02:22.300
AKS, Data Factory, Synapse, Logic Apps, конвейеры DevOps — все они умеют взаимодействовать с Key Vault.

00:02:22.420 --> 00:02:26.100
Это становится основой вашей безопасной облачной архитектуры. И как только вы правильно все

00:02:26.100 --> 00:02:30.180
настроите, вы полностью перестанете думать об управлении учетными данными. Что можно хранить?

00:02:30.300 --> 00:02:34.160
Теперь, когда вы знаете, что такое Key Vault, давайте поговорим о том, что именно можно в него

00:02:34.160 --> 00:02:39.500
поместить. Есть три основные категории — секреты, ключи и сертификаты. Каждая из них выполняет свою

00:02:39.500 --> 00:02:44.460
задачу, и понимание разницы поможет вам правильно использовать Key Vault. Начнем с секретов. Это то,

00:02:44.460 --> 00:02:48.760
что люди хранят чаще всего. Секреты — это строки подключения, ключи API, пароли баз данных,

00:02:48.880 --> 00:02:52.400
ключи учетных записей хранения, в общем, все повседневные учетные данные, необходимые вашим

00:02:52.400 --> 00:02:55.960
приложением для связи с другими службами. Вместо того, чтобы вставлять их в свой код или файл

00:02:55.960 --> 00:02:59.680
конфигурации, вы помещаете их в Key Vault. Ваше приложение получает их во время выполнения,

00:02:59.860 --> 00:03:03.580
и никто никогда не видит их в открытом виде. Представьте это как запертый ящик в вашем цифровом

00:03:03.580 --> 00:03:08.580
картотечном шкафу. Далее идут ключи. Это ключи шифрования для неактивных данных. Если вы используете

00:03:08.580 --> 00:03:12.800
ключи, управляемые клиентом, для хранилищ Azure, баз данных SQL или шифрования дисков виртуальных

00:03:12.800 --> 00:03:16.640
машин, эти ключи могут храниться в Key Vault. Это дает вам полный контроль над тем, кто и когда

00:03:16.640 --> 00:03:20.100
может их использовать. А если для соответствия требованиям вам нужны ключи на аппаратном уровне,

00:03:20.220 --> 00:03:25.520
тарифный план Premium обеспечит защиту с помощью HSM. Затем у нас есть сертификаты. TLS и SSL — сертификаты

00:03:25.520 --> 00:03:29.520
для ваших веб-приложений, API и внутренних служб. Key Vault может хранить их, управлять их жизненным

00:03:29.520 --> 00:03:33.260
циклом и даже автоматически продлевать их, когда срок действия подходит к концу. Это спасение для

00:03:33.260 --> 00:03:37.760
любого, у кого хоть раз истекал срок действия сертификата в 3 часа ночи в воскресенье. Вот реальный

00:03:37.760 --> 00:03:41.820
пример. Представьте, что у вас есть веб-приложение, которому нужна строка подключения к базе данных

00:03:41.820 --> 00:03:46.080
и ключ API для стороннего сервиса. По старинке вы бы поместили это и другое в JSON-файл настроек

00:03:46.080 --> 00:03:50.260
приложения. Скорее всего, если этот файл попадет в ваш репозиторий, любой, у кого есть доступ к коду,

00:03:50.480 --> 00:03:54.960
сможет увидеть учетные данные вашей базы данных. С Key Vault вы храните оба значения как секреты. Ваше

00:03:54.960 --> 00:03:59.400
приложение получает их при запуске, и они никогда не появляются в исходном коде. Нужно сменить пароль базы

00:03:59.400 --> 00:04:03.460
данных. Обновите его в Key Vault. Приложение автоматически получит новое значение при следующем

00:04:03.460 --> 00:04:07.340
перезапуске. Никаких изменений кода или повторных развертываний, что часто застает людей врасплох,

00:04:07.500 --> 00:04:11.040
так это встроенное управление версиями. При обновлении секрета Key Vault не перезаписывает старое

00:04:11.040 --> 00:04:15.220
значение. Он создает новую версию. Старые версии сохраняются, поэтому вы можете откатиться,

00:04:15.360 --> 00:04:19.560
если что-то пойдет не так. Это невероятно удобно во время инцидентов. Вы можете быстро вернуться

00:04:19.560 --> 00:04:25.120
к предыдущему секрету, не вспоминая, каким было старое значение. Вы можете хранить все три типа данных – секреты,

00:04:25.300 --> 00:04:29.180
ключи и сертификаты – в одном хранилище. Но лучшая практика – разделять их

00:04:29.180 --> 00:04:33.640
по средам. Имейте одно хранилище для разработки, одно для тестирования и одно для производства.

00:04:33.780 --> 00:04:38.200
Это предотвращает случайное использование производственного секрета в среде разработки и ограничивает

00:04:38.200 --> 00:04:42.440
масштаб ущерба при компрометации хранилища. Но хранение секретов – это лишь часть дела.

00:04:42.640 --> 00:04:46.480
Главный вопрос в том, кто получает к ним доступ. Как работает управление доступом?

00:04:46.580 --> 00:04:51.160
А теперь давайте поговорим о том, кто получает доступ. В Key Vault есть два способа контроля доступа,

00:04:51.280 --> 00:04:55.580
и ваш выбор имеет большое значение. Первая модель – это устаревшие политики доступа.

00:04:55.580 --> 00:04:59.940
Это старый подход. Вы создаете политики непосредственно в хранилище и назначаете разрешение

00:04:59.940 --> 00:05:03.740
конкретным пользователям или группам для определенных типов данных, секретов, ключей или

00:05:03.740 --> 00:05:07.920
сертификатов. Проблема в том, что эти политики привязаны непосредственно к хранилищу. Если у вас

00:05:07.920 --> 00:05:11.400
несколько хранилищ, вам придется управлять политиками в каждом из них отдельно. Это плохо

00:05:11.400 --> 00:05:15.660
масштабируется. Microsoft теперь не рекомендует их использовать, так как они имеют известные проблемы

00:05:15.660 --> 00:05:19.700
с безопасностью. Они не поддерживают управление привилегированными удостоверениями и могут создавать

00:05:19.700 --> 00:05:24.640
пути для неожиданного повышения привилегий. Вторая модель – это Azure RBAC – управление доступом на основе

00:05:24.640 --> 00:05:28.740
ролей. Это современный подход. Он использует удостоверение IntraID и соответствует тому,

00:05:28.920 --> 00:05:32.620
как вы управляете разрешениями везде в Azure. Если вы уже знаете, как предоставить доступ к

00:05:32.620 --> 00:05:36.500
учетной записи хранения или виртуальной машине, вы уже знаете, как предоставить доступ к Keywall.

00:05:36.660 --> 00:05:40.760
Та же система, те же шаблоны. Вот золотое правило – принцип наименьших привилегий.

00:05:41.000 --> 00:05:45.120
Предоставляйте только тот минимум доступа, который нужен, и ничего больше. Если кому-то нужно только

00:05:45.120 --> 00:05:48.980
читать секреты, не давайте ему право на их создание или удаление. Если кому-то нужно только

00:05:48.980 --> 00:05:53.020
управлять сертификатами, не давайте ему доступ к ключам. Позвольте мне рассказать об основных ролях.

00:05:53.020 --> 00:05:56.280
У вас есть роль – читатель Keywall. Она позволяет просматривать список секретов,

00:05:56.380 --> 00:06:00.040
но не читать их значения. Роль – пользователь секретов Keywall. Она позволяет пользователю

00:06:00.040 --> 00:06:04.240
считывать значения секретов. И роль – администратор секретов Keywall. Она позволяет создавать,

00:06:04.460 --> 00:06:08.380
обновлять и удалять секреты. Заметьте закономерность. Каждая роль относится к данным

00:06:08.380 --> 00:06:12.720
внутри хранилища, а не к самому хранилищу. Теперь сравните это с общими ролями – владелец,

00:06:12.880 --> 00:06:16.760
участник, читатель. Они применяются к хранилищу как к ресурсу, а не к данным внутри него.

00:06:16.960 --> 00:06:21.640
Владелец может удалить хранилище целиком. Участник может изменять настройки хранилища. Однако,

00:06:21.640 --> 00:06:25.920
ни одна из этих ролей сама по себе не дает доступа к секретам внутри. Это отдельный уровень

00:06:25.920 --> 00:06:30.600
разрешений, и это ключевой момент. Контроль доступа – это многоуровневая структура. Вам нужен

00:06:30.600 --> 00:06:35.220
доступ к самому хранилищу – это первый уровень, и доступ к данным внутри него – это второй уровень.

00:06:35.360 --> 00:06:39.800
Оба должны предоставляться отдельно. Большинство новичков думают только о первом уровне и забывают

00:06:39.800 --> 00:06:44.460
о втором. С этого и начинаются проблемы. Главная ошибка в вопросах безопасности. Вот в чем дело.

00:06:44.660 --> 00:06:48.840
Многие смотрят на роль участник Key Vault и считают ее безопасной. Они видят слово «участник» и

00:06:48.840 --> 00:06:51.960
предполагают, что могут управлять настройками хранилища, но не трогать секреты внутри.

00:06:52.100 --> 00:06:56.820
В документации Microsoft изначально было сказано именно это. Эта роль не дает доступа к секретам,

00:06:57.000 --> 00:07:02.140
ключам или сертификатам. Но это не совсем так. Пользователь с ролью «участник Key Vault» может

00:07:02.140 --> 00:07:06.420
изменять политики доступа к хранилищу. И если в хранилище все еще используются устаревшие

00:07:06.420 --> 00:07:10.500
политики доступа, что встречается часто, они могут просто предоставить себе полный доступ на чтение

00:07:10.500 --> 00:07:14.760
ко всем секретам, ключам и сертификатам. Никаких специальных эксплойтов или уязвимости для

00:07:14.760 --> 00:07:18.820
исправления. Так работают эти разрешения. Исследователи безопасности из Datadoc доказали,

00:07:18.840 --> 00:07:23.840
это в 2024 году. Они показали, что участник может получить полный доступ к данным в любом

00:07:23.840 --> 00:07:28.220
хранилище с устаревшими политиками. Реакция Microsoft была интересной. Они заявили,

00:07:28.400 --> 00:07:31.780
что это неуязвимость, так как участники предназначены для управления политиками,

00:07:31.900 --> 00:07:36.140
но обновили документацию, явно предупредив, что эта роль позволяет дать себе доступ к плоскости

00:07:36.140 --> 00:07:40.300
данных. Таким образом, это не ошибка в самом Key Vault, а конфигурационная ловушка. И на нее

00:07:40.300 --> 00:07:44.460
попадаются даже опытные команды, потому что название роли звучит безобидно. Участник не звучит,

00:07:44.460 --> 00:07:47.940
как кто-то. Кто может прочитать пароли от вашей базы данных? Но на практике это возможно.

00:07:48.120 --> 00:07:51.820
Подумайте о рисках. Если злоумышленник скомпрометирует учетную запись с ролью

00:07:51.820 --> 00:07:56.220
«участник» в вашем Key Vault, ему не нужно взламывать само хранилище. Ему не нужно взламывать

00:07:56.220 --> 00:08:00.940
шифрование. Он просто меняет политику доступа, предоставляет себе права на чтение и незаметно

00:08:00.940 --> 00:08:05.880
крадет все ваши секреты, строки подключения, API-ключи, сертификаты, все целиком. И поскольку

00:08:05.880 --> 00:08:09.840
изменение политики доступа является обычной административной задачей, это может не вызвать никаких

00:08:09.840 --> 00:08:14.060
оповещений. Так как же это исправить? Во-первых, используйте Azure RBAC для доступа к плоскости

00:08:14.060 --> 00:08:18.240
данных вместо устаревших политик. RBAC разделяет управление хранилищем и данные, находящиеся

00:08:18.240 --> 00:08:22.440
внутри него. Во-вторых, никогда не давайте роль участника Key Vault тем, кому она не требуется.

00:08:22.620 --> 00:08:26.800
В-третьих, если у вас уже есть пользователи с такой ролью, проверьте их сегодня же. Замените роль

00:08:26.800 --> 00:08:31.080
участника на более специфичные, например, пользователь секретов или сотрудник по работе с секретами.

00:08:31.280 --> 00:08:35.720
Существует вторая ошибка, усугубляющая первую – хранение всех секретов в одном хранилище.

00:08:35.720 --> 00:08:41.360
Если у вас одно хранилище для всего разработки, тестов, стайджинга, продакшена и всех приложений,

00:08:41.500 --> 00:08:46.540
то при его взломе под угрозой окажется все. Это единая точка отказа. Мы еще поговорим о стратегии

00:08:46.540 --> 00:08:51.140
с несколькими хранилищами, но принцип прост. Не кладите все яйца в одну корзину, особенно когда в

00:08:51.140 --> 00:08:55.460
этой корзине хранятся ключи от всей вашей инфраструктуры. Управляемое удостоверение – золотой

00:08:55.460 --> 00:08:59.600
стандарт. Итак, как сделать это правильно? Давайте обсудим лучший способ доступа к Key Vault.

00:08:59.820 --> 00:09:03.680
Здесь есть фундаментальная проблема. Чтобы получить учетные данные из Key Vault, приложению нужно

00:09:03.680 --> 00:09:07.240
аутентифицироваться, а для аутентификации нужны учетные данные. Где хранить учетные данные,

00:09:07.380 --> 00:09:11.240
которые приложение использует для получения других учетных данных? Это классическая проблема – курица

00:09:11.240 --> 00:09:15.680
и яйца. Старым решением был сервисный субъект с секретом клиента, но этот секрет должен где-то

00:09:15.680 --> 00:09:19.500
храниться в файле конфигурации, в переменных окружениях или в конвейере развертывания.

00:09:19.660 --> 00:09:23.440
И теперь вы вернулись к той же самой проблеме. Вы просто переместили секрет в другое место.

00:09:23.640 --> 00:09:27.760
Управляемое удостоверение полностью решает эту задачу. Вот как это работает. Когда вы включаете

00:09:27.760 --> 00:09:32.300
управляемое удостоверение для ресурса Azure, например, веб-приложение, функции или виртуальной

00:09:32.300 --> 00:09:37.360
машины, Azure автоматически создает удостоверение в IntraID. Это удостоверение полностью управляется

00:09:37.360 --> 00:09:42.260
самим Azure. Не нужно создавать учетные данные, обновлять секреты или что-то хранить. У ресурса

00:09:42.260 --> 00:09:47.160
просто появляется удостоверение, о котором знает Azure. Существует два типа. Управляемое удостоверение,

00:09:47.360 --> 00:09:52.000
назначаемое системой, привязано к конкретному ресурсу. Если вы удалите ресурс, удостоверение также

00:09:52.000 --> 00:09:56.400
исчезнет. У них общий жизненный цикл, что упрощает администрирование. Управляемое удостоверение,

00:09:56.400 --> 00:09:59.840
назначаемое пользователем, это самостоятельное удостоверение, которое можно назначить

00:09:59.840 --> 00:10:03.380
нескольким ресурсом. У него нет общего жизненного цикла с ними, поэтому оно удобно,

00:10:03.520 --> 00:10:07.260
когда одно удостоверение нужно для нескольких сервисов. Вот как это выглядит на практике.

00:10:07.420 --> 00:10:11.440
У вас есть веб-приложение, которому нужно прочитать строку подключения к базе данных из KeyVault.

00:10:11.580 --> 00:10:15.800
Вы включаете системное управляемое удостоверение для этого веб-приложения. Затем вы предоставляете

00:10:15.800 --> 00:10:20.280
этому удостоверению роль пользователь секретов KeyVault для вашего хранилища. Вот и все. Никаких строк

00:10:20.280 --> 00:10:23.900
подключения в коде, никаких секретов клиента в файлах конфигурации. Веб-приложение

00:10:26.400 --> 00:10:30.420
удостоверения, а Азур берет на себя все управление учетными данными. Это максимально близкий

00:10:30.420 --> 00:10:34.400
к беспарольной аутентификации вариант в Азур. Это настоящий прорыв в безопасности,

00:10:34.640 --> 00:10:38.120
так как устраняется самый частый вектор атаки – кражи учетных данных.

00:10:38.280 --> 00:10:41.460
Если красть нечего, то злоумышленнику нечего и взламывать.

00:10:41.600 --> 00:10:45.360
Позвольте привести пример из реальной практики. Представьте конвейер данных в синапс,

00:10:45.520 --> 00:10:49.900
которому нужен доступ к учетной записи хранения. Раньше вы сохраняли ключ доступа к хранилищу

00:10:49.900 --> 00:10:54.080
прямо в настройках конвейера. Если кто-то получал доступ к этому конвейеру, он получал и ключ.

00:10:54.080 --> 00:10:57.580
С управляемым удостоверением у рабочей области синапс есть свое собственное удостоверение.

00:10:57.740 --> 00:11:01.800
Этому удостоверению предоставляется доступ к Key Vault, где хранится ключ учетной записи хранения.

00:11:01.940 --> 00:11:05.860
Конвейер получает ключ во время выполнения, использует его и нигде не сохраняет.

00:11:05.960 --> 00:11:08.980
Никаких ключей в коде, никаких секретов в настройках конвейера.

00:11:09.160 --> 00:11:12.160
Сочетая управляемое удостоверение с RBC и принципом наименьших привилегий,

00:11:12.180 --> 00:11:14.400
вы создаете безопасную основу для любой рабочей нагрузки в Азур.

00:11:14.540 --> 00:11:17.140
Ваше приложение проходит проверку подлинности без использования паролей.

00:11:17.260 --> 00:11:20.640
Они получают доступ только к тому, что нужно, а каждое действие логируется и подлежит проверке.

00:11:20.640 --> 00:11:23.780
Это стандарт, который Microsoft рекомендует практически для любого сценария.

00:11:23.900 --> 00:11:27.000
Начав использовать этот подход, вы удивитесь, почему делали это иначе раньше.

00:11:27.220 --> 00:11:29.320
Стоимость и стратегия использования нескольких хранилищ.

00:11:29.440 --> 00:11:31.020
Итак, давайте поговорим о стоимости.

00:11:31.260 --> 00:11:32.820
Здесь большинство людей ждет сюрприз.

00:11:33.000 --> 00:11:34.800
Сколько на самом деле стоит Азур Key Vault?

00:11:34.960 --> 00:11:36.240
Модель ценообразования проста.

00:11:36.400 --> 00:11:38.100
Нет платы за хранение каждого отдельного секрета.

00:11:38.220 --> 00:11:40.340
Вы не платите за каждый пароль или API-ключ, который храните.

00:11:40.480 --> 00:11:41.920
Вместо этого вы платите за операцию.

00:11:42.120 --> 00:11:45.200
Для стандартного уровня это около 3 центов за каждые 10 тысяч операций.

00:11:45.360 --> 00:11:47.560
Запрос на получение секрета считается за одну операцию.

00:11:47.560 --> 00:11:50.580
То же самое касается создания секрета или просмотра содержимого хранилища.

00:11:50.700 --> 00:11:54.100
Для обычного малого или среднего приложения это выливается в сущие копейки в месяц.

00:11:54.240 --> 00:11:55.120
Буквально копейки.

00:11:55.320 --> 00:11:57.440
Сравните это с AWS Secretus Manager.

00:11:57.640 --> 00:12:00.140
Они взимают 40 центов за секрет в месяц только за хранение.

00:12:00.360 --> 00:12:01.840
Плюс дополнительная плата за вызовы API.

00:12:02.020 --> 00:12:05.680
Если у вас 100 секретов, это 40 долларов в месяц еще до того, как вы прочитаете хотя бы один из них.

00:12:05.840 --> 00:12:09.560
С Азур Key Vault 100 секретов при умеренном использовании могут обойтись вам в 15 центов.

00:12:09.660 --> 00:12:11.600
При масштабировании разница растет очень быстро.

00:12:11.840 --> 00:12:13.240
Существует также премиум уровень.

00:12:13.240 --> 00:12:17.600
Он добавляет ключи на базе HSM для нагрузок, требующих высочайшего уровня криптографической защиты.

00:12:17.740 --> 00:12:21.320
Например, финансовые транзакции, медицинские данные, государственные системы.

00:12:21.460 --> 00:12:26.280
Стоимость за операцию там выше около 15 центов за 10 тысяч операций для продвинутых типов ключей.

00:12:26.400 --> 00:12:28.480
Плюс ежемесячная плата за каждый HSM-ключ.

00:12:28.700 --> 00:12:31.860
Но для большинства приложений стандартного уровня более чем достаточно.

00:12:32.060 --> 00:12:34.860
А вот и ценовой сюрприз, который застает многих врасплох.

00:12:35.080 --> 00:12:40.300
Для типичного веб-приложения с парой секретов и несколькими тысячами операций в месяц Key Vault стоит меньше доллара.

00:12:40.300 --> 00:12:43.020
Вы потратите больше на кофе, пока будете его настраивать.

00:12:43.160 --> 00:12:45.260
Но есть стратегия, которая важнее стоимости.

00:12:45.500 --> 00:12:46.860
Сколько хранилищ вы используете?

00:12:47.020 --> 00:12:49.320
Разумный подход – это стратегия с несколькими хранилищами.

00:12:49.500 --> 00:12:52.640
Используйте отдельные хранилища для разработки, тестирования, промежуточный и рабочий сред.

00:12:52.760 --> 00:12:54.620
Это предотвращает самую частую ошибку.

00:12:54.740 --> 00:12:59.840
Кто-то запускает тестовый скрипт, который случайно считывает рабочую базу данных, потому что строка подключения была в том же хранилище.

00:12:59.960 --> 00:13:02.540
Когда среды разделены, такая ошибка становится невозможной.

00:13:02.680 --> 00:13:05.880
Вам также следует разделять их по бизнес-подразделениям или областям соответствия требованиям.

00:13:05.880 --> 00:13:09.420
Если вы работаете с данными платежных карт, поместите эти секреты в отдельное хранилище.

00:13:09.540 --> 00:13:12.740
Общие бизнес-задачи – в другое, данные здравоохранения – в третье.

00:13:12.860 --> 00:13:15.620
Это не усложнение работы, а ограничение радиуса поражения.

00:13:15.820 --> 00:13:19.080
Если одно хранилище будет скомпрометировано, будут раскрыты только секреты в немецком.

00:13:19.220 --> 00:13:21.400
Остальная часть вашей инфраструктуры останется в безопасности.

00:13:21.520 --> 00:13:24.020
И есть две встроенные защитные функции, которые всегда стоит включать.

00:13:24.160 --> 00:13:27.520
Мягкое удаление означает, что если кто-то удалит секрет, он не исчезнет навсегда.

00:13:27.700 --> 00:13:31.920
Он переходит в восстанавливаемое состояние на выбранный вами период хранения до 90 дней.

00:13:31.920 --> 00:13:34.320
Защита от очистки делает еще один шаг вперед.

00:13:34.480 --> 00:13:38.520
Никто не может окончательно удалить хранилище или его содержимое, пока не истечет период хранения.

00:13:38.720 --> 00:13:43.180
Вместе они предотвращают случайную потерю данных, из-за которой команды безопасности не спят по ночам.

00:13:43.300 --> 00:13:44.240
Как все это связано?

00:13:44.400 --> 00:13:47.020
Давайте объединим все это и посмотрим, как эти части сочетаются.

00:13:47.180 --> 00:13:48.880
Key Vault – это неизолированный элемент.

00:13:49.020 --> 00:13:52.020
Это центральная нервная система для секретов в вашей архитектуре Azure.

00:13:52.020 --> 00:13:55.480
Когда вы понимаете, как функционирует вся система, все встает на свои места.

00:13:55.680 --> 00:13:57.900
Вот что происходит, когда приложению нужен секрет.

00:13:58.040 --> 00:14:01.000
Приложение запрашивает его, используя свое управляемое удостоверение.

00:14:01.000 --> 00:14:03.440
Это удостоверение уже зарегистрировано в IntraID.

00:14:03.620 --> 00:14:07.820
Azure создала его автоматически, когда вы включили управляемое удостоверение для ресурса.

00:14:07.980 --> 00:14:12.120
IntraID проверяет подлинность удостоверения, а затем передает запрос в Key Vault.

00:14:12.340 --> 00:14:14.980
Key Vault проверяет назначенные вами разрешения RBC.

00:14:15.220 --> 00:14:19.360
Если у удостоверения есть нужная роль, например, пользователь секретов Key Vault, секрет возвращается.

00:14:19.520 --> 00:14:21.000
Все это происходит за миллисекунды.

00:14:21.140 --> 00:14:22.940
Приложение никогда не видит учетные данные.

00:14:23.140 --> 00:14:24.280
Оно никогда не хранит пароль.

00:14:24.440 --> 00:14:25.920
Оно просто получает нужное значение.

00:14:26.060 --> 00:14:28.760
Теперь подумайте о том, сколько сервисов Azure могут подключиться к этому.

00:14:28.760 --> 00:14:34.500
App Service, Functions, AKS, Data Factory, Synapse, Logic Apps, Defops, Pipelines – все они умеют работать с Key Vault.

00:14:34.680 --> 00:14:38.980
Вы можете настроить веб-приложение так, чтобы оно ссылалось на секрет прямо в параметрах приложения.

00:14:39.140 --> 00:14:43.860
Вы можете настроить конвейер Data Factory на получение ключа учетной записи хранения из Key Vault во время выполнения.

00:14:44.040 --> 00:14:48.360
Вы можете настроить кластер Kubernetes для получения секретов с помощью драйвера Key Vault CSI.

00:14:48.480 --> 00:14:54.500
Каждый сервис интегрируется одинаково, используя ту же систему идентификации, те же роли RBAC и те же журналы аудита.

00:14:54.500 --> 00:14:56.860
Шаблон CI, CD особенно эффективен.

00:14:57.000 --> 00:14:59.880
Ваши конвейеры получают секреты из Key Vault во время развертывания.

00:15:00.040 --> 00:15:03.180
Они никогда не хранят их в переменных конвейера или секретах репозитория.

00:15:03.360 --> 00:15:06.460
Если вам нужно сменить пароль базы данных, вы обновляете его в Key Vault.

00:15:06.660 --> 00:15:09.620
При следующем запуске конвейер автоматически подхватывает новое значение.

00:15:09.820 --> 00:15:12.800
Никаких изменений в конвейере, никакого изменения кода, никаких повторных развертываний.

00:15:12.980 --> 00:15:14.900
Вот что заставляет все это работать как единое целое.

00:15:15.040 --> 00:15:19.700
Как только вы настроите Key Vault с управляемым удостоверением и RBAC, вы полностью перестанете думать об управлении учетными данными.

00:15:19.880 --> 00:15:21.320
Ваши приложения просто работают.

00:15:21.320 --> 00:15:23.380
Секреты обновляются незаметно для всех.

00:15:23.680 --> 00:15:25.620
Сертификаты продлеваются без ночных авралов.

00:15:25.740 --> 00:15:27.560
Система выполняет все это в фоновом режиме.

00:15:27.640 --> 00:15:29.860
Это тот подход к безопасности, который действительно важен.

00:15:29.980 --> 00:15:32.040
Периметром является идентификация, а не сеть.

00:15:32.220 --> 00:15:35.180
Неважно, находится ли кто-то внутри вашей виртуальной сети или снаружи.

00:15:35.320 --> 00:15:38.660
Важно лишь то, есть ли у них действительное удостоверение с соответствующими правами доступа.

00:15:38.780 --> 00:15:40.840
Key Vault обеспечивает это по своей архитектуре.

00:15:40.960 --> 00:15:46.500
Каждый запрос на доступ проходит аутентификацию интро-ID и авторизацию RBAC, независимо от того, откуда он исходит.

00:15:46.500 --> 00:15:47.560
И все это логируется.

00:15:47.560 --> 00:15:50.480
Каждое чтение секрета, каждая операция с ключом, каждое получение сертификата.

00:15:50.620 --> 00:15:52.420
Вы можете видеть, кто, что и когда запрашивал.

00:15:52.580 --> 00:15:55.180
Если что-то выглядит подозрительно, у вас есть данные для расследования.

00:15:55.380 --> 00:15:59.840
Это критически важно для соответствия требованиям, реагирования на инциденты и понимания того, что происходит в вашей среде.

00:15:59.960 --> 00:16:01.040
В этом-то вся и прелесть.

00:16:01.200 --> 00:16:06.340
Key Vault, интро-ID, RBAC и управляемые удостоверения работают вместе как единая система безопасности.

00:16:06.500 --> 00:16:08.220
Каждый компонент усиливает остальные.

00:16:08.400 --> 00:16:11.880
И когда все настроено правильно, вы получаете систему управления учетными данными,

00:16:11.880 --> 00:16:15.860
которые одновременно безопаснее и проще в эксплуатации, чем любая самописная разработка.

00:16:15.860 --> 00:16:17.020
Практические выводы.

00:16:17.120 --> 00:16:19.040
Итак, что вам стоит сделать прямо сейчас?

00:16:19.240 --> 00:16:20.920
Давайте превратим эти знания в действия.

00:16:21.100 --> 00:16:23.040
Вот задачи, которыми можно заняться на этой неделе.

00:16:23.220 --> 00:16:24.620
Начните с вашей модели разрешений.

00:16:24.780 --> 00:16:27.800
Откройте Key Vault на портале, перейдите в конфигурацию доступа и проверьте, что там указано.

00:16:27.920 --> 00:16:30.740
Если вы видите политику доступа к хранилищу, в All Access Policy это устаревший способ.

00:16:30.860 --> 00:16:33.580
Вам следует перейти на управление доступом на основе ролей Azure, Azure RBC.

00:16:33.820 --> 00:16:35.100
Миграция выполняется просто.

00:16:35.300 --> 00:16:39.940
Переключите модель разрешений и назначьте роли RBC тем же пользователям, у которых уже были политики доступа.

00:16:40.000 --> 00:16:41.000
Сделайте это сегодня.

00:16:41.000 --> 00:16:44.720
Microsoft рекомендует это, и исследование, о котором мы говорили, показало почему.

00:16:44.920 --> 00:16:48.220
Затем проверьте все учетные записи, обладающие ролью участника, контрибутор Key Vault.

00:16:48.420 --> 00:16:51.660
Откройте вкладку IAM в вашем хранилище и посмотрите, у кого есть доступ уровня участник.

00:16:51.760 --> 00:16:54.120
У каждого, у кого есть эта роль, должны быть веские причины для этого.

00:16:54.260 --> 00:16:55.560
В большинстве случаев нет.

00:16:55.760 --> 00:16:57.880
Замените роль участника на что-то более специфическое.

00:16:58.040 --> 00:17:01.020
Если кому-то нужно только читать секреты, назначьте роль пользователя секретов Key Vault.

00:17:01.240 --> 00:17:04.200
Если нужно управлять секретами, используйте роль администратора секретов Key Vault.

00:17:04.400 --> 00:17:07.100
Цель состоит в том, чтобы полностью закрыть этот путь повышения привилегий.

00:17:07.100 --> 00:17:09.360
Затем воспользуйтесь управляемыми удостоверениями.

00:17:09.460 --> 00:17:12.600
Любая служба Azure, которой нужен доступ к Key Vault, должна их использовать.

00:17:12.820 --> 00:17:16.480
Если у вас есть веб-приложение, функция, фабрика данных или виртуальная машина,

00:17:16.600 --> 00:17:20.320
использующая субъект службу с секретом клиента, перейдите на управляемое удостоверение.

00:17:20.500 --> 00:17:24.420
Это проще, безопаснее и решает проблему «курица и яйца», которую мы обсуждали.

00:17:24.560 --> 00:17:27.420
Azure берет на себя управление учетными данными в фоновом режиме.

00:17:27.500 --> 00:17:28.140
И еще кое-что.

00:17:28.280 --> 00:17:31.160
Включите мягкое удаление и защиту от очистки для каждого хранилища.

00:17:31.280 --> 00:17:35.020
Мягкое удаление включено по умолчанию для новых хранилищ, а защиты от очистки нет.

00:17:37.100 --> 00:17:40.580
Никому навсегда удалить хранилище или его содержимое в течение периода удержания.

00:17:40.780 --> 00:17:43.320
Это не раз спасало команды от катастрофических ошибок.

00:17:43.440 --> 00:17:44.640
Вот ваш призыв к действию.

00:17:44.820 --> 00:17:47.060
Взгляните на свой текущий подход к управлению секретами.

00:17:47.220 --> 00:17:51.140
Найдите один секрет, который все еще лежит в файле конфигурации, переменной окружения или жестко закодирован в коде.

00:17:51.340 --> 00:17:52.940
Перенесите его в Key Vault на этой неделе.

00:17:53.100 --> 00:17:53.600
Всего один.

00:17:53.740 --> 00:17:56.040
Когда вы увидите, как это просто, вы захотите перенести остальные.

00:17:56.380 --> 00:17:57.860
Безопасность — это не разовая настройка.

00:17:57.960 --> 00:17:58.620
Это практика.

00:17:58.740 --> 00:18:01.740
Key Vault упрощает эту практику, но только если вы используете его правильно.

00:18:02.160 --> 00:18:02.820
Инструменты есть.

00:18:03.040 --> 00:18:03.920
Шаблоны проверены.

00:18:03.920 --> 00:18:06.140
Теперь все зависит от того, внедрите ли вы их.

00:18:06.280 --> 00:18:07.000
Такова система.

00:18:07.180 --> 00:18:11.160
Key Vault — это ваш цифровой сейф, но он безопасен лишь настолько, насколько безопасны средства контроля доступа к нему.

00:18:11.340 --> 00:18:13.200
Начните с аудита, который я только что описал.

00:18:13.320 --> 00:18:14.660
Проверьте свою модель разрешений.

00:18:14.820 --> 00:18:18.080
Проверьте назначенные роли участников и перенесите хотя бы один секрет в хранилище на этой неделе.

00:18:18.260 --> 00:18:21.360
Подписывайтесь, чтобы получать больше полезных советов по облачной безопасности простым языком.

00:18:21.440 --> 00:18:23.940
И поделитесь этим с тем, кто все еще хранит секреты в конфигурационных файлах.