По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
OpenAPI Spec – излюбленный выбор экспертов по разработке API, особенно если главным приоритетом является безопасность. Инструментарий Swagger в этом отношении кажется хорошим вспомогательным средством. Однако пытаться совместить эти два понятия – настоящая задача. Вы, наверное, уже запутались?
Не беспокойтесь. Эта статья поможет вам во всем разобраться.
OpenAPI: хронология его создания
OpenAPI – это всемирно признанная проектная спецификация RESTful API, разработанная под эгидой OpenAPI Initiative. Лучшие игроки IT-индустрии, такие как Google, Capital One, SmartBear, Microsoft, Apigee и PayPal, вместе запустили этот проект. Сама спецификация также поддерживается Linux Foundation.
OpenAPI также известен как коммерчески нейтральный и независимый от языка интерфейс для RESTful API. Он широко используется для того, чтобы пользователи и машины могли взаимодействовать без фактического доступа к документации, фрагментам исходного кода или аудита перегрузки сети.
Хронология создания
(2009) – OpenAPI и Swagger появились благодаря Тони Тэму, специалисту по программному обеспечению. Первоначально он запустил спецификацию Swagger с открытым исходным кодом для использования в компании.
(2011) – первая версия пользовательского интерфейса Swagger смогла описать JSON API для Wordnik. Она может использовать консоль разработчика/документацию компании, интеграцию кода и функции генерации кода.
(2012) – появилась усовершенствованная, но все же еще бета, версия.
(2014) – самая первая формализованная и официальная версия Swagger Spec0 была представлена публике в 2014 году. Она получила высокую оценку пользователей API.
(2015) – SmartBear приобрела Swagger Spec.
(2016) – Swagger стал «Спецификацией OpenAPI» и был переведен в другой репозиторий Git.
(2017) – входит в OpenAPI Initiative
На сегодняшний день уже доступна версия 3.1.0, которая пока считается лучшей. Для этой версии важно структурирование и форматирование API. Она выполняет процесс аутентификации и авторизации в соответствии со схемами аутентификации HTTP.
Помимо этого, аутентификация и авторизация пользователя могут быть выполнены путем отправки ключей API в качестве заголовка или файлов cookie. Также у вас есть возможность использовать методы обнаружения OAuth 2 или OpenID Connect из версии 3.1.0.
Swagger: история и инструментарий
Swagger – это, по своей сути, тип языка описания интерфейса, разработанный для эффективного определения процедур использования RESTful API. Он использует в своей основе JSON.
Набор инструментов Swagger включает в себя несколько инструментов с открытым исходным кодом и несколько коммерческих инструментов, которые могут использоваться в течение стандартного жизненного цикла API. Говоря без преувеличений, набор инструментов Swagger упрощает написание API. О его популярности можно судить по одному лишь факту – на 2017 год инструменты Swagger загружались более 100 000 раз в день.
В инструментарий Swagger вошли такие инструменты как:
SwaggerCore – это набор библиотек Java для подготовки, использования и развертывания определений OpenAPI.
Конечные пользователи могут использовать Swagger Editor с целью написания или модификации спецификаций OpenAPI на основе YAML через популярные веб-браузеры. С ним вы можете улучшить читаемость документации, провести предварительный просмотр от лица конечных пользователей и модифицировать ее, чтобы устранить ошибки и сделать ее более удобной в использовании.
Страницы HTML, JS и CSS в репозитории Swagger UI упрощают процесс написания документации.
Если вам необходим хороший инструмент для проектирования и документирования, то правильным выбором будет SwaggerHub. Его часто используют специалисты для всех типов проектов OpenAPI.
Swagger Parser позволяет анализировать определения.
Swagger Codegen – это инструмент для создания заглушек сервера API, SDK и других документов.
С помощью Swagger Inspector можно проверить процесс создания определения OpenAPI. Это поможет вам улучшить этот процесс благодаря тщательному тестированию.
Swagger vs OpenAPI: топ-4 отличия
Давайте начнем с основ: OpenAPI = Спецификация для правильного определения и описания RESTful API. Swagger = Набор инструментов, используемый для развертывания спецификаций API.
Swagger допускает комбинацию host+base_path для одного сервера. С другой стороны, OpenAPI позволяет добавлять несколько URL-адресов серверов и путей поддоменов для того, чтобы упростить вашу жизнь.
Все инструменты Swagger используют OpenAPI; обратное также должно быть верно.
Инструменты Swagger сохранили свои первоначальные названия, несмотря на то, что Swagger изменил название на спецификацию OpenAPI.
Общее влияние Swagger и OpenAPI на создателей API и API-отрасль
Когда Тони Тэм создавал Swagger, он даже предположить не мог, что в будущем изменит представление о безопасности API и API-отрасли в целом. С течением времени OpenAPI Spec и Swagger стали именами нарицательными при упоминании RESTful API.
Поскольку OpenAPI является бесплатным средством с открытым исходным кодом, которое предлагается пользователям API, то у начинающих разработчиков есть возможность научиться большему и показать весь свой потенциал. У разработчиков-новичков есть множество возможностей для работы и оттачивания своих навыков разработки API.
Главной задачей разработчиков оставалось поддержание стандартов безопасности на каждом этапе разработки API. Количество взломов API растет с каждым днем. Крупные предприятия, такие как Cisco Systems, Facebook и Shopify, регулярно сталкиваются с уязвимостями API и изо всех сил пытаются укрепить свою систему безопасности. Нарушение API в Equifax, которое стоило компании судебного иска в размере 700 миллионов долларов, вынудило предприятия лучше следить за безопасностью ИИ.
Использование OpenAPI положительно повлияло на методы разработки API, поскольку позволило команде разработчиков говорить на одном языке и, соответственно, легко общаться. Разработчикам больше не требуется убирать назначение API из ключевого функционала или исходного кода.
Принятие предопределенных стандартов безопасности является вполне осуществимой задачей, поскольку созданный API может взаимодействовать на простом языке и не вызывает беспокойства при обнаружении возможных брешей и угроз безопасности.
Что предлагают Swagger и OpenAPI на сегодняшний день?
OpenAPI, а равно и Swagger, на сегодняшний день являются движущей силой API-индустрии. Оин упрощают создание серверной заглушки для API. Разработчики могут создавать библиотеки клиентских API на более, чем 40 языках. Они расширяют возможности разработки API и повышают его безопасность за счет:
Создания интерактивного API: Разработчики могут использовать OpenAPI для написания интерактивной документации. Мало того, он позволяет запускать тесты API непосредственно из браузера во время подготовки документа.
Поддержки инструментов генерации кода: OpenAPI – это великое благословение, поскольку он полезен при создании серверных SDK и клиентских CDK на нескольких языках программирования. Он хорошо работает с инструментами генерации кода.
Аудита: OpenAPI Spec хорошо работает совместно с инструментом Contract Audit, который контролирует защиту операций, связанных с данными API. Фактически, этот инструмент является отличным ресурсом для обеспечения безопасности высокого уровня. При совместной работе OpenAPI Spec и Contract Audit выявление проблем безопасности в созданном API и их аудит становятся не такими утомительными. Можно выполнить аудит API с самого начала и избавить себя от аудита огромного количества API в конце разработки.
Куда держит курс Swagger?
OpenAPI – важная утилита, и эксперты рынка утверждают, что она имеет хорошие перспективы. Однако небольшая часть людей все же считает, что Swagger теряет свой лоск после передачи ключевых спецификаций OpenAPI. Учитывая, что на сегодняшний день он используется и играет решающую роль во многих задачах, особенно в тестировании API и повышении уровня безопасности, они могут ошибаться.
Инструменты Swagger позволяют наглядно увидеть код и протестировать практическую ценность фрагментов кода в режиме реального времени. Благодаря пользовательскому интерфейсу Swagger, разработчикам стало еще проще, чем когда-либо, запускать команды и получать всестороннее представление о функциональных возможностях системы.
Поддержание стандартизации в написании API также возможно с помощью Swagger, поскольку он совместно с OpenAPI предлагает всемирно признанный набор стандартов создания API.
Инструменты Swagger также могут помочь в написании API с нуля. Используя Swagger Editor, можно тестировать API в режиме реального времени. Это позволяет пользователям проверять проектное решение утилиты на соответствие спецификации OAS OpenAPI и узнать текущий визуальный результат. Лучшее свойство этого инструмента заключается в том, что его можно использовать из любой точки.
Также Swagger Inspector является одним из важнейших инструментов из набора Swagger, поскольку он позволяет создавать свои собственные спецификации API. Возможно не только создание настраиваемых API, но и передача этих API другим членам команды.
Когда речь идет о безопасности API в Интернете, то лучшее решение – это Swashbuckle. Это реализация Swagger с открытым исходным кодом, позволяющая конечным пользователям создавать живую документацию для всех своих API. Этот инструмент синхронизирует документацию с вашей текущей версией API и сокращает риски безопасности до нуля.
Заключение
Поскольку OpenAPI сформировался из Swagger, то тут явно было где запутаться.
Первая утилита предназначена для описания RESTful API. Это хороший инструмент с точки зрения безопасности, поскольку он сохраняет спецификацию в машиночитаемой форме. С другой стороны, вторая утилита – на сегодняшний день это фаворит разработчиков в случаях, когда речь идет о коммерчески нейтральном развертывании OpenAPI Spec.
Надеюсь, что когда в следующий раз вы услышите эти два понятия, то не запутаетесь и правильно разберетесь в фактах. Они оба оказывают положительное влияние на API-отрасль и способствуют развитию API.
Public Key Infrastructure (PKI) - это набор различных технологий, которые используются для обеспечения аутентификации источника, целостности данных и конфиденциальности для пользователя в сети. PKI использует преимущества асимметричного шифрования и использует пары открытого и закрытого ключей для шифрования данных.
В PKI открытый ключ обычно связан с цифровой подписью, чтобы добавить доверие и проверить сведения о владельце сертификата. Ниже приведен ключевой жизненный цикл в PKI:
Генерация ключа: Этот процесс определяет шифр и размер ключа.
Генерация сертификата: Этот процесс создает цифровой сертификат и назначает его человеку или устройству.
Распространение: Процесс распространения отвечает за безопасное распространение ключа пользователю или устройству.
Хранение: Этот процесс отвечает за безопасное хранение ключа, чтобы предотвратить любой несанкционированный доступ к нему.
Отзыв: Сертификат или ключ могут быть отозваны, если они скомпрометированы субъектом угрозы.
Срок действия: Каждый сертификат имеет срок службы.
Каждый день мы посещаем различные веб-сайты, такие как социальные сети, стрим, новости, спорт, блоги и другие платформы. Однако задумывались ли вы когда-нибудь о проверке подлинности веб-сайтов, которые вы посещаете? Вы, наверное, думаете, что всему, что находится в Интернете, нельзя доверять. Хотя это отчасти правда, мы можем доверять только ограниченному числу веб-сайтов, например, доверять веб-сайту вашего банка. Главный вопрос заключается в том, как мы можем проверить подлинность веб-сайтов, которые мы посещаем? Именно здесь как PKI, так и цифровые сертификаты помогают установить доверие между хостом в Интернете и нашим компьютером.
Центр сертификации
PKI играет жизненно важную роль в Интернете, поскольку многим пользователям и устройствам требуется метод установления доверия в самой ненадежной сети в мире – Интернете. Понимание компонентов, которые помогают PKI обеспечить доверие, необходимую как пользователям, так и устройствам, имеет важное значение для любого специалиста по кибербезопасности.
Вы можете рассматривать PKI как набор процедур, правил, аппаратного и программного обеспечения, а также людей, которые работают вместе для управления цифровыми сертификатами. Цифровой сертификат-это официальная форма идентификации объекта, которая проверяется доверенной стороной. Эти цифровые сертификаты выдаются доверенной стороной в сети или Интернете. Они известны как Центр сертификации (Certificate Authority - CA).
В каждой стране существует государственное учреждение, которое обычно отвечает за проверку личности своих граждан и выдачу удостоверений личности, такой как паспорт.
Этот паспорт будет содержать важную информацию о владельце и сроке действия, например, дату окончания срока действия. В сети и в Интернете центр сертификации выполняет похожую роль и функции. В Интернете есть множество поставщиков, которые являются доверенными центрами сертификации, которые позволяют вам приобретать цифровой сертификат для личного использования. Примеры доверенных центров сертификации включают GoDaddy, DigiCert, Let's Encrypt, Comodo, Cloudflare и многие другие.
Важное примечание! Цифровой сертификат создается при объединении ключа и цифровой подписи. Сертификат будет содержать сведения о владельце сертификата, например, об организации.
ЦС выдаст объекту цифровой сертификат только после того, как его личность будет проверена. После того, как ЦС создает цифровой сертификат, он сохраняется в базе данных сертификатов, которая используется для безопасного хранения всех утвержденных ЦС цифровых сертификатов.
Важное примечание! По истечении срока действия цифрового сертификата он возвращается в ЦС, который затем помещается в список отзыва сертификатов (Certificate Revocation List - CRL), который поддерживается ЦС.
Цифровой сертификат форматируется с использованием стандарта X.509, который содержит следующие сведения:
Номер версии
Серийный номер
Идентификатор алгоритма подписи
Название эмитента
Срок годности
Не раньше, чем
Не после
Имя субъекта
Информация об открытом ключе субъекта
Алгоритм открытого ключа
Открытый ключ субъекта
Уникальный идентификатор эмитента (необязательно)
Уникальный идентификатор субъекта (необязательно)
Расширения (необязательно)
Алгоритм подписи сертификата
Подпись сертификата
Регистрирующий орган (RA)
Следующий рисунок - это цифровой сертификат, который используется для проверки веб-сайта Cisco:
Как показано на предыдущем рисунке, видно, что CA - это HydrantID SSH ICA G2, который выдает сертификат на www.cisco.com на срок действия с 20 сентября 2019 года по 20 сентября 2021 года.
Как показано на следующем рисунке, цифровой сертификат содержит дополнительную информацию, которая хранится с использованием стандарта X.509:
Далее давайте рассмотрим, как создается цифровая подпись и ее роль в PKI.
Цифровая подпись
При совершении деловых операций на документах требуется подпись, чтобы гарантировать, что сделка санкционирована соответствующим лицом. Такая же концепция требуется в сети, так что цифровая подпись отправляется вместе с сообщением на конечный хост. Затем узел назначения может использовать цифровую подпись для проверки подлинности сообщения.
При использовании PKI используются следующие алгоритмы для создания и проверки цифровых подписей:
DSA
RSA
Elliptic Curve Digital Signature Algorithm (ECDSA)
Чтобы создать цифровую подпись, между Алисой (отправителем) и Сергеем Алексеевичем (получателем) происходит следующий процесс:
1) Алиса будет использовать алгоритм хеширования для создания хэша (дайджеста) сообщения:
2) Затем Алиса будет использовать свой закрытый ключ для шифрования хэша (дайджеста) сообщения:
Цифровая подпись используется в качестве доказательства того, что Алиса подписала сообщение.
Чтобы лучше понять, как используются цифровые подписи в реальной жизни, давайте представим, что в сети есть два пользователя. Алиса хочет отправить Сергею Алексеевичу сообщение. Алиса может использовать цифровую подпись с сообщением, чтобы заверить Сергея Алексеевича в том, что сообщение исходило именно от нее. Это шаги, которые Алиса будет использовать для обеспечения подлинности, целостности и неотрицания:
Алиса создаст пару открытых и закрытых ключей для шифрования данных.
Алиса даст Сергею Алексеевичу только открытый ключ. Таким образом, закрытый ключ хранится у Алисы.
Алиса создаст сообщение для Сергея Алексеевича и создаст хэш (дайджест) сообщения.
Затем Алиса будет использовать закрытый ключ для шифрования хэша (дайджеста) сообщения для создания цифровой подписи.
Алиса отправит сообщение и цифровую подпись Сергею Алексеевичу.
Сергей Алексеевич будет использовать открытый ключ Алисы для расшифровки цифровой подписи, чтобы получить хэш сообщения.
Сергей Алексеевич также сгенерирует хэш сообщения и сравнит его с хэшем, полученным из цифровой подписи Алисы. Как только два значения хэша (дайджеста) совпадают, это просто означает, что сообщение подписано и отправлено Алисой.
Цифровые подписи используются не только для проверки подлинности сообщений. Они также используются в следующих случаях:
Цифровые подписи для цифровых сертификатов: это позволяет отправителю вставить цифровую подпись в цифровой сертификат.
Цифровые подписи для подписи кода: это позволяет разработчику приложения вставить свою цифровую подпись в исходник приложения, чтобы помочь пользователям проверить подлинность программного обеспечения или приложения.
На следующем рисунке показан пример приложения, содержащего цифровой сертификат:
На следующем рисунке показана дополнительная проверка цифровой подписи подписавшего:
Система доверия PKI
Ранее мы узнали, что организация может получить цифровой сертификат от доверенного центра сертификации в Интернете. Однако во многих крупных организациях вы обычно найдете корневой ЦС и множество промежуточных ЦС. Корневой ЦС отвечает за создание первичного цифрового сертификата, который затем делегируется каждому подчиненному ЦС или промежуточному ЦС. Промежуточный ЦС будет использовать цифровой сертификат корневого сервера для создания новых цифровых сертификатов для конечных устройств, таких как внутренние серверы.
На следующем рисунке показана иерархия корневого и промежуточного ЦС:
Использование этого типа иерархической структуры снимает нагрузку с корневого центра сертификации по управлению всеми цифровыми сертификатами в организации. Некоторые из этих обязанностей делегированы промежуточным серверам ЦС в сети. Представьте, что в вашем головном офисе вы развернули корневой ЦС, а в каждом удаленном филиале развернули промежуточные ЦС. Следовательно, каждый промежуточный ЦС отвечает за управление сертификатами своего собственного домена или филиала. Это также снижает риски взлома корневого ЦС злоумышленником, так что в случае взлома промежуточного ЦС корневой ЦС может быть отключен от сети, не затрагивая другие конечные устройства или промежуточные ЦС.
В небольших сетях можно развернуть один корневой ЦС для предоставления цифровых сертификатов каждому конечному устройству, как показано на следующем рисунке:
Как показано на предыдущем рисунке, одним ЦС легко управлять. Однако по мере роста сети наличие единственного центра сертификации в сети не позволит легко масштабироваться, поэтому необходимо использовать иерархическую структуру с корневым центром сертификации и промежуточными (подчиненными) центрами сертификации.
Kali Linux (ранее известная как BackTrack Linux) объявила о выпуске новой версии - Kali Linux 2020.2 Kali Linux - это дистрибутив на основе Debian, специально предназначенный для тестирования на проникновение и использования цифровой криминалистики.
Последняя версия Kali Linux поставляется с функциональными и косметическими изменениями. В этой статье мы описали основные улучшения, включенные в Kali 2020.2.
Новый рабочий стол и экран входа в систему
Новый Kali Linux 2020.2 поставляется с элегантным рабочим столом со светлыми и темными темами. Вы можете переключаться между темами, перейдя в «Настройки» и выбрав предпочитаемую тему.
Среда рабочего стола GNOME также обновлена до последней версии - GNOME 3.36. Среды KDE Plasma и XFCE также получили новый изысканный внешний вид.
Интеграция PowerShell в Kali Linux
Powershell был перемещен из сетевого репозитория Kali Linux в один из основных метапакетов, известный как kali-linux-large. Это подразумевает, что вы можете установить Powershell либо во время установки - поскольку он теперь включен в метапакеты kali-Linux-large - либо после окончательной установки Kali. Это можно сделать на терминале с помощью показанной команды
$ sudo apt install -y kali-linux-large
Чтобы вызвать Powershell, просто запустите команду.
$ pwsh
Новые ключевые пакеты и значки
Некоторые из новых пакетов, включенных в Kali 2020.2:
Python 3.8
Joplin - приложение для заметок
Nextnet - инструмент обнаружения точек поворота (pivot point), написанный на языке Go
SpiderFoot - разведывательный инструмент
Также появились новые значки пакетов для каждого инструмента в новой версии Kali 2020.2.
Улучшения ARM
ARM-образы больше не используют учетные данные root/toor по умолчанию при входе в систему, как это было со времен Kali Linux 2020.1. Кроме того, в последней версии Kali отсутствует поддержка SD-карт объемом не менее 8 ГБ. Теперь вам потребуется использовать SD-карту объемом 16 ГБ или более для образов ARM.
Изменения в установщике
Новая Kali 2020.2 избавляется от опции kali-linux-everything от установщика. Это решает проблему, которая присутствовала в более ранней версии (Kali 2020.1), когда пользователям приходилось выбирать «все», что занимало намного больше времени для получения очень больших метапакетов.
Теперь каждая среда рабочего стола и большие метапакеты Kali-Linux кэшируются в образе ISO, и пользователи могут выбирать, что им нужно установить.
Скачать Kali Linux
Чтобы получить последнюю версию Kali Linux, просто перейдите на страницу загрузки Kali и выберите предпочитаемый ISO-образ, соответствующий архитектуре вашей системы.
64-битные и 32-битные ISO-образы Kali Linux можно скачать по следующим ссылкам.
Kali Linux 64-Bit (Installer)
Kali Linux 64-Bit (Live)
Kali Linux 64-Bit (NetInstaller)
Kali Linux 32-Bit (Installer)
Kali Linux 32-Bit (Live)
Kali Linux 32-Bit (NetInstaller)
Kali Linux for ARM
Обновление Kali Linux до последней версии
Поскольку Kali является скользящим релизом, вы можете обновить свою систему, выполнив следующие команды, чтобы получить последние обновления.
$ sudo apt -y update
$ sudo apt -y full-upgrade
Про установку Kali Linux с нуля можно прочитать в этой статье.