WEBVTT

00:00:00.000 --> 00:00:04.080
Ваша команда руководителей считает, что это вопрос внедрения. Это не так. Это решение,

00:00:04.200 --> 00:00:07.720
требующее управления, с очень коротким сроком действия, и давление велико, потому что Копайлот

00:00:07.720 --> 00:00:11.340
не ждет, пока вы упорядочите свои политики или согласуете внутренние процессы. Как только он

00:00:11.340 --> 00:00:15.520
начинает работать в вашей среде, он использует систему именно так, как ее находит, и именно здесь

00:00:15.520 --> 00:00:19.720
возникает проблема. Большинство организаций с несколькими арендаторами Microsoft 365 предполагают,

00:00:19.840 --> 00:00:23.020
что у них есть единая стратегия управления и, в основном потому, что они покупают у одного

00:00:23.020 --> 00:00:26.340
поставщика и управляют одной системой идентификации. Они слышат одну стратегическую

00:00:26.340 --> 00:00:30.160
концепцию от Microsoft и предполагают, что реальность соответствует презентации. Но условия

00:00:30.160 --> 00:00:34.300
работы совершенно иные, и работают на границах арендаторов, в то время как риски перемещаются

00:00:34.300 --> 00:00:38.460
между ними. Поэтому вопрос не в том, можем ли мы включить Копайлот везде. Настоящий вопрос в том,

00:00:38.600 --> 00:00:41.560
какая модель управления позволит нам безопасно масштабироваться между арендаторами,

00:00:41.680 --> 00:00:45.360
которые ведут себя независимо. Прежде чем мы перейдем к этой модели, нам нужно определить

00:00:45.360 --> 00:00:50.420
ловушку. Ловушка — суверенные островки и внутри одного предприятия. В большинстве организаций

00:00:50.420 --> 00:00:55.440
иллюзия начинается со знакомства. Вы открываете Microsoft 365, вы открываете Perview, вы открываете

00:00:55.440 --> 00:00:59.660
интро, вы открываете Power Platform. Брендинг одинаков. Язык администрирования кажется

00:00:59.660 --> 00:01:03.940
единым, а коммерческая составляющая рассказывает очень понятную историю. Одна экосистема,

00:01:04.020 --> 00:01:08.360
одна стратегия, одно направление. Но модель управления, лежащая в основе, не является чем-то одним,

00:01:08.520 --> 00:01:12.180
и это важнее, чем брендинг. На основе проведенного исследования не существует единого глобального

00:01:12.180 --> 00:01:15.480
центра администрирования и с полным функциональным разнообразием, который бы предоставлял единое

00:01:15.480 --> 00:01:19.400
место для четкого управления Копайлот во всех арендаторах. На самом деле, у вас есть фрагментированный

00:01:19.400 --> 00:01:23.660
стек управления. Часть управления находится в Perview, другая часть — в центрах администрирования,

00:01:23.660 --> 00:01:28.100
а остальное разбросано по интро и Power Platform. Некоторые функции появляются в новых уровнях

00:01:28.100 --> 00:01:32.620
управления Microsoft, но они еще не формируют единую зрелую глобальную плоскость, охватывающую

00:01:32.620 --> 00:01:37.120
все арендаторы. Этот разрыв создает ложную уверенность. Руководители смотрят на экосистему и

00:01:37.120 --> 00:01:40.800
предполагают централизацию, в то время как команды смотрят на общую идентичность и предполагают

00:01:40.800 --> 00:01:44.500
согласованность. Отдел закупок видит единое соглашение и предполагает единую операционную модель,

00:01:44.600 --> 00:01:47.520
но каждый арендатор по-прежнему имеет свои собственные границы политики и свои собственные

00:01:47.520 --> 00:01:50.880
границы данных, что означает, что на практике каждый из них имеет свою собственную версию истины.

00:01:50.880 --> 00:01:55.980
Таким образом, на самом деле все просто. У вас не одна корпоративная среда и, у вас несколько сред и,

00:01:56.140 --> 00:02:00.640
которые принадлежат одному и тому же предприятию. Это совершенно другая картина рисков. Один клиент

00:02:00.640 --> 00:02:04.580
может иметь более широкий охват, в то время как другой — более слабое использование меток или

00:02:04.580 --> 00:02:08.960
неполный ввод данных аудита. С точки зрения совета директоров это может выглядеть как одна программа,

00:02:08.980 --> 00:02:12.780
но с точки зрения аудита или инцидентов это вовсе не одна программа. Это набор отдельных

00:02:12.780 --> 00:02:17.260
условий эксплуатации. И как только эти условия начинают меняться, отчетность начинает лгать.

00:02:17.260 --> 00:02:22.200
Не намеренно, а структурно. Ключевая команда спрашивает, управляем ли мы. Один клиент отвечает

00:02:22.200 --> 00:02:26.160
«да», потому что аудит включен. Другой отвечает «да», потому что метки существуют, даже если охват

00:02:26.160 --> 00:02:30.440
слабый. Третий отвечает «да», потому что идентификация связана. Четвертый отвечает «да»,

00:02:30.440 --> 00:02:33.800
потому что капайлот технически развернут. Каждый ответ звучит разумно сам по себе,

00:02:33.980 --> 00:02:38.360
но ни один из них не означает одно и то же. В этом ловушка. Вы думаете, что смотрите на глобальную

00:02:38.360 --> 00:02:42.140
плоскость управления, тогда как на самом деле вы видите набор суверенных островков и внутри

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

00:02:47.260 --> 00:02:51.520
И если вы ничего больше не запомните из этого раздела, запомните эту фразу. Нет глобального

00:02:51.520 --> 00:02:56.160
центра администрирования и есть только иллюзия его существования. Как только эта иллюзия рушится,

00:02:56.400 --> 00:03:00.600
быстро возникает следующая проблема. Большинство организаций реагируют, управляя каждым

00:03:00.600 --> 00:03:05.000
арендатором вручную, и называют это контролем. Почему ручное управление каждым арендатором

00:03:05.000 --> 00:03:09.040
рушится в масштабах? Как только руководители видят проблему границ, обычный ответ кажется разумным.

00:03:09.180 --> 00:03:12.820
Они говорят «хорошо, мы будем должным образом управлять каждым арендатором». Одна команда администраторов

00:03:12.820 --> 00:03:16.360
проверяет настройки здесь, другая команда повторяет их там. Кто-то ведет электронную таблицу,

00:03:16.360 --> 00:03:20.340
кто-то составляет контрольный список. Руководящая группа встречается раз в месяц и спрашивает,

00:03:20.520 --> 00:03:24.400
идет ли развертывание по плану. На бумаге это выглядит дисциплинированно. На практике это

00:03:24.400 --> 00:03:28.780
ручное повторение, замаскированное под управление. И причина, по которой это терпит неудачу,

00:03:28.880 --> 00:03:33.260
проста. Повторение не создает контроля, оно создает вариативность во времени. Это происходит

00:03:33.260 --> 00:03:36.600
потому, что каждый арендатор работает с разной скоростью, каждый администратор по-разному

00:03:36.600 --> 00:03:40.420
интерпретирует стандарты, и локальные исключения начинают казаться оправданными, поскольку бизнес

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

00:03:44.440 --> 00:03:48.680
потому что она кажется наглядной. Люди могут указывать на закрытые заявки, созданные политики

00:03:48.680 --> 00:03:52.520
и измененные настройки. Они могут демонстрировать активность, но видимые усилия — это не то же

00:03:52.520 --> 00:03:56.260
самое, что стабильная операционная модель. А с появлением Капайлот этот пробел очень быстро

00:03:56.260 --> 00:03:59.900
становится дорогостоящим. Система начинает использовать существующее разрешение, существующий доступ

00:03:59.900 --> 00:04:02.780
к контенту и существующие пробелы в маркировке в тот момент, когда пользователи начинают

00:04:02.780 --> 00:04:06.880
запрашивать информацию. Именно это большинство людей упускает из виду. Капайлот не ждет зрелости

00:04:06.880 --> 00:04:10.660
управления. Он работает на основе уже имеющихся у вас разрешений, уже допустимой вами гигиены

00:04:10.660 --> 00:04:14.060
контента и стандартизированного подхода к аудиту, который вы так и не смогли стандартизировать.

00:04:14.200 --> 00:04:18.220
Если один арендатор очистил доступ, а другой удалил его, или если один арендатор передает

00:04:18.220 --> 00:04:21.920
полезные данные аудита, а другой едва собирает достаточной информации для расследования,

00:04:22.080 --> 00:04:26.020
Капайлот немедленно выявит эти различия. Это происходит не в теории, а на практике.

00:04:26.160 --> 00:04:30.660
Если один пользователь проверил широкий доступ к SharePoint, а другой посчитал, что этого достаточно,

00:04:30.860 --> 00:04:34.880
и обнаружит пробелы. И на более глубоком уровне каждый новый пользователь усугубляет проблему,

00:04:35.000 --> 00:04:38.500
не потому что пользователи плохие, а потому что накапливаются неуправляемые различия.

00:04:38.500 --> 00:04:41.900
Одна новая пилотная группа добавляет локальное исключение. Слияние приводит к появлению

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

00:04:44.960 --> 00:04:48.700
базовую конфигурацию. Бизнес-подразделение запрашивает более быстрый доступ, и ни один из

00:04:48.700 --> 00:04:52.240
этих вариантов сам по себе не выглядит радикальным. Если же их объединить на несколько месяцев,

00:04:52.420 --> 00:04:56.140
получится дрейф-политик, дрейф-доступа и дрейф-развертывания. В результате команда управления

00:04:56.140 --> 00:04:59.200
тратит больше времени на согласование различий, чем на предотвращение рисков.

00:04:59.360 --> 00:05:02.860
Вот где ручной контроль дает сбой. Кажется, что это безопасней, потому что настройки контролируются

00:05:02.860 --> 00:05:05.700
людьми, но на самом деле это приводит к масштабируемой несогласованности, потому что каждая точка

00:05:05.700 --> 00:05:08.660
контакта – это еще один шанс для пользователей расходиться во мнениях. В результате – замедление

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

00:05:12.100 --> 00:05:15.840
и больше доработок там, где нужны стандарты. Хуже всего-то, что это создает скрытую уязвимость

00:05:15.840 --> 00:05:19.900
там, где руководство ожидает гарантий. Я понял это, когда перестал рассматривать управление

00:05:19.900 --> 00:05:24.200
как задачу настройки. Это не так. Оно больше похоже на деградацию. Если вы один раз исправляете

00:05:24.200 --> 00:05:27.600
разрешение, но никакой контроль не предотвращает их повторное изменение, уязвимость возвращается.

00:05:32.860 --> 00:05:36.300
Если вы утверждаете капайлот волнами, не проверяя, сохраняется ли базовый контроль,

00:05:36.440 --> 00:05:40.320
вы не масштабируетесь безопасно. Вы просто расширяетесь быстрее, чем ваша система управления

00:05:40.320 --> 00:05:43.940
может справиться. Таким образом, важным показателем здесь является изменение доступа,

00:05:44.020 --> 00:05:47.480
а не только-то, исправили ли вы что-то, а так, как быстро разрешение снова распространяется

00:05:47.480 --> 00:05:51.920
после исправления. Это показывает, держится ли ваша модель или нет. Потому что управление – это не

00:05:51.920 --> 00:05:55.920
проект, который вы заканчиваете. Это проблема деградации, которой вы постоянно управляете. И когда

00:05:55.920 --> 00:05:59.080
масштабирование разрушает старую модель, большинство руководителей обращаются к наиболее знакомому

00:05:59.080 --> 00:06:02.220
ответу – идентификации. Они предполагают, что если пользователи могут беспрепятственно перемещаться

00:06:02.220 --> 00:06:04.940
между арендаторами, то управление каким-то образом переместится вместе с ними. Этого не

00:06:04.940 --> 00:06:09.120
произойдет. Почему идентификация не решает проблему управления? Именно здесь многие программы

00:06:09.120 --> 00:06:12.740
сворачивают с правильного пути, потому что идентификация кажется простым решением. Если

00:06:12.740 --> 00:06:16.380
пользователи могут проходить аутентификацию в разных арендаторах, если интро подключена и если

00:06:16.380 --> 00:06:19.720
настроены межарендные параметры, руководители считают, что самая сложная часть решена.

00:06:19.880 --> 00:06:23.560
Доступ выглядит унифицированным, вход в систему выглядит унифицированным, архитектурная схема

00:06:23.560 --> 00:06:26.800
выглядит аккуратной, но управление Copilot не становится унифицированным только потому,

00:06:26.980 --> 00:06:30.160
что идентификация может перемещаться. Это предположение не работает в том месте,

00:06:30.380 --> 00:06:33.460
где и действительно работает. Copilot основывает ответы в контексте арендатора,

00:06:33.640 --> 00:06:37.240
где выполняется запрос, и собственные рекомендации Microsoft ясно указывают на этот момент.

00:06:37.400 --> 00:06:42.380
Microsoft 365 Copilot работает в рамках безопасности и соответствия требованиям арендатора и уважает

00:06:42.380 --> 00:06:45.960
разрешение пользователя в этом конкретном контексте арендатора. Пользователь может переключать

00:06:45.960 --> 00:06:49.620
контекст как гость, да, но Copilot по-прежнему ограничен одним арендатором за раз. Он не

00:06:49.620 --> 00:06:52.560
объединяет несколько арендаторов в одно интеллектуальное рабочее пространство для получения

00:06:52.560 --> 00:06:55.900
одного ответа. Таким образом, идентификация может перемещаться, управление — нет.

00:06:56.020 --> 00:06:59.680
И как только вы разделяете эти два аспекта, многие формулировки руководителей начинают

00:06:59.680 --> 00:07:04.640
звучать опасно расплывчато. Связанные арендаторы — общая идентификация, унифицированный опыт.

00:07:05.500 --> 00:07:08.840
Эти фразы могут быть в целом верны для совместной работы, но они не означают,

00:07:09.020 --> 00:07:13.060
что обеспечение соблюдения политик, привязка данных, ведение журналов и проверка контроля

00:07:13.060 --> 00:07:16.480
теперь работают как единая система. Этот разрыв становится еще более очевидным,

00:07:16.480 --> 00:07:19.860
если посмотреть на многопользовательский режим Copilot Studio, поскольку предварительная версия

00:07:19.860 --> 00:07:23.140
рассказывает очень конкретную историю. Да, многопользовательское использование существует,

00:07:23.220 --> 00:07:25.840
и агент, размещенный в одном клиенте, может использоваться из другого клиента,

00:07:25.940 --> 00:07:28.980
но аутентификация конечных пользователей в многопользовательском режиме пока не поддерживается

00:07:28.980 --> 00:07:32.740
в предварительной версии. Гостевые пользователи не поддерживаются. Пользовательские коннекторы

00:07:32.740 --> 00:07:36.680
не поддерживаются. Коннекторы Graph и Microsoft 365 Standard не поддерживаются.

00:07:37.080 --> 00:07:40.760
Многогеографическая аутентификация не поддерживается. Некоторые аналитические возможности

00:07:40.760 --> 00:07:45.620
недоступны. В этом режиме также отключена запись разговоров. Это незрелая система управления между

00:07:45.620 --> 00:07:49.320
клиентами. Это ограниченная предварительная версия с четкими ограничениями. И эти ограничения

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

00:07:52.400 --> 00:07:55.940
Они слышат о многопользовательском режиме и предполагают операционную зрелость. Их архитекторы

00:07:55.940 --> 00:07:59.860
слышат о межклиентском режиме и предполагают симметрию политик. Их команды управления слышат

00:07:59.860 --> 00:08:03.400
об одном поставщике и предполагают согласованность аудита. Затем начинается внедрение,

00:08:03.560 --> 00:08:07.240
и люди обнаруживают различное поведение, недостающие сигналы и неудобные пробелы в

00:08:07.240 --> 00:08:11.100
аутентификации и аналитике. Представьте второй случай. Глобальная компания устанавливает

00:08:11.100 --> 00:08:14.180
внутрикорпоративные связи между арендаторами и предполагает, что пользовательский опыт

00:08:14.180 --> 00:08:17.560
естественным образом распространиться и на использование Капайлот. Ожидание звучит разумно,

00:08:17.740 --> 00:08:21.460
учитывая доверие к общему каталогу, более плавный доступ и общие шаблоны идентификации.

00:08:21.580 --> 00:08:25.020
Но когда команды тестируют реальные сценарии Капайлот и агентов, поведение оказывается

00:08:25.020 --> 00:08:28.680
неравномерным. Некоторые данные появляются только в переключенных контекстах. Некоторые

00:08:28.680 --> 00:08:32.560
ожидаемые коннекторы недоступны. Некоторые ожидания аудита не совпадают с тем, что фактически

00:08:32.560 --> 00:08:35.740
предоставляют функции предварительной версии. Руководство по-прежнему слышит о подключении,

00:08:35.940 --> 00:08:39.320
в то время как команда контроля начинает находить исключения. Это не технический крайний случай.

00:08:39.320 --> 00:08:43.220
Это неправильное понимание принципов управления, потому что аудиторы проверяют не вашу архитектурную

00:08:43.220 --> 00:08:46.760
историю, а доказательства. Они спрашивают, где выполнялись запросы, какой арендатор применял

00:08:46.760 --> 00:08:50.220
политику, какие журналы существуют и были ли ваши средства контроля действительно сопоставимы в

00:08:50.220 --> 00:08:53.380
средах, которые вы описали как связанные. Если ваша операционная модель рассматривает

00:08:53.380 --> 00:08:57.120
идентификацию как управление, у вас не будет однозначного ответа. Поэтому, если вы запомните

00:08:57.120 --> 00:09:00.480
здесь одну фразу, пусть это будет вот это. Межпользовательская идентификация — это не

00:09:00.480 --> 00:09:04.400
межпользовательская аналитика. Идентификация помогает пользователям войти в систему. Она не говорит о том,

00:09:04.400 --> 00:09:07.520
регулируется ли поведение капайлот последовательно, контролируется ли должным образом или безопасно

00:09:07.520 --> 00:09:10.280
ли масштабировать его во всех местах, которые ваше предприятие теперь называет одной средой.

00:09:10.340 --> 00:09:13.200
И как только это станет ясно, ответом не может быть увеличения количества связей между

00:09:13.200 --> 00:09:17.160
пользователями. Это должна быть архитектура. Модель управления, которая действительно работает,

00:09:17.360 --> 00:09:20.920
центр и периферия. Итак, как выглядит реальная модель управления, когда ваша платформа

00:09:20.920 --> 00:09:24.480
фрагментирована, идентификация лишь частично, а границы между пользователями все еще имеют

00:09:24.480 --> 00:09:28.760
значение. Она выглядит как система, центр и периферия. Я предлагаю это не потому, что диаграмма

00:09:28.760 --> 00:09:32.300
выглядит аккуратно на слайде, а потому, что она действительно соответствует сложным условиям работы,

00:09:32.300 --> 00:09:36.200
с которыми вы имеете дело прямо сейчас. Вам нужно одно центральное место, где решения по управлению

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

00:09:40.140 --> 00:09:44.000
команды пользователей для выполнения этих решений. Эти локальные команды должны работать в рамках

00:09:44.000 --> 00:09:47.800
своих собственных границ, не изобретая свою собственную версию правил каждый раз, когда они

00:09:47.800 --> 00:09:52.180
чувствуют небольшое давление. Мы должны начать с центра. Центр управления – это не административный

00:09:52.180 --> 00:09:56.140
портал, не блестящая панель управления и уж точно не героическая централизованная команда,

00:09:56.260 --> 00:10:00.240
которая вручную проверяет файлы в каждом клиенте. Вместо этого центр управления выступает в

00:10:00.240 --> 00:10:04.600
качестве высшего органа управления. Эта группа отвечает за разработку политик, базовые показатели

00:10:04.600 --> 00:10:09.220
аудита, стандарты меток и критерии развертывания. Именно они решают, что на самом деле означает

00:10:09.220 --> 00:10:13.000
готовность к опайлот, какие доказательства считаются доказательствами и как быстро необходимо

00:10:13.000 --> 00:10:17.240
устранить уязвимость в системе безопасности. Этот сдвиг меняет весь подход. Благодаря такой

00:10:17.240 --> 00:10:22.280
структуре глобальный перестает быть словом, обозначающим один волшебный экран и начинает означать

00:10:22.280 --> 00:10:26.580
единую систему управления. Вы получаете один стандарт для контроля доступа, один стандарт для

00:10:26.580 --> 00:10:30.060
обработки результатов аудита и один стандарт для меток конфиденциальности. Существует

00:10:30.060 --> 00:10:32.920
один четкий критерий, которому должен соответствовать любой конкретный клиент, прежде чем ему

00:10:32.920 --> 00:10:35.960
будет разрешено расширить доступ к опайлот для большего числа пользователей. Затем вам нужны

00:10:35.960 --> 00:10:39.360
периферийные узлы. Периферийные узлы – это ваши локальные команды по выполнению задач в каждом

00:10:39.360 --> 00:10:42.680
клиенте, которые берут этот базовый уровень и применяют его к своей конкретной среде. Именно они

00:10:42.680 --> 00:10:47.580
проводят исправления, проверяют журналы и анализируют общие права доступа. Однако вся эта работа

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

00:10:51.860 --> 00:10:55.540
Если местной команде необходимо отклониться от плана, существует формальный порядок для

00:10:55.540 --> 00:10:59.360
исключений. И если они хотят двигаться быстрее, им все равно сначала нужно выполнить общее

00:10:59.360 --> 00:11:02.940
требование контроля. Когда возникают региональные или юридические различия, эти проблемы

00:11:02.940 --> 00:11:06.460
документируются и утверждаются, вместо того, чтобы незаметно поглощаться каким-то локальным

00:11:06.460 --> 00:11:09.960
обходным путем, о котором никто не знает. Такая структура жизненно важна, потому что полностью

00:11:09.960 --> 00:11:13.680
централизованные модели обычно застревают на локальных деталях, в то время как полностью локальные

00:11:13.680 --> 00:11:18.200
модели почти сразу же впадают в полную несогласованность. Структура, центр и периферия позволяют избежать

00:11:18.200 --> 00:11:22.140
обеих этих проблем. Центр обеспечивает необходимую согласованность, а периферия – скорость

00:11:22.140 --> 00:11:26.060
выполнения там, где работа фактически ведется. Давайте рассмотрим это на конкретном примере.

00:11:26.160 --> 00:11:29.440
В центре вы определяете минимальный набор контрольных параметров, которые должен выполнить

00:11:29.440 --> 00:11:33.620
каждый арендатор, прежде чем капайлот сможет развиваться. Вы точно определяете, какие события

00:11:33.620 --> 00:11:38.140
аудита вы ожидаете увидеть и как часто вы будете их проверять. Вы также создаете общую таксономию

00:11:38.140 --> 00:11:42.880
меток для конфиденциального контента, чтобы метка «конфиденциально» не означала пять разных вещей

00:11:42.880 --> 00:11:47.240
для пяти разных арендаторов. Вы устанавливаете ритм проверок, возможно, ежемесячно для оценки

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

00:11:51.640 --> 00:11:55.480
На периферии ваша команда сопоставляет эти высокоуровневые стандарты с реальностью

00:11:55.480 --> 00:11:59.780
конкретного арендатора. Они определяют, какие сайты по-прежнему имеют открытый доступ и какие

00:11:59.780 --> 00:12:04.040
бизнес-подразделения отстают в маркировке. Они проверяют, действительно ли включен аудит и видны

00:12:04.040 --> 00:12:07.860
ли необходимые записи команде безопасности. Они ищут локальных администраторов, которые могли

00:12:07.860 --> 00:12:11.700
внести исключения, которые никогда не проверялись официально, и решают, может ли пилотная группа

00:12:11.700 --> 00:12:14.880
безопасно расширяться или необходимо сначала остановить процесс и исправить ошибки.

00:12:15.000 --> 00:12:18.840
И вот жесткое правило. Потому что без правила эта модель – всего лишь рекомендация,

00:12:18.840 --> 00:12:22.680
а не реальное управление. Ни одно развертывание к пилот не происходит ни в одном арендаторе

00:12:22.680 --> 00:12:26.060
без подтвержденного аудита, завершенного сканирования на предмет избыточного доступа и

00:12:26.060 --> 00:12:30.320
минимального базового уровня покрытия метками. Я говорю не о планировании или частичном обсуждении

00:12:30.320 --> 00:12:34.160
этих вещей. Они должны быть подтверждены. Если арендатор не может доказать выполнение этих

00:12:34.160 --> 00:12:37.720
трех условий, развертывание приостанавливается. Это может показаться строгим, пока вы не сравните

00:12:37.720 --> 00:12:40.460
это с огромными затратами на устранение последствий, когда пользователи начинают находить

00:12:40.460 --> 00:12:43.980
конфиденциальную информацию, которую вы никогда не собирались раскрывать, с помощью И. Если посмотреть

00:12:43.980 --> 00:12:48.280
на это с такой точки зрения, эти правила – просто здравый смысл. Еще одна причина, по которой эта

00:12:48.280 --> 00:12:52.460
модель так хорошо работает – это время. Чем дольше вы откладываете настройку, тем больше проблем

00:12:52.460 --> 00:12:56.060
вы создаете себе позже. Каждый арендатор, который развертывается раньше базового уровня,

00:12:56.180 --> 00:12:59.900
становится еще одним огромным списком исключений и недостающих данных, которые вашей команде в

00:12:59.900 --> 00:13:03.440
конечном итоге придется устранять. Руководители часто рассматривают управление как нечто,

00:13:03.580 --> 00:13:06.940
что может созреть после завершения внедрения, но в многопользовательском мире к-пайлот

00:13:06.940 --> 00:13:10.160
эта последовательность совершенно обратная. Управление должно руководить развертыванием,

00:13:10.160 --> 00:13:13.440
иначе развертывание создаст больше проблем, чем ваши команды когда-либо смогут решить.

00:13:13.600 --> 00:13:17.300
Если вы руководите этим на уровне предприятия, ваш следующий шаг совершенно ясен. Разверните

00:13:17.300 --> 00:13:20.700
центральный узел прямо сейчас и определите базовый уровень сегодня же. Назначьте своих

00:13:20.700 --> 00:13:24.200
периферийных узлов и немедленно зафиксируйте процесс обработки исключений в письменном виде.

00:13:24.420 --> 00:13:28.360
Необходимо, чтобы глобальный подход означал, что ваши решения и этапы внедрения работают как

00:13:28.360 --> 00:13:32.300
единая система, даже если сами пользователи этого не понимают. Модель имеет значение только в том

00:13:32.300 --> 00:13:35.820
случае, если она действительно меняет то, что будет применяться завтра утром. Руководители должны

00:13:35.820 --> 00:13:39.280
измерять показатели, прежде чем масштабировать систему. Модель управления работает эффективно только

00:13:39.280 --> 00:13:42.820
в том случае, если она обеспечивает измерения, которыми все делятся. В противном случае каждый

00:13:42.820 --> 00:13:46.420
пользователь будет утверждать, что добивается прогресса на своем языке, а руководство будет

00:13:46.420 --> 00:13:50.300
получать обновление статуса, не имея реального контроля. Прежде чем масштабировать Капайлот дальше,

00:13:50.500 --> 00:13:54.700
вам нужен небольшой набор метрик, которые покажут, ведет ли себя архитектура так, как вы думаете.

00:13:54.860 --> 00:13:59.020
Уровни активности не покажут вам правду, а показатели внедрения определенно не покажут риски.

00:13:59.220 --> 00:14:03.300
Следует начать с сокращения чрезмерного обмена информацией. Это по-прежнему один из самых очевидных

00:14:03.300 --> 00:14:07.160
признаков того, что ваша среда становится более безопасной для И. Необходимо обратить внимание

00:14:07.160 --> 00:14:10.960
на группы широкого доступа, открытые сайты SharePoint и старые разрешения, которые предоставляют

00:14:10.960 --> 00:14:14.160
гораздо больше доступа, чем действительно необходимо бизнесу. Цель здесь не в достижении

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

00:14:18.020 --> 00:14:22.320
Капайлот увеличится. Если эти две линии движутся в противоположных направлениях, вы расширяетесь

00:14:22.320 --> 00:14:26.520
гораздо быстрее, чем решаете основные проблемы. Второй необходимый показатель – это охват

00:14:26.520 --> 00:14:30.420
мониторинга. Можете ли вы реально видеть, что делает Капайлот во всех ваших клиентах, таким образом,

00:14:30.420 --> 00:14:33.800
чтобы это позволило провести реальное расследование. Большинство исследований указывают на

00:14:33.800 --> 00:14:37.900
Microsoft Perview как на основное место хранения основных записей, таких как взаимодействие с Капайлот,

00:14:38.020 --> 00:14:42.260
но это предполагает, что у вас везде включен аудит. Охват – это не то, что можно просто считать

00:14:42.260 --> 00:14:47.360
работающим. Вам нужно точно знать, в каких клиентах активен сбор данных аудита, а в каких вы по-прежнему

00:14:47.360 --> 00:14:52.220
имеете лишь частичную видимость. Если у вас нет журналов, у вас нет управления и нет подотчетности.

00:14:52.360 --> 00:14:56.240
Это звучит прямолинейно, потому что так и должно быть. Если клиент не может предоставить полезные

00:14:56.240 --> 00:14:59.360
доказательства того, что происходит, этот клиент не готов к безопасному масштабированию.

00:14:59.360 --> 00:15:02.380
Вы не можете управлять тем, что вам не разрешено проверять, и вы, конечно же,

00:15:02.420 --> 00:15:04.820
не сможете защитить свои действия, если позже что-то пойдет не так.

00:15:04.900 --> 00:15:09.120
Третий показатель – это время внедрения политик во всех клиентах. Здесь руководство выясняет,

00:15:09.280 --> 00:15:12.760
действительно ли модель «центр-периферия» реальна или это всего лишь декоративный элемент.

00:15:13.100 --> 00:15:16.540
Централизованное решение абсолютно ничего не значит, если один арендатор внедряет его на этой

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

00:15:20.780 --> 00:15:24.720
утверждения политики до ее эффективного внедрения в каждом арендаторе. Я говорю не о времени,

00:15:24.720 --> 00:15:28.940
необходимом для объявления или документирования, а о времени до фактического запуска. Для программы

00:15:28.940 --> 00:15:32.760
«И», которая развивается так быстро, такая задержка – это просто другое слово для обозначения риска.

00:15:32.920 --> 00:15:37.040
Практическая цель для большинства организаций – менее 72 часов для стандартных изменений.

00:15:37.200 --> 00:15:41.420
Если ваш цикл намного дольше, у вас пока нет масштабируемой модели. У вас просто проблема

00:15:41.420 --> 00:15:45.760
координации, которую нужно решить. Далее вам нужно посмотреть на коэффициент покрытия метками.

00:15:45.920 --> 00:15:48.980
Не позволяйте этому превратиться в показатель тщеславия, когда один арендатор достигает

00:15:48.980 --> 00:15:52.600
высоких показателей, а другие отстают. Действительно важно, достаточно ли последовательно

00:15:52.600 --> 00:15:56.180
маркируется ваш конфиденциальный контент, чтобы поведение Копайлот не основывалось только на

00:15:56.180 --> 00:16:00.260
догадках пользователей. Здесь не требуется совершенства, но необходим сопоставимый уровень

00:16:00.260 --> 00:16:04.580
контроля для каждого клиента в организации. Наконец, необходимо отслеживать скорость изменения

00:16:04.580 --> 00:16:07.540
прав доступа. Этот показатель показывает, действительно ли ваши усилия по исправлению

00:16:07.540 --> 00:16:10.800
ситуации дают результаты с течением времени. После завершения проекта по устранению проблем,

00:16:11.020 --> 00:16:14.420
как быстро эти разрешения начинают снова распространяться. Как часто эти широкие группы

00:16:14.420 --> 00:16:18.040
пользователей возвращаются в систему. Многие команды понимают это слишком поздно, потому что они оценили

00:16:18.040 --> 00:16:21.040
эффективность исправления один раз и предположили, что проблема решена навсегда. Это не так.

00:16:21.040 --> 00:16:24.460
Единственный важный показатель – это скорость, с которой система начинает давать сбои после того,

00:16:24.600 --> 00:16:28.280
как вы перестаете за ней следить. Это ваша операционная панель. Вам необходимо отслеживать

00:16:28.280 --> 00:16:32.800
снижение избыточного доступа, охват мониторинга, время внедрения политики, охват меток и изменение

00:16:32.800 --> 00:16:37.640
прав доступа. Ритм вашей отчетности также важен, как и сами цифры. Центр должен отвечать за панель

00:16:37.640 --> 00:16:41.580
управления для руководства, поскольку лидерам необходимо единое представление о всей ситуации.

00:16:41.740 --> 00:16:45.000
В то же время периферийные подразделения должны отвечать за исправление, поскольку фактическая работа

00:16:45.000 --> 00:16:48.880
должна выполняться там, где находятся границы клиентских учетных записей. Одна команда читает систему,

00:16:48.880 --> 00:16:53.140
а другая исправляет ее. Отслеживать эти показатели необходимо до расширения, а не после.

00:16:53.340 --> 00:16:57.540
Риск не ждет вашей следующей встречи или семинара по управлению. Он уже активен в каждом клиенте,

00:16:57.600 --> 00:17:00.940
где Копайлот может точно определить, что ваши текущие средства контроля по-прежнему позволяют

00:17:00.940 --> 00:17:04.580
ему видеть. Две закономерности, которые руководители постоянно упускают из виду. Я постоянно

00:17:04.580 --> 00:17:07.360
наблюдаю две конкретные закономерности в этой области, и обе они возникают из-за того,

00:17:07.460 --> 00:17:10.680
что руководители относятся к Копайлот как к запуску программного обеспечения, а не как к важному событию

00:17:10.680 --> 00:17:14.300
в области контроля. Первая закономерность начинается, когда организация внедряет Копайлот,

00:17:14.300 --> 00:17:18.420
не установив реальные базовые параметры доступа или не проверив доступ к SharePoint. В первый день

00:17:18.420 --> 00:17:23.140
внедрение выглядит идеально. Лицензии назначены, пользователи в восторге, и внутренние сообщения

00:17:23.140 --> 00:17:27.420
направлены на повышение производительности. Но затем обычные запросы начинают выводить материалы,

00:17:27.620 --> 00:17:31.840
которые технически были доступны все это время, но практически невидимы для среднего сотрудника.

00:17:32.000 --> 00:17:35.980
До появления и никто не тратил свой день на просмотр старых сайтов, устаревших папок или

00:17:35.980 --> 00:17:40.020
унаследованных разрешений в поисках того, чего видеть не следовало. Но теперь им это не нужно.

00:17:40.200 --> 00:17:44.220
Пользователь задает простой вопрос, получает краткое описание, и появляется файл.

00:17:44.340 --> 00:17:47.920
Возможно, это конфиденциальная информация отдела кадров, финансовые материалы или информация

00:17:47.920 --> 00:17:51.140
о сделках, которая должна была оставаться в строгой секретности. Не было ни взлома,

00:17:51.260 --> 00:17:55.360
ни вредоносного ПА, ни нарушения безопасности в традиционном смысле. Система просто использовала

00:17:55.360 --> 00:17:59.320
разрешения и состояние контента, которые уже были разрешены арендаторам. Именно в этот момент

00:17:59.320 --> 00:18:03.060
многие команды наконец понимают проблему. Искусственный интеллект не создал уязвимость.

00:18:03.060 --> 00:18:07.400
Он просто устранил препятствие, которое раньше скрывало ее. Как только это происходит в одном арендаторе,

00:18:07.520 --> 00:18:11.000
уверенность руководства обычно падает во всей организации, потому что никто не может с уверенностью

00:18:11.000 --> 00:18:14.880
сказать, где та же самая схема может появиться в следующий раз. Инцидент может выглядеть локальным,

00:18:15.080 --> 00:18:19.920
но ущерб доверию распространяется на всю компанию. Вторая схема менее очевидна, но не менее опасна.

00:18:20.060 --> 00:18:24.100
Компания устанавливает межарендные связи идентификации, слышит о возможности многопользовательских

00:18:24.100 --> 00:18:28.040
сценариев и предполагает, что ее операционная модель достаточно зрелая для широкого внедрения.

00:18:28.040 --> 00:18:31.980
На презентации это звучит как надежный план. В реальности же операционная деятельность

00:18:31.980 --> 00:18:35.800
становится сложной. Одна команда ожидает бесперебойной работы Капайлот во всех подключенных

00:18:35.800 --> 00:18:39.460
средах, другая — сопоставимой видимости, а третья предполагает, что одни и те же элементы

00:18:39.460 --> 00:18:43.200
управления будут сопровождать пользователя повсюду. Затем фактическое использование начинает

00:18:43.200 --> 00:18:46.360
выявлять неравномерное поведение, пробелы в аутентификации и слабые места в том,

00:18:46.460 --> 00:18:50.400
что действительно можно измерить. Проблема невнебрежности этих команд. Настоящая проблема в том,

00:18:50.520 --> 00:18:54.140
что они перевели понятие «подключенность» в понятие «гарантия». Это предположение создает

00:18:54.140 --> 00:18:58.120
ложное представление о соответствии требованиям. Руководство слышит слово «подключенность» и

00:18:58.120 --> 00:19:01.780
предполагает, что организация готова. Спустя несколько месяцев проверки контроля показывают,

00:19:01.920 --> 00:19:04.820
что поведение, доказательство и соблюдение требований различались гораздо больше,

00:19:04.820 --> 00:19:08.200
чем кто-либо хотел признать в начале. Теперь сравним это с более удачной схемой.

00:19:08.360 --> 00:19:12.020
Другая организация решает замедлить темпы, прежде чем масштабировать систему. Сначала они

00:19:12.020 --> 00:19:15.680
устанавливают базовый уровень меток, сначала проверяют широкий доступ и подтверждают видимость

00:19:15.680 --> 00:19:19.420
аудита, прежде чем делать что-либо еще. Они расширяют копайлот поэтапно не потому,

00:19:19.560 --> 00:19:23.600
что боятся внедрения, а потому что хотят, чтобы каждая волна давала полезные доказательства

00:19:23.600 --> 00:19:27.540
до начала следующей. В долгосрочной перспективе такая организация обычно работает быстрее,

00:19:27.660 --> 00:19:31.320
потому что ей не приходится постоянно объяснять неожиданности, исправлять уязвимый контент или

00:19:31.320 --> 00:19:35.040
спорить о том, что на самом деле означает «управляемый». В этом и заключается преимущество,

00:19:35.160 --> 00:19:38.940
которое упускают большинство руководителей. Хорошее управление не блокирует развертывание,

00:19:39.120 --> 00:19:44.080
оно снимает препятствия после завершения первой волны. Ловушка не в самом внедрении. Ловушка

00:19:44.080 --> 00:19:48.160
в неуправляемом внедрении в разных арендаторах, которые издалека кажутся связанными, но ведут себя

00:19:48.160 --> 00:19:52.500
совершенно по-разному при ближайшем рассмотрении. Решение, которое вам нужно принять, на самом деле

00:19:52.500 --> 00:19:57.060
очень простое. Вам нужно перейти к федеративной модели управления и по принципу «центр и периферия»,

00:19:57.060 --> 00:20:00.700
и вам нужно перестать путать переключение между арендаторами с реальным контролем. Вам следует

00:20:00.700 --> 00:20:04.360
приостановить расширение Копайлот в любом арендаторе, который не может доказать наличие логов,

00:20:04.500 --> 00:20:08.120
чрезмерного обмена информацией в отзывах и базового покрытия метр, и будет следовать за системой,

00:20:08.180 --> 00:20:11.400
которую вы фактически создадите, а не за организационной структурой, которой вы подчиняетесь.

00:20:11.400 --> 00:20:14.660
Если это изменило ваше представление об управлении многопользовательскими системами Копайлот,

00:20:14.760 --> 00:20:17.860
подпишитесь на меня, Мирку Петерса, в LinkedIn и поделитесь этим со своей командой,

00:20:17.980 --> 00:20:19.580
если вы сейчас сталкиваетесь с подобными проблемами.