По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Большинство приложений и веб-администраций привыкли к тому, то клиенты вспоминают и вводят свои пароли каждый раз при входе в систему. Помимо того, что это тяготит клиентов, такой подход представляет угрозу безопасности, так как клиенты часто выбирают ненадежные пароли и повторно используют из во многих других администрациях. Эти проблемы решаются на основе проверки на основе токенов (или токенов). Как насчет того, чтобы посмотреть, как это помогает?
Определение токена
Мы должны начать с точных значений «токенов», которые в основном представляют собой измененные формы паролей или выражений, которые используются для проверки символов.
Когда происходят какие-то обмены данных в Интернете, токены аутентификации являются очень полезными инструментами для демонстрации своей личности во время входа в систему, обновлений, покупок и других процессов. Интересным в токенах является то, что они могут быть последовательными, как при входе в систему, или могут быть более «фиктивными», требуя «контакта» (дополнительного подтверждения или физического присутствия), чтобы гарантировать, что вы тот, за кого себя выдаете, и что вам действительно можно войти.
Токены более безопасны, так как они не должны содержать информацию о клиенте и создаются путем вычислений или выполнения программы. Это существенно лучше в сравнении с тем, что некоторые организации используют индивидуальные данные клиентов в качестве своего регистрационного номера, что позволяет злоумышленникам без особых усилий использовать в своих целях еще больше пользователей. Клиенты, которые используют некоторые частные данные для своих паролей, беспомощны против тех, кто без особых усилий нашел их, просматривая страницы в социальных сетях этих клиентов.
Аутентификация на основе токенов
Токены можно использовать для многофакторной аутентификации (MFA - multi-factor authentication) и серверных протоколов, которые соединяют приложения, API и веб-сайты.
Важность аутентификации на основе токена
Отойдите в сторону от технологий для того, чтобы рассмотреть проблему, которую вы пытаетесь решить. Вы просите законных пользователей подтвердить свою личность, чтобы не пропустить злоумышленников в вашу сеть (где они могут украсть данные, установить программы-вымогатели и т.д.). Так как токен основан на закрытом ключе устройства, то, когда мы используем токен из приложения, такого как PingID, брелка или ключа, который мы подключаем к нашему компьютеру, мы предотвращаем вмешательство внешних субъектов. «Зачем» заключается в том, чтобы выбрать решение для аутентификации на основе токенов, которое проверяет пользователей, не создавая конфликтов и безвыходных положений. Пользователи довольны, а данные в безопасности, когда процесс проходит гладко.
Аутентификация на основе токена в действии
Клиентам могут быть предоставлены токены подтверждения различными способами, включая токены на базе оборудования, одноразовые пароли (обычно предоставляемые с помощью мобильных телефонов) и токены, созданные с помощью программирования на основе стандарта JWT.
Все токены хранят характеристики и информацию о клиенте в безопасном виде. С учетом такого бесчисленного количества правил защиты информации, имеющимися на сегодняшний день, токен также может проверять, что информация достоверна и не была изменена, что является основным условием безопасности. Они также расширяют возможности клиентов, позволяя им входить в систему, не запоминая пароли.
Подтверждение на основе токена обычно происходит в четыре этапа:
Требование – клиент требует доступ к защищенному ресурсу, который его интересует. Клиент изначально должен как-то отличиться без использования токена, например, воспользовавшись именем пользователя или секретной фразой.
Подтверждение – проверка гарантирует, что сертификаты клиента являются действительными и что клиент имеет соответствующие полномочия в указанной инфраструктуре.
Токены – токен выдается инфраструктурой и передается клиенту. Этот процесс включает в себя предоставление токенов клиенту за счет токена оборудования. Это происходит «за кулисами» при генерации токенов, так как взаимодействие клиента происходит с сервером.
Определение – токен фактически хранится у клиентов, будь то в их программе или на их мобильном телефоне. Это дает им возможность в будущем проходить проверку без использования сертификатов.
Преимущества и недостатки аутентификации на основе токена
У такой процедуры есть свои преимущества и недостатки, как и у любого другого подхода или метода.
Преимущества
Эффективность. Программные токены более эффективны и универсальны, чем фактические Токены. Сервер может создавать и проверять сколько угодно токенов в зависимости от ситуации, что упрощает масштабирование количества клиентов, обращающихся к вашему сайту или веб-приложению. Они также не предполагают, что организации будут предоставлять своим клиентам фактические токены.
Адаптивность. Программные токены являются гибкими в том смысле, что они могут быть задействованы на нескольких серверах и одновременно проверять различные сайты и приложения. Они часто используются для реализации системы единого входа (SSO - single sign-on), что упрощает работу клиентов, а также повышает безопасность.
Безопасность. Токены JWT не фиксирует свое текущее состояние и должны быть подтверждены, когда закрытый ключ получен приложением на стороне сервера, которое их создало. Поэтому они считаются надежным и безопасным методом проверки.
Недостатки
Скомпрометированный секретный ключ. Наличие всего одного ключа является существенным недостатком в стандарте JWT. В случае, если за ключом, как предполагалось, не следят проектировщики и администраторы сайта, и он вдруг перехватывается злоумышленниками, то конфиденциальная информация может быть раскрыта. Это может позволить злоумышленникам имитировать клиентов и перехватывать встречи с клиентами, что трудно определить и остановить.
Служебная информация. JWT намного больше стандартного токена встреч и заполняется по мере добавления дополнительной информации о клиенте. Добавление дополнительной информации к маркеру может увеличить время загрузки страницы за счет увеличения времени, необходимого для организации встречи с клиентом.
Долговременная аутентификация не идеальна. Системы, позволяющие клиентам оставаться в системе в течение длительного периода времени, не очень хороши. Эти токены требуют постоянной повторной проверки, что может раздражать клиентов. Хорошей альтернативой в этом случае является использование токенов обновления и их правильное хранение. Клиенты могут использовать токены обновления, чтобы оставаться в сети в течение более длительных периодов времени без необходимости повторного подтверждения.
Насколько безопасна аутентификация на основе токена?
Так как киберпреступность не стоит на месте, а развивается, то специалистам по управлению следует постоянно обновлять свои стратегии и механизмы обеспечения безопасности. Участись атаки с использованием фишинга, физических сил и слов-ссылок с целью получения доступа. Теперь пароли не подходят для подтверждения.
Проверка на основе токенов, в сочетании с другими стратегиями проверки, может стать еще более сложным препятствием, которое не позволит даже опытным хакерам воспользоваться взломанными паролями. Токены должны быть извлечены из устройства, которое их создало (например, мобильного телефона или генератора ключей), что делает их на сегодняшний день исключительно хорошей стратегией подтверждения.
Хотя этапы проверки токенов имеют массу преимуществ, обычно это очень затратный процесс. Токены, хранящиеся в сотовых телефонах, можно использовать, но они могут оказаться бесполезными из-за каких-либо дефектов гаджета. Токены можно спокойно перехватить, если предположить, что они были отправлены через сообщение. Злоумышленник может получить токены, хранящиеся на устройстве, если оно было потеряно или украдено.
Тем не менее, стоит помнить, что нельзя полагаться на стратегию однократной проверки. Проверка токена должна использоваться для двухфакторного или многофакторного подтверждения.
Типы токенов
1. Аппаратный ключ (токен) (USB-ключ)
Токены оборудования – это реальные устройства, которые после утверждения позволяют клиентам получать доступ к защищенным сетям. Иначе их называют токенами проверки или безопасности. Токен оборудования используется для добавления дополнительного уровня безопасности посредством двухфакторной или многофакторной проверки (2FA или MFA). Владелец такого токена подключает его к системе или администрации, которую будет использовать.
Для того, чтобы обеспечить превосходное обслуживание клиентов и возможность адаптироваться, токены оборудования поставляются различных форм и размеров. Самые известные токены – USB-ключи или удаленные токены.
2. JWT – JSON веб-токен
Этот тип является открытым стандартом для обработки данных JSON (RFC 7519). Он подразумевает определенную бесплатную методологию для безопасной передачи данных между сторонами. Для передачи данных между сторонами стандарт JWT использует объекты JSON. Эти токены можно использовать для подтверждения, а также для перемещения дополнительных данных о клиенте или записи.
JWT могут быть отправлены в виде URL-адресов, ограничений POST или заголовков HTTP и могут быть быстро переданы ввиду их небольшого размера. Чтобы избежать различных информационных индексных запросов, JWT содержит всю основную информацию о компоненте. Чтобы подтвердить токен, получателю JWT не нужно обращаться к серверу.
JWT состоит из трех частей:
Заголовок, содержащий информацию о типе токена и использованном методе шифрования.
Полезная нагрузка, содержащая возможности подтверждения наряду с дополнительной информацией о клиенте или записи.
Отпечаток, объединяющий криптографический ключ, который можно использовать для подтверждения полезности полезной нагрузки.
3. Токен одноразового пароля (OTP - One-Time Password)
Это защищенное оборудование или программное устройство, которое генерирует одноразовые пароли. Чаще всего используются индивидуальные идентификационные номер (PIN), которые представляют собой числовые коды от 4 до 12 цифр.
Одноразовые пароли в большинстве случаев создаются и получаются с помощью мобильных телефонов. После подтверждения владения телефоном клиент может использовать приложение-аутентификатор для создания одноразовых паролей. В этом случае телефон выступает в роли генератора кода. OTP также можно отправлять с устройства через SMS.
Объединяя созданные системы проверок, одноразовые пароли дополняют проверку пользователей и паролей. Токены OTP создают PIN-коды одновременно или нет, в зависимости от сервера.
Одновременные токены создают одноразовый пароль, используя ваш закрытый ключ и текущее время, а то время как неодновременный использует механизм аутентификации «запрос-ответ» (CRAM - Challenge Response Authentication Mechanism), набор соглашений, в которых сервер задает вопрос, а токендолжен дать правильный ответ.
4. Токен API
Этот тип токена служит полезным идентификатором для приложений, запрашивающих доступ к вашей администрации. Приложение в этот момент использует токен API, созданный вашей администрацией, чтобы запросить доступ к вашей администрации. Токен API сравнивается с тем, который вы сохранили для проверки и предоставления доступа. Время от времени можно использовать идентификатор сессии, но это отдельный случай.
Токен программного интерфейса становятся все более безопасным вариантом, в отличие от отправки набора имени пользователя и пароля по HTTP. OAuth2 – это одно из наиболее широко используемых на сегодняшний день соглашений о безопасности API.
Рассказываем как быстро и просто поднять свой NFS сервер на Ubuntu Linux Server 14-04.1, а также разберёмся с принципами работы протокола NFS и рассмотрим теорию.
Теория
Аббревиатура NFS расшифровывается как Need for Speed - Network File System. Это протокол для доступа к распределённым сетевым файловым системам, с помощью которого можно подмонтировать удалённые директории к своему серверу. Это позволяет использовать дисковое пространство другого сервера для хранения файлов и регулярно производить запись данных на него с нескольких серверов.
Протокол имеет клиент-серверную модель, то есть один сервер (ещё его называют “шара” от слова share), с установленным пакетом NFS, будет обеспечивать доступ к своим каталогам и файлам, а клиентские компьютеры будут подключаться к нему по сети. Закрепим прочитанное схемкой:
Обращения к серверу NFS осуществляются в виде пакетов протокола RPC (Remote Call Procedure), который позволяет выполнить различные функции или процедуры в другом сетевом пространстве, то есть на удалённом сервере.
Авторизация пользователей, которые подключаются к серверу осуществляется по IP-адресу, а также по специальным идентификаторам пользователя UID и группы GID. Это не лучший способ относительно безопасности хранимых файлов, в сравнении с классической моделью «логин/пароль». Зато, благодаря такой архитектуре и тому, что NFS использовал протокол UDP без установления сессии, он практически невосприимчив к сбоям сети и самих клиентских компьютеров. Так, при каком-либо сбое, передача файла просто приостановится, а когда связь будет налажена, то передача возобновиться без необходимости какой-либо перенастройки.
Настройка
Думаю, с теорией понятно, так что давайте переходить к практике. Как было сказано, все настройки будет проводить на Ubuntu 14.04.1
Прежде всего, на компьютер, который будет выступать в роли сервера NFS, нужно установить необходимые компоненты.
Итак, скачиваем пакет nfs-kernel-server, с помощью которого мы сможем раздать доступ (“расшарить”) директории. Для этого на будущем NFS сервере вводим команды:
sudo apt-get update
sudo apt-get install nfs-kernel-server
Теперь создаём собственно директорию к которой хотим раздать доступ. Стоит отметить, что можно также “расшарить” уже имеющиеся на сервере директории, но мы создадим новую:
sudo mkdir /var/nfs
Далее мы должны сделать так, чтобы владельцем директории /var/nfs и группе, к которой он принадлежит стали все пользователи в нашей системе. Для этого вводим на сервере команду:
sudo chown nobody:nogroup /var/nfs
Вводите эту команду только для тех директорий, которые создали сами, не надо вводить её для уже имеющихся директорий, например /home .
Следующим шагом необходимо изменить конфигурацию самого NFS, она лежит в файле /etc/exports, открываем его для редактирования любимым редактором:
sudo nano /etc/exports
Перед вами откроется конфигурационный файл с закомментированными строками, которые содержат примеры настройки для разных версий NFS.
Закомментированные – это те, в начале которых стоит символ #, и это значит, что параметры, указанные в них, не имеют силы.
Нам необходимо внести в этот файл следующие не закомментированные строки:
/var/nfs 10.10.0.10/24(rw,sync,no_subtree_check)
Где:
/var/nfs - Директория, которую мы хотим расшарить
10.10.0.10 - IP-адрес и маска клиентского компьютера, которому нужно раздать доступ к директории
rw - Разрешает клиенту читать (r) и записывать (w) файлы в директории
sync - Этот параметр заставляет NFS записывать изменения на диск перед ответом клиенту.
no_subtree_check - Данная опция отключает проверку того, что пользователь обращается именно к файлу в определённом подкаталоге. Если это проверка включена, то могут возникнуть проблемы, когда, например, название файла или подкаталога было изменено и пользователь попробует к ним обратиться.
После этого, нужно создать таблицу соответствия расшаренных директорий и клиентов, а затем запустить NFS сервис. Для этого вводим следующие команды:
sudo exportfs –a
sudo service nfs-kernel-server start
После выполненных действий расшаренные директории должны стать доступными для доступа с клиентов.
Почитать лекцию №15 про управление потоком пакетов в сетях можно тут.
Совокупность проблем и решений, рассмотренных в предыдущих лекциях, дает некоторое представление о сложности сетевых транспортных систем. Как системные администраторы могут взаимодействовать с очевидной сложностью таких систем?
Первый способ - рассмотреть основные проблемы, которые решают транспортные системы, и понять спектр решений, доступных для каждой из этих проблем. Второй - создание моделей, которые помогут понять транспортные протоколы с помощью:
Помощь администраторам сетей в классификации транспортных протоколов по их назначению, информации, содержащейся в каждом протоколе, и интерфейсам между протоколами;
Помочь администраторам сетей узнать, какие вопросы задавать, чтобы понять конкретный протокол или понять, как конкретный протокол взаимодействует с сетью, в которой он работает, и приложениями, для которых он несет информацию;
Помощь администраторам сетей в понимании того, как отдельные протоколы сочетаются друг с другом для создания транспортной системы.
Далее будет рассмотрен способ, с помощью которого администраторы могут более полно понимать протоколы: модели. Модели по сути являются абстрактными представлениями проблем и решений. Они обеспечивают более наглядное и ориентированное на модули представление, показывающее, как вещи сочетаются друг с другом. В этой лекции мы рассмотрим этот вопрос:
Как можно смоделировать транспортные системы таким образом, чтобы администраторы могли быстро и полностью понять проблемы, которые эти системы должны решать, а также то, как можно объединить несколько протоколов для их решения?
В этой серии лекции будут рассмотрены три конкретные модели:
Модель Министерства обороны США (United States Department of Defense - DoD)
Модель взаимодействия открытых систем (Open Systems Interconnect - OSI)
Модель рекурсивной интернет-архитектуры (Recursive Internet Architecture - RINA)
Модель Министерства обороны США (DoD)
В 1960-х годах Агентство перспективных исследовательских проектов Министерства обороны США (DARPA) спонсировало разработку сети с коммутацией пакетов для замены телефонной сети в качестве основного средства компьютерной связи. Вопреки мифу, первоначальная идея состояла не в том, чтобы пережить ядерный взрыв, а скорее в том, чтобы создать способ для различных компьютеров, используемых в то время в нескольких университетах, исследовательских институтах и правительственных учреждениях, чтобы общаться друг с другом. В то время каждая компьютерная система использовала свою собственную физическую проводку, протоколы и другие системы; не было никакого способа соединить эти устройства, чтобы даже передавать файлы данных, не говоря уже о создании чего-то вроде "Всемирной паутины" или кросс-исполняемого программного обеспечения. Эти оригинальные модели часто разрабатывались для обеспечения связи между терминалами и хостами, поэтому вы могли установить удаленный терминал в офис или общественное место, которое затем можно было использовать для доступа к общим ресурсам системы или хоста. Большая часть оригинальных текстов, написанных вокруг этих моделей, отражает эту реальность.
Одной из первых разработок в этой области была модель DoD, показанная на рисунке 1.
DoD разделяла работу по передаче информации по сети на четыре отдельные функции, каждая из которых могла выполняться одним из многих протоколов. Идея наличия нескольких протоколов на каждом уровне считалась несколько спорной до конца 1980-х и даже в начале 1990-х гг. На самом деле одним из ключевых различий между DoD и первоначальным воплощением модели OSI является концепция наличия нескольких протоколов на каждом уровне.
В модели DoD:
Физический уровень отвечает за получение "0" и "1" модулированных или сериализованных на физическом канале. Каждый тип связи имеет свой формат для передачи сигналов 0 или 1; физический уровень отвечает за преобразование 0 и 1 в физические сигналы.
Интернет-уровень отвечает за передачу данных между системами, которые не связаны между собой ни одной физической связью. Таким образом, уровень интернета предоставляет сетевые адреса, а не локальные адреса каналов, а также предоставляет некоторые средства для обнаружения набора устройств и каналов, которые должны быть пересечены, чтобы достичь этих пунктов назначения.
Транспортный уровень отвечает за построение и поддержание сеансов между коммутирующими устройствами и обеспечивает общий прозрачный механизм передачи данных для потоков или блоков данных. Управление потоком и надежная транспортировка также могут быть реализованы на этом уровне, как и в случае с TCP.
Прикладной уровень - это интерфейс между Пользователем и сетевыми ресурсами или конкретными приложениями, которые используют и предоставляют данные другим устройствам, подключенным к сети.
В частности, прикладной уровень кажется неуместным в модели сетевого транспорта. Почему приложение, использующее данные, должно считаться частью транспортной системы? Потому что ранние системы считали пользователя-человека конечным пользователем данных, а приложение - главным образом способом изменить данные, которые будут представлены фактическому пользователю. Большая часть обработки от машины к машине, тяжелая обработка данных перед их представлением пользователю и простое хранение информации в цифровом формате даже не рассматривались как жизнеспособные варианты использования. Поскольку информация передавалась от одного человека другому, приложение считалось частью транспортной системы.
Два других момента могли бы помочь включению прикладного уровня сделать его более осмысленным. Во-первых, в конструкции этих оригинальных систем было два компонента: терминал и хост. Терминал тогда был дисплейным устройством, приложение располагалось на хосте. Во-вторых, сетевое программное обеспечение не рассматривалось как отдельная "вещь" в системе, маршрутизаторы еще не были изобретены, как и любое другое отдельное устройство для обработки и пересылки пакетов. Скорее, хост был просто подключен к терминалу или другому хосту; сетевое программное обеспечение было просто еще одним приложением, запущенным на этих устройствах.
Со временем, когда модель OSI стала чаше использоваться, модель DoD была изменена, чтобы включить больше уровней. Например, на рисунке 2, на диаграмме, взятой из статьи 1983 года о модели DoD ("Cerf and Cain, "The DoD Internet Architecture Model"), есть семь слоев (семь почему-то являются магическим числом).
Были добавлены три слоя:
Уровень утилит - это набор протоколов, "живущих" между более общим транспортным уровнем и приложениями. В частности, простой протокол передачи почты (SMTP), протокол передачи файлов (FTP) и другие протоколы рассматривались как часть этого уровня.
Сетевой уровень из четырехслойной версии был разделен на сетевой уровень и уровень интернета. Сетевой уровень представляет различные форматы пакетов, используемые на каждом типе канала, такие как радиосети и Ethernet (все еще очень Новые в начале 1980-х годов). Уровень межсетевого взаимодействия объединяет представление приложений и протоколов утилит, работающих в сети, в единую службу интернет-дейтаграмм.
Канальный уровень был вставлен для того, чтобы различать кодирование информации на различные типы каналов и подключение устройства к физическому каналу связи. Не все аппаратные интерфейсы обеспечивали уровень связи.
Со временем эти расширенные модели DoD потеряли популярность; модель с четырьмя слоями является той, на которую чаще всего ссылаются сегодня. На это есть несколько причин:
Уровни утилит и приложений в большинстве случаев дублируют друг друга. Например, FTP мультиплексирует контент поверх протокола управления передачей (TCP), а не как отдельный протокол или слой в стеке. TCP и протокол пользовательских дейтаграмм (UDP) со временем превратились в два протокола на транспортном уровне, а все остальное (как правило) работает поверх одного из этих двух протоколов.
С изобретением устройств, предназначенных в первую очередь для пересылки пакетов (маршрутизаторы и коммутаторы), разделение между сетевым и межсетевым уровнями было преодолено определенными событиями. Первоначальная дифференциация проводилась в основном между низкоскоростными дальнемагистральными (широкозонными) и короткозонными локальными сетями; маршрутизаторы обычно брали на себя бремя установки каналов в широкополосные сети вне хоста, поэтому дифференциация стала менее важной.
Некоторые типы интерфейсов просто не имеют возможности отделить кодирование сигнала от интерфейса хоста, как было предусмотрено в разделении между канальным и физическим уровнями. Следовательно, эти два уровня обычно объединены в одну "вещь" в модели DoD.
Модель DoD исторически важна, потому что
Это одна из первых попыток систематизировать функциональность сети в модели.
Это модель, на которой был разработан набор протоколов TCP / IP (на котором работает глобальный Интернет); Артефакты этой модели важны для понимания многих аспектов проектирования протокола TCP / IP.
В нее была встроена концепция множественных протоколов на любом конкретном уровне модели. Это подготовило почву для общей концепции сужения фокуса любого конкретного протокола, позволяя одновременно работать многим различным протоколам в одной и той же сети.