[{"data":1,"prerenderedAt":194},["ShallowReactive",2],{"publication:ru:P182":3},{"meta":4,"copy":17,"relatedArticles":153,"terms":186,"term":187,"resourceParent":188,"glossaryParent":191},{"id":5,"path":6,"kind":7,"keyword":8,"title":9,"seoTitle":10,"description":11,"incoming":12,"updated":15,"preparedOn":16},"P182","\u002Fblog\u002Fmicrosoft-365-security-checklist","article","чек-лист безопасности Microsoft 365","Чек-лист безопасности Microsoft 365 для малого бизнеса","Безопасность Microsoft 365: чек-лист для бизнеса","Проверка Microsoft 365: владельцы и роли, MFA, аварийный доступ, почта, приложения и журналы. Как учитывать лицензии, исключения и приемку настроек.",[13,14],"\u002Fservices\u002Fcorporate-email","\u002Fservices\u002Faccess-2fa-audit","2026-07-04","2026-10-31",{"intro":18,"sections":19,"checklistTitle":108,"checklist":109,"faq":116,"sources":126,"links":131,"cta":148},"Чек-лист безопасности Microsoft 365 проверяет, кто управляет организацией, как защищены вход и восстановление, какие приложения и почтовые правила имеют доступ к данным и какие события реально видны администратору. Начните с лицензий, источника учетных записей и границ проверки. Затем собирайте подтверждения, исправляйте приоритетные недостатки и проверяйте работу бизнеса после каждого согласованного изменения.",[20,26,36,46,87,97],{"title":21,"paragraphs":22},"Определите tenant, источник идентичности и область работы",[23,24,25],"Зафиксируйте организацию Microsoft 365, домены, лицензии, административные роли, внешних пользователей и критичные процессы. Уточните, управляются ли учетные записи только в облаке или связаны с локальной инфраструктурой и федерацией. Место изменения пароля и политики зависит от этой архитектуры; универсальная инструкция для любого tenant может оказаться неверной.","Согласуйте проверяемые сервисы и ответственных: почта, файлы, приложения, доступ администратора, устройства или отдельные группы. Указание Microsoft 365 на счете не означает, что доступны все функции Entra, Defender и хранения журналов. В реестре доказательств фиксируют фактическую лицензию, разрешения проверяющего и недоступные области.","Проверка начинается с разрешенного чтения конфигурации и выявления зависимостей. Не включайте массовые ограничения до согласования с владельцем бизнеса. Признаки активного захвата аккаунта переводят в отдельный процесс реагирования: плановая последовательность чек-листа не должна задерживать ограничение подтвержденного вредоносного доступа.",{"title":27,"paragraphs":28,"sources":32},"Администраторы и аварийный доступ должны быть защищены",[29,30,31],"Сопоставьте назначения привилегированных ролей с реальными обязанностями и владельцами. Для повседневной работы используйте отдельные обычные учетные записи. Общий логин администратора затрудняет ответственность и восстановление; права бывшего подрядчика не становятся допустимыми только потому, что давно не использовались.","Аварийный доступ проектируют по актуальному руководству Microsoft: независимые облачные учетные записи, сильная устойчивая к фишингу аутентификация, контролируемое хранение, мониторинг и регулярная проверка. Путь восстановления должен отличаться по зависимостям от обычного входа. Исключение из блокирующей политики не означает отключение всей защиты MFA.","Назначьте владельцев средств восстановления и проверьте доступ с предназначенного доверенного устройства. Тест проводят по согласованному сценарию, сохраняя текущий рабочий доступ. Пароли, ключи и коды восстановления не включают в обычный отчет или форму заявки; фиксируют результат и способ защищенного хранения, а не сами секреты.",[33],{"label":34,"url":35},"Microsoft Entra: защищенный аварийный доступ","https:\u002F\u002Flearn.microsoft.com\u002Fen-us\u002Fentra\u002Fidentity\u002Frole-based-access-control\u002Fsecurity-emergency-access",{"title":37,"paragraphs":38,"sources":42},"Политики входа: проверяйте охват, исключения и восстановление",[39,40,41],"Security defaults предоставляет базовые меры защиты, а Conditional Access позволяет строить более детальные политики при наличии нужных возможностей. Выбор зависит от фактической лицензии, архитектуры и требований компании. Нельзя отключать действующую защиту только потому, что планируется другая политика: сначала подтверждают непрерывность охвата и приемку.","Сопоставьте, к каким пользователям и приложениям применяется требование, какие группы исключены и почему. Успешная регистрация метода не равна доказанному требованию MFA для нужного сценария входа. Проверяйте разрешенным тестом обычного пользователя, администратора и согласованный резервный путь.","Разберитесь с устаревшими способами входа и сервисными зависимостями до их ограничения. Изменение, полезное для интерактивного пользователя, может затронуть сканер, интеграцию или уведомления сайта. Подготовьте поддерживаемый маршрут замены и владельца тестирования вместо бессрочного исключения без контроля.",[43],{"label":44,"url":45},"Microsoft Entra: Security defaults и границы политики","https:\u002F\u002Flearn.microsoft.com\u002Fen-us\u002Fentra\u002Ffundamentals\u002Fsecurity-defaults",{"title":47,"paragraphs":48,"table":52,"sources":83},"Почтовые правила, делегирование и приложения",[49,50,51],"Проверьте разрешенные переадресации, правила ящиков, делегатов, почтовые маршруты и рабочие адреса. Разделяйте пользовательский ящик, общий ящик и сервисную отправку. Для каждого внешнего назначения нужна подтвержденная деловая причина, владелец и понимание того, какие данные уходят за пределы организации.","Составьте реестр приложений и предоставленных им полномочий. Согласие пользователя, административные разрешения и доступ самой интеграции могут иметь разные области действия. Чтение данных тоже является доступом, а знакомое имя приложения не доказывает, что текущие полномочия нужны. Удаление прав согласуют с владельцем процесса.","SPF, DKIM и DMARC проверяют отдельно для рабочих отправителей, включая формы сайта и CRM. Защищенный вход администратора не подтверждает согласование почтового домена. И наоборот, корректная подпись письма не исключает захват настоящего ящика или вредоносное правило пересылки.",{"caption":53,"headers":54,"rows":58},"Реестр доказательств для проверки Microsoft 365",[55,56,57],"Область","Свидетельство","Критерий приемки",[59,63,67,71,75,79],[60,61,62],"Роль администратора","Назначение, владелец и рабочая причина","Объем прав соответствует задаче",[64,65,66],"Политика входа","Область, исключения и контрольный вход","Защита применяется к нужным сценариям",[68,69,70],"Аварийный доступ","Независимость, сильная защита и проверка","Восстановление работает и контролируется",[72,73,74],"Пересылка или делегат","Назначение, получатель и подтверждение владельца","Необоснованный доступ устранен согласованно",[76,77,78],"Приложение","Разрешения, учетная запись и зависимость","Права минимальны и бизнес-процесс проверен",[80,81,82],"Почтовый домен","Реальные сообщения каждого потока","Аутентификация и согласование подтверждены",[84],{"label":85,"url":86},"Microsoft: реагирование на захват облачного ящика","https:\u002F\u002Flearn.microsoft.com\u002Fen-us\u002Fdefender-office-365\u002Fresponding-to-a-compromised-email-account",{"title":88,"paragraphs":89,"sources":93},"Журналы и отзыв доступа: учитывайте реальные пределы",[90,91,92],"Запишите доступные журналы, срок хранения и права проверяющего. Проверьте, кто замечает новые привилегии, подозрительные входы и изменения критичных настроек. Отсутствие события в недоступном интервале не является доказательством, что нарушения не было. Наблюдение и реакция должны иметь назначенного владельца.","Пароль, запрет новых входов, отзыв токенов обновления и сеансы приложений являются разными элементами управления. Уже выданный токен или собственный сеанс приложения может вести себя иначе. Entra не может напрямую отозвать каждый сеанс, созданный сторонним приложением; срок прекращения доступа нельзя обещать как мгновенный и универсальный.","Условный пример: сотрудник уволен, вход в учетную запись закрыт, но отдельная интеграция продолжает работать со своими полномочиями. Следующий шаг: установить тип доступа и владельца приложения, согласовать отзыв, проверить сохранение нужных данных и повторить тест. Это учебный сценарий, а не выполненный отзыв в чужой организации.",[94],{"label":95,"url":96},"Microsoft Entra: отзыв доступа и ограничения сеансов","https:\u002F\u002Flearn.microsoft.com\u002Fen-us\u002Fentra\u002Fidentity\u002Fusers\u002Fusers-revoke-access",{"title":98,"paragraphs":99,"steps":102},"Порядок улучшений и итоговая приемка",[100,101],"Приоритет зависит от подтвержденной экспозиции, важности данных и возможности восстановления. Сначала разбирают необоснованные привилегии, незащищенный доступ и отсутствующий резерв. Затем планируют зависимые изменения, тестовую группу и контроль рабочих процессов. Повышение строгости без проверки бизнеса не считается завершенной работой.","CyberFixCrew является израильской компанией, обслуживающей русскоязычный бизнес по всему миру. Практический израильский опыт работы с сайтами и цифровой инфраструктурой помогает связать учетные записи, почту, DNS и интеграции в одну проверяемую область. Конкретные действия, лицензии и доступы согласуются заранее; страница не заявляет статус партнера Microsoft, круглосуточный SOC или сертификационный аудит.",[103,104,105,106,107],"Зафиксировать лицензию, архитектуру идентичности и владельцев.","Собрать исходные доказательства и ограничения видимости.","Согласовать приоритеты и способ восстановления до изменений.","Провести ограниченное изменение и контроль рабочих сценариев.","Передать подтвержденные результаты, оставшиеся риски и ответственных.","Что проверить в Microsoft 365",[110,111,112,113,114,115],"Определены tenant, лицензии и источник учетных записей.","Привилегированные роли персональные и обоснованы.","MFA, исключения и защищенный аварийный доступ проверены.","Правила, пересылки, делегаты и приложения имеют владельцев.","Доступные журналы и границы отзыва сеансов документированы.","У изменений есть приемка, план возврата и контроль бизнес-процессов.",[117,120,123],{"question":118,"answer":119},"Security defaults достаточно для любой компании?","Это базовый механизм, а достаточность зависит от архитектуры и требований. Более детальные политики могут требовать другой лицензии и подготовки. Не отключайте текущую защиту до проверки замены, охвата пользователей, исключений и безопасного восстановления.",{"question":121,"answer":122},"Можно ли создать резервного администратора без MFA?","Такой универсальный совет небезопасен: Microsoft описывает защищенные аварийные учетные записи с сильной аутентификацией и независимыми зависимостями. Их хранение, использование, мониторинг и проверка должны быть организованы заранее; исключения из отдельных политик не равны отказу от защиты.",{"question":124,"answer":125},"После смены пароля весь прежний доступ исчезает?","Не обязательно: нужно учитывать токены, собственные сеансы приложений, тип идентичности и независимые разрешения интеграций. Конкретные действия и сроки зависят от системы. Проверяйте отдельные механизмы и повторный вход, не обещая мгновенное прекращение любого доступа.",[127,128,129,130],{"label":44,"url":45},{"label":34,"url":35},{"label":95,"url":96},{"label":85,"url":86},[132,134,136,139,142,145],{"path":13,"label":133},"Корпоративная почта и рабочие домены",{"path":14,"label":135},"Проверка доступов и MFA",{"path":137,"label":138},"\u002Fblog\u002Fmicrosoft-365-account-compromise","Что делать при захвате аккаунта Microsoft 365",{"path":140,"label":141},"\u002Fglossary\u002Fmfa","Механизмы и пределы MFA",{"path":143,"label":144},"\u002Fblog\u002Femployee-offboarding-access","Отключение сотрудника и передача ресурсов",{"path":146,"label":147},"\u002Fservices\u002Fdmarc-spf-dkim","Аутентификация почтового домена",{"title":149,"description":150,"button":151,"type":152},"Нужна проверка Microsoft 365 по вашему сценарию?","Укажите рабочие сервисы, тип учетных записей и известные проблемы. Согласуем область, полномочия, доказательства и порядок улучшений.","Обсудить проверку Microsoft 365","check",[154,163,171,178],{"id":155,"path":156,"title":157,"description":158,"category":159,"artwork":160,"order":161,"publishedOn":162},"P183","\u002Fblog\u002Fgoogle-workspace-security-checklist","Чек-лист безопасности Google Workspace для бизнеса","Проверка Google Workspace: администраторы, 2SV, восстановление, почтовые маршруты, Drive, приложения и журналы с учетом доступной редакции и полномочий.","email","integrations",38,"2026-06-18",{"id":164,"path":165,"title":166,"description":167,"category":159,"artwork":168,"order":169,"publishedOn":170},"P181","\u002Fblog\u002Fdmarc-report-reading","Как читать отчеты DMARC и выбирать следующее действие","Как разбирать период, источник, количество и результаты в агрегированном отчете DMARC, учитывать дубликаты и связывать строки с разрешенными отправителями.","audit",51,"2026-07-20",{"id":172,"path":137,"title":173,"description":174,"category":159,"artwork":175,"order":176,"publishedOn":177},"P064","Взломали аккаунт Microsoft 365: первые действия и восстановление","Что делать при подозрении на взлом Microsoft 365: доверенный администратор, ограничение доступа, сеансы, правила, приложения, материалы и приемка восстановления.","access",33,"2026-06-02",{"id":179,"path":180,"title":181,"description":182,"category":159,"artwork":183,"order":184,"publishedOn":185},"P050","\u002Fblog\u002Fdmarc-none-to-reject","Переход DMARC с none на reject: как проверить готовность","Как подготовить усиление политики DMARC: разрешенные отправители, согласование, отчеты, редкие потоки, условия остановки и проверка изменения.","security",57,"2026-08-05",[],null,{"path":189,"label":190},"\u002Fresources","Материалы и шаблоны безопасности сайта",{"path":192,"label":193},"\u002Fglossary","Словарь кибербезопасности для бизнеса",1794134065051]