Ръководство за одитни доказателства за контрол на достъпа по ISO 27001

09:10 е в деня на одита. Мария, CISO на бързо растяща FinTech и облачна платформа, е отворила своята политика за контрол на достъпа. Ръководителят на ИТ експортира настройките за условен достъп от доставчика на идентичност. Отдел „Човешки ресурси“ търси тикета за прекратяване на правоотношението на финансов анализатор, напуснал преди шест седмици. Вътрешният одитор вдига поглед и задава въпроса, който всички очакват:

„Покажете ми как се заявява, одобрява, предоставя, преглежда и отнема достъпът за потребител с привилегирован достъп до лични данни.“

Това едно изречение може да разкрие дали програмата за контрол на достъпа е готова за одит, или е готова само на ниво политика.

Екипът на Мария разполагаше със зряла система за управление на информационната сигурност (ISMS), годишен цикъл за ресертификация по ISO/IEC 27001:2022, внедрена многофакторна автентикация, ролево базиран контрол на достъпа в основните системи и тримесечни таблици за преглед на достъпа. Но този одит беше различен. Списъкът с искания на одитора включваше готовност за нововъзникващи регулаторни изисквания. За организацията на Мария това означаваше NIS2, DORA и GDPR, разглеждани през една и съща оперативна призма: идентичност, достъп, автентикация, привилегии и доказателства.

Проблемът пред много CISO не е, че контролът на достъпа липсва. Проблемът е, че доказателствата съществуват на фрагменти. Одобренията при въвеждане в длъжност се намират в Jira или ServiceNow. Настройките на MFA са в Microsoft Entra ID, Okta или друг доставчик на идентичност. Разрешенията в AWS, Azure и Google Cloud са в отделни административни конзоли. Привилегированите действия може да се журналират в PAM инструмент, а може и изобщо да не се журналират. Статусът от ЧР е в BambooHR, Workday или електронни таблици. Прегледите на правата за достъп може да са одобрени по имейл.

Когато одиторът свърже IAM, MFA, PAM, събитията по постъпване, промяна на роля и напускане, личните данни, облачната администрация и регулаторните очаквания, фрагментираните доказателства бързо се разпадат.

Одитите на контрола на достъпа по ISO/IEC 27001:2022 не са само прегледи на техническа конфигурация. Те са тестове на системата за управление. Проверява се дали рисковете, свързани с идентичностите и достъпа, са разбрани, третирани, внедрени, наблюдавани и подобрявани. Когато NIS2, DORA и GDPR също са релевантни, същите доказателства трябва да показват управление на правата за достъп, базирано на риска, силна автентикация, проследими одобрения, своевременно отнемане на достъп, ограничаване на привилегиите, защита на личните данни и управленска отчетност.

Практическият отговор не е по-голям класьор. Отговорът е един модел за доказателства за контрол на достъпа, който започва от обхвата на ISMS и риска, преминава през политиката и дизайна на контролите, достига до инструментите за IAM и PAM и се съпоставя ясно с ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST и COBIT.

Защо контролът на достъпа е регулаторната опорна точка

Контролът на достъпа се превърна в тема на ниво управителен съвет и регулатори, защото компрометирането на идентичности вече е често срещан път към оперативно прекъсване, нарушение на сигурността на данните, измами и експозиция във веригата на доставки.

Съгласно NIS2, Articles 2 и 3, разглеждани заедно с Annex I и Annex II, много средни и по-големи субекти в изброените сектори попадат в обхвата като съществени или важни субекти. Това включва цифрова инфраструктура и доставчици на управление на ИКТ услуги, като доставчици на облачни услуги, доставчици на услуги за центрове за данни, доставчици на управлявани услуги и доставчици на управлявани услуги за сигурност. Държавите членки трябваше да транспонират NIS2 до октомври 2024 г. и да прилагат националните мерки от октомври 2024 г., като списъците на субектите трябва да бъдат готови през април 2025 г. Article 20 възлага на управителните органи отговорност за одобряване на мерките за управление на риска в областта на киберсигурността и за надзор върху внедряването им. Article 21 изисква технически, оперативни и организационни мерки, включително политики за контрол на достъпа, управление на активите, киберхигиена, обработване на инциденти, непрекъсваемост на дейността, сигурност на веригата на доставки и MFA или непрекъсната автентикация, когато е приложимо.

DORA добавя секторно специфичен слой за оперативна устойчивост за финансовите субекти и релевантните външни доставчици на ИКТ услуги. Articles 1, 2 и 64 установяват DORA като единна рамка, приложима от 17 януари 2025 г. Articles 5 и 6 изискват управление и документирана рамка за управление на ИКТ риска. Article 9 разглежда защитата и превенцията, включително политики, процедури, протоколи и инструменти за ИКТ сигурност. Articles 24 до 30 добавят тестване на цифровата оперативна устойчивост и управление на риска, свързан с външни доставчици на ИКТ услуги. За финансовите субекти доказателствата за контрол на достъпа се превръщат в доказателства за устойчивост, а не само в доказателства за ИТ администрация.

GDPR въвежда гледната точка на личните данни. Articles 2 и 3 дефинират широката приложимост за обработване в ЕС и пазарен обхват в ЕС. Article 5 изисква цялостност, поверителност и доказуема отчетност. Article 25 изисква защита на данните още при проектирането и по подразбиране. Article 32 изисква подходящи технически и организационни мерки. На практика това означава контролиран достъп, сигурна автентикация, журналиране, преглед и своевременно премахване за системи, обработващи лични данни.

ISO/IEC 27001:2022 предоставя на организациите механизма на системата за управление, чрез който тези задължения могат да се обединят. Клаузи 4.1 до 4.3 изискват организацията да разбира контекста, заинтересованите страни, правните и договорните изисквания, интерфейсите, зависимостите и обхвата на ISMS. Клаузи 6.1.1 до 6.1.3 изискват оценка на риска за информационната сигурност, третиране, сравнение с Annex A, Декларация за приложимост и одобрение на планове за третиране и остатъчен риск. Клауза 8.1 изисква оперативен контрол, документирана информация, показваща, че процесите са изпълнени по план, контрол на промените и контрол върху външно предоставяни процеси.

Следователно одиторският въпрос не е „Имате ли MFA?“ Въпросът е „Можете ли да докажете, за идентичностите и системите в обхвата, че рискът, свързан с достъпа, се управлява, третира, внедрява, наблюдава и подобрява?“

Изградете доказателствената основа от обхвата на ISMS до доказателствата от IAM

Clarysec започва подготовката за одит на контрола на достъпа, като прави доказателствата проследими от бизнес контекста. ISO/IEC 27001:2022 очаква ISMS да бъде интегрирана в процесите на организацията и мащабирана спрямо нейните нужди. Доставчик на SaaS с 30 души и мултинационална банка няма да имат една и съща архитектура на достъпа, но и двете организации се нуждаят от последователна верига от доказателства.

ISO/IEC 27005:2022 е полезен, защото препоръчва обединяване на правни, регулаторни, договорни, секторно специфични и вътрешни изисквания в общ контекст на риска. Клаузи 6.4 и 6.5 подчертават критерии за риска, които вземат предвид организационните цели, законите, взаимоотношенията с доставчици и ограниченията. Клаузи 7.1 и 7.2 позволяват сценарии, базирани на събития и активи. За контрола на достъпа това означава оценяване на стратегически сценарии като „привилегирован администратор на SaaS експортира данни на клиенти от ЕС“ наред със сценарии за активи като „осиротял AWS IAM ключ, прикачен към продукционно хранилище“.

В Zenith Blueprint: An Auditor’s 30-Step Roadmap на Clarysec тази доказателствена основа се изгражда по време на фазата „Контроли в действие“. Стъпка 19 се фокусира върху технологични контроли за управление на крайни точки и достъпа, а Стъпка 22 формализира организационния жизнен цикъл на достъпа.

Zenith Blueprint указва на екипите да проверят дали предоставянето и отнемането на достъп са структурирани, интегрирани с ЧР, когато е възможно, подкрепени от работни потоци за заявки за достъп и преглеждани на тримесечна база. Той също така указва на организациите да документират типовете идентичности, да прилагат контроли за индивидуални, споделени и служебни идентичности, да прилагат силни политики за пароли и MFA, да премахват неактивни акаунти и да поддържат сигурно съхранение в сейф за тайни или документация за служебни удостоверителни данни.

Точно така одиторите тестват контрола на достъпа: една идентичност, една система, едно одобрение, една привилегия, един преглед и едно отнемане на достъп наведнъж.

Какво да съберете като готови за одит доказателства за контрол на достъпа

Пакетът с доказателства за контрол на достъпа трябва да позволява на одитора да избере произволен потребител и да проследи жизнения цикъл: заявка, одобрение, присвояване, автентикация, повишаване на привилегиите, мониторинг, преглед и отнемане.

Силен пакет с доказателства включва:

1. Политика за контрол на достъпа и политика за потребителски акаунти
2. Процедура за постъпване, промяна на роля и напускане
3. Матрица на ролите или матрица за контрол на достъпа
4. Списък на приложенията, платформите и хранилищата на данни в обхвата
5. Конфигурация на MFA при доставчика на идентичност
6. Политики за условен достъп и списък на изключенията
7. Инвентаризация на привилегированите акаунти
8. Доказателства за работни потоци на PAM, включително одобрения и журнали на сесии
9. Скорошни резултати от кампания за преглед на достъпа
10. Примерни потвърждения от мениджъри и действия за отстраняване
11. Отчет на ЧР за прекратени правоотношения, съпоставен с журнали за деактивиране
12. Инвентаризация на служебните акаунти, собственици, записи за ротация и доказателства за съхранение в сейф за тайни
13. Процедура за авариен администраторски акаунт „break glass“ и тестов журнал
14. Доказателства за инциденти или предупреждения, свързани с неуспешни вписвания, ескалация на привилегии или неактивни акаунти
15. Записи в Декларацията за приложимост за контроли от Annex A, свързани с достъпа

Политиките на Clarysec правят това очакване изрично. В политиката за МСП Политика за контрол на достъпа за МСП изискването е ясно и ориентирано към одита:

„Трябва да се поддържа защитен запис за всяко предоставяне, изменение и премахване на достъп.“

От раздел „Изисквания за внедряване на политиката“, клауза 6.1.1.

Същата политика за МСП свързва RBAC и MFA директно с ролевите отговорности:

„Внедрява ролево базиран контрол на достъпа (RBAC) и налага силна автентикация (напр. многофакторна автентикация (MFA)).“

От раздел „Роли и отговорности“, клауза 4.2.3.

За по-големи организации корпоративната Политика за въвеждане в длъжност и прекратяване на правоотношенията изисква IAM системата да журналира създаването на акаунти, присвояването на роли и разрешения и събитията по деактивиране, да поддържа шаблони за ролево базиран достъп и да се интегрира със системите на ЧР за тригери при постъпване, промяна на роля и напускане. Тази клауза помага одиторската история да бъде разказана на едно място: стандартизирано въвеждане, жизнен цикъл на идентичността, задействан от ЧР, и проследими IAM събития.

Съпоставете IAM, MFA, PAM и прегледите с контролите по ISO/IEC 27001:2022

Zenith Controls: The Cross-Compliance Guide на Clarysec разглежда контрола на достъпа като свързано семейство от контроли, а не като елемент от контролен списък. За ISO/IEC 27001:2022 най-релевантните контроли включват:

• Контрол 5.15, контрол на достъпа
• Контрол 5.16, управление на идентичности
• Контрол 5.17, информация за автентикация
• Контрол 5.18, права за достъп
• Контрол 8.2, права за привилегирован достъп
• Контрол 8.3, ограничаване на достъпа до информация
• Контрол 8.5, сигурна автентикация
• Контрол 8.15, журналиране
• Контрол 8.16, дейности по мониторинг

За информацията за автентикация Zenith Controls съпоставя контрол 5.17 като превантивен контрол, подпомагащ поверителност, цялостност и наличност, с оперативната способност „Управление на идентичности и достъп“. Той е пряко свързан с управление на идентичности, сигурна автентикация, роли и отговорности, допустима употреба и съответствие с политики. Сигурността на удостоверителните данни включва жизнения цикъл на автентификатора, сигурно издаване, съхранение, нулиране, отнемане, MFA токени, частни ключове и служебни удостоверителни данни.

За правата за достъп Zenith Controls съпоставя контрол 5.18 с формално предоставяне, преглед, изменение и отнемане. Той е свързан с контрол на достъпа, управление на идентичности, разделение на задълженията, права за привилегирован достъп и мониторинг на съответствието. Това е контролът, който превръща минимално необходимия достъп в доказателства.

За правата за привилегирован достъп Zenith Controls съпоставя контрол 8.2 със специфичния риск от акаунти с повишени права, включително домейн администратори, root потребители, администратори на облачни тенанти, суперпотребители на бази данни и CI/CD контролери. Ръководството свързва привилегирования достъп с управление на идентичности, права за достъп, ограничаване на достъпа до информация, сигурна автентикация, дистанционна работа, журналиране и мониторинг.

Един добре проектиран отчет за преглед на достъпа може да подпомогне ISO/IEC 27001:2022, NIS2, DORA и GDPR, ако включва обхват, собственик на система, преглеждащо лице, списък с акаунти, обосновка на ролята, флаг за привилегирован достъп, решения, премахвания, изключения и дата на завършване.

Доказателствата за MFA са повече от екранна снимка

Честа одиторска грешка е представянето на екранна снимка с текст „MFA enabled“. Одиторите се нуждаят от повече. Те трябва да знаят къде се прилага MFA, кой е изключен, как се одобряват изключенията, дали привилегированите акаунти са обхванати и дали техническата конфигурация съответства на политиката.

От Zenith Blueprint, фазата „Контроли в действие“, Стъпка 19, одиторите ще попитат как се прилагат политиките за пароли и MFA, кои системи са защитени, за кого се прилага MFA и дали критичните приложения могат да бъдат тествани с примерен акаунт. Доказателствата може да включват конфигурация на IdP, политики за условен достъп, статистика за регистриране в MFA и процедури за нулиране на пароли.

За корпоративни среди Политика за управление на потребителски акаунти и привилегии на Clarysec посочва:

„Когато е технически възможно, многофакторната автентикация (MFA) е задължителна за: 6.3.2.1 Административни акаунти и акаунти на ниво root 6.3.2.2 Отдалечен достъп (VPN, облачни платформи) 6.3.2.3 Достъп до чувствителни или регулирани данни“

От раздел „Изисквания за внедряване на политиката“, клауза 6.3.2.

Това създава пряк одиторски мост. Ако MFA е задължителна за администраторски акаунти, отдалечен достъп и регулирани данни, пакетът с доказателства трябва да включва списъци на административни акаунти и акаунти на ниво root, конфигурация за отдалечен достъп, политики за условен достъп за облачни платформи, списъци на приложения с чувствителни данни, отчети за регистриране в MFA, одобрения на изключения, компенсиращи контроли и скорошни доказателства от преглед на предупреждения за неуспешни вписвания или опити за заобикаляне на MFA.

За NIST SP 800-53 Rev. 5 това съответства на IA-2 Identification and Authentication, IA-5 Authenticator Management, AC-17 Remote Access и AU-2 Event Logging. За COBIT 2019 то подпомага DSS05.04 Manage user identity and logical access и свързаните практики за мониторинг на сигурността.

Поддържащите ISO стандарти разширяват картината. ISO/IEC 27018:2020 разширява очакванията за автентикация за публичен облак, обработващ лични данни. ISO/IEC 24760-1:2019 подпомага обвързването на автентификатори и управлението на жизнения цикъл. ISO/IEC 29115:2013 въвежда нива на увереност при автентикация, полезни при определяне къде са необходими хардуерни токени или MFA, устойчива на фишинг. ISO/IEC 27033-1:2015 подпомага силна мрежова автентикация за отдалечен или междумрежов достъп.

Доказателствата за PAM са най-бързият път към съществена констатация или чист одит

Привилегированият достъп е мястото, където одиторите стават скептични, защото привилегированите акаунти могат да заобикалят контроли, да извличат данни, да създават устойчиво присъствие и да променят журнали. В Zenith Blueprint, Стъпка 19, е посочено:

„Във всяка информационна система привилегированият достъп е власт, а с тази власт идва и риск.“

Насоките се фокусират върху това кой има привилегирован достъп, какво позволява той, как се управлява и как се наблюдава във времето. Препоръчват се актуална инвентаризация, минимални привилегии, RBAC, времево ограничено или точно навреме повишаване на привилегиите, работни потоци за одобрение, уникални персонални акаунти, избягване на споделени акаунти, журналиране на „break glass“, PAM системи, ротация на удостоверителни данни, съхранение в сейф за тайни, запис на сесии, временно повишаване на привилегиите, мониторинг и редовен преглед.

Корпоративната Политика за контрол на достъпа на Clarysec превръща това в изискване за контрол:

„Административният достъп трябва да бъде строго контролиран чрез: 5.4.1.1 Отделни привилегировани акаунти 5.4.1.2 Наблюдение и запис на сесии 5.4.1.3 Многофакторна автентикация 5.4.1.4 Времево ограничено или задействано от работен поток повишаване на привилегиите“

От раздел „Изисквания за управление“, клауза 5.4.1.

Този цитат е почти сценарий за одиторски тест. Ако политиката изисква отделни администраторски акаунти, покажете списъка на привилегированите акаунти и докажете, че всеки е свързан с идентифицирано лице. Ако изисква наблюдение на сесиите, покажете записани сесии или PAM журнали. Ако изисква MFA, покажете прилагането ѝ за всеки път на привилегирован достъп. Ако изисква времево ограничено повишаване, покажете времеви маркери за изтичане и тикети за одобрение.

Версията за МСП е също толкова директна. Политика за управление на потребителски акаунти и привилегии за МСП посочва:

„Повишените или административните привилегии изискват допълнително одобрение от Управителя или ИТ ръководителя и трябва да бъдат документирани, времево ограничени и подложени на периодичен преглед.“

От раздел „Изисквания за внедряване на политиката“, клауза 6.2.2.

За по-малки организации това често е разликата между „доверяваме се на нашия администратор“ и „контролираме привилегирования риск“. Одиторът не изисква корпоративен инструментариум във всяко МСП, но изисква доказателства, пропорционални на риска. Тикет, одобрение, временно назначение в група, прилагане на MFA и запис от преглед може да са достатъчни, когато обхватът е ограничен и рискът е по-нисък.

Прегледите на правата за достъп доказват, че минимално необходимият достъп работи

Прегледите на правата за достъп показват дали разрешенията се натрупват незабелязано. Те също показват дали мениджърите разбират какъв достъп реално имат техните екипи.

Корпоративната Политика за управление на потребителски акаунти и привилегии изисква:

„Прегледи на всички потребителски акаунти и свързаните с тях привилегии трябва да се извършват на тримесечна база от ИТ сигурност в сътрудничество с ръководителите на отдели.“

От раздел „Изисквания за внедряване на политиката“, клауза 6.5.1.

За МСП Политика за управление на потребителски акаунти и привилегии за МСП определя пропорционален цикъл:

„Преглед на всички потребителски акаунти и привилегии трябва да се извършва на всеки шест месеца.“

От раздел „Изисквания за внедряване на политиката“, клауза 6.4.1.

Надеждният преглед на достъпа включва име на системата, обхват, име на преглеждащото лице, дата на експортиране, дата на прегледа, собственик на идентичността, отдел, мениджър, статус на правоотношението, роля или системно право, флаг за привилегирован достъп, флаг за чувствителност на данните, решение, тикет за отстраняване, дата на приключване, собственик на изключението и дата на изтичане на изключението.

За Zenith Controls права за достъп 5.18 е мястото, където това се превръща в доказателство за кръстосано съответствие. Ръководството съпоставя правата за достъп с GDPR Article 25, защото достъпът трябва да бъде ограничен още при проектирането и по подразбиране. То ги съпоставя с NIS2 Article 21(2)(i), защото политиките за контрол на достъпа и управлението на активите изискват риск-базирано присвояване, своевременно премахване на ненужен достъп и формално отнемане. Съпоставя ги и с DORA, защото финансовите ИКТ системи се нуждаят от ролево базиран достъп, мониторинг и процеси за отнемане.

Одиторите с ориентация към NIST често тестват това чрез AC-2 Account Management, AC-5 Separation of Duties и AC-6 Least Privilege. Одиторите по COBIT 2019 разглеждат DSS05.04 Manage user identity and logical access и DSS06.03 Manage roles, responsibilities, access privileges and levels of authority. Одиторите по ISACA ITAF се фокусират върху това дали доказателствата са достатъчни, надеждни и пълни.

Напускането и отнемането на токени са лесни за извадково тестване

Напускащите служители са едно от най-лесните места за доказване дали жизненият цикъл работи. Одиторите често избират служител с наскоро прекратено правоотношение и искат записа за прекратяване от ЧР, тикета, журнала за деактивиране на акаунта, доказателство за деактивиране в SaaS, премахване на VPN, отнемане на MFA, премахване на API токени и връщане на активи.

В Политика за въвеждане в длъжност и прекратяване на правоотношенията за МСП Clarysec посочва:

„Прекратените акаунти трябва да бъдат заключени или изтрити, а свързаните токени за достъп трябва да бъдат отнети, включително отдалечен достъп (VPN), обвързвания на MFA приложения и API токени.“

От раздел „Изисквания за внедряване на политиката“, клауза 6.3.3.

Това е важно, защото съвременният достъп не е само потребителско име и парола. Достъпът може да се запази чрез refresh токени, API ключове, SSH ключове, OAuth разрешения, служебни акаунти, локални администраторски права, мобилни сесии и портали на трети страни. Деактивиран запис в ЧР без отнемане на токени е непълно доказателство.

Zenith Blueprint, фазата „Контроли в действие“, Стъпка 16, указва на организациите да бъдат готови с документиран контролен списък за прекратяване, доказателства от наскоро напуснало лице, журнал за деактивиране на потребителски акаунт от AD или MDM, подписан формуляр за връщане на активи и документация за напускане, която включва задължения за поверителност.

Одиторът на Мария поиска напускащ старши разработчик, който е имал привилегирован достъп до продукционни бази данни. Екипът ѝ представи Политика за въвеждане в длъжност и прекратяване на правоотношенията за МСП, контролния списък за прекратяване, изграден по Zenith Blueprint Стъпка 16, ITSM тикета, задействан от ЧР, журнала за деактивиране в директорията, отнемането на VPN сертификата, премахването от GitHub организацията, изтриването на AWS IAM ключа и затворения тикет за проверка, подписан от ИТ мениджъра. Доказателствата бяха пълни, своевременни и пряко свързани с политиката.

Изпълнете доказателствен спринт с три извадки преди одитора

Практическо упражнение за готовност е да изберете три извадки преди одита:

1. Нов служител, постъпил през последните 90 дни
2. Привилегирован потребител с администраторски достъп до облак, база данни, продукционна среда или IAM
3. Напуснал служител или служител с променена роля през последните 90 дни

След това свържете всяка извадка със записите в ISMS: сценарий на риска, решение за третиране, избор на контрол в Декларацията за приложимост, клауза от политиката, техническа конфигурация, запис от преглед и коригиращо действие, ако има пропуск.

Това превръща подготовката за одит от събиране на документи в проверка на контролите.

Подгответе се за различни одиторски гледни точки

Различният одиторски опит води до различни въпроси, дори когато доказателствата са едни и същи.

Подготовката на доказателства, които удовлетворяват всички тези гледни точки, показва зряла програма за съответствие и намалява дублирането на работа.

Чести констатации и превантивни действия

Констатациите при контрол на достъпа са предвидими. Превантивните действия също.

Корпоративната Политика за контрол на достъпа добавя изискване за съхранение, което предотвратява един от най-честите откази на доказателства:

„Решенията за одобрение трябва да бъдат журнализирани и съхранявани за целите на одита за минимум 2 години.“

От раздел „Изисквания за управление“, клауза 5.3.2.

Ако одобренията изчезнат след почистване на имейли, контролът може да е действал, но одитът не може да разчита на него. Съхранението е част от дизайна на контрола.

Управленската отчетност се нуждае от показатели за достъпа

NIS2 Article 20 и DORA Articles 5 и 6 превръщат контрола на достъпа в управленски въпрос, защото компрометирането на идентичности може да доведе до оперативно прекъсване, регулаторно докладване, нарушение на сигурността на данните и вреди за клиентите. ISO/IEC 27001:2022 клаузи 5.1 до 5.3 също изискват висшето ръководство да съгласува ISMS с бизнес стратегията, да предоставя ресурси, да комуникира значимостта, да възлага отговорности и да насърчава непрекъснато подобрение.

Полезни показатели за контрол на достъпа включват:

• Процент на критичните системи, обхванати от SSO
• Процент на привилегированите акаунти с MFA
• Брой постоянни привилегировани акаунти спрямо JIT акаунти
• Процент на завършване на прегледите на достъпа
• Брой отнети прекомерни разрешения
• Съответствие със SLA за деактивиране на напускащи
• Брой неактивни акаунти
• Покритие на собствениците на служебни акаунти
• Покритие на запис на PAM сесии
• Брой и възраст на изключенията от MFA

Тези показатели помагат на ръководството да одобрява третиране на риска и да демонстрира надзор. Те също правят одитите по-надеждни, защото организацията може да покаже, че контролът на достъпа се наблюдава като текущ риск, а не се преоткрива преди всеки одит.

Превърнете разпръснатите доказателства в увереност при одит

Ако доказателствата за контрол на достъпа по ISO/IEC 27001:2022 са разпръснати между ЧР, ITSM, IAM, PAM, облачни конзоли и електронни таблици, следващата стъпка не е ново пренаписване на политика. Следващата стъпка е архитектура на доказателствата.

Започнете с тази последователност:

1. Дефинирайте системите, идентичностите и данните в обхвата.
2. Съпоставете изискванията на NIS2, DORA, GDPR и договорните изисквания с контекста на ISMS.
3. Използвайте рискови сценарии в стил ISO/IEC 27005:2022, за да приоритизирате IAM, MFA, PAM и прегледите на правата за достъп.
4. Актуализирайте Декларацията за приложимост и плана за третиране на риска.
5. Съгласувайте клаузите на политиките с реалните работни потоци в IAM и PAM.
6. Изпълнете доказателствения спринт с три извадки.
7. Отстранете пропуските, преди одиторът да ги открие.
8. Поддържайте преизползваем пакет с доказателства за сертификация, клиентска надлежна проверка и регулаторни прегледи.

Clarysec може да ви помогне да внедрите това чрез Zenith Blueprint: An Auditor’s 30-Step Roadmap, да съпоставите изискванията чрез Zenith Controls: The Cross-Compliance Guide и да превърнете изискванията в оперативни процеси с правилния набор от политики на Clarysec, включително Политика за контрол на достъпа, Политика за управление на потребителски акаунти и привилегии и Политика за въвеждане в длъжност и прекратяване на правоотношенията.

Готовността за одит на контрола на достъпа не е въпрос на доказване, че сте закупили IAM инструмент. Тя е въпрос на доказване, че процесите за идентичност, автентикация, привилегии и преглед намаляват реалния бизнес риск и удовлетворяват стандартите и регулациите, които са важни за вашата организация.

Изтеглете инструментариумите на Clarysec, изпълнете доказателствения спринт с три извадки и превърнете доказателствата си за контрол на достъпа от разпиляна маса в ясно, повторяемо и защитимо одиторско портфолио.