Криптиране и управление на ключове: проверете веригата на защита

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

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

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

Определете целта на защитата, преди да изберете технология

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

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

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

За всеки важен поток запишете:

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

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

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

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

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

Симетричната и асиметричната криптография имат различни задачи

Симетричното криптиране използва споделен таен ключ за криптиране и декриптиране. То обикновено се използва за големи обеми данни, защото е ефективно. AES поддържа ключове от 128, 192 и 256 бита, но само етикетът за размера на ключа не описва сигурно внедряване: значение имат също режимът, обработката на nonce, удостоверяването и поведението на библиотеката.

Асиметричната криптография използва свързани публичен и частен ключ. В зависимост от алгоритъма и протокола тя поддържа криптиране, подписи или договаряне на ключове. RSA и конструкциите с елиптични криви имат различни възможности и параметри; те не са взаимозаменяеми етикети. Асиметричната криптография не е по същество „по-сигурна“ от симетричното криптиране.

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

Поверителността не е същото като целостта или автентичността

Удостовереното криптиране, например правилно използваният AES-GCM, защитава поверителността и открива неоторизирани промени в защитения шифротекст и свързаните данни. Повторната употреба на nonce със същия ключ може да подкопае тази защита. Предпочитайте поддържани библиотеки и добре поддържани формати, които обработват тези изисквания безопасно; не измисляйте собствен шифър, режим или протокол за обмен на ключове.

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

Кодът за удостоверяване на съобщения използва тайна, за да провери целостта и автентичността между страните, които споделят тази тайна. Цифровите подписи използват частен ключ за подписване и публичен ключ за проверка; те не правят подписаното съдържание поверително.

Тези разграничения са важни при прегледа. Питайте кое свойство се изисква и кой механизъм го осигурява, вместо да приемате „криптографията“ като една-единствена недиференцирана контрола.

Проверете всеки слой за съхранение и всяко вторично копие

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

Различните слоеве защитават срещу различни пътища за достъп:

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

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

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

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

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

Транспортното криптиране защитава данните, които се движат между крайни точки. Полезният въпрос не е „Използваме ли HTTPS?“, а „Кои връзки са защитени и кои идентичности са удостоверени?“

Картографирайте връзките от браузъра до периферията, от периферията до приложението, между услугите, от приложението до базата данни, репликацията, преноса на резервни копия, административния достъп и експортите към трети страни. Терминирането на TLS при балансьор на натоварването създава граница: следващата стъпка изисква собствено решение за защита. Частната мрежа не премахва автоматично рисковете от прихващане или странично придвижване.

Като практическа основа предпочитайте поддържани съвременни TLS конфигурации и поддържани клиентски библиотеки. TLS 1.3 е силен избор по подразбиране, където се поддържа; подходящо конфигуриран TLS 1.2 може да остане необходим за съвместимост. Наследеният SSL не е подходящ съвременен избор за сигурност.

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

Взаимният TLS може да удостовери двата края на връзката, но не замества оторизацията в приложението. Издаването на сертификати, идентичността на натоварването, подновяването и отнемането стават оперативни зависимости, които се нуждаят от собственици и тестове.

Разграничавайте транспортното криптиране от криптирането от край до край. Услуга, която терминира TLS и обработва открит текст, не осигурява поверителност от край до край спрямо самата себе си. Решенията от край до край запазват декриптирането за определени крайни точки; те пораждат отделни въпроси за регистрирането на устройства, проверката на получателите, достъпа от множество устройства и възстановяването.

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

Управлявайте ключовете като активи с жизнен цикъл

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

Генерирайте и регистрирайте ключовете целенасочено

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

Поддържайте регистър на ключовете, съдържащ предназначение, собственик, среда, защитени системи, алгоритъм, идентификатор на ключа, дата на създаване, статус и зависимости за възстановяване. Записвайте метаданни, а не тайния ключов материал. Разграничавайте ключовете за криптиране, ключовете за подписване, частните ключове за TLS и идентификационните данни за API, защото процедурите при тяхната експозиция и замяна се различават.

Отделете производствената среда от средите за разработка и тестване. Споделянето на ключ между среди разширява въздействието на среда с по-ниско ниво на доверие и затруднява тълкуването на журналите за употреба.

Отделете контрола върху ключовете от достъпа до данните

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

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

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

Ограничете декриптирането до натоварванията, които се нуждаят от него. Където е възможно, отделете администрирането на ключовете от употребата им и от администрирането на хранилището. Проверете дали администратор, който в момента не може да декриптира, може сам да си предостави това право. Аварийният достъп трябва да има изрично одобрение, ограничена продължителност и следа за преглед.

Третирайте ротацията като процес на промяна, а не като отметка

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

Изяснете какво прави „ротацията“ в избраната услуга. Създаването на нова версия на ключа за бъдещо криптиране може да остави историческите данни зависими от по-стари версии. Повторното опаковане на ключовете за данни с нов ключ за криптиране на ключове се различава от декриптирането и повторното криптиране на самите данни. Нито една от тези операции не бива да се предполага само от настройка за автоматична ротация.

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

Разграничавайте отнемането от унищожаването

Отнемането премахва правото или деактивира бъдещата употреба на ключа. То не изтрива вече извлечения открит текст, не обезсилва всеки кеширан ключ за данни и не кара експортирана тайна да изчезне.

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

Поддържайте проектирането на съхранението и изтриването свързано. Безсрочното съхранение на ключове може да подкопае целта за изтриване; преждевременното унищожаване може да предизвика инцидент с наличността.

Оценявайте облачните модели за ключове по действителната им граница на контрол

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

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

Термини като „bring your own key“, „bring your own encryption“ и „encryption as a service“ не са равностойни архитектурни гаранции. Импортирането на ключ в услуга на доставчика не означава непременно, че доставчикът никога не може да извърши декриптиране. Внедряването на криптиране от страна на клиента променя границата на открития текст, но може да усложни функциите на приложението и възстановяването.

Попитайте потенциален доставчик:

• Можем ли да идентифицираме ключа, използван за всеки релевантен ресурс за съхранение и резервно копие?
• Кой може да променя политиките за ключовете и как се записват тези промени?
• Какво се случва, когато ключ е деактивиран или услугата за ключове е недостъпна?
• Как експортът, репликацията, миграцията и закриването на акаунта влияят на защитата?
• Кои събития за употреба са налични и каква дейност остава извън тяхната видимост?

Оценявайте производителността с представителни натоварвания: пропускателна способност, латентност, квоти на услугата за ключове, поведение на кеширането и режими на отказ. Услуга, която работи в малка демонстрация, може да се провали при масово възстановяване. Местоположението на данните и собствеността на клиента върху ключовете са полезни входни данни за проектирането, а не доказателство за суверенитет или регулаторно съответствие.

Изберете решение чрез оперативно изпитване

Сравнявайте кандидатите спрямо картата на защитата, а не спрямо списък с имена на алгоритми. Включете поддръжката на библиотеките, поддържаните платформи, административното разделяне, наличността на доказателства, възможностите за миграция и способността на екипа да управлява услугата. Ако договор изисква валидиран криптографски модул, установете съответния модул, версия, работна среда и обхват на валидирането; само етикетът AES не установява това изискване.

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

Запишете изрично решение за приемане: кои заплахи се адресират, кои зависимости се въвеждат, какво остава извън обхвата и кой е собственик на тези остатъчни рискове. Тествайте и преносимостта. Експортираният шифротекст има малка оперативна стойност, ако неговият формат, опакованите ключове или необходимите метаданни не могат да бъдат интерпретирани след края на отношенията с услугата.

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

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

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

Документирайте версиите на ключовете, необходими за всяко поколение резервни копия, изискваните идентичности, стъпките за одобрение, зависимостите от доставчици и ограниченията за възстановените данни. Възстановяването в тестова среда не бива тихомълком да разкрива производствена информация на разработчиците.

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

Включете отказа на услугата за ключове в тестовете за устойчивост. Решете дали дадено натоварване трябва да се затвори при отказ, да опита отново или да използва одобрен кеширан ключ. Кеширането може да подобри наличността, но удължава периода, през който процесът може да декриптира след премахване на централния достъп. Документирайте този компромис изрично.

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

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

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

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

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

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

Изградете доказателства, които тестват веригата

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

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

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

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

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

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

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

Да приемем, че илюстративна SaaS услуга съхранява поверителни клиентски документи в обектно хранилище. Приложението ѝ извлича документи за удостоверени потребители, а ежедневните резервни копия подкрепят определена от бизнеса цел за възстановяване. Разглежданите заплахи са откраднати копия от хранилището, неоторизиран административен достъп и разкриване между наематели.

Екипът картографира TLS от браузъра до периферията, TLS от периферията до приложението, връзките от приложението до хранилището, производствения bucket и отделно местоназначение за резервни копия. Той открива, че задача за експорт при отстраняване на проблеми записва декриптирани файлове в папка за поддръжка. Тази папка веднага става елемент от обхвата; настройката за криптиране на производствения bucket не я обхваща.

В първоначалния дизайн криптирането на хранилището с ключ, управляван от клиента, защитава производствените обекти. Идентичността на приложението може да извлича оторизирани обекти и да извиква необходимите операции с ключове. Ролята за внедряване може да създава ресурси, но няма рутинно право за декриптиране. Администрирането на политиките за ключовете следва отделен път за одобрение.

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

Проверката дава конкретни резултати:

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

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

Този пример не установява защита срещу всяка атака. Той установява кои заплахи адресира дизайнът, на коя идентичност все още се доверява и какви доказателства подкрепят тези заключения.

Свържете правните изисквания и бъдещите промени с дизайна

Решенията за криптиране трябва да отразяват правните, договорните и рамковите изисквания, без да ги превръщат в общи твърдения. Член 32 от ОРЗД използва подход, основан на риска, и включва криптирането сред подходящите мерки; той не налага универсално задължение за криптиране за всяка дейност по обработване. Криптирането също не премахва задълженията, свързани със законосъобразното обработване, достъпа, съхранението или оценката на инциденти.

В рамките на ISMS по ISO 27001 с определен обхват документирайте третирането на риска, приложимите контроли, собствеността и доказателствата, вместо да приемате, че една криптирана база данни удовлетворява цялата система за управление. Когато NIS2 се прилага чрез национален закон, нейните мерки по член 21 включват политики и процедури относно криптографията и, когато е целесъобразно, криптирането. Потвърдете приложимостта и националните изисквания отделно.

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

Направете следващия преглед конкретен

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

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