По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Универсальный уникальный идентификатор (UUID - Universally Unique Identifier) – это форма идентификатора, которую можно с уверенностью признать уникальной для большинства практических целей. Даже если два UUID были сгенерированы в двух различных средах двумя сторонами, они имеют ничтожные шансы на то, чтобы оказаться идентичными. Именно поэтому UUID считаются универсально уникальными.
В этой статье мы с вами рассмотрим характеристики UUID, то, как работает их уникальность, и сценарии, для которых они могут упростить процесс идентификации ресурсов. Несмотря на то, что мы будем рассматривать UUID с точки зрения программного обеспечения, которое взаимодействует с записями базы данных, их также можно применять и в других ситуациях, где требуется децентрализованная генерация уникальных идентификаторов.
Что такое на самом деле универсальный уникальный идентификатор (UUID)?
UUID – это просто значение, которое с уверенностью можно рассматривать как уникальное. Вероятность обнаружения двух одинаковых UUID настолько мала, что ее можно просто игнорировать. Вы можете встретить и другие термины для UUID, например, GUID (Globally Unique Identifier, - глобальный уникальный идентификатор) (такой вариант предпочитает Microsoft), однако смысл и свойства остаются теми же.
Истинный UUID – это уникальный идентификатор, который был сгенерирован и представлен в стандартизированном формате. Допустимые UUID определены в спецификации RFC 4122. Она описывает алгоритмы, которые можно использовать для генерации UUID, которые бы сохраняли свою уникальность в различных реализациях без участия основной выдающей стороны.
В RFC есть пять различных алгоритмов. У каждого из этих алгоритмов есть свой собственный механизм генерации значений. Ниже приведено краткое описание доступных «версий»:
Версия 1 – Time-Based – объединяет метку времени, тактовую последовательность и значение, которое является характерным для генерирующего устройства (как правило, это MAC-адрес); таким образом создается выходное значение, которое является уникальным для этого хоста на определенный момент времени.
Версия 2 – DCE Security – эта версия была создана как модификация Версии 1, которую можно использовать в среде распределенных вычислений (DCE - Distributed Computing Environment). Применяется не так часто.
Версия 3 – Name-Based (MD5) – MD5 хеширует «пространство имен» и «имя» для того, чтобы создать значение, которое будет уникальным для этого имени в пределах пространства имен. Попытка создать другой UUID с тем же пространством имен и тем же именем приведет к тому, что вы получите идентичный результат. Так что, этот метод дает воспроизводимые результаты.
Версия 4 – Random – большинство современных систем выбирают именно эту версию, поскольку здесь для получения выходного значения используется источник случайных и псевдослучайных чисел. Вероятность того, что будут созданы два одинаковых UUID, ничтожна мала.
Версия 5 – Name-Based (SHA-1) – эта версия в какой-то степени похожа на Версию 3, но здесь для хеширования пространства имен и имени используется более криптостойкий алгоритм SHA-1.
Хоть в RFC алгоритмы и обозначены как «версии», это ни в коем случае не значит, что всегда нужно использовать Версию 5, потому что она вроде бы самая новая. Выбор версии зависит от вашего варианта использования; зачастую выбирается Версия 4 из-за случайного характера генерации значений. Именно это делает ее идеальным вариантом для простых сценариев из разряда «дайте мне новый идентификатор».
Алгоритмы генерации на выходе дают 128-битное целое число без знака. Но при этом UUID чаще всего рассматривают как шестнадцатеричные строки. Также их можно хранить в виде двоичной последовательности из 16 символов. Ниже приведен пример UUID:
16763be4-6022-406e-a950-fcd5018633ca
Значение записано с помощью пяти групп буквенно-числовых символов, разделенных дефисом. Последние не являются обязательными составляющими строки; их наличие связано с историческими тонкостями спецификации UUID. А еще они значительно облегчают зрительное восприятие идентификатора.
Варианты использования UUID
В основном UUID используют для децентрализованного создания уникальных идентификаторов. Вы можете создать UUID где угодно и с уверенностью сказать, то он уникальный, независимо от того, был он создан на вашем сервере, в клиентском приложении или в вашей базе данных.
UUID упрощают определение и обеспечение идентичности объекта в изолированных средах. Согласно сложившейся практике, большинство приложений в качестве первичного ключа используют целочисленное поле с автоинкрементом. В таком случае, когда вы создаете новый объект, то вы не узнаете его идентификатор до тех пор, пока не добавите его в базу данных. С помощью UUID вы можете определить идентификатор в вашем приложении намного раньше.
Ниже приведен демонстрационный пример, написанный на PHP, который покажет разницу. Для начала давайте посмотрим на целочисленную систему:
class BlogPost {
public function __construct(
public readonly ?int $Id,
public readonly string $Headline,
public readonly ?AuthorCollection $Authors=null) {}
}
#[POST("/posts")]
function createBlogPost(HttpRequest $Request) : void {
$headline = $Request -> getField("Headline");
$blogPost = new BlogPost(null, $headline);
}
Мы должны инициализировать свойство
$Id
как
null
, поскольку мы не будем знать его фактический идентификатор до тех пор, пока не добавим его в базу данных. Это не самый идеальный вариант –
$Id
не должен обнуляться, из-за этого экземпляры
BlogPost
находятся в незавершенном состоянии.
Перейдем к UUID; это решит проблему:
class BlogPost {
public function __construct(
public readonly string $Uuid,
public readonly string $Headline,
public readonly ?AuthorCollection $Authors=null) {}
}
#[POST("/posts")]
function createBlogPost(HttpRequest $Request) : void {
$headline = $Request -> getField("Headline");
$blogPost = new BlogPost("16763be4-...", $headline);
}
Идентификаторы публикаций теперь можно создавать прямо в приложении, не думая о том, что они могут повториться. Это гарантирует, что экземпляры объекта всегда находятся в действительном состоянии и что ну нужно присваивать ID нулевое значение. Также эта модель упрощает обработку транзакционной логики; дочерние записи, которым нужна ссылка на родителя (например, взаимосвязи автора (
Author
) нашей публикации), могут быть добавлены немедленно, и не нужно обращаться к базе данных для того, чтобы получить идентификатор родителя.
В перспективе большую часть логики данного приложения-блога можно будет переместить на клиентскую сторону. Возможно, внешний интерфейс сможет поддерживать полностью автономное создание черновиков, по сути создавая экземпляры
BlogPost
, которые будут временно сохраняться на устройстве пользователя. Теперь клиент может создавать UUID для публикации и, если ему нужно будет восстановить подключение к сети, передавать его на сервер. Если в обозримом будущем клиент получит копию черновика с сервера, то он сможет сравнить ее с любым сохранившимся локальным состоянием, так как он уже будет знать UUID.
С помощью UUID можно комбинировать данные из различных источников. Объединение таблиц базы данных и кэшей, которые используют целочисленные первичные ключи, может оказаться довольно трудоемким процессом, и, плюс ко всему, в процессе могут возникать ошибки. UUID обеспечивает уникальность идентификатора не только внутри таблиц, но и на уровне всего пространства. Это делает их более предпочтительным вариантом для дублируемых структур и данных, которые часто необходимо перемещать из одной системы хранения в другую.
Нюансы, возникающие при встрече UUID с базами данных
Преимущества UUID довольно привлекательны. Однако есть несколько подводных камней, о которых следует помнить при использовании UUID в реальных системах. Один из значительных факторов в пользу целочисленных идентификаторов – их легко масштабировать и оптимизировать. Механизмы управления базами данных могут с легкостью индексировать, сортировать и фильтровать список чисел, которые идут одно за другим.
А вот про UUID такого сказать нельзя. Прежде всего, UUID в четыре раза больше, чем целое число (36 против 4 байтов); для больших наборов данных этот факт уже может быть существенным моментом. Такие значения намного сложнее сортировать и индексировать, особенно если речь идет о случайных UUID, которые являются самыми популярными. Их случайный характер говорит о том, что они не имеют естественного порядка. Если вы используете UUID в качестве первичного ключа, то это может навредить производительности при индексировании.
Все эти проблемы могут усугубляться в хорошо нормализованной базе данных, которая активно использует внешние ключи. В таком случае у вас может оказаться большое количество реляционных таблиц, каждая из которых хранит ссылки на ваши 36-байтные UUID. В конечном счете, дополнительная память, которая необходима для выполнения операций объединения и сортировки, может негативно сказаться на производительность вашей системы.
У вас есть возможность немного сгладить нежелательные последствия, сохранив свои UUID в виде двоичных данных. Это значит, что вместо столбца
VARCHAR(36)
у вас будет столбец
BINARY(16)
. Некоторые базы данные, например, PostgreSQL, имеют встроенный тип данных
UUID
; другие, например, MySQL, имеют специальные функции, которые преобразовывают строку UUID в двоичную форму и наоборот. Такой подход, конечно, более эффективный, но не забывайте, что вам по-прежнему придется использовать дополнительные ресурсы для хранения и выборки данных.
Эффективной может оказаться стратегия, когда вы в качестве первичных ключей оставляете целые числа, но при этом добавляете дополнительное поле UUID для того, чтобы ваше приложение могло на него ссылаться. Реляционные таблицы ссылок могут использовать идентификаторы для повышения производительности, пока ваш код извлекает и вставляет объекты верхнего уровня с UUID. Здесь все зависит от вашей системы, ее масштаба и ваших приоритетов: если вам нужна децентрализованная генерация идентификаторов и простейшее слияние данных, то лучший вариант – это UUID, но вам следует помнить и об обратной стороне медали.
Заключение
UUID – это уникальные значения, которые можно использовать для децентрализованной генерации идентификаторов. Совпадение идентификаторов возможно, но вероятность такого события настолько мала, что ее можно не учитывать. Если бы вы генерировали один миллиард UUID в секунду в течении 100 лет, то вероятность обнаружить дубликат составила бы около 50% при условии наличия достаточной энтропии.
У вас есть возможность использовать UUID для установления идентичности независимо от вашей базы данных до того, как вы добавите объект в базу данных. Такой подход упрощает код прикладного уровня и не допускает того, что объекты в вашей системе будут идентифицированы неправильно. UUID также содействуют репликации данных, гарантируя уникальность вне зависимости от хранилища данных, устройства или среды, чего нельзя сказать о целочисленных ключах, которые действуют на уровне таблиц.
Несмотря на то, что UUID широко используются при разработке программного обеспечения, они не являются идеальным решением. Новички часто зацикливаются на возможности обнаружения совпадений, но это не должно быть вашим главным аргументом, если только ваша система не настолько чувствительна, что вам просто необходимо гарантировать уникальность идентификаторов.
Более очевидная проблема для большинства разработчиков заключается в хранении и извлечении сгенерированных UUID. Примитивное использование
VARCHAR(36)
(или
VARCHAR(32)
, если вы удалите дефисы) в долгосрочной перспективе может оказывать негативное влияние на ваше приложение, так как большая часть попыток оптимизировать индексацию базы данных будут неэффективными. Изучите встроенные средства обработки UUID в вашей системе управления базой данных для того, чтобы максимально улучшить производительность вашего программного решения.
Привет! Сегодня в статье мы расскажем про базовую настройку SIP-транка в Cisco Unified Communications Manager (CUCM) .
Настройка
В меню Cisco Unified CM Administration переходим во вкладку Device → Trunk и нажимаем Add New:
В открывшемся окне в поле Trunk Type выбираем SIP Trunk, а в поле Device Protocol выбираем SIP:
Далее в новом окне нам нужно указать следующие опции:
Device Name – Имя транка;
Device Pool – Девайс пул создаваемого транка, необходимо чтобы он совпадал с устройствами, которые будут маршрутизироваться через него (по умолчанию default);
Calling Search Space – CSS для транка, необходимо чтобы он совпадал с маршрутизируемыми устройствами (если используется, по умолчанию none). Также CSS указывается в полях Rerouting Calling Search Space, Out-Of-Dialog Refer Calling Search Space и SUBSCRIBE Calling Search Space;
Destination Address и Destination Port – IP адрес и порт устройства на другой стороне транка;
SIP Trunk Security Profile - профиль безопасности транка, по умолчанию Non Secure SIP Trunk Profile;
SIP Profile - SIP профиль, по-умолчанию Standard SIP Profile;
После создания транка нужно настроить Route Pattern, при помощи которого мы будем направлять звонки в нужном направлении. (Подробнее об этом написано в статьях про Route pattern и Route list/Route group).
Для этого переходим во вкладку Call Routing → Route/Hunt → Route Pattern. Здесь в строке Route Pattern указываем паттерн, набрав который вызов будет направляться в выбранном направлении, которое указываем в строке Gateway/Route List:
Неизменяемая резервная копия защищает данные, фиксируя их и не позволяя их менять. Этот тип резервного копирования предотвращает возможность удаления данных и позволяет восстановить их в любое время. В результате неизменяемые резервные копии защищают данные от случайного или преднамеренного удаления данных или атак программ-вымогателей.
Что же такое неизменяемые резервные копии?
Данные – это критически важная часть любой организации. Именно по этой причине они являются основной целью кибератак.
Программа-вымогатель – это тип вредоносного ПО, которое шифрует данные так, что их больше нельзя использовать. Шифрование может доходить до уровня загрузочной записи, чтобы загрузка была невозможна. Это также распространяется и на резервные копии данных.
Атака программы-вымогателя приводит к отключению важнейших бизнес-служб. Для того, чтобы получить доступ к вашим данным снова, вам придется заплатить выкуп.
Одним из способов минимизировать вред от атак программ-вымогателей является регулярное резервное копирование данных, что является последней линией защиты. Однако обычное копирование данных вовсе не означает, что они защищены от кибератак.
Усовершенствованные атаки программ-вымогателей могут быть теперь нацелены и на резервные копии. Злоумышленники могут изменить или удалить резервную копию и потребовать крупный выкуп. Чтобы предотвратить такую ситуацию, можно воспользоваться неизменяемой резервной копией.
Неизменяемость препятствует несанкционированному доступу к данным или их удалению. Наличие неизменяемой резервной копии гарантирует, что у вас всегда будет самая последняя верная копия ваших данных, безопасная и доступная для восстановления в любое время.
Неизменяемые резервные копии создаются путем копирования битов данных в облако сразу после их создания.
После того, как данные попадут в облако, пользователь может установить флаг неизменяемости (неизменяемости битов). Этот флаг блокирует данные, предотвращая случайное удаление данных, заражение вредоносным ПО или повреждение данных.
Пользователь может установить флаг на определенный период времени. То есть если вы установите флаг на семь дней, то не сможете удалить или изменить резервную копию в течение этого периода времени.
Вы можете хранить краткосрочные неизменяемые резервные копии локально или многоуровневые резервные копии данных в неизменяемом объектном хранилище удаленно. Таким образом, вы защищаете данные от непредвиденного вредоносного действия или случайного удаления.
Недостатки изменяемой инфраструктуры
Изменяемая инфраструктура – это инфраструктура информационного сервера, которую можно постоянно изменять и обновлять в обычном порядке.
Несмотря на то, что такая инфраструктура имеет свои преимущества, она также имеет и несколько недостатков в сравнении с неизменяемой инфраструктурой.
Недостатки изменяемой инфраструктуры следующие:
Конфигурационный дрейф. Изменения конфигурации сервера не регистрируются систематически, трудно диагностировать или воспроизвести технические проблемы.
Недискретное управление версиями. Отслеживание версий затруднено, поскольку изменения сервера не всегда документируются.
Ошибки обновления. Обновления с большей долей вероятности завершатся сбоем из-за различных проблем с сетью (DNS в автономном режиме, плохое подключение, не отвечающие репозитории и т.д.)
Медленная отладка. Проблемы с отслеживанием версий замедляют процесс отладки. Следовательно, пользователи могут столкнуться с несколькими версиями обновлений и большими рабочими нагрузками в случае обновлений с ошибками.
Повышенный риск. Изменяемая инфраструктура увеличивает риск потери данных и атак программ-вымогателей, если сравнивать с неизменяемой инфраструктурой.
Ручная настройка. Изменяемая инфраструктура требует ручной настройки сервера, что проводит к увеличению длительности процесса подготовки серверов.
Как реализовать стратегию неизменяемого резервного копирования?
Компании часто пытаются противостоять программам-вымогателям, вкладывая средства в надежную и устойчивую к отказам систему защиты. Однако лучше стоит подготовиться к наихудшему сценарию – сценарию, при котором системы защиты компании откажут.
Внедрение стратегии неизменяемого резервного копирования – лучший способ защитить ваши данные и быстро отреагировать на кибератаку без необходимости платить огромный выкуп.
Многие передовые методы резервного копирования и восстановления данных не защищены от атак программ-вымогателей.
Например, репликация данных в удаленный центр обработки данных не обеспечивает защиту от программ-вымогателей, поскольку непрерывное резервное копирование может перезаписывать исправные файлы зашифрованными версиями. Поэтому сложно точно определить начальную точку возникновения вируса.
Правило резервного копирования 3-2-1 (3-2-1 backup rule) – это стратегия защиты данных, которая предполагает, как минимум, три копии данных. Две копии являются локальными, но находятся на разных носителях, а третья – удаленная (например, неизменяемая резервная копия с воздушным зазором в облаке).
Передовые методы для реализации неизменяемого резервного копирования:
Целостность данных
Лучший способ защитить резервную копию данных – хранить ее на платформе, которая не позволит вносить изменения. Некоторые фирмы-поставщики предлагают объектно-ориентированное хранилище, которое делает невозможным изменение данных или их шифрование при атаке программы-вымогателя.
Модель нулевого доверия
Такая модель включает строгую проверку личности для любого, кто получает доступ к вашим резервным копиям данных в частной сети. Такой целостный подход состоит из нескольких методов и технологий, которые обеспечивают повышенный уровень безопасности и надежность резервного копирования.
Один из таких методов – усиление безопасности с помощью многофакторной аутентификации.
Многоуровневая устойчивость к отказам
Хорошая стратегия защиты сочетает в себе неизменяемое резервное копирование данных с новейшими технологиями кибербезопасности и обучением сотрудников.
Платформы, включающие в себя функции предотвращения удаления лишних файлов или удаления с возможность восстановления, гарантируют наличие копии данных, даже если программа-вымогатель проникнет в систему.
Другой уровень защиты заключается в использовании формата WORM (write once read many - однократная запись и многократное считывание), который предлагают многие фирмы-поставщики.
Автоматическое реагирование
Атаки программ-вымогателей обычно происходят через несколько месяцев после того, как система была заражена. Злоумышленники специально выжидают столько времени, чтобы программа-вымогатель могла незаметно распространиться и найти все резервные копии данных. Затем, когда в офисе никого не остается, они заполучает ваши данные.
Внедрите систему автоматического реагирования в решение для резервного копирования, чтобы помещать зараженные системы в «карантин», даже если в этот момент в офисе никого нет.
«Чистое» восстановление
Убедитесь, то ваша резервная копия данных не содержит вредоносных программ, чтобы предотвратить повторное заражение. Сканируйте резервные копии на наличие вредоносных программ или индикаторов компрометации перед тем, как восстанавливать данные.
Храните неизменяемые резервные копии данных в формате WORM, чтобы защитить данные от шифрования и обеспечить быстрое восстановление данных.
Заключение
Теперь вы знаете, что такое неизменяемые резервные копии и как они могут защитить ваши данные от кибератак. Когда речь идет о программах-вымогателях, то лучшее нападение – это надежная защита.