Приветствую, Хабр! В очередной раз возникло желание обсудить блокчейн‑технологии, хотя им и было посвящено уже немало публикаций на Хабре (да и, несомненно, их еще будет много в дальнейшем).

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

В результате этого выбор данной технологии как базовой в той или иной системе может быть продиктован не техническими требованиями к системе, а как результат выбора (возможно даже, что навязанного извне) в пользу модной и перспективной технологии, возможно при этом не совсем технически обоснованного.

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

В этой статье мы рассмотрим достоинства и недостатки блокчейн‑технологий и попытаемся классифицировать сферы их применения, после чего дадим обзор формализованных методов выбора: «блокчейн или не блокчейн».

Привет, Хабр! Недавно мы с коллегами стали вспоминать, как выглядела работа с электронной подписью (ЭП) и ключевые носители, когда мы только начали работать в этой области. Мы искренне удивились тому, как за такое короткое время технологии шагнули вперед. Так родилась идея для этой статьи. Она для всех, кто когда‑нибудь имел дело с настройкой компьютера для работы с ЭП, отправкой отчетности в контролирующие органы, знает, что такое токены, оказывал техническую поддержку по работе с электронным документооборотом. Особенно для тех, кто помнит Windows XP, шариковые мышки и дискеты.

Очень надеюсь, что этот материал вызовет у вас такую же теплую ностальгию, которую ощутили мы с коллегами, когда вспоминали, как это было.

Муки самоопределения, кринжовые стажировки и собеседования, первый опыт, портфолио редактора...или как филолог искала работу в ИТ.

В этой статье — об увлекательно случайной истории пути от стажера-копирайтера до технического писателя. Как мне тут работается, почему не хочется уходить и помогает ли мне образование филолога. Отвечаем вместе на вопрос "Есть ли гуманитариям место в ИТ?".

Приветствую, Хабр! Одной из интереснейших тем для обсуждения из современной криптографии, на мой взгляд, является тема эволюции криптографических ключей и связанных с ними протоколов, обеспечивающих наличие ряда дополнительных полезных свойств систем, основанных на асимметричных криптоалгоритмах.

Различные методы эволюции ключей (терминология не устоялась, предпочитаю использовать такой перевод словосочетания «key-evolving techniques») асимметричных криптоалгоритмов позволяют защититься от компрометации секретных ключей путем периодической модификации ключевых пар. Подобная защита направлена не на предотвращение компрометации секретного ключа, а на минимизацию последствий такой компрометации: поскольку ключи периодически модифицируются, эволюционируют, данные методы позволяют ограничиться отрицательным воздействием компрометации ключа на свойство целостности или конфиденциальности сообщений, зашифрованных или подписанных только в течение определенного, относительно короткого периода, оставляя защиту сообщений других периодов ненарушенной. Большинство протоколов с эволюцией ключей подразумевает достаточно активный обмен сообщениями между сторонами защищенного обмена данными. При этом бывают сценарии, когда возможности для интерактивного взаимодействия у сторон отсутствуют.

Далее предлагаю обсудить различные известные методы эволюции ключей (обеспечивающие различные полезные свойства криптосхем: от секретности в будущем до устойчивости к вторжениям), после чего описать возможный вариант протокола модификации ключевых пар для неинтерактивных применений. 

Приветствую, Хабр! Меня зовут Сергей Панасенко, я работаю в компании «Актив» директором по научной работе. По роду занятий мне достаточно часто требуется знание (а иногда и решение вопросов практического применения) нормативных документов регуляторов в области ИБ, в том числе приказов ФСТЭК России, которые устанавливают требования по защите данных в информационных системах различного назначения (подробнее о них – под катом), а также меры по защите информации, применимые для обеспечения соответствия данным требованиям. Одна из таких мер – контроль перемещения машинных носителей информации за пределы контролируемой зоны, вызвала мой  особый интерес. Данная мера выглядит важной для обеспечения безопасности, но ее реализация напрямую (проверка сотрудников на выходе с предприятий) выглядит весьма затруднительной: носители (для определенности – USB-флешки) становятся всё более миниатюрными, и проверка их отсутствия у выходящего с территории сотрудника может превратиться в проблему и для сотрудников, и для проверяющих.

Вместо этого возникла идея определения местонахождения носителей внутри контролируемой зоны по принципу «белого списка», которой захотелось поделиться с вами. Буду признателен за обратную связь и полезные замечания.

Итак, начнем.

Привет, Хабр! Я Анастасия Дмитриева, работаю ведущим техническим писателем в компании “Актив”. Долгое время я была единственным техническим писателем в компании. Но в какой-то момент мне стало понятно, что задач очень много, и одной мне просто не справиться. Я начала поиск junior-а. Особой спешки не было, и я понимала, что я могу потратить какое-то время и научить его всему. 

В этой статье я опишу первый этап поиска: формирование требований к кандидатам и просмотр их резюме. Здесь вы увидите только моё мнение, и я не возражаю, если в комментариях появится ваше личное видение процесса поиска. Мне также хочется рассказать молодым специалистам про профессию “технический писатель”. Может, кто-то увидит себя в ней. 

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

При проектировании нового программного решения была поставлена задача выбрать язык и фреймворк. По результатам проведенного исследования был выбран язык Go, как обеспечивающий высокую производительность вместе со скоростью разработки, а также фреймворк Flamingo для реализации принципов Domain Driven Design. Всем, кому интересно узнать, что же за птица такая Flamingo, приглашаю под кат.

Концепция предметно-ориентированного проектирования, она же DDD (Domain Driven Design), описанная Эриком Эвансом, активно используется при построении информационных систем для предприятий. Не стоит пересказывать основные принципы DDD, благо, помимо книги самого Эванса, они описаны в большом количестве статей. Нам важно другое. Эти принципы гораздо проще реализовать в своей информационной системе, если они поддерживаются фреймворком.

Для .Net, например, есть ASP.NET Boilerplate (https://aspnetboilerplate.com/), полностью реализующая все компоненты DDD – Entity, Value, Repository, Domain Service, Unit of Work и еще много всего. Но мы для одной из своих внутренних информационных систем используем Go. 

Мы решили использовать фреймворк Flamingo, распространяемый под лицензией MIT. Он разработан немецкой компанией AOE GmbH в 2018 году и к настоящему моменту “дорос” до версии 3.4 и до 331 звезды на Github. Flamingo используется в информационных системах аэропортов Окланда, Франкфурта и Хитроу, а также в T-Mobile.

Данный текст не является руководством по внедрению двухфакторной аутентификации в Linux на основе токенов / смарт-карт. Подобные (и весьма подробные) руководства вы сможете найти как на сайтах производителей токенов, так и операционных систем. Я лишь хочу перечислить возможные варианты реализации 2ФА, а заодно побудить ответственных за информационную безопасность предприятия реализовать столь необходимую защиту от кражи паролей пользователей.

Друзья и коллеги, всем здравствуйте!

Началась настоящая весна, приблизив нас еще на один шаг к лету. А лето – это время долгожданных отпусков! Наверное, многие из вас перед отпуском задумывались над простыми вопросами – сколько дней отпуска у меня осталось, сколько отпускных я получу, в какие дни оптимально будет взять отпуск.
В свою очередь перед руководителями всегда стоит вопрос мониторинга баланса ресурсов, на работе присутствующих, и ресурсов, восстанавливающих силы «на югах и дачах».

О том, как в компании организовать оперативное получение "отпускной" (и не только) информации далее и пойдет речь.

Я обожаю кинематограф. Однако по мере знакомства со старой классикой и современным кино, все реже и реже встречаются действительно качественные и глубокие фильмы. В большинстве случаев картина не вызывает никаких эмоций, и приятных впечатлений хватает на один раз. Статистика походов в кино за последние лет пять совсем удручающая - 9 из 10 фильмов вызывают, как минимум, недоумение, как максимум - раздражение. Зато появилось новое хобби - выискивать тупости в сюжете. На этот раз они посвящены информационной безопасности. 

В этой статье хочу поделиться списком фильмов, в которых наглядно продемонстрировано, что может случиться, если персонажи вообще не секут в ИБ. 

Автор серии публикаций - Алексей Лазарев, руководитель Департамента защиты кибер-физических систем Компании «Актив»

В предыдущей части статьи мы рассмотрели текущую ситуацию с криптографическими системами в IoT, применив к ним закон развития систем по S-образной кривой, и сделали вывод, что подобным системам есть, куда развиваться, потому что они находятся на начальном этапе своей эволюции. Точнее, на переходном этапе между зарождением и стремительным развитием. Уже понятна необходимость их применения, так как есть запрос от общества и государства. Уже есть технологические островки для обкатки. И в целом ясно, что смерть данному направлению в ближайшие годы, а, скорее всего, десятилетия не грозит.

Глядя на то, как сегодня продвигается внедрение аппаратных средств криптографии в кибер-физических системах, к которым относят и интернет вещей, невольно вспоминаешь анекдот. 

Улитка заходит в бар, но бармен заявляет: "У нас строгая политика в отношении улиток!", — и ногой выпихивает ее на улицу. Через неделю улитка возвращается в бар и говорит бармену: "Ну и зачем ты это сделал!?"

А ведь все еще помнят, как прекрасно начиналось развитие интернета вещей. Все, что связано с IoT, IIoT, M2M поднимало волну хайпа, уступавшую разве что криптовалютной истерии. Огромное число стартапов, многие из которых казались настоящим прорывом для своего времени (“Цифровизация экономики”, “Индустрия 4.0” и др.) пробуждало немалый интерес как среди специалистов, так и у государственных лиц. Одни видели в IoT возможности реализации смелых и перспективных идей, другие – эффективный инструмент для привлечения в экономику регионов новых ресурсов. Мы же, как "безопасники", не оставались в стороне и пристально следили за развитием событий. Вот какие наблюдения нам удалось сделать.

Аспекты безопасности в IoT - в выигрыше предусмотрительные

Было понятно, что на старте, то есть в ситуации, когда важны каждая минута и каждая копейка, мало кто будет заморачиваться внедрением сложных механизмов защиты. Важнее показать потенциальному заказчику, что решение в принципе работоспособно. Но рано или поздно настает момент, когда само решение или его часть достигает состояния, допускающего возможность применения в других областях. В том числе и в тех, которые связаны с критически важной инфраструктурой. И это вызывало вполне определенные опасения. Одно дело, когда вы развлекаетесь с умной лампочкой у себя в защищенном периметре, другое – когда вы управляете исполнительным механизмом включения подачи энергоресурса, находящимся далеко за пределами вашей физической досягаемости. При схожих принципах организации взаимодействия риски и последствия вторжения в обеих ситуациях несопоставимы.

В этой статье мы хотим помочь глубже разобраться, как устроен процесс загрузки Linux, дать советы по реализации сложных сценариев загрузки Linux, а также познакомить с удобным и быстрым генератором initramfs образов - make-initrd.

Не так давно Компания «Актив» предоставила в открытый доступ на GitHub исходный код версии продукта Рутокен VPN Community Edition. В этой статье мы хотим рассказать зачем и для кого мы это сделали, как можно воспользоваться исходным кодом, и чего ожидаем в результате от сообщества разработчиков.

Зачем нужен еще один VPN? 

Как известно, события последних полутора лет стимулировали развитие рынка VPN, и сегодня он переживает эпоху роста. Конкуренция на этом рынке значительная, цены на услуги растут. Одновременно Россия в 2021 году остается в десятке топ-потребителей VPN сервисов, т.е. спрос на рынке присутствует.  

Создавая Рутокен VPN, основной «фишкой» мы решили сделать ориентацию на малый и средний бизнес, т.е. на компании, которые, вероятно, не имеют в штате постоянного и высококвалифицированного системного администратора. Именно для таких компаний мы сделали версию продукта Рутокен VPN, которая упрощает настройку VPN-сервера и клиента. Кроме того, нашей целью было предоставить разработчикам возможность развивать интересный и востребованный продукт, совершенствовать свои навыки, получая таким образом бесценный опыт и дополнительные очки к своему CV. Не скроем также, что заинтересованы и в советах участников профессионального сообщества по улучшению Рутокен VPN, которым будем максимально рады. 

В этой статье мы познакомимся со стандартом PKCS#11, предназначенным для работы с различными криптографическими устройствами. Для демонстрации мы будем использовать токены и смарт-карты Рутокен ЭЦП 2.0.

Мы решили продолжить наш цикл статей про разработку пользовательской документации, но на этот раз нам захотелось рассказать об еще одном способе создания инструкций для пользователей — это съемка видеороликов. Мы расскажем о процессе их производства: от возникновения идеи до загрузки ролика на YouTube-канал. У нас нет студии и профессиональных актеров, мы все делаем сами и хотим показать вам, что это не так сложно. Здесь вы найдете: идеи, готовые алгоритмы и, быть может, вдохновитесь на съемку своей видеоинструкции.

Люди читают пользовательскую документацию, когда самостоятельно не могут с чем-то разобраться. Они не делают это для развлечения. И эмоции, которые преобладают в этот момент, далеко не всегда позитивные. Как разработчик пользовательской документации может помочь пользователю? Что ему необходимо учитывать при написании документа?

Все мы рано или поздно оказываемся один на один со сложной информационной системой, а ведь далеко не каждый интерфейс позволяют нам быстро найти и выполнить нужную процедуру. В такой ситуации события могут развиваться по одному из двух сценариев:

Что пользователь хочет видеть в пользовательской документации? Что его в ней раздражает? Эти вопросы задаёт себе каждый, кто пишет такую документацию, но далеко не каждый правильно отвечает на них. Совсем небольшой процент пользователей читает документацию. Давайте разберёмся, почему так и как сделать пользовательскую документацию эффективной и изменить отношение пользователей к ней.

Проблематика

Ещё совсем недавно многие не знали, как это — работать из дома. Пандемия резко изменила ситуацию в мире, все начали адаптироваться к сложившимся обстоятельствам, а именно к тому, что выходить из дома стало просто небезопасно. И многим пришлось быстро организовывать работу из дома для своих сотрудников.

Однако отсутствие грамотного подхода в выборе решений для удалённой работы может привести к необратимым потерям. Пароли пользователей могут быть украдены, а это даст возможность злоумышленнику бесконтрольно подключаться к сети и ИТ-ресурсам предприятия.

Именно поэтому сейчас выросла потребность в создании надёжных корпоративных VPN сетей. Я расскажу вам о надёжной, безопасной и простой в использовании VPN сети.

Она работает по схеме IPsec/L2TP, использующей для аутентификации клиентов неизвлекаемые ключи и сертификаты, хранящиеся на токенах, а также передает данные по сети в зашифрованном виде.