Производители средств криптографической защиты информации (СКЗИ) предлагают различные механизмы для интеграции криптосредств в информационные системы. Существуют решения, ориентированные на поддержку систем с Web-интерфейсом, мобильных и десктопных приложений, серверных компонентов. СКЗИ интегрируются в приложения Microsoft и в продукты Open Source, обеспечивают поддержку различных прикладных протоколов и форматов электронной подписи.

С учетом растущего количества проектов с применением ЭЦП и появления массовых проектов для физических лиц, разработчикам подобных проектов требуется хорошо ориентироваться в предлагаемых производителями решениях по ЭЦП для того, чтобы сделать систему удобной в эксплуатации и недорогой в плане техподдержки. Таким образом, если еще лет 5 назад главным фактором выбора криптосредства являлось его полное соответствие требованиям регуляторов, то при сегодняшнем разнообразии важными критериями могут выступать охват поддерживаемых платформ, возможность интеграции с браузером, поддержка мобильных пользователей, возможность установки без прав системного администратора и т.п.

В данном материале сделана попытка классифицировать средства криптографической защиты информации.

• Рассмотрены в основном СКЗИ, использующиеся на клиентских местах для защиты клиент-серверных соединений по протоколу TLS, для организации ЭЦП, шифрования передаваемых данных;
  
• Не рассматриваются СКЗИ, применяемые для создания VPN и шифрования файловой системы, хранимых данных, а так же УЦ;
  
• Отдельно выделены аппаратные криптографические устройства.

Классификация построена на основе:

• технологий интеграции (CryptoAPI, Active-X, NPAPI и др.), которые поддерживают СКЗИ для встраивания в приложения и прикладные системы;
• интерфейсов, которые предоставляют СКЗИ для встраивания в приложения и прикладные системы.

Кроме того, показаны способы интеграции СКЗИ с Web-приложениями и возможность его использования на мобильных платформах

Общая схема классификации приведена в таблице:

Криптопровайдеры	Нативные библиотеки (openssl-style, PKCS#11, NSS, собственные интерфейсы)	Локальные прокси	Браузерные плагины	Облачная подпись	Браузеры с российской криптографией
Почтовые клиенты с российской криптографией	Российская криптография в фреймворках, платформах, интерпретаторах	Настольные криптографические приложения	Криптография в BIOS UEFI	Сервис-провайдеры ЭЦП	Эмуляторы доверенной среды
Аппаратные средства

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

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

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

• Браузеры используют совершенно различные криптографические библиотеки (MS Crypto API, NSS, openssl). Универсального криптосредства, которое «добавляет» ГОСТы во все эти библиотеки нет
• Механизмы встраивания многих криптосредств в операционную систему и в браузер «завязаны» на версию ОС. С выходом обновления ОС работоспособность криптосредства может кончиться
• Google Chrome отказывается от поддержки плагинов, работающих через NPAPI. А многие российские вендоры криптосредств разработали плагины, используя именно данный механизм
• На мобильных платформах браузеры не поддерживают плагины

В данной ситуации наиболее универсальным решением представляется вынести реализацию TLS-ГОСТ и функций ЭЦП в отдельное сетевое приложение, которое принимает запросы от браузера на localhost, позволяет «туннелировать» соединения между браузером и удаленными web-серверами (real proxy), а также предоставляет HTTP API для функционала ЭЦП, работы с сертификатами, токенами и т.п.
Не скажу, что идея является новой, но давайте попробуем сделать некоторый конструктор для ее реализации.

Деталями конструктора будут:

• nginx в режиме reverse proxy
• php, php-cgi
• stunnel
• openssl
• Рутокен ЭЦП Flash
• engine pkcs11_gost
• библиотека pkcs#11
• C++ библиотека PKI-Core

Любители модульных архитектурных экпериментальных решений приглашаются под кат.

Прошедшим и будущим выборам посвящается.

После вбросов, скандалов, интриг, расследований, которые были на думских выборах, невольно задаешься вопросом: а как сделать так, чтобы было все честно? Ну а применительно к ИТ, как сделать так, чтобы все было честно, да еще и с помощью высоких технологий? Я читал и про пробивание дырочек, и про QR-коды, поэтому решил внести скромную математическую лепту.
В этом топике мы поговорим с вами о том, как решить две взаимно противоположные проблемы с помощью криптографии: проблему верификации избирателя и проблему тайны голосования. Я немного расскажу о так называемой «слепой подписи» и даже представлю демонстрационное приложение, которое показывает, каким образом могут быть решены задачи верификации и анонимности одновременно, причем на основе криптоалгоритмов ГОСТ 34.10 и 34.11, которые официально одобрены ФСБ.

Intro: Synergy является кумулятивным Open Source расширением Spree, ориентированным на создание интернет-магазинов в России.
Миссия проекта состоит в том, чтобы предоставить весь необходимый фунционал, специфичный для российских интернет-магазинов, а также упростить интеграцию рекомендуемых расширений.

Список изменений по сравнению с Synergy 0.50.0:

На фото — Терри Фокс, пробежал 5 373 км за 143 дня, без перерыва.

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

Семантический спектр слова "Resourceful" = <находчивый, изобретательный, продуктивный, ловкий, сообразительный, инициативный, изворотливый, хитроумный>.

Оригинал — Relentlessly Resourceful
(За перевод спасибо Andrew Tchernov)

Пару дней назад я наконец-то нашел способ описать хорошего основателя стартапа: неустанно находчив (relentlessly resourceful).

До этого лучшим, что мне удавалось сформулировать, это свести противоположные качества к одному – несчастный. Большинство словарей говорят, что это значит отсутствие успеха, удачи. Но словари не сослужат хорошей службы в данном случае. Команде, которая обыгрывает своих соперников, но проигрывает из-за судьи, не повезло, но она не несчастная. Этот термин скорее подразумевает пассивность, быть несчастным значит быть размазанным обстоятельствами — прогнуться под окружающий мир, когда нужно идти по своему пути.[1]

К сожалению, нет антонима к слову несчастный, и это мешает объяснить основателям стартапов к чему они должны стремиться. «Не будь несчастным» это что-то больше похожее на крик безысходности.

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

К сожалению это всего лишь метафора, причем бесполезная для большинства людей за пределами США. «Будь подобен бегуну спиной вперед», не лучше чем «Не будь несчастен».

Но, наконец, я придумал, как выразить это качество. Я писал речь для инвесторов, и мне надо было объяснить, на что надо обращать внимание в организаторах стартапов. Каким должен быть человек в противоположность несчастному? Неустанно находчивым. Не только неустанным. Этого недостаточно чтобы заставить события развиваться согласно вашему плану, ну может кроме пары неинтересных ситуаций. В интересной же – сложности будут нестандартными. Что значит, что вы не сможете просто пробиться через них потому, что вы изначально не знаете насколько они сложны; вы не знаете, где будете пробиваться через кусок пены, а где – через гранит. Поэтому вы должны быть находчивы. Вы должны стараться находить новые решения.

Будьте неустанно находчивы.

Создание приложений — комплексный процесс, который включает в себя несколько элементов: написание кода, тестирование, устранение ошибок, проверку и, наконец, запуск в эксплуатацию. Можно сказать, что в этом процессе участвуют три независимых «государства» — разработчики, тестировщики и сотрудники отдела эксплуатации. Каждая из этих групп выполняет собственные задачи и пользуется разными критериями оценки эффективности своей работы. Для разработчиков — это скорость написания и количество реализованных в программном коде функций, для тестировщиков — число выявленных ошибок, для отдела эксплуатации — стабильность функционирования систем и минимальное количество инцидентов. Подобная модель работы нередко приводит к конфликту интересов: первые стараются как можно быстрее написать код и отдать его на проверку, вторые готовы проверять и тестировать сколь угодно долго, чтобы выявить все баги, а третий с трудом принимает код, поскольку любые изменения влекут за собой потенциальные риски для всей ИТ-инфраструктуры. В итоге весь процесс создания приложений растягивается надолго, что с учетом сложной экономической ситуации совершенно недопустимо, ведь бизнес должен быть максимально гибким и клиентоориентированным, а выпуск новых продуктов и услуг своевременным.

Карта Тройка представляет из себя универсальный пополняемый электронный кошелек, широко используемый в системах оплаты общественного транспорта Москвы с 2013 года.

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

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

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

Внимание! Данные материалы представлены исключительно в ознакомительных целях. Подделка проездных билетов является уголовным преступлением и преследуется по закону.

Не так давно Google купили Firebase и теперь на странице с описанием GCM нас встречает радостная новость о том, что пора бы мигрировать на Firebase.

...GCM users are strongly recommended to upgrade to FCM, in order to benefit from new FCM features today and in the future.

В этой статье мы разберем тестовый проект и рассмотрим один подводный камень связанный с иконкой уведомления.

Нам понадобится:

• Android Studio
• Код демо-проекта с github
• 20 минут свободного времени

Слепота Microsoft. Предупреждающие знаки для Google и Apple

В одной из фундаментальных книг по этой теме «Организационная культура и лидерство» Эдгар Шейн пишет:

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

В терминологии Шейна вещи вроде столов для настольного тенниса и холодильников с пивом — это два (маленьких) примера артефактов – видимых качеств организации. Их легко заметить, но их значение обычно не поддаётся расшифровке и уникально для конкретной группы (другими словами, простое копирование фишек Google не работает).

Гордон Винтроб, редактор «GET PUT POST» — электронной рассылки об API приложений, «захвативших» рынок, недавно взял интервью у Кристины Кордовой, начальника отдела работы с клиентами Stripe — одной из самых заметных компаний среди наших западных коллег. Ранее, в рамках цикла статей о платежном сервисе, мы рассказали о его основателях — братьях Коллисон, а также о том, с чего начинал Stripe, как он выглядит изнутри, как стал многомиллиардной компанией и чем завоевал любовь своих партнеров. Сегодня же поговорим о подходе компании к партнерским отношениям и о том, как они помогают платформе расти, а также обсудим вопрос построения процесса разработки API, максимально учитывающего клиентские потребности. Далее непосредственно интервью.

Это статья для руководителей отделов разработки, бывших разработчиков. Я очень часто слышу два противоположных мнения. Они звучат примерно так:

• «Нам важен готовый продукт — плевать на плохой код»
• «Нам важен поддерживаемый продукт — пусть это и будет долго»

Это вечный спор между «говнокодом» и «скоростью разработки», менеджерами и разработчиками. Ошибаются обе стороны. Это два конца одной палки. На этой палке я бы написал красными буквами «ошибки руководителя разработки». Кому интересная эта тема — добро пожаловать под кат. А еще под катом много букв об архитектуре ПО, микросервисах и здравом смысле.

Автор: Вячеслав Михайлов, Solutions Architect.

В этой статье я поделюсь опытом проектирования RESTful API — на конкретных примерах покажу, как делать хотя бы простые сервисы красиво. Также мы поговорим, что такое API и зачем он нужен, поговорим об основах REST — обсудим, на чем его можно реализовывать; коснемся основных веб-практик, которые зависят и не зависят от этой технологии. Также узнаем, как составлять хорошую документацию, затрачивая на это минимум усилий, и посмотрим, какие существуют способы нумерации версий для RESTful API.

Часть 1. Теория

Итак, как мы все знаем, API — application programming interface (интерфейс программирования приложений), набор правил и механизмов, с помощью которых одно приложение или компонент взаимодействует с другими

Почему хороший API — это важно?

• Простота использования и поддержки. Хороший API просто использовать и поддерживать.
• Хорошая конверсия в среде разработчиков. Если всем нравится ваш API, к вам приходят новые клиенты и пользователи.
• Выше популярность вашего сервиса. Чем больше пользователей API, тем выше популярность вашего сервиса.
• Лучше изоляция компонентов. Чем лучше структура API, тем лучше изоляция компонентов.
• Хорошее впечатление о продукте. API — это как бы UI разработчиков; это то, на что разработчики обращают внимание в первую очередь при встрече с продуктом. Если API кривой, вы как технический эксперт не будете рекомендовать компаниям использовать такой продукт, приобретая что-то стороннее.

Теперь посмотрим, какие бывают виды API.

Виды API по способу реализации:

• Web service APIs
  
  • XML-RPC and JSON-RPC
  • SOAP
  • REST
  
  
• WebSockets APIs
• Library-based APIs
  
  • Java Script
  
  
• Class-based APIs
  
  • C# API
  • Java
  
  

Виды API по категориям применения:

• OS function and routines
  
  • Access to file system
  • Access to user interface
  
  
• Object remoting APIs
  
  • CORBA
  • .Net remoting
  
  
• Hardware APIs
  
  • Video acceleration (OpenCL…)
  • Hard disk drives
  • PCI bus
  • …
  
  

Автор: Вячеслав Михайлов

Монолитные приложения и их проблемы

Все прекрасно знают, что такое монолитное приложение: все мы делали такие двух- или трехслойные приложения с классической архитектурой:

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

Так или иначе, по мере роста и развития приложения, вы сталкиваетесь с проблемами монолитных архитектур:

• сложность системы постоянно растет;
• поддерживать ее все сложнее и сложнее;
• разобраться в ней трудно — особенно если система переходила из поколения в поколение, логика забывалась, люди уходили и приходили, а комментариев и тестов нет);
• много ошибок;
• мало тестов — монолит не разобрать и не протестировать, поэтому обычно есть только UI-тесты, поддержка которых обычно занимает много времени;
• дорого вносить изменения;
• застревание на технологиях (например, я работал в компании, где с 2003 г. технологии до сих пор не изменились).

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

Привет, Хабр!

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

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

У всех этих источников есть общая черта: ни один не сделал из меня более крутого собеседующего, и ничто не улучшило качество рекрутинга (это, конечно, не численная оценка, а мое личное ощущение). Ну, может, не все так плохо. Конечно, я изучил что-то новое и полезное, и стал задумываться о процессе собеседования глубже. Что, в итоге, очень хорошо.

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

Сегодня выходной, так что напишу коротко про мелочи, до которых, как правило, руки не доходят.

TCP FS

Есть ещё одна вещь, которой нет в современном Юниксе и которую я хочу иметь в unix box фантома. Она проста как мычание, и почему её никто не сделал — непостижимо:

#cat /tcp/host/port > local_file

Правда, я хочу использовать иной синтаксис имени файла, URL style — tcp://host:port, но это уже детали. Естественно, наравне с TCP просится UDP, и там вообще проблем нет.



Для TCP есть очевидная проблема — нужен ли нам listen или connect, но её можно решить через указание в имени «файла» определённого суффикса.

Сказать на эту тему настолько больше нечего, что перейдём без остановки к следующей.

TRFS — тривиальная дистанционная файловая система.

Введение:

На мой взгляд, одна из основных проблем между бизнес аналитиками и пограммистами Баз Данных – это их взаимодействие. Многие современные BI решения предлагают, по сути, перенести работу аналитиков на программистов. Либо поднять технический уровень аналитиков, приблизив их к программистам. Вместо этого, я предлагаю рассмотреть решение, которое берет информацию у программистов БД и отдаёт её бизнес-аналитикам. Это решение позволит каждому заниматься своим делом, а не становиться программистом и бизнес аналитиком в одном лице.

Недавно я занялся поиском хорошего инструмента для создания прототипов и анимации своих идей. В итоге исследование рынка превратилось в пересмотр специализаций инструментов своего арсенала и шлифовкой процесса проектирования нового продукта.

Предыстория

Пару лет назад на Хабре была статья, посвящённая Адаму Мадьяру Камера Эйнштейна: как один фотограф изображает время. Мне она показалась очень интересной, но, если честно, то я так и не понял технологию для съёмки видео Stainless. Особенно меня восхитили его фотографии поезда метро. После чего я задался мыслью: а могу ли я сам создать нечто подобное?

Адам Мадьяр — компьютерный гик, бросивший университет, фотограф-самоучка, Руб Голдберг высоких технологий, путешественник по миру и художник-концептуалист с растущим мировым признанием. Но никто не мог предположить, что он может быть еще и террористом, до того утра, пока он не спустился на станцию метро Юнион-Сквер в Нью-Йорке.

В то время Мадьяр был погружен в долговременный проект на стыке технологий и искусства под названием Stainless («Безупречные»), создавая изображения высокого разрешения из проезжающих поездов и пассажиров, используя сложное, написанное им самим программное обеспечение и доработанную промышленную фотокамеру. Техника сканирования, которую он разработал — объединение тысяч кадров шириной в пиксель в одно изображение — позволяет ему заставать пассажиров врасплох, пока они с шумом и лязгом летят сквозь темные тоннели метро, фиксируя их в призрачных изображениях, наполненных деталями, которые не может запечатлеть ни одна обычная камера.

Всем привет!
Хочу представить вам собственную разработку для создания API-документации. Она еще немного «сыровата», поскольку я уделил ей всего неделю, кроме того, я не являюсь веб-разработчиком. Однако на данном этапе, с целью написания API-документации для своего будущего проекта, она меня полностью устраивает.

Сама разработка находится на GitHub: github.com/gatools/restful-visual-editor

Заинтересовавшихся — милости прошу под кат.