WEBVTT

00:00:00.140 --> 00:00:06.040
Готовы к 10 дням погружения в Microsoft 365, Copilot и Azure и знакомство с людьми,

00:00:06.220 --> 00:00:12.280
формирующими будущие работы. В этом январе M365 CON возвращается, и мы расширяем границы.

00:00:12.460 --> 00:00:16.420
Присоединяйтесь к нам для участия в живых сессиях, демонстрациях реальных кейсов и получения

00:00:16.420 --> 00:00:20.360
практических знаний от MVP и экспертов со всего мира. Никаких общих слайдов,

00:00:20.440 --> 00:00:25.700
никакой пустой терминологии. Мы решаем реальные задачи, Copilot Studio, E-агенты,

00:00:25.700 --> 00:00:31.080
фабрик, безопасность, управление и автоматизация. Независимо от того, являетесь ли вы это

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

00:00:35.520 --> 00:00:39.880
За 10 полных дней вы сможете изучить множество технологий и наладить связи с глобальным

00:00:39.880 --> 00:00:44.700
сообществом. Смотрите в прямом эфире и применяйте практические идеи в своей организации.

00:00:44.940 --> 00:00:51.020
Январь 2027 года, 10 дней, одно сообщество Microsoft. Регистрация уже открыта.

00:00:51.020 --> 00:00:58.920
Зайдите на m365con.net и забронируйте свое место сегодня. Это m365con.net.

00:01:00.300 --> 00:01:04.740
Присоединяйтесь на m365con.net. Увидимся в прямом эфире в январе.

00:01:04.860 --> 00:01:08.380
Если вы думаете, что Copilot показывает только то, на что у вас уже есть права доступа,

00:01:08.480 --> 00:01:12.360
подумайте еще раз. Одно неверное разрешение в граф, и ваш и внезапно может выдать данные,

00:01:12.540 --> 00:01:16.720
которые не были одобрены комплайнс-отделом. Самое пугающее это, что вы можете даже не заметить,

00:01:16.720 --> 00:01:20.420
как это происходит. В этом видео я разберу реальные риски неконтролируемого доступа

00:01:20.420 --> 00:01:24.380
Copilot и покажу, как конфиденциальные файлы, финансовые отчеты и данные клиентов могут

00:01:24.380 --> 00:01:28.840
оказаться в чужих руках. Затем я покажу, как ограничить этот доступ с помощью разрешений

00:01:28.840 --> 00:01:33.860
граф, политик, DLP и перевью, не снижая продуктивность тех, кому доступ действительно нужен.

00:01:34.460 --> 00:01:39.940
Когда Copilot знает слишком много, младший сотрудник запрашивает заметки по проекту за прошлый квартал

00:01:39.940 --> 00:01:44.740
и получает некраткое содержание своей встречи, а подробный протокол закрытого заседания

00:01:44.740 --> 00:01:50.340
совета директоров, включая стратегические решения, сокращение бюджета и имена, которые не должны были

00:01:50.340 --> 00:01:55.240
попасть к этому человеку. Никаких оповещений об утечке, никаких предупреждений DLP просто и

00:01:55.240 --> 00:01:58.940
спокойно передал документ, которому не должен был иметь доступа. Это происходит потому,

00:01:59.140 --> 00:02:03.200
что Copilot не останавливается магическим образом на почтовом ящике или папке OneDrive пользователя.

00:02:03.400 --> 00:02:07.660
Его возможности ограничены лишь разрешениями, предоставленными через Microsoft Graph.

00:02:07.660 --> 00:02:12.300
А Graph — это не просто база данных, это центральная точка доступа практически ко всему

00:02:12.300 --> 00:02:18.760
контенту в Microsoft 365, SharePoint, сообщениям Teams, событиям календаря, OneNote и данным CRM,

00:02:18.760 --> 00:02:23.260
привязанным к тенанту. Все это проходит через Graph, если нужная дверь открыта. Это то,

00:02:23.400 --> 00:02:27.180
что упускают из виду многие администраторы. Существует распространенное мнение, что если я

00:02:27.180 --> 00:02:31.220
вошел в систему под своей учетной записью, Copilot увидит только то, что вижу я. Звучит разумно.

00:02:31.360 --> 00:02:36.100
Проблема в том, что сам Copilot часто работает с отдельным набором прав доступа приложения.

00:02:36.100 --> 00:02:40.740
Если эти разрешения шире прав вошедшего в систему пользователя, вы получаете и помощника,

00:02:40.960 --> 00:02:45.600
способного получить доступ к гораздо большему объему данных, чем человек за клавиатурой. И в некоторых

00:02:45.600 --> 00:02:50.400
случаях внедрение эти повышенные права предоставляются без каких-либо вопросов о целесообразности.

00:02:50.540 --> 00:02:54.920
Представьте финансового аналитика, работающего над квартальным прогнозом. Он запрашивает

00:02:54.920 --> 00:03:00.140
у Copilot текущие данные по продажам для 20 крупнейших клиентов. В рамках своих обычных полномочий

00:03:00.140 --> 00:03:04.700
он должен видеть показатели только по части этих клиентов. Но из-за того, как настроены области

00:03:04.700 --> 00:03:09.860
доступа граф в регистрации приложения Copilot и извлекает полный отчет о продажах с общего командного

00:03:09.860 --> 00:03:14.140
сайта, которому у аналитика никогда не было прямого доступа. С точки зрения конечного

00:03:14.140 --> 00:03:17.960
пользователя, ничего подозрительного нет. Но с точки зрения безопасности и соответствия

00:03:17.960 --> 00:03:21.920
нормативным требованиям, это утечка конфиденциальных данных. Разрешение граф API – это,

00:03:22.060 --> 00:03:26.620
по сути, парадная дверь к данным вашей организации. Microsoft разделяет их на делегированные

00:03:26.620 --> 00:03:31.040
разрешения, действующие от имени вошедшего пользователя, и разрешение уровня приложения,

00:03:31.200 --> 00:03:35.760
позволяющие приложению работать автономно. Для сценариев Copilot часто требуются делегированные

00:03:35.760 --> 00:03:40.480
разрешения на извлечение контента, но некоторые функции, например, создание сводки собрания Teams,

00:03:40.480 --> 00:03:44.840
в котором пользователь не участвовал, могут побудить администраторов утвердить разрешение на уровне

00:03:44.840 --> 00:03:49.260
приложения. И именно здесь кроется опасность. Разрешение уровня приложения игнорирует

00:03:49.260 --> 00:03:52.940
ограничения отдельных пользователей, если вы намерены не ограничите их область действия.

00:03:53.060 --> 00:03:57.120
Такие одобрения часто происходят на ранних этапах внедрения, и Т-администратор,

00:03:57.300 --> 00:04:02.360
тестирующий Copilot в тестовом арендаторе, может нажать «Принять» в запросе прав, просто чтобы завершить

00:04:02.360 --> 00:04:06.760
настройку, а затем перенести эту конфигурацию в рабочую среду, не оценив последствия.

00:04:06.760 --> 00:04:11.380
Будучи однажды предоставленными, эти широкие права сохраняются, пока кто-то активно их не

00:04:11.380 --> 00:04:16.500
пересмотрит. Со временем, по мере подключения новых источников данных к М365, охватка

00:04:16.500 --> 00:04:21.000
Copilot расширяется без принятия каких-либо осознанных решений. Это незаметное расползание прав,

00:04:21.220 --> 00:04:25.880
никакой драмы, никаких жалоб пользователей, просто постепенное расширение зоны доступа и…

00:04:25.880 --> 00:04:30.640
Проблема в том, что большинство команд безопасности не знают, какие функции Copilot требуют

00:04:30.640 --> 00:04:35.800
определенного уровня доступа к графу. Они могут увидеть чтение всех файлов в SharePoint и предположить,

00:04:35.800 --> 00:04:40.180
что оно ограничено контекстом пользователя, не осознавая, что это разрешение действует на

00:04:40.180 --> 00:04:45.060
уровне всего арендатора. Без сопоставления конкретных сценариев и с минимально необходимыми

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

00:04:50.100 --> 00:04:55.740
И чем шире эти права, тем больше потенциальный разрыв между ожидаемым и фактическим поведением

00:04:55.740 --> 00:05:01.140
системы. Также стоит помнить, что результаты работы Copilot не сопровождаются встроенным

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

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

00:05:10.820 --> 00:05:14.680
что это выходит за рамки вашего допуска. Из-за отсутствия прозрачности рискованной

00:05:14.680 --> 00:05:19.440
утечки легче маскируется под повседневные рабочие процессы. Главный вывод здесь заключается в том,

00:05:19.560 --> 00:05:23.700
что разрешение граф для развертывания, и это не просто очередная галочка в процессе внедрения.

00:05:23.700 --> 00:05:27.780
Это архитектурное решение, определяющее каждое взаимодействие, которое Copilot будет

00:05:27.780 --> 00:05:32.440
осуществлять в вашей сети. Относитесь к ним также, как к правилам Брандмауэра или настройкам VPN,

00:05:32.680 --> 00:05:37.120
обдуманно, тщательно проверяя и периодически пересматривая. Стандартные настройки позволяют

00:05:37.120 --> 00:05:41.280
быстро начать работу, но они также предполагают, что вы готовы к тому, что и будет охватывать

00:05:41.280 --> 00:05:45.160
гораздо больше данных, чем человек. Теперь, когда мы увидели, как легко границы доступа

00:05:45.160 --> 00:05:49.140
могут размываться, возникает вопрос, как обнаружить эти уязвимости до того, как они превратятся

00:05:49.140 --> 00:05:53.780
в серьезный инцидент. Найти утечки до того, как они произойдут. Если бы Copilot уже начал показывать

00:05:53.780 --> 00:05:57.720
данные, которые не должен, заметили бы вы это. Для большинства организаций честные

00:05:57.720 --> 00:06:02.500
ответы нет. Дело не в том, что информация будет опубликована на общедоступном сайте или

00:06:02.500 --> 00:06:07.240
разослана по списку рассылки. Утечка может незаметно проявиться в черновике документа,

00:06:07.500 --> 00:06:12.300
сводке или ответе, сгенерированном ИИ. И если никто не заметит ничего необычного,

00:06:12.540 --> 00:06:16.740
она пройдет незамеченной, не вызывая тревоги. Проблема с видимостью начинается с того,

00:06:16.920 --> 00:06:21.440
как устроено большинство систем мониторинга. Они настроены на традиционные действия,

00:06:21.680 --> 00:06:27.300
загрузку файлов, подозрительные места входа, массовые рассылки, а не на то, как и извлекает

00:06:27.300 --> 00:06:32.800
и компилирует информацию. Copilot не открывает файлы в обычном понимании. Он опрашивает источники

00:06:32.800 --> 00:06:37.600
данных через Microsoft Graph, компилирует результаты и представляет их в виде текста на естественном

00:06:37.600 --> 00:06:41.900
языке. Это означает, что стандартные отчеты о доступе к файлам могут выглядеть чистыми,

00:06:42.080 --> 00:06:45.680
в то время как и в фоновом режиме продолжает обращаться к конфиденциальным данным.

00:06:45.820 --> 00:06:50.880
Я видел ситуации, когда компания понимала, что что-то не так, только потому, что сотрудник случайно

00:06:50.880 --> 00:06:55.260
упоминал имя клиента, не входящего в компетенцию его отдела. Когда руководитель спрашивал,

00:06:55.260 --> 00:07:00.020
откуда он это узнал, ответом было, Copilot добавил это в мой черновик. Не было ни текета об инциденты,

00:07:00.220 --> 00:07:04.180
ни автоматического оповещения, лишь случайный комментарий, который заставил ИТ-отдел начать

00:07:04.180 --> 00:07:09.300
расследование. К тому времени, как они разобрались в ситуации, те же ответы и уже успели распространиться

00:07:09.300 --> 00:07:14.700
по нескольким командам. Microsoft 365 предоставляет инструменты для расследования таких сценариев,

00:07:14.920 --> 00:07:19.880
но нужно знать, где искать. Функция аудита в первью может детально записывать историю доступа

00:07:19.880 --> 00:07:24.980
Copilot к данным. Просто она не помечена большим ярким значком и в поиске по журналу

00:07:24.980 --> 00:07:29.900
аудита можно отфильтровать действия по специфическим операциям Copilot, таким как поисковый запрос

00:07:29.900 --> 00:07:34.320
или доступ к файлу и сузить поиск по идентификатору приложения, привязанному к вашему

00:07:34.320 --> 00:07:38.500
развертыванию Copilot. Это требует небольшой предварительной подготовки. Вам нужно подтвердить

00:07:38.500 --> 00:07:42.240
детали регистрации приложения в IntraID, чтобы иметь возможность идентифицировать этот трафик.

00:07:42.340 --> 00:07:46.400
После этого задача сводится к выявлению закономерностей. Если вы видите большой объем запросов

00:07:46.400 --> 00:07:50.760
от учетных записей, которые обычно не нуждаются в больших данных, например, стажер делает 10 сложных

00:07:50.760 --> 00:07:55.020
поисковых запросов в час, это стоит проверить. То же самое касается внезапных всплесков появления

00:07:55.020 --> 00:07:58.620
контента с грифом «Конфиденциально» в отделах, которые обычно с ним не работают.

00:07:58.760 --> 00:08:03.900
Первью может помечать активность с метками, поэтому если запрос к Copilot задействует документ

00:08:03.900 --> 00:08:07.900
с меткой, вы увидите это в журналах, даже если и не выдал полный текст.

00:08:08.020 --> 00:08:11.940
Проверки доступа на основе ролей – еще один способ связать факты воедино.

00:08:12.180 --> 00:08:16.840
Сопоставляя список реальных пользователей Copilot с типами данных, с которыми они работают,

00:08:16.840 --> 00:08:21.140
можно заранее выявить потенциальные несоответствия. Возможно, финансовый отдел активно

00:08:21.140 --> 00:08:25.100
использует Copilot для отчетов, это логично. Но почему несколько аккаунтов отдела маркетинга

00:08:25.100 --> 00:08:29.580
обращаются к зарплатным ведомостям через запросы к И? Такие проверки дают более широкую картину,

00:08:29.840 --> 00:08:34.540
выходящую за рамки отдельных событий в журнале Аудита. Проблема в том, что стандартные панели

00:08:34.540 --> 00:08:40.420
мониторинга здесь мало помогут. Они объединяют всю активность M365 в широкие категории,

00:08:40.600 --> 00:08:44.800
из-за чего специфическое поведение и может смешиваться с обычными операциями.

00:08:44.800 --> 00:08:49.880
Не создавая пользовательские фильтры или отчеты, ориентированные на ID вашего приложения

00:08:49.880 --> 00:08:54.860
Copilot и шаблоны использования, вы по сути пытаетесь найти крупицы песка в море данных.

00:08:55.040 --> 00:08:59.600
Вам нужна целенаправленная прозрачность, а не просто больше данных. Речь не о создании культуры

00:08:59.600 --> 00:09:04.180
слежки, а о том, чтобы точно знать, что именно извлекает ваш И. Правильный подход к ведению

00:09:04.180 --> 00:09:09.100
журналов позволяет ответить на три критических вопроса. Что извлек Copilot? Кто запустил запрос? И

00:09:09.100 --> 00:09:13.280
соответствовало ли это действие вашим текущим политикам безопасности и соответствия требованиям?

00:09:13.280 --> 00:09:18.020
Эти ответы позволяют решать проблемы точечно, будь то изменение прав доступа,

00:09:18.200 --> 00:09:23.560
уточнение правил DLP или пересмотр ролей. Без этой ясности приходится гадать,

00:09:23.800 --> 00:09:29.300
а гадание – это не стратегия безопасности. Поэтому вместо того, чтобы ждать случайного

00:09:29.300 --> 00:09:35.240
комментария, стоит потратить время на структурирование мониторинга, чтобы следы Copilot были видны и

00:09:35.240 --> 00:09:40.660
очлеживаемы. Таким образом, любой признак избыточного доступа к данным становится контролируемым

00:09:40.660 --> 00:09:46.280
событиям, а не сюрпризом. Знать, где находятся утечки – это только первый шаг. Настоящая цель – сделать

00:09:46.280 --> 00:09:51.160
так, чтобы они не повторились. И именно здесь нужны правильные защитные механизмы. Защитные механизмы,

00:09:51.300 --> 00:09:56.060
которые действительно работают. DLP предназначен не только для отлова писем с номерами кредитных

00:09:56.060 --> 00:10:02.060
карт. В контексте Copilot это может быть растяжка, которая не даст конфиденциальным данным попасть

00:10:02.060 --> 00:10:07.720
в ответ и, который затем вставят в чат-тимс или экспортируют в документ за пределы вашего тенанта.

00:10:07.720 --> 00:10:15.860
Это все тот же инструмент в Microsoft 365, но для настройки его под сценарией и требуется другой

00:10:15.860 --> 00:10:21.780
подход. Разрыв в том, что DLP-политики большинства организаций по-прежнему опираются на старые

00:10:21.780 --> 00:10:27.200
трикгеры – вложения в письмах, скачивание файлов на USB-накопители, копирование данных в

00:10:27.200 --> 00:10:31.520
несанкционированные приложения. Copilot не активирует эти правила по умолчанию,

00:10:31.520 --> 00:10:37.060
потому что он не пересылает файлы. Он генерирует контент на лету. Если вы попросите Copilot

00:10:37.060 --> 00:10:42.100
предоставить полный список клиентов с пометкой «Ограниченный доступ», и он извлечет его из

00:10:42.100 --> 00:10:47.020
маркированного документа, данные могут быть переданы, не затронув традиционные условия DLP.

00:10:47.020 --> 00:10:52.360
Вот почему запросы и ответы от него должны быть явно включены в область действия вашей политики

00:10:52.360 --> 00:10:57.660
DLP. Практический пример. Предположим, ваша политика запрещает экспорт определенных

00:10:57.660 --> 00:11:02.580
контрактных документов за пределы защищенной среды. Пользователь может попросить Copilot извлечь

00:11:02.580 --> 00:11:07.680
ключевые пункты и вставить их в PowerPoint. Если ваши правила DLP не очлеживают контент,

00:11:07.680 --> 00:11:12.060
созданный и эти конфиденциальные материалы окажутся в незащищенном файле.

00:11:12.060 --> 00:11:17.760
Расширив проверку DLP на выходные данные Copilot, вы сможете заблокировать сохранение этого

00:11:17.760 --> 00:11:23.740
PowerPoint в неуправляемом месте или передачу его внешнему гостю в Teams. Настройка этого процесса в

00:11:23.740 --> 00:11:29.820
Microsoft 365 несложна, но требует тщательного подхода. Сначала в портале «Соответствие Microsoft

00:11:29.820 --> 00:11:34.480
Первью» перейдите в раздел «Защиты от утечки данных» и создайте новую политику. При выборе

00:11:34.480 --> 00:11:40.280
расположений для применения политики включите Exchange, SharePoint, OneDrive и, что важно, Teams,

00:11:40.280 --> 00:11:45.300
так как Copilot может выводить данные в любой из них. Затем определите условия. Вы можете

00:11:45.300 --> 00:11:49.600
использовать встроенные типы конфиденциальной информации, такие как номера финансовых счетов,

00:11:49.720 --> 00:11:53.740
или пользовательские, которые обнаруживают внутренние коды ваших проектов. А если вы

00:11:53.740 --> 00:11:58.960
последовательно используете метки конфиденциальности, вы также можете настроить срабатывание условия при

00:11:58.960 --> 00:12:03.060
появлении помеченного контента в конечном файле при его сохранении или отправке.

00:12:03.220 --> 00:12:08.280
Наконец, настройте действия, блокируйте общий доступ, показывайте пользователю подсказку о политике

00:12:08.280 --> 00:12:12.420
или требуйте обоснования для продолжения действий. Сами метки конфиденциальности играют

00:12:12.420 --> 00:12:17.260
ключевую роль в работе этого механизма. В контексте и метка – это метадонные, которые Copilot

00:12:17.260 --> 00:12:23.560
может считывать так же, как и любая другая служба М365. Если документ с грифом строго конфиденциально

00:12:23.560 --> 00:12:27.620
имеет метку, ограничивающую доступ и использование, Copilot будет соблюдать

00:12:27.620 --> 00:12:32.000
эти ограничения при генерации ответов, при условии, что параметры защиты меток применяются

00:12:32.000 --> 00:12:36.660
единообразно во всех используемых приложениях. Если и пытается использовать контент с меткой

00:12:36.660 --> 00:12:41.500
в неразрешенной области действия, связанная с этой меткой политика DLP может либо предотвратить

00:12:41.500 --> 00:12:46.880
действие, либо пометить его для проверки. Без этой связи с точки зрения комплаенса метка является

00:12:46.880 --> 00:12:51.180
лишь формальностью. Одна из самых распространенных ошибок конфигурации, с которыми я сталкиваюсь,

00:12:51.300 --> 00:12:56.100
это оставление политик DLP без учета сценариев использования и. Правила существуют, но нет связи с

00:12:56.100 --> 00:13:00.140
выходными данными Copilot, поскольку администраторы не рассматривают его как отдельный канал.

00:13:00.320 --> 00:13:05.200
Это создает слепую зону, где конфиденциальные термины в сгенерированном ответе не проверяются,

00:13:05.420 --> 00:13:09.260
хотя такой же текст в электронном письме был бы заблокирован. Чтобы исправить это,

00:13:09.420 --> 00:13:14.480
вы должны рассматривать рабочие процессы с использованием и как одно из расположений для DLP и

00:13:14.480 --> 00:13:19.520
отслеживать их наравне со всем остальным. Если DLP и метки конфиденциальности настроены правильно

00:13:19.520 --> 00:13:24.460
и взаимосвязаны, Copilot остается полезным инструментом, не создавая проблем с соответствием

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

00:13:28.940 --> 00:13:33.820
наборы данных, при этом автоматически соблюдая те же ограничения, что и в письмах или сообщениях

00:13:33.820 --> 00:13:38.060
Teams. Пользователи получают преимущество и помощника, а защитные механизмы предотвращают

00:13:38.060 --> 00:13:41.980
утечку конфиденциальной информации. Преимущество здесь заключается не только в предотвращении

00:13:41.980 --> 00:13:46.140
случайного разглашения данных. Речь идет о том, чтобы позволить технологии работать в рамках

00:13:46.140 --> 00:13:50.740
четких правил. Таким образом, вам не придется прибегать к тотальным запретам, которые разочаровывают

00:13:50.740 --> 00:13:55.120
сотрудников и препятствуют внедрению. Вы можете настроить параметры так, чтобы отдел

00:13:55.120 --> 00:14:00.180
маркетинга мог проводить мозговые штурмы, финансовый отдел, анализ, а HR – создавать

00:14:00.180 --> 00:14:05.580
руководство по адаптации, каждый в своей зоне доступа. Однако контроль выходных данных – это лишь

00:14:05.580 --> 00:14:11.420
часть задачи. Чтобы полностью снизить риски, нужно сначала решить, кому и к каким возможностям

00:14:11.420 --> 00:14:17.160
и предоставить доступ. Универсальный подход здесь не работает. Должны ли стажер по маркетингу

00:14:17.160 --> 00:14:22.040
и финансовый директор обладать одинаковыми привилегиями в Капайлот? Эта мысль звучит

00:14:22.040 --> 00:14:27.580
абсурдно, но во многих компаниях настроена именно так. Капайлот включают для всех с одинаковыми

00:14:27.580 --> 00:14:32.360
правами доступа, потому что это быстрее и проще, чем настраивать конфигурации для каждой роли.

00:14:32.520 --> 00:14:36.820
Обратная сторона в том, что доступ и соответствует максимально открытому сценарию,

00:14:36.880 --> 00:14:40.940
а не потребностям конкретных ролей. Именно здесь на помощь приходят группы доступа к Капайлот,

00:14:41.100 --> 00:14:44.820
основанные на ролях. Вместо того, чтобы считать всех пользователей взаимозаменяемыми,

00:14:44.820 --> 00:14:49.200
вы адаптируете возможности и к информации, и рабочим процессам, необходимым для конкретных

00:14:49.200 --> 00:14:53.720
ролей. Маркетингу может потребоваться доступ к рекламным материалам и брендбукам,

00:14:54.000 --> 00:14:59.140
но не к сырым финансовым моделям. Финансовому отделу нужны эти модели, но им не нужны планы

00:14:59.140 --> 00:15:03.700
разработки продуктов на ранних стадиях. Смысл не в том, чтобы сделать Капайлот менее полезным,

00:15:03.820 --> 00:15:07.740
а в том, чтобы его возможности соответствовали рабочим задачам каждого сотрудника. Риски при

00:15:07.740 --> 00:15:11.920
предоставлении универсального доступа выше, чем кажется большинству команд. Капайлот работает,

00:15:11.920 --> 00:15:17.880
используя данные, которые уже хранятся в вашей среде Microsoft 365. Если у всех сотрудников есть

00:15:17.880 --> 00:15:22.640
равный доступ к ИИ, технология может разрушить барьеры, которые вы намеренно выстраивали.

00:15:22.800 --> 00:15:28.260
Именно так помощники HR могут случайно наткнуться на финансовые отчеты, а операционный менеджер

00:15:28.260 --> 00:15:33.520
запросить у Капайлот план выпуска продуктов на следующий год и получить еще неутвержденные детали

00:15:33.520 --> 00:15:38.580
дизайна. В моменте это не выглядит как утечка, но риск нарушения конфиденциальности вполне реален.

00:15:38.580 --> 00:15:42.660
Правильная модель доступа начинается с сопоставления рабочих функций с потребностями в данных,

00:15:42.840 --> 00:15:46.780
не только с приложениями, которые используют люди, но и с глубиной и конфиденциальностью данных,

00:15:46.900 --> 00:15:51.720
с которыми они работают ежедневно. Вы можете обнаружить, что 70% запросов вашего отдела продаж

00:15:51.720 --> 00:15:56.080
Капайлот касаются истории отношений с клиентами, в то время как менее 5% затрагивают

00:15:56.080 --> 00:16:00.540
высококонфиденциальные договоры. Это означает, что можно безопасно ограничить использование ИИ

00:16:00.540 --> 00:16:05.000
определенными библиотеками SharePoint, закрыв доступ к остальным. Проведите эту работу для каждого

00:16:05.000 --> 00:16:09.320
отдела, и вы увидите общие закономерности. Когда вы определите потребности каждой группы,

00:16:09.460 --> 00:16:14.180
Microsoft IntraID, который многие все еще называют Azure AD, станет вашим инструментом контроля.

00:16:14.320 --> 00:16:20.020
Вы создаете группы безопасности, соответствующие ролям, а затем назначаете разрешение Капайлот на

00:16:20.020 --> 00:16:24.900
уровне групп. Это может означать предоставление определенных областей графапи только участникам

00:16:24.900 --> 00:16:28.940
финансовой группы Капайлот, в то время как у маркетинговой группы будет другой набор.

00:16:29.100 --> 00:16:33.760
Доступ к конфиденциальным сайтам, каналам Teams или конкретным папкам OneDrive может регулироваться

00:16:33.760 --> 00:16:38.120
по той же модели. Сила этого подхода проявляется при его сочетании с элементами управления,

00:16:38.280 --> 00:16:41.940
которые мы уже рассмотрели. Разрешения графа определяют внешние границы того,

00:16:42.180 --> 00:16:46.620
к чему Капайлот может получить технический доступ. Политики DLP отшлеживают выходные данные

00:16:46.620 --> 00:16:51.700
и на предмет наличия конфиденциального контента. Ролевые группы выступают промежуточным звеном,

00:16:51.880 --> 00:16:56.340
гарантируя, что разрешения графа не будут избыточными для менее ответственных ролей,

00:16:56.540 --> 00:17:01.640
а DLP не придется блокировать то, что можно было предотвратить ограничением источников ввода.

00:17:01.640 --> 00:17:06.300
Но, как и любую систему, этот подход можно довести до абсурда. Возникает соблазн создавать

00:17:06.300 --> 00:17:10.960
микрогруппы для каждого отдельного сценария. Финансовый аналитик Капайлот с правами на отчетность

00:17:10.960 --> 00:17:15.200
или маркетинговый стажер без доступа к Teams так можно получить десятки вариантов.

00:17:15.340 --> 00:17:19.280
Такая детализация может выглядеть точной на бумаге, но в реальной работе это превращается в

00:17:19.280 --> 00:17:23.260
головную боль при администрировании. Пользователи меняют должности, проекты завершаются,

00:17:23.460 --> 00:17:27.720
подрядчики приходят и уходят. Если модель групп слишком жесткая, ваш ИТ-персонал будет тратить

00:17:27.720 --> 00:17:31.360
больше времени на исправление проблем с доступом, чем на реальное повышение безопасности.

00:17:31.360 --> 00:17:35.800
Главная цель – достичь баланса. Нескольких четких и хорошо определенных ролевых групп будет

00:17:35.800 --> 00:17:39.840
достаточно для большинства задач без создания административного хаоса. Группе финансового

00:17:39.840 --> 00:17:44.280
директора нужны широкие аналитические возможности, но строгий контроль над обменом результатами.

00:17:44.500 --> 00:17:49.460
Группа стажеров получает ограниченный доступ к данным, но достаточный функционал для участия в

00:17:49.460 --> 00:17:53.800
реальной работе. Руководители отделов занимают промежуточное положение, а ИТ-отдел сохраняет

00:17:53.800 --> 00:17:57.260
возможность вносить коррективы, когда для специальных проектов требуется исключение.

00:17:57.260 --> 00:18:00.820
Вы не пытаетесь заблокировать все до такой степени, что это вызывает лишь разочарование.

00:18:01.000 --> 00:18:04.640
Вы делаете работу каждого пользователя с ирелевантной, безопасной и соответствующей

00:18:04.640 --> 00:18:08.420
политике компании. Когда все настроено верно, преимущества проявляются очень быстро.

00:18:08.560 --> 00:18:12.260
Пользователей больше не удивляют данные, которые им предоставляет Капайлот, потому что они

00:18:12.260 --> 00:18:16.620
всегда находятся в рамках их сферы ответственности. У групп комплаенса становится меньше инцидентов

00:18:16.620 --> 00:18:21.580
для расследования, так как случайные утечки данных исключены. А ИТ-специалисты могут спокойно

00:18:21.580 --> 00:18:26.840
внедрять новые функции Капайлот, не опасаясь, что глобальное развертывание незаметно разрушит

00:18:26.840 --> 00:18:31.580
все выстроенные ими границы данных. Благодаря совместной работе контроля доступа и защитных

00:18:31.580 --> 00:18:36.520
механизмов, вы существенно снижаете свой профиль рисков. Но даже отлично разработанная модель важна

00:18:36.520 --> 00:18:40.780
лишь тогда, когда вы можете доказать ее эффективность как самим себе, так и тем, кто придет с

00:18:40.780 --> 00:18:45.380
проверкой. Подтверждение соответствия требованиям без замедления работы. Соблюдение нормативов – это не

00:18:45.380 --> 00:18:49.820
просто имитация безопасности, это доказательства, которые удовлетворят аудиторов. Политики и защитные

00:18:49.820 --> 00:18:53.700
механизмы – это хорошо, но если вы не можете точно показать, что происходило с данными при

00:18:53.700 --> 00:18:58.160
использовании ИИ, вам остается лишь делать заявление, а не доказывать их. Среда Капайлот, готовая

00:18:58.160 --> 00:19:03.580
к аудиту, означает, что каждое взаимодействие от запроса пользователя до извлечения данных ИИ можно

00:19:03.580 --> 00:19:08.460
объяснить и подтвердить проверяемым журналом событий. Сложность в том, что многие компании считают

00:19:08.460 --> 00:19:13.900
себя защищенными, так как проходят внутренние проверки. Эти проверки часто лишь подтверждают наличие

00:19:13.900 --> 00:19:19.400
контроля и несколько тестовых сценариев, но не всегда требуют той детализации, которую ожидают

00:19:19.400 --> 00:19:25.060
внешние аудиторы. Когда сторонний оценщик запрашивает журнал всего конфиденциального контента,

00:19:25.320 --> 00:19:30.740
к которому обращался Капайлот за прошлый квартал, а также информацию о том, кто и зачем его запрашивал,

00:19:30.960 --> 00:19:36.360
нередко обнаруживаются пробелы. Либо журналы неполные, либо они вовсе опускают события, связанные с ИИ,

00:19:36.480 --> 00:19:41.120
потому что те изначально не были соответствующим образом помечены. Именно здесь Microsoft Perview

00:19:41.120 --> 00:19:45.880
может сыграть огромную роль. Его возможности по обеспечению соответствия – это не просто применение

00:19:45.880 --> 00:19:50.440
меток и политик DLP. Они также собирают необходимые вам доказательства для форензики.

00:19:50.620 --> 00:19:55.000
В контексте Капайлот-системы Perview может записывать каждый соответствующий запрос на доступ к данным,

00:19:55.160 --> 00:19:59.520
личность пользователя и источник данных. Она также может сопоставлять эти события с моделями

00:19:59.520 --> 00:20:04.500
перемещения данных, например, если конфиденциальные файлы упоминаются в черновиках, сводках или

00:20:04.500 --> 00:20:09.640
экспортах, не полагаясь на отчеты самого ИИ. Показатель соответствия в Perview – это не просто метрика

00:20:09.640 --> 00:20:14.380
для галочки. Это моментальный снимок того, как ваша среда соответствует рекомендуемым Microsoft элементам

00:20:14.380 --> 00:20:19.120
управления, включая те, что напрямую ограничивают риски, связанные с ИИ. Более строгая гигиена

00:20:19.120 --> 00:20:24.040
разрешений граф, более жесткие конфигурации DLP и правильно настроенные ролевые группы – все это

00:20:24.040 --> 00:20:28.400
влияет на этот показатель. А поскольку показатель обновляется по мере внесения изменений,

00:20:28.560 --> 00:20:33.140
вы можете почти в реальном времени видеть, как улучшения в управлении и повышают ваш уровень

00:20:33.140 --> 00:20:38.800
соответствия. Представьте себе регуляторную проверку, где вам нужно оправдать появление определенных

00:20:38.800 --> 00:20:43.480
данных клиентов в отчете, созданном Капайлот. Без структурированного протоколирования такой

00:20:43.480 --> 00:20:47.500
разговор превращается в гадание. При правильно настроенном Perview вы можете показать запрос на

00:20:47.500 --> 00:20:51.620
доступ в журнале аудита, указать роль и разрешение, которые его санкционировали, и доказать,

00:20:51.800 --> 00:20:55.520
что вывод данных оставался в рамках утвержденных каналов. Это гораздо более легкий разговор,

00:20:55.760 --> 00:20:59.480
чем лихорадочные попытки объяснить недокументированное событие. Главное – сделать

00:20:59.480 --> 00:21:04.740
отчетность о соответствии частью вашего обычного цикла ИТ-управления, а не просто спецпроектом перед

00:21:04.740 --> 00:21:09.480
аудитом. Автоматизированная отчетность здесь очень помогает. Perview может генерировать периодические

00:21:09.480 --> 00:21:14.100
отчеты о совпадениях с политиками защиты информации, инцидентах DLP и использовании меток

00:21:14.100 --> 00:21:19.260
конфиденциальности. Когда эти отчеты ежемесячно поступают в рабочую область вашей группы управления,

00:21:19.460 --> 00:21:24.760
вы создаете базовый уровень активности ИИ, который легко проверять. Любая аномалия сразу выделяется

00:21:24.760 --> 00:21:28.980
на фоне исторических данных. Функции экономии времени имеют большое значение. Например,

00:21:29.180 --> 00:21:33.240
Perview поставляется с готовыми отчетами, которые подсвечивают все инциденты с маркированным

00:21:33.240 --> 00:21:37.860
контентом, сгруппированные по расположению или типу активности. Если сеанс Капайлот вывел

00:21:37.860 --> 00:21:43.340
конфиденциальный документ, а система DLP отреагировала на это, инцидент уже появится в отчете

00:21:43.340 --> 00:21:48.000
без создания пользовательских запросов с нуля. Вы можете углубиться в запись для получения

00:21:48.000 --> 00:21:53.620
подробностей, но основная работа по сбору и классификации уже выполнена. Еще одна эффективная

00:21:53.620 --> 00:22:00.060
функция – интеграция аудита Perview с данными о доступе на основе ролей в Microsoft 365. Поскольку

00:22:00.060 --> 00:22:05.580
Perview распознает группы IntraID, он может разделять журналы доступа по типам ролей. Это значит,

00:22:05.580 --> 00:22:09.540
что вы можете быстро отвечать на конкретные вопросы. Например, покажи все случаи,

00:22:09.720 --> 00:22:14.020
когда отдел маркетинга получал доступ к финансовым данным через Капайлот за последние 90 дней.

00:22:14.800 --> 00:22:19.380
Это возможность фильтрации как по роли, так и по классификации данных именно то,

00:22:19.660 --> 00:22:24.300
что ищут внешние аудиторы. Если задуматься, соответствие требованиям на таком уровне – это не

00:22:24.300 --> 00:22:28.380
абуза. Это защитный механизм, подтверждающий, что ваша модель управления работает на практике.

00:22:28.540 --> 00:22:31.860
Это также избавляет от стресса при проверках, потому что вам не приходится собирать данные по крупицам.