Аудит и соответствие Awareness

Готовность к работе по стандарту FedRAMP, сертификация класса А и выход на федеральный рынок.

by Альянс Лазаря 0 комментарий
Цифровое облако на абстрактном технологическом фоне, парящее над макетами зданий.

Обновления и расширение FedRAMP проясняют несколько моментов, наиболее важным из которых является то, что государственные учреждения рассчитывают на облачные инструменты для выполнения своей работы. Но им также нужна определенность. Статус FedRAMP Ready был призван преодолеть разрыв между учреждениями, стремящимися к проверенным платформам, и поставщиками SaaS, стремящимися к авторизации на более реалистичном пути. 

Теперь, когда статус Ready будет отменен в июле 2026 года, кажется, что двери закрываются. Но переход от традиционных разрешений на ввод в эксплуатацию к постоянной проверке снова открывает их и делает гораздо более перспективным выход этих SaaS-провайдеров на федеральный рынок. 

Новые обозначения «Влиятельный фактор» и «Готовность» класса А

Статус «Готов» в рамках FedRAMP был создан для того, чтобы помочь поставщикам облачных услуг пройти процесс сертификации FedRAMP Rev5. Однако по состоянию на июль 2026 года... Программа полностью перейдет на стандарт FedRAMP 20x.А у поставщиков облачных услуг со статусом «Готовы» будет время до ноября 2026 года (не позднее), чтобы быть исключенными из списка участников рынка. 

В результате статус «Готов» постепенно выводится из употребления. Вместо этого PMO разрабатывает новые пути авторизации, которые сокращают время аудита и обеспечивают плавный выход на рынок для поставщиков SaaS-услуг. 

Наиболее очевидный из этих путей — сертификация класса А, пилотный базовый уровень, который, по сути, заменяет FedRAMP Ready. Организации, имеющие статус FedRAMP Ready, могут перейти на сертификацию класса А или, если они не соответствуют требованиям, выбрать другой путь. 

Тем не менее, существенных изменений в требованиях между статусом Ready и сертификацией класса A нет. От поставщиков SaaS ожидается выполнение шести федеральных требований:

  • Шифрование, сертифицированное по стандарту FIPS: Для систем, претендующих на сертификацию класса А, инструменты должны использовать Проверено по стандарту FIPS 140 криптографические модулиКриптографические модули должны использоваться согласованно везде, где требуется шифрование, хеширование или генерация ключей, включая данные в состоянии покоя и при передаче. 
  • Многофакторная аутентификация: В соответствии с требованиями стандарта NIST SP 800-63B, решения для многофакторной аутентификации (MFA) должны использовать шифрование, соответствующее стандарту FIPS 140, для самих инструментов. 
  • Поддержка общего доступа и PIV: Система должна в полной мере поддерживать аутентификацию пользователей с использованием служебных карт общего доступа (CAC) или учетных данных для проверки личности (PIV).
  • Расширения безопасности DNS: Внешние авторитетные и внутренние рекурсивные DNS-решения системы должны поддерживать расширения безопасности DNS (DNSSEC) для обеспечения аутентификации источника.
  • Устранение уязвимости: Поставщики облачных услуг должны продемонстрировать способность устранять уязвимости высокой степени тяжести в течение 30 дней, уязвимости средней степени тяжести в течение 90 дней и уязвимости низкой степени тяжести в течение 180 дней.
  • Документация по границам авторизации и потоку данных: Поставщики услуг должны предоставить два основных документа, документирующих поток данных через их приложение и инфраструктуру: диаграмму границ авторизации и диаграмму потока данных. Обе диаграммы должны быть достаточно точными, чтобы оценщик мог самостоятельно проверить каждое утверждение посредством демонстрации в реальном времени или анализа документации.

Кроме того, сертификация класса А влечет за собой ряд эксплуатационных требований:

Без доверенности и гарантий

Инженерные группы, привыкшие к полному процессу авторизации, в ходе которого обычно представляются десятки открытых пунктов плана действий и мониторинга, отражающих известные, но принятые риски, должны полностью перестроиться. Для класса А каждый необходимый элемент контроля обязательно должны быть внедрены, протестированы и продемонстрированы как работоспособные. 

Переход на OSCAL

Исторически сложилось так, что пакет документов для авторизации по программе FedRAMP представлял собой огромный набор документов, электронных таблиц и PDF-файлов. Проверка этих пакетов требовала участия аналитиков, которые читали и проверяли заявления, что напрямую влияло на сроки авторизации, составлявшие от 12 до 24 месяцев.

FedRAMP переходит к машиночитаемым пакетам авторизации, созданным на основе языка оценки средств контроля безопасности Open Security Controls Assessment Language (OSCAL). OSCAL позволяет выражать утверждения о реализации средств контроля, результаты оценки и метаданные системы в структурированных форматах (JSON, XML, YAML), которые могут быть обработаны, проверены и сопоставлены автоматизированными инструментами.

Цифровое облако на абстрактном технологическом фоне, парящее над макетами зданий.

Путь к получению сертификата класса А

Для хорошо подготовленного поставщика услуг получение сертификата класса А может быть завершено за три-шесть месяцев. Однако для этого необходим четкий план действий.

Шаг 1: Анализ пробелов

Проведите тщательную оценку текущего уровня безопасности системы и того, как она вписывается в существующую систему классификации/воздействия. Как и в случае с FedRAMP Ready, для соответствия требованиям нет основного набора контрольных мер. Вместо этого ожидается, что поставщик SaaS выполнит шесть федеральных требований (перечисленных выше). 

Шаг 2: Техническое устранение неполадок

Выполняйте задачи из списка невыполненных исправлений, сосредоточившись на обязательных требованиях, подлежащих оценке. К приоритетным задачам обычно относятся:

  • Внедрение криптографических модулей, соответствующих стандарту FIPS 140, для шифрования данных в состоянии покоя и при передаче.
  • Внедрение многофакторной аутентификации, соответствующей стандарту FIPS, для всех уровней доступа, включая привилегированный и пользовательский.
  • Создание инфраструктуры непрерывного мониторинга, включающей сканирование уязвимостей и ведение журналов.
  • Разработка соответствующих требованиям схем границ авторизации и потоков данных.
  • Настройка автоматизированного сбора доказательств для проверки контроля
  • Усиление системных конфигураций в соответствии с применимыми стандартами DISA STIG или CIS.

Шаг 3: Взаимодействие с 3PAO

Обратитесь к аккредитованному специалисту. Сторонняя организация по оценке для проведения оценки готовности. Оценка 3PAO включает в себя анализ документации, техническое тестирование, демонстрацию внедрения средств управления в реальных условиях, а в некоторых случаях и инспекцию объектов центров обработки данных или производственных площадок. 

Шаг 4: Проверка PMO и размещение на торговой площадке.

Отправьте заполненный отчет RAR в офис управления проектами FedRAMP для рассмотрения. После принятия отчета поставщик получает статус «Готов» и размещается на торговой площадке FedRAMP, доступной для всех федеральных агентств.

 

Успейте получить статус готовности к внедрению Lazarus Alliance до истечения крайнего срока в июле 2026 года.

Не ждите, пока федеральный клиент спросит о соответствии ваших требований FedRAMP. С переходом на FedRAMP 20x у поставщиков SaaS, как крупных, так и небольших, появляется множество возможностей для получения сертификации и предоставления услуг на федеральном рынке.  

Чтобы узнать больше о том, как Lazarus Alliance может помочь, Свяжитесь с нами. 

Загрузите брошюру нашей компании.

Альянс Лазаря

Веб-сайт: