По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Периметр сети в традиционном понимании исчез. Доступ к приложениям и цифровым ресурсам организации происходит из разных мест вне стен офиса и контроль за этими доступами становится серьезной проблемой. Дни, когда можно было защитить границы сети, давно прошли. Настало время для новых стратегий безопасности с нулевым доверием - Zero Trust.
Когда цифровым активам компании приходится преодолевать большие расстояния по небезопасным путям Интернета, ставки настолько высоки, что нельзя доверять ничему и никому. Поэтому следует использовать модель сети с нулевым доверием, чтобы постоянно ограничивать доступ всех пользователей ко всем сетевым ресурсам.
В сетях с нулевым доверием любая попытка доступа к ресурсу ограничивается пользователем или устройством, независимо от того, имели ли они ранее доступ к одному и тому же ресурсу. Чтобы получить доступ к ресурсам любой пользователь или устройство всегда должны проходить процесс аутентификации и верификации, даже если они физически находятся в организации. Эти проверки должны быть быстрыми, чтобы политики безопасности не снижали производительность приложений и работу пользователей.
Zero-trust vs. VPN
Модель сети с нулевым доверием заменяет модель VPN, традиционно используемую компаниями для удаленного доступа своих сотрудников к цифровым ресурсам. VPN заменяется, поскольку они имеют основной недостаток, который могут устранить сети с нулевым доверием. В VPN любая уязвимость, которое происходит в зашифрованном канале, соединяющем пользователя с сетью организации, предоставляет потенциальным злоумышленникам неограниченный доступ ко всем ресурсам компании, подключенным к сети.
В старых локальных инфраструктурах VPN работали хорошо, но они создают больше проблем, чем решений в облачных или смешанных инфраструктурах.
Сети с нулевым доверием устраняют этот недостаток VPN, но добавляют потенциальный недостаток: они могут привести к дополнительной сложности с точки зрения реализации и обслуживания, поскольку полномочия должны быть обновлены для всех пользователей, устройств и ресурсов. Это требует дополнительной работы, но взамен ИТ-отделы получают больший контроль над ресурсами и уменьшается плоскость атаки.
К счастью, преимуществами сети с нулевым доверием можно пользоваться без дополнительных усилий по обслуживанию и развертыванию благодаря инструментам, которые автоматизируют и помогают в задачах администрирования сети. Описанные ниже инструменты помогают применять политики нулевого доверия с минимальными усилиями и затратами.
1. Perimeter 81
Perimeter 81 предлагает два подхода к управлению приложениями и сетями организации и обеспечению их безопасности как в облачных, так и локальных средах. Оба подхода начинаются с предложения сетей с нулевым доверием в качестве услуги. Для этого в Perimeter 81 используется программно-определяемая архитектура периметра, которая обеспечивает большую гибкость для новых пользователей и обеспечивает большую видимость сети. Кроме того, сервис совместим с основными поставщиками облачной инфраструктуры.
Доступ к приложениям с нулевым доверием основан на предположении, что каждая компания имеет критически важные приложения и службы, доступ к которым большинству пользователей не требуется. Сервис позволяет создавать политики для конкретных пользователей в зависимости от их ролей, устройств, местоположений и других идентификаторов.
При этом Zero Trust Network Access определяет сегментацию сети организации по зонам доверия, что позволяет создавать пределы доверия, контролирующие поток данных с высоким уровнем детализации. Доверенные зоны состоят из наборов элементов инфраструктуры с ресурсами, которые работают на одном уровне доверия и обеспечивают аналогичную функциональность. Это уменьшает количество каналов связи и минимизирует возможность возникновения угроз.
Служба доступа к сети с нулевым доверием Perimeter 81 обеспечивает полное и централизованное представление сети организации, обеспечивая наименее привилегированный доступ для каждого ресурса. Его функции безопасности соответствуют модели SASE компании Gartner, поскольку безопасность и управление сетью унифицированы на единой платформе.
Две услуги Perimeter 81 включены в схему ценообразования с широким спектром опций. Эти возможности варьируются от базового плана с необходимыми компонентами для обеспечения безопасности сети и управления ею до корпоративного плана, который может неограниченно масштабироваться и обеспечивает специальную поддержку 24/7.
2. ZScaler Private Access
ZScaler Private Access (ZPA) - это облачная сетевая служба с нулевым доверием, которая управляет доступом к частным приложениям организации независимо от того, находятся ли они в собственном центре обработки данных или в общедоступном облаке. Благодаря ZPA приложения полностью невидимы для неавторизованных пользователей.
В ZPA связь между приложениями и пользователями осуществляется в соответствии со стратегией «наизнанку». Вместо расширения сети для подключения пользователей (как это должно быть сделано при использовании VPN), пользователи никогда не находятся внутри сети. Этот подход существенно минимизирует риски, избегая распространения вредоносных программ и рисков перемещения внутри периметра. Кроме того, сфера применения ZPA не ограничивается веб-приложениями, а относится к любому частному приложению.
ZPA использует технологию микро-туннелей, которая позволяет сетевым администраторам сегментировать сеть по приложениям, устраняя необходимость сегментации в сети с помощью межсетевого экрана или списками управления доступом (ACL). В микро-туннелях используется шифрование TLS и пользовательские закрытые ключи, которые усиливают безопасность при доступе к корпоративным приложениям.
Благодаря усовершенствованным API и ML (машинное обучение), ZPA позволяет ИТ-отделам автоматизировать механизмы нулевого доверия, обнаруживая приложения и создавая для них политики доступа, а также автоматически создавая сегментацию для каждой отдельной рабочей нагрузки приложения.
3. Cloudflare Access
Сетевая служба нулевого доверия Cloudflare поддерживается частной сетью с точками доступа, распределенными по всему миру. Это позволяет ИТ-отделам обеспечивать высокоскоростной и безопасный доступ ко всем ресурсам организации - устройствам, сетям и приложениям.
Сервис Cloudflare заменяет традиционные, ориентированные на сеть периметры безопасности, используя вместо этого безопасный доступ на близком расстоянии, обеспечивающий оптимальную скорость распределенных рабочих групп.
Доступ Cloudflare с нулевым доверием управляет общими приложениями в организации, проверяя подлинность пользователей через собственную глобальную сеть. Это позволяет ИТ-менеджерам регистрировать каждое событие и каждую попытку доступа к ресурсу. Кроме того, это упрощает поддержку пользователей и добавление новых пользователей.
С помощью Cloudflare Access организация может поддерживать свои идентификационные данные, поставщиков защиты, состояние устройств, требования к местоположению каждого приложения и даже существующую облачную инфраструктуру. Для контроля идентичности Cloudflare интегрируется с Azure AD, Okta, Ping и устройством с Tanium, Crowdstrike и Carbon Black.
Cloudflare предлагает бесплатную версию своего сервиса, которая предоставляет основные инструменты и позволяет защитить до 50 пользователей и приложений. Для большего числа пользователей или приложений, а также чтобы воспользоваться другми преимуществами, вроде круглосуточной поддержки по телефону и чату, следует выбрать платные версии.
4. Wandera
Сетевое решение Wandera Private Access с нулевым доверием обеспечивает быстрый, простой и безопасный удаленный доступ к приложениям организации, независимо от того, работают ли они в SaaS или развернуты внутри организации. Сервис отличается своей простотой, процедурами установки, которые могут быть выполнены за считанные минуты и не требуют специализированного оборудования, сертификатов или масштабирования.
Wandera Private Access предлагает гибкость распределенным рабочим группам, работающим на разнородных платформах, с управляемыми или личными устройствами (BYOD). Решение обеспечивает видимость доступа к приложениям в реальном времени, идентификацию теневых ИТ-отделов и автоматическое ограничение доступа с зараженных или небезопасных устройств благодаря политике доступа на базе учета рисков.
С помощью Wandera Private Access можно реализовать модели безопасности, ориентированные на идентификацию, гарантируя, что только авторизованные пользователи смогут подключаться к приложениям организации. Использование микротуннелей на основе приложений связывает пользователей только с приложениями, к которым они имеют право доступа. Применение политики безопасности остается согласованным во всех инфраструктурах, будь то облачные приложения, центры обработки данных или приложения SaaS.
Система защиты Wandera работает от интеллектуального механизма обнаружения угроз под названием MI: RIAM. Этот двигатель ежедневно снабжается информацией, предоставляемой 425 миллионами мобильных датчиков, что обеспечивает защиту от самого широкого спектра известных угроз и угроз нулевого дня.
5. Okta
Okta предлагает модель безопасности с нулевым доверием, которая охватывает широкий спектр услуг, включая защиту приложений, серверов и API; унифицированный и безопасный доступ пользователей к интерактивным и облачным приложениям; адаптивная, контекстно-зависимая, многофакторная аутентификация и автоматическое отключение для уменьшения рисков для бесхозных учетных записей.
Универсальная служба каталогов Okta обеспечивает единое консолидированное представление каждого пользователя в организации. Благодаря интеграции групп пользователей с AD и LDAP, а также связям с системами HR, приложениями SaaS и сторонними поставщиками удостоверений, Okta Universal Directory интегрирует всех типов пользователей, будь то сотрудники компании, партнеры, подрядчики или клиенты.
Okta выделяется своей службой защиты API, поскольку API рассматриваются как новая форма теневых ИТ. Управление доступом к API Okta сокращает время планирования и применения политик на основе XML до нескольких минут, облегчая ввод новых API и интеграцию с партнерами для использования API. Механизм политики Okta позволяет внедрять передовые практики в области безопасности API, легко интегрируясь с фреймворками идентификации вроде OAuth. Политики авторизации API создаются на основе приложений, пользовательского контекста и членства в группах для обеспечения доступа к каждому API только нужных пользователей.
Интеграционная сеть Okta позволяет избежать блокировки поставщиков, предоставляя организациям свободу выбора из более чем 7000 встроенных интеграций с облачными и готовыми системами.
6. CrowdStrike Falcon
Решение CrowdStrike Falcon Identity Protection с нулевым доверием быстро останавливает нарушения безопасности из-за скомпрометированных учётных записей, защищая учетные записи всех пользователей, расположений и приложений в организации с помощью политики нулевого доверия.
Программа Falcon Identity Protection направлена на сокращение затрат и рисков и повышение окупаемости инвестиций используемых инструментов за счет снижения требований к инженерным ресурсам и устранения избыточных процессов обеспечения безопасности.
Унифицированный контроль всех учетных записей упрощает реализацию стратегий условного доступа и адаптивной аутентификации, а также обеспечивает более высокий уровень обслуживания пользователей и более широкий охват многофакторной аутентификации (MFA) даже для устаревших систем.
Решение для удаленного доступа CrowdStrike обеспечивает полную видимость активности аутентификации всех учетных записей и конечных точек, предоставляя, среди прочего, данные о местоположении, источнике/назначении, типе входа (учетная запись человека или службы). В свою очередь, он защищает сеть от инсайдерских угроз, таких как устаревшие привилегированные учетные записи, неправильно назначенные учетные записи служб, ненормальное поведение и полномочия, скомпрометированные атаками продвижения внутри периметра.
Благодаря интеграции с существующими решениями по обеспечению безопасности развертывание Falcon Identity Protection осуществляется в минимальные сроки и без усилий. Помимо прямой интеграции с решениями безопасности для критически важных активов, таких как CyberArk и Axonius, CrowdStrike предлагает высокопроизводительные API, которые позволяют компаниям интегрировать практически с любой системой.
Заключение
Новая норма, похоже, останется, и ИТ-администраторам нужно привыкнуть к ней. Удаленная работа будет оставаться повседневной реальностью, и сети организации больше никогда не будут иметь четко определенных границ.
В этом контексте ИТ-администраторы должны как можно скорее внедрить сетевые и прикладные решения с нулевым доверием, если они не хотят подвергать риску самые ценные цифровые активы своих организаций.
CORS – это механизм браузера, который позволяет серверам указывать сторонние источники, которые имеют право запрашивать у них ресурсы. Этот механизм обеспечивает безопасность и не дает вредоносным сайтам красть данные, которые принадлежат другим источникам.
CORS расшифровывается как Cross-Origin Resource Sharing, что переводится как «обмен ресурсами с запросом происхождения». В случае, когда для загрузки ресурса используется CORS, браузер отправляет предварительный HTTP-запрос
OPTIONS
. Сервер должен ответить, указав все источники, с которыми он собирается взаимодействовать. Также он может определить дополнительные ограничения, например, указать HTTP-заголовки, которые могут быть отправлены.
Браузер проверяет текущий источник и исходящий запрос на соответствие спецификациям сервера. Если все проверки были пройдены успешно, то запрос одобряется. В противном случае запрос будет отклонен. Если это произойдет, вы увидите предупреждение в консоли.
Когда используется CORS
Браузеры применяют CORS для запросов Ajax и Fetch. Этот механизм также используется для веб-шрифтов, текстур WebGL и отрисовки изображения холста с помощью
drawImage()
. CORS также потребуется для любого правомерного запроса к стороннему источнику.
CORS не применяется в том случае, если запрос рассматривается как «простой». Простой запрос должен начинаться с
GET
,
HEAD
или
POST
и иметь тип содержимого
text/plain
,
application/x-www-form-urlencoded
или
multipart/form-data
. Единственные заголовки простых запросов, которые допускаются, - это
Accept
,
Accept-Language
,
Content-Language
и
Content-Type
.
Если запрос не соответствует всем критериям, которые мы перечислили выше, то современные браузеры запускают CORS. Важно понимать, что CORS – это технология для браузера, и вы не сможете использовать его при самостоятельной отправке запросов, например, с помощью утилиты
curl
в своем терминале.
CORS не всегда отправляет предварительный запрос
OPTIONS
. Предварительная проверка нужна и используется только тогда, когда запрос может вызвать «побочные эффекты» на сервере. Как правило, это относится ко всем методам запроса, кроме
GET
.
Предположим, что есть запрос
POST
к
/api/users/create
. Сервер всегда будет создавать нового пользователя, но при этом браузер может отказать в доступе к ответу на этот запрос, если для запроса был использован CORS. Есть шанс, что сервер может отклонить реальный запрос, если перед этим был отправлен запрос
OPTIONS
. Это обеспечивает то, что учетная запись пользователя на самом деле не будет создаваться.
Управление CORS на стороне клиента
Несмотря на то, что CORS является технологией для браузера, вы все равно не можете влиять на нее напрямую с помощью клиентского кода. Это гарантирует, что вредоносные скрипты не смогут обойти защиту CORS, чтобы загрузить данные со сторонних доменов.
CORS, как правило, незаметен, поэтому вы даже не будете знать о том, что он работает. Если в процессе CORS произойдет сбой, то ваш код JavaScript увидит обычную сетевую ошибку. Получить точную информацию о том, что пошло не так, невозможно, поскольку это может представлять риск нарушения безопасности. Все подробности записываются в консоль.
Единственный способ устранить сбои CORS – это убедиться, что ваш сервер отправляет корректные заголовки ответов. Теперь давайте посмотрим, как это делается.
Управление CORS на стороне сервера
Для начала вам следует убедиться в том, что ваш сервер правильно обрабатывает запросы
OPTIONS
. Возможно, вам придется создать новый маршрут обработки запросов в вашей веб-среде. В большинстве случаев вам придется принимать запросы
OPTIONS
к каждой конечной точке, которая может получить CORS-запрос от браузера. Ответ не обязательно должен иметь тело, но он должен включать в себя определенные заголовки, которые сообщают браузеру, что делать дальше.
Начните с заголовка
Access-Control-Allow-Origin
. Он укажет на сторонний источник, который имеет право взаимодействовать с вашей конечной точкой. Указать можно только один источник; но вы можете обрабатывать несколько источников, динамически устанавливая в качестве значения заголовка источник, из которого был отправлен запрос. Текущий источник можно найти в заголовке запроса
Origin
.
Access-Control-Allow-Origin
принимает * в качестве специального подстановочного символа. Это позволит принимать запросы CORS из всех источников. Здесь следует быть осторожным, поскольку указание разрешенных источников обеспечивает контроль и не дает вредоносным скриптам запрашивать данные с вашего сервера.
Access-Control-Allow-Origin
должен быть включен в ответ вашего сервера на реальный запрос и в ответ на запрос
OPTIONS
. После того, как этот заголовок будет настроен, будет разрешен базовый обмен данными со сторонним клиентом браузера.
Указание CORS-заголовков
CORS-запросы, как правило, поддерживают только заголовки «простых» запросов, которые были перечислены выше. Если вы хотите использовать какой-то другой заголовок, например,
Authorization
или настраиваемый заголовок, то вашему серверу необходимо будет явно разрешить его в ответе на предварительный запрос.
Установите заголовок
Access-Control-Allow-Headers
. Его значение – это список названий заголовков через запятую, которые будут приняты с реальным запросом.
Access-Control-Allow-Headers: Authorization, X-Custom-Header
Теперь браузер разрешит запросы с заголовками
Authorization
или
X-Custom-Header
.
Браузер отправляет заголовок
Access-Control-Allow-Headers
вместе с предварительным CORS-запросом. Он содержит список заголовков, которые будут отправлены с реальным запросом. Ваш серверный код может использовать эту информацию для того, чтобы понять, как нужно ответить на предварительный запрос.
Ограничение на определенные методы запроса
Аналогично тому, как мы указываем заголовки запроса, так и конечные точки сервера могут определять, какие HTTP-методы из различных источников будут разрешены. Установите заголовок
Access-Control-Allow-Methods
. Его значение – список названий методов через запятую.
Access-Control-Allow-Methods: GET, POST, DELETE
Браузер отправляет заголовок
Access-Control-Request-Method
с предварительным запросом. Таким образом сервер узнает HTTP-метод, который будет использоваться для выполнения окончательного запроса.
Cookie-файлы и учетные данные
CORS-запросы, как правило, не отправляют cookie-файлы, так как в них может содержаться конфиденциальные учетные данные, которые идентифицируют отправителя. Если вам необходимо добавить cookie-файл к запросу на другой источник, то это нужно явно разрешить в клиентском коде:
fetch("https://localhost/demo", {
mode: "cors",
credentials: "include"
});
К тому же сервер должен установить заголовок ответа
Access-Control-Allow-Credentials: true
, чтобы сообщить о том, что он соглашается на обмен cookie-файлами, которые содержат учетные данные.
Если вы используете заголовок
Access-Control-Allow-Credentials
, то нельзя использовать подстановочный символ (*) в заголовке
Access-Control-Allow-Origin
. Сервер должен явно указать источник для того, чтобы обезопасить конфиденциальность пользователя. Если вы будете использовать подстановочный символ, то браузер не выполнит запрос и вернет ошибку.
Предварительное кэширование
Предварительные запросы
OPTIONS
усиливают нагрузку на каждый запрос, который вы отправляете. При хорошем соединении задержка должна быть почти незаметной, и все же нерационально вызывать одну и ту же конечную точку раз за разом.
Вы можете указать браузеру кэшировать ответы на предварительные запросы. Для этого вам нужно установить заголовок
Access-Control-Max-Age
. Значение этого заголовка – это время, выраженное в секундах. В течение этого времени браузер может хранить кэшированный ответ. Последующие запросы к той же конечной точке в течении заданного периода времени не будут сопровождаться предварительными запросами.
Заключение
При первом знакомстве с технологией CORS она может сбивать с толку. Эта технология браузера, которая контролируется ответами сервера. Использование CORS неизбежно, но при этом оно может оказаться неуправляемым, если у вас нет доступа к серверному коду, с которым вы взаимодействуете.
Фактическая реализация CORS довольно проста. Убедитесь, что ваш API или CDN отправляет корректные заголовки ответов, в особенности это касается заголовка
Access-Control-Allow-Origin
. Если с этим проблем нет, то у вас будет безопасная связь между источниками, которая поможет избежать вмешательства злоумышленников.
Сегодня подробно разберёмся в том, как настроить запись телефонных разговоров, проходящих через нашу IP-АТС Asterisk, с помощью графической оболочки FreePBX 13. Данная статья будет так же полезна тем, у кого, по каким то причинам, не записываются телефонные разговоры и они хотят это исправить.
Заглянем в FreePBX
Множество модулей во FreePBX позволяют включить запись телефонных разговоров напрямую, к таким относятся Extensions, Queues, Ring Groups, Inbound Routes. То есть, например, при создании нового внутреннего номера или ринг группы мы можем определить, записывать ли разговоры проходящие через них.
Для этого, в каждом модуле, который позволяет настроить запись, есть раздел Recording Options или Call Recording, в котором доступно 5 режимов записи - Force, Yes, Don't Care, No и Never.
Данные режимы, позволяют определить, как именно будет идти запись в течение "жизни вызова" или call flow. Вы можете спросить - "Зачем в модулях предусмотрено целых 5 режимов? Почему бы просто не оставить: Yes - есть запись, No - записи нет?"
Все дело в том, что звонок может менять свое назначение, например, он может изначально поступить на телефон секретаря Extension, а потом его переведут, например, на отдел продаж Ring Group (цикл звонка и есть call flow), в одном модуле запись может быть включена, а в другом нет и вот чтобы определить, что будет записано и служат эти 5 режимов. Давайте разберёмся подробнее в их логике:
Force и Never заменяют друг друга и имеют высший приоритет чем Yes и No
Yes и No имеют одинаковый приоритет
Когда один и больше Yes или No встречается в call flow, в приоритете всегда будет первое значение.
Последующие опции Yes или No не переопределяют первую.
Force и Never будут всегда переопределять опции, которые установлены ранее.
Force и Never будут всегда заменять друг друга. Например если сначала был установлен Force, а потом встречается Never, то в приоритете будет Never
Force и Never будут всегда заменять предустановленные опции Yes и No
Yes и No никогда не заменять Force и Never
Don’t Care не будет изменять предыдущую опцию.
Чтобы было проще понять логику этих 5 режимов, каждый раз, когда встречается No представляйте себе такую фразу – «Я бы предпочел не записывать эту часть вызова, если раньше мне не говорили записать её», когда Yes, такую фразу – «Я хотел бы записать эту часть вызова, если только ранее я не был предупрежден не делать этого». Если встречаете Force, то представьте такую фразу – «Начать или продолжить запись сейчас же!», а если Never - «Закончить запись сейчас же!». И наконец, если встречаете Don’t Care - «Сейчас ничего менять не нужно»
Следует отметить, что некоторые модули, такие как Conference не имеют опций Force, Don’t Care и Never, а имеют только Yes и No, а некоторые, например, Ring Group наоборот, имеют только опции Force, Don’t Care и Never.
Ещё одной важной функцией записи телефонных разговоров, является запись по требованию - On Demand Recording. С помощью данной функции, администратор IP-АТС может настроить пользователю определенного внутреннего номера Extension, эксклюзивное право включать и выключать запись прямо во время разговора, используя программируемую кнопку на корпусе его телефона или специальный Feature Code, по умолчанию это *1. Для того, чтобы настроить данный функционал, необходимо открыть Applications → Extensions далее открыть вкладку Advanced, прокрутить меню до опции Recording Option и найти поле On Demand Recording
Как видите, On Demand Recording имеет следующие режимы:
Disable - Пользователь внутреннего номера не сможет использовать функцию записи по требованию, не зависимо от того, какой режим имеет вызов Force, Yes, Don't Care, No или Never.Если пользователь попробует ввести специальный Feature Code, то он услышит ответ “access denied” – “доступ запрещен”
Enable - Функция записи по требованию доступна пользователю, но только если звонок имеет режим Yes,No или Don’t Care. Если звонок в режиме Force, или Never, то он услышит “доступ запрещен”
Overrride - Пользователь всегда может включить или выключить запись по требованию, вне зависимости от режима Force, Yes, Don't Care, No или Never.
Теперь, чтобы основательно закрепить материал, давайте рассмотрим пример вызова и посмотрим, как будет меняться режим записи в этом call flow:
Допустим, мы имеем входящий звонок, в правилах входящего маршрута - Inbound Route которого установлен режим записи Yes. В результате генерируется файл записи и запись разговора начинается.
По правилам этого входящего маршрута, вызов переходит в очередь Queue, режим записи которой - Don’t Care - запись продолжается.
В очереди, звонок принимает оператор, в правилах внутреннего номера которого, стоит режим записи входящих звонков (Inbound External Calls) - No. Запись продолжается, потому что перед этим, в первом шаге, на входящем маршруте был установлен режим Yes и он имеет приоритет.
Оператор нажимает *1, в настройках его внутреннего номера On Demand Recording установлен режим - Enable. Запись останавливается.
Оператор переводит звонок на ринг-группу (Ring Group), режим записи которой - Force. Запись продолжается.
В ринг группе, звонок принимает менеджер, в правилах внутреннего номера которого, стоит режим записи входящих звонков (Inbound Internal Calls) - Never. Запись снова остановлена.
Менеджер хочет начать запись и нажимает *1 и слышит в трубке “доступ запрещен”, потому что функция записи по требованию заблокирована режимом Never
Таким образом, если Вы вдруг заметили, что у вас отсутствуют записи каких-либо телефонных разговоров или отдельных их частей, а вы вроде как её включали в настройках, то рекомендуем Вам проследить call flow звонка, в котором нет записи и посмотреть – какой режим включается на каждом из этапов.