Управління ідентифікацією та адміністрування для оборонних організацій

Управління ідентифікацією та адміністрування (IGA) — це дисципліна систематичного контролю того, хто має доступ до чого, протягом якого часу та на якій підставі, а також формування документальних доказів того, що доступ є відповідним у кожний момент часу. У комерційній організації IGA керує ролями, правами доступу та регулярними перевірками в рамках кадрового життєвого циклу. В оборонній організації IGA повинна виконувати все це і водночас забезпечувати другий рівень контролю доступу, побудований на основі рівнів допуску до державної таємниці, членства в компартментах, визначень «потреби знати» та програмних авторизацій. Розрив між цими двома постановками задачі — саме там, де більшість комерційних розгортань IGA зазнають невдачі при перенесенні в оборонне середовище. У цій статті розглядаються інженерні рішення, що закривають цей розрив: provisioning з урахуванням допуску, інжиніринг ролей для середовищ з кількома рівнями класифікації, розподіл обов'язків в умовах малих команд, проєктування сертифікації доступу, інтеграція CAC/PIV та архітектура журналу аудиту, необхідна для проходження акредитації RMF. Щодо рівня брокерингу облікових даних, від якого залежить IGA під час привілейованого доступу, дивіться наш матеріал про управління привілейованим доступом в обороні.

Чому IGA в обороні відрізняється від корпоративного середовища — рівні допуску як додатковий вимір доступу, управління компартментами, виконання вимоги «потреби знати»

У комерційній організації контроль доступу має два значущі виміри: хто є користувач (ідентифікація) та до якої ролі або групи він належить (право доступу). Оборонна організація додає третій вимір, ортогональний до обох: до чого користувач має допуск та авторизацію. Старший мережевий інженер може мати дійсний допуск SECRET, але не мати авторизації на доступ до розвідувального компартменту, що функціонує в тій самій мережі рівня SECRET. Молодший аналітик може мати допуск TOP SECRET і бути конкретно введеним у компартмент, до якого старший інженер не введений. Ні рівень старшинства, ні організаційна ієрархія не вирішують ці питання — тільки формальний запис авторизації.

Комерційні платформи IGA — SailPoint IdentityNow, Saviynt, Omada, One Identity — розроблені для двовимірного завдання. Вони можуть зберігати власні атрибути і при достатній кастомізації можуть застосовувати обмеження рівня допуску, але вони не моделюють нативно компартменти, застереження щодо поводження або програмні авторизації як першокласні об'єкти. Платформа дозволить вам додати власний атрибут «clearance_level» і написати правило provisioning, яке його перевіряє. Але платформа — без спеціальної розробки — не підтримуватиме живий канал із системи кадрової безпеки, не розрізнятиме офіційний запис про введення в SCI та самодеклараційне твердження про допуск, і не моделюватиме решітку компартментів з їх власними процесами введення та виведення.

Виконання вимоги «потреби знати» — це найгостріша відмінність. У корпоративній IGA доступ зазвичай надається до класу ресурсів — «цей користувач може отримати доступ до сховища даних Фінансів». В обороні доступ до того самого ресурсу може бути наданий користувачу A, але не користувачу B, навіть якщо обидва мають правильний допуск, тому що користувач B не був офіційно введений у програму, яка виробляє ці дані. IGA повинна забезпечити це на етапі provisioning і на етапі повторної сертифікації, запитуючи авторитетні записи доступу до програм, а не покладаючись на підтвердження менеджера. Розрив між «мій менеджер схвалив мій доступ» і «авторитетний запис підтверджує, що я введений у цю програму» — це саме той розрив, який призводить до висновків аудиту і, в найгірших випадках, до несанкціонованого розголошення.

Практичний висновок полягає в тому, що розгортання IGA в обороні вимагає розробки конекторів і кастомізації процесів, що виходять за межі того, з чим постачається будь-який готовий продукт IGA. Закладіть бюджет на це заздалегідь, розглядайте канали даних про допуски та компартменти як найбільш критичну роботу з інтеграції в проєкті, і розгляньте, чи можна розширити існуючий комерційний продукт для виконання вимоги, чи правильним відправним пунктом є спеціалізоване оборонне рішення IGA (наприклад, побудоване на архітектурі корпоративного сервісу ідентифікаційних даних IC). Модель нульової довіри для оборонного програмного забезпечення залежить від того, чи надає IGA точні, постійно підтверджені дані про права доступу — без цього рушії політик приймають рішення про авторизацію на основі застарілих або неперевірених атрибутів ідентичності.

Життєвий цикл joiner-mover-leaver у засекреченому середовищі — автоматизовані тригери provisioning, інтеграція перевірки допуску, переходи ролей при переведенні

Життєвий цикл joiner-mover-leaver (JML) є фундаментальним операційним циклом будь-якого розгортання IGA. В обороні кожна фаза циклу має додаткові обмеження, які його сповільнюють, але також роблять наслідки помилки більш значущими.

Процес joiner. Подія joiner спрацьовує, коли авторитетна система HR або кадрового обліку створює новий запис — новий найм, новий підрядник, нове тимчасове призначення. В обороні provisioning не повинен розпочинатися, доки платформа IGA самостійно не підтвердить ад'юдикований рівень допуску особи з системи кадрової безпеки (JPAS або DISS в контексті Міністерства оборони США; національні аналоги в організаціях оборони союзників) і не підтвердить дійсне DN карти CAC або PIV із системи реєстрації. Послідовність важлива: перевірка допуску є воротами для provisioning, а не навпаки. Платформа IGA, яка спочатку створює обліковий запис, а потім перевіряє допуск у фоновому завданні, вже створила вразливе вікно для атаки.

Процес joiner також повинен ініціювати перевірку доступу до компартменту для будь-якого права доступу, що вимагає офіційного введення в програму. Якщо запис про введення існує в авторитетній системі доступу до програм, provisioning продовжується. Якщо ні — право доступу пригнічується і створюється завдання для офіцера безпеки для ініціювання офіційного процесу введення. Обліковий запис існує; конфіденційне право доступу — ні, доки не існує паперовий запис для його обґрунтування.

Процес mover. Переведення в оборонних організаціях відбувається часто і має важливі наслідки. Людина, що переходить з однієї програми на іншу, зазвичай втрачає доступ до систем першої програми і отримує доступ до систем другої. Процес mover у IGA повинен детерміновано вирішувати цей перехід: обчислити різницю прав доступу між старим і новим набором ролей, відкликати те, що більше не є відповідним, і надати те, що тепер є обґрунтованим — усе це з урахуванням тих самих перевірок допуску та компартменту. Якщо нова роль вимагає вищого допуску, ніж той, що є у особи, обліковий запис для цього рівня класифікації пригнічується до підтвердження підвищення допуску.

Складнішим випадком mover є тимчасове відрядження (TDY) або прикомандирування. Особа зберігає набір ролей своєї основної частини і отримує обмежений у часі додатковий набір ролей на час виконання призначення. IGA повинна моделювати це без надання особі постійно підвищеного доступу, що зберігається після завершення призначення. Правильним підходом є часово обмежені призначення ролей з автоматичним закінченням терміну, перевірені офіцерами безпеки як основної, так і приймаючої частини.

Процес leaver. Процес leaver — ініційований звільненням, закінченням контракту, виходом на пенсію або відкликанням допуску — є фазою з найвищими ставками і тією, де комерційні розгортання IGA найчастіше виявляються недостатніми в обороні. Очікується деprovisioning усіх облікових записів в усіх підключених системах у той самий день, незалежно від того, чи повернула особа фізично свою карту CAC, чи вийшла зі своєї робочої станції, чи виконала будь-який процес відрядження в HR. Платформа IGA не повинна чекати, поки запис в HR досягне статусу «завершено», перш ніж відкликати доступ — тригером є подія відкликання допуску з системи кадрової безпеки, яка повинна поширюватися в режимі, близькому до реального часу.

# Цільові показники SLA процесу leaver (оборонний контекст)
clearance_revocation_to_AD_disable:   < 1 year
AD_disable_to_all_app_deprovisioning: < 4 hours
CAC_invalidation_propagation:         < 1 hour (DEERS → connected systems)
audit_closure_record_generated:       same business day
physical_access_revocation:           same day (physical security system integration)

Інжиніринг ролей для середовищ з кількома рівнями класифікації — проєктування моделі ролей, набори ролей з урахуванням допуску, гібридна модель на основі атрибутів та ролей для компартментів

Інжиніринг ролей — процес визначення та підтримки моделі ролей, яку забезпечує платформа IGA, — є найбільш трудомісткою частиною розгортання IGA в обороні і тією, яка найімовірніше накопичує технічний борг при неналежному виконанні. Фундаментальне обмеження полягає в тому, що ролі повинні бути стабільними при організаційних змінах, оскільки кожна зміна ролі в платформі IGA є адміністративною подією, що вимагає управління змінами, повторного тестування і, можливо, кампанії повторної сертифікації.

Перше проєктне рішення — розділення доменів. Оборонні організації діють у кількох доменах класифікації — як мінімум UNCLASSIFIED і SECRET, часто також TOP SECRET та один або кілька анклавів SCI. Ролі повинні бути визначені окремо для кожного домену і зберігатися в окремих екземплярах каталогу. Роль «аналітик» у домені UNCLASSIFIED і роль «аналітик» у домені SECRET — це не одна й та сама роль: вони несуть різні права доступу, різні передумови допуску і управляються різними офіцерами безпеки. Їх об'єднання в одну міждоменну роль є архітектурною помилкою, яку акредитори виявлять негайно і яка створює реальний ризик витоку прав доступу між доменами.

В рамках кожного домену ролі повинні бути функціональними, а не організаційними. Організаційна роль — «член розвідувальної комірки 3-ї ескадрильї» — стабільна лише доти, доки стабільна організація. Функціональна роль — «розвідувальний аналітик, засекречені системи» — переходить разом із функцією особи через організаційні межі і витримує реорганізації, що відбуваються кожні вісімнадцять місяців у більшості оборонних структур. Функціональні ролі також краще поєднуються: людина з подвійною роллю (аналітик і адміністратор секції) отримує дві функціональні ролі, кожна з яких управляється та сертифікується незалежно.

Управління компартментами вимагає рівня контролю доступу на основі атрибутів (ABAC) поверх основи RBAC. Роль визначає, що може робити людина; атрибути компартменту в її записі ідентичності визначають, що вона може бачити при цьому. Ця гібридна модель — RBAC для структурних прав доступу, ABAC для фільтрації на рівні даних — є архітектурою, яка масштабується до складності реальної оборонної організації без необхідності створювати нову роль щоразу, коли створюється новий компартмент.

# Схема атрибутів ідентичності (спрощена)
{
  "dn": "CN=J.Smith,OU=SECRET,DC=mil",
  "clearance_level": "SECRET",
  "compartments": ["ALPHA", "BRAVO"],
  "programs": ["PGM-001", "PGM-004"],
  "roles": ["intelligence-analyst-s", "portal-user-s"],
  "card_dn": "CN=SMITH.JANE.1234567890,OU=DoD,O=U.S. Government,C=US",
  "clearance_expiry": "2028-03-15",
  "last_certified": "2026-04-01"
}

Управління життєвим циклом ролей — додавання, модифікація та вилучення ролей — вимагає окремого процесу управління від управління життєвим циклом користувачів. Нові ролі повинні вимагати схвалення офіцером безпеки, аналізу впливу на права доступу та валідації в тестовому середовищі перед переведенням у виробниче. Вилучені ролі вимагають плану міграції, що переводить поточних власників ролей на замінні ролі до видалення старої, запобігаючи утворенню «осиротілих» прав доступу в підключених системах.

Розподіл обов'язків в оборонних програмах — проєктування правил SoD для закупівель та забезпечення, компенсаційні засоби контролю для винятків малих команд

Розподіл обов'язків (SoD) — це принцип контролю, відповідно до якого жодна окрема особа не повинна мати обидві сторони ризикованої транзакції: можливість і ініціювати, і схвалювати фінансове зобов'язання, або і запитувати, і надавати власний доступ, або і писати, і сертифікувати програмний реліз. У середовищах оборонних закупівель і забезпечення збої SoD призвели до деяких найбільш витратних випадків шахрайства та неналежного управління: офіцер з контрактів, який міг також сертифікувати платежі за рахунками; системний адміністратор, який міг змінювати як код застосунку, так і його контроль доступу; менеджер з логістики, який міг і замовляти, і сертифікувати отримання матеріальних засобів.

IGA застосовує SoD через набір правил, що виявляє конфліктуючі пари прав доступу і запобігає тому, щоб будь-яка окрема особа мала обидва. Набір правил повинен бути спроєктований з урахуванням специфічних ризикованих процесів оборонних закупівель, а не запозичений із шаблону комерційного фінансового сектора. Ключові конфліктні пари в оборонних контекстах включають:

• Ініціювання та затвердження контракту (SoD у закупівлях)
• Подача запиту на доступ та його схвалення (SoD у IAM)
• Коміт коду та авторизація розгортання коду (SoD у DevSecOps)
• Генерація криптографічного ключа та сертифікація зберігача ключа
• Авторизація утилізації активів та сертифікація отримання активів
• Внесення фінансового зобов'язання та його сертифікація

Інженерний виклик в обороні полягає в тому, що багато програм виконуються дуже малими командами — іноді менше десяти чоловіків із допуском, які охоплюють усі ролі. Правило SoD, що вимагає двох різних людей для конфліктуючих прав доступу, може бути нездійсненним у три особи передовому підрозділі. Правильна відповідь IGA полягає не у відключенні правил SoD для малих команд; вона полягає у впровадженні структурованого процесу виключень з компенсаційними засобами контролю.

Компенсаційний засіб контролю для виключення SoD повинен включати: задокументоване прийняття ризику, підписане уповноваженою посадовою особою; посилений прапор аудиту для всіх транзакцій, виконаних власником виключення, щоб кожна така транзакція відображалася в наступному огляді відповідності; обов'язкову вимогу вторинного огляду (транзакція є завершеною, але інша особа з допуском повинна переглянути та завірити її в межах визначеного часового вікна); і дату закінчення виключення, яка ініціює повторну оцінку, а не тихе продовження.

Правила SoD також виявляються під час кампаній сертифікації доступу. Коли рецензент повторної сертифікації схвалює доступ для особи, яка має конфліктуючу пару прав доступу, платформа IGA повинна відобразити конфлікт у явному вигляді і вимагати явного рішення про перевизначення, а не мовчки дозволяти схвалення. Кожне перевизначення записується як виключення сертифікації в журналі аудиту, гарантуючи, що акредитор може бачити не лише те, який доступ існує, але й які конфлікти SoD були свідомо прийняті та ким.

Кампанії сертифікації доступу — частота кампаній для доступу до засекречених систем, автоматизоване призначення рецензентів за ланцюгом керівництва, пакетна та ризик-орієнтована повторна сертифікація

Сертифікація доступу — це циклічний процес надання кожному рецензенту поточних прав доступу користувача для підтвердження того, що доступ залишається відповідним. В обороні це також основний механізм, за допомогою якого організація демонструє безперервну відповідність контролям AC-2 та пов'язаним з ними — питання акредитора «чи можете ви довести, що весь доступ до цієї системи наразі авторизований?» відповідає запис кампанії сертифікації.

Мінімальна вимога NIST 800-53 AC-2(j) передбачає щорічний огляд усіх облікових записів, але оборонна практика і більшість рекомендацій щодо акредитації очікують більшого. Практичний графік кампаній для засекречених систем:

• Щоквартально: привілейовані облікові записи (системні адміністратори, офіцери безпеки, сервісні облікові записи з підвищеними правами), облікові записи на міждоменних рішеннях, системах управління криптографічними ключами та розвідувальних сховищах
• Кожні півроку: всі облікові записи користувачів у системах SECRET та вище; облікові записи з доступом до функцій фінансових зобов'язань та контрактування
• Щорічно: облікові записи систем UNCLASSIFIED; облікові записи лише для читання без можливостей запису або привілейованих функцій
• На основі подій: будь-який обліковий запис особи, яка змінює роль, програму або підрозділ; будь-який обліковий запис у системі, що завершила значну зміну; будь-який обліковий запис, де відбулося поновлення, підвищення або пониження допуску

Автоматизоване призначення рецензентів є критичним в оборонних середовищах, де організаційні структури часто змінюються і платформа IGA не може покладатися на статичне відображення рецензентів. Правильним джерелом призначення рецензентів є авторитетний ланцюг керівництва з системи HR — коли платформа IGA генерує кампанію сертифікації, вона запитує поточний запис керівника для кожної ідентичності і призначає огляд цьому керівнику. Якщо посада керівника вакантна (часта ситуація в розгорнутих середовищах), ланцюг автоматично переходить до керівника наступного рівня, з визначеним таймаутом ескалації, який ініціює перевизначення офіцером безпеки.

Пакетна сертифікація — надання всіх прав доступу для групи користувачів одночасно — підходить для піврічних та річних кампаній, де метою є всебічний огляд. Ризик-орієнтована сертифікація є кращою для частих перевірок: замість того, щоб щоквартально надавати весь набір прав привілейованого користувача, платформа IGA визначає, які права доступу змінилися, які використовувалися (а які ні) і які несуть конфлікти SoD, і надає лише ці для цілеспрямованого огляду. Невикористані права доступу — привілейована роль, надана шість місяців тому і жодного разу не застосована — є найбільш цінними знахідками ризик-орієнтованої кампанії; вони являють собою доступ, що існує на папері, але коштує організації нічого для відкликання, а їх видалення негайно зменшує поверхню атаки, задокументовану в моделі ризиків виявлення внутрішніх загроз в обороні.

Рівні завершеності кампаній є запізнілим індикатором стану програми. Кампанія, яка досягає 95% завершеності з 5% виключень, є обґрунтованою. Кампанія, яка досягає 60% завершеності, оскільки рецензенти ігнорували сповіщення, — це знахідка аудиту, що чекає свого часу. Платформи IGA повинні ескалувати незавершені огляди по ланцюгу керівництва з наростаючою терміновістю, і офіцери безпеки повинні мати видимість інформаційної панелі щодо рівнів завершеності кампаній у реальному часі, а не виявляти проблему завершеності в кінці дедлайну кампанії.

Інтеграція з HR, постачальниками ідентифікаційних даних та CAC/PIV — архітектура інтеграції для PKI Міністерства оборони США/союзних держав, provisioning прив'язаний до CAC/PIV, поширення відкликання допуску в реальному часі

Архітектура інтеграції для оборонної платформи IGA є більш складною, ніж будь-яке комерційне розгортання, оскільки охоплює кілька авторитетних систем, що не мають спільного API-контракту, працюють на різних рівнях класифікації і належать різним організаціям.

Якорем ідентичності в контексті Міністерства оборони США є Common Access Card (CAC). Кожен кадровий військовослужбовець, резервіст на службі та більшість цивільних і підрядних працівників мають її. CAC містить три сертифікати PKI (ідентифікаційний, для електронної пошти та для підписання вмісту), відмінювані імена (DN) яких є стабільним авторитетним ідентифікатором особи в усіх підключених системах. Модель облікового запису платформи IGA повинна будуватися навколо DN CAC, а не навколо адреси електронної пошти або ідентифікатора співробітника, оскільки вони можуть змінюватися, тоді як DN CAC залишається стабільним при поновленні карток.

Дані про видачу та поновлення карток CAC надходять із Defense Enrollment Eligibility Reporting System (DEERS) через Real-time Automated Personnel Identification System (RAPIDS). Інтеграція IGA з DEERS/RAPIDS забезпечує три критичні події: видача картки (ініціює активацію облікового запису), поновлення картки (ініціює поширення оновлення DN до всіх підключених систем) і відкликання картки (ініціює негайне призупинення облікового запису). Поширення відкликання повинно бути практично в реальному часі — відкликана картка CAC, яка ще надає доступ до системи протягом 24 годин, тому що платформа IGA опитує DEERS раз на день, є порушенням вимог відповідності та потенційним інцидентом безпеки. Ціль — поширення менше ніж за годину для подій відкликання, досягнута через вебхуки, що ґрунтуються на подіях, або канал delta-sync з високою частотою, а не пакетне опитування.

Поширення відкликання допуску має ту саму вимогу. Потік такий: офіцер кадрової безпеки відкликає допуск у JPAS/DISS → платформа IGA отримує подію → всі облікові записи на відкликаному рівні допуску та вище призупиняються → підключені системи поширюють призупинення через власні конектори IGA. Платформа IGA є рівнем оркестрації; кожна підключена система відповідає за застосування призупинення через власні засоби контролю доступу, а не покладається на те, що платформа IGA окремо викликатиме API кожної системи.

Для союзних оборонних організацій, що працюють під PKI союзних держав, архітектура інтеграції слідує тій самій схемі з національними центрами сертифікації PKI замість PKI Міністерства оборони США. Платформа IGA повинна довіряти відповідному національному якорю довіри та аналізувати структуру DN сертифікатів національного PKI, яка відрізняється від формату Міністерства оборони США. Міждоменні сценарії — офіцер зв'язку США, що діє в мережі держави-партнера, — вимагають федерації між якорями довіри, як правило, реалізованої через PKI-міст або місійну угоду про федерацію, яку платформа IGA перетворює у тимчасову прив'язку ідентичності.

# Топологія інтеграції IGA
HR system (DCPDS / SAP) ──→ [IGA platform] ←── Personnel security (JPAS/DISS)
                                   ↑
DEERS/RAPIDS (CAC events) ─────────┘
                                   ↓
           ┌───────────────────────┼───────────────────────┐
           ↓                       ↓                       ↓
   AD (UNCLASSIFIED)        AD (SECRET)           AD (TS/SCI)
           ↓                       ↓                       ↓
   App connectors           App connectors         App connectors
   (NIPR systems)           (SIPR systems)         (JWICS systems)

Журнали аудиту та звітність про відповідність вимогам — контролі AC/IA за NIST 800-53, вимоги до журналу аудиту для доступу до засекречених систем, формування доказів відповідності

Журнал аудиту, що формується платформою IGA, є основним доказовим артефактом для сімей контролів доступу та ідентифікації й автентифікації при оцінці NIST 800-53. Правильне налаштування цього не є опціональним — це різниця між пакетом акредитації, що демонструє безперервну відповідність, і пакетом, що ініціює Plan of Action and Milestones (POA&M) для кожної знахідки контролю доступу.

Журнал аудиту IGA повинен фіксувати кожну подію provisioning та de-provisioning на рівні транзакцій. Кожен запис повинен містити: ідентичність, якої це стосується, право доступу, надане або відкликане, час події, підставу, на якій була виконана подія (автоматизований процес, схвалення менеджера, перевизначення офіцером безпеки або рішення кампанії сертифікації), і стабільне посилання на вихідну подію, що ініціювала дію (зміна запису в HR, подія допуску, рішення сертифікації). Такий рівень деталізації підтримує три різні сценарії використання аудиту: реконструкцію стану доступу в будь-який момент в минулому, розслідування конкретної події доступу та агреговану звітність про відповідність по всій групі користувачів.

Контролі NIST 800-53, що найбільш безпосередньо підтверджуються даними аудиту IGA, є:

• AC-2 (Управління обліковими записами): записи життєвого циклу IGA демонструють, що облікові записи створюються лише для авторизованих осіб, переглядаються з визначеною частотою та деактивуються при звільненні осіб
• AC-5 (Розподіл обов'язків): журнали застосування правил SoD та записи про виключення демонструють, що конфліктуючі обов'язки ідентифіковані та управляються
• AC-6 (Мінімальні привілеї): записи інжинірингу ролей та аналіз невикористаних прав із кампаній сертифікації демонструють, що доступ обмежений до мінімально необхідного
• IA-2 (Ідентифікація та автентифікація): записи прив'язки CAC/PIV демонструють, що багатофакторна автентифікація застосовується для всіх облікових записів у засекречених системах
• IA-4 (Управління ідентифікаторами): записи joiner та leaver демонструють, що ідентифікатори облікових записів призначаються та деактивуються в рамках визначеного процесу управління
• IA-5 (Управління засобами автентифікації): записи прив'язки та відкликання карток демонструють, що засоби автентифікації управляються та відкликаються у контрольований та своєчасний спосіб

Звітність про відповідність із платформи IGA повинна бути спроєктована так, щоб формувати заздалегідь відформатовані пакети доказів, а не необроблені експорти журналів. Акредитор, якому запропоновано оцінити AC-2, повинен мати можливість отримати звіт, що показує всі активні облікові записи, дату останнього огляду кожного з них, чи є прострочені для сертифікації, і кількість виключень — а не журнал подій із 500 000 рядків і прохання «розберіть самостійно». Проєктування цих звітів до першого огляду акредитації та валідація того, що звіти точно відображають реалізацію контролю, є різницею між дводенним процесом збору доказів і двотижневою кризою.

Незмінність журналу аудиту вимагає сховища з одноразовим записом або криптографічного ланцюжка хешів. Оборонні вимоги щодо зберігання журналів доступу до засекречених систем зазвичай становлять 3–7 років залежно від місії системи та рівня класифікації; деякі ядерно-суміжні та стратегічні системи мають більш тривалі вимоги щодо зберігання. Рівень зберігання повинен бути розрахований і керований відповідно з процедурами отримання, що функціонують, коли оригінальний програмний стек більше не підтримується. Вимога до зберігання, яка виконується в перший день, але дає нечитабельні журнали на шостий рік, є порушенням відповідності на тому часовому горизонті, що має значення.