Есть какие-то различные темы оформления на выбор (чтобы не надо было самому заниматься правками CSS)? Не знаю, почему, но вот не могу работать с темными темами оформления. Всегда выбираю на светлом фоне.
Рассматривал Kibana в свое время, когда выбирал, что использовать в production. Понравилась система на первый взгляд. Интерфейс удобным и понятным выглядит. Но я искал SaaS в силу ряда причин. Это отдельная тема для обсуждения.Остановил свой выбор все же на другом, а Kibana для себя отметил, что надо будет посмотреть еще раз, когда вернусь к вопросу мониторинга и анализа логов со всех серверов.
По вашему опыту Kibana хорошо подойдет для задачи сбора информационных и сообщений об ошибках из логов для их визуального представления с различными фильтрами по ключевым словам и отображению на графиках кол-ва ошибок? И связать это со сторонним сервисом для оповещений, когда какой-то порог превышен. Или что-то требуется найти в логах. Например, все, что относится к такому-то пользователю (если в логе указывается имя пользователя, конечно).
На мой взгляд у Zabbix огромные проблемы с UI/UX. Удовольствия от работы с ним не испытываешь. По функциональности, конечно, очень гибко, в целом все есть готовое и расширяемое.
Я думаю, здесь зависит от того, кто к чему больше привык. Это тоже самое, как есть фанаты iOS и Android с вечными «войнами» в плане интерфейса. ;)
Очень рекомендую посмотреть DataDog (http://datadoghq.com). Коммерческое решение, стоит $15/месяц за сервер. Бесплатный тарифный план не позволяет хранить исторические данные более суток и создавать alert'ы по приходящим данным.
Все очень гибко настраивается визуально на сайте. Есть интеграция со многими стандартными сервисами, есть API. Помимо стандартных вещей типа мониторинга нагрузки на сервере очень легко написать свои небольшие модули для передачи в DataDog любых данных типа количества регистраций или входов в личный кабинет.
Можно настроить alert'ы на случаи, когда какие-то показатели выходят за пределы нормы (например, место на диске заканчивается). Alert'ы идеально интегрируются с сервисом PagerDuty, который умеет отправлять SMS/звонить на телефон с учетом расписания работы технического персонала (задается, чья смена и в каком порядке кого необходимо уведомить).
Да, это не бесплатно. Хотя, можно попробовать и на бесплатном тарифе. Возможно, подойдет для определенных задач. Но ничего лучше в роли dashboard, с чем легко и приятно работать, я не встречал.
runbox.com не предоставляет шифрование почты, как я понял из его описания и пробного аккаунта. Только обычное HTTPS соединение. Но зато самая навороченная админка. Можно очень много чего настроить.
Я решил, что читателям не будет интересно смотреть на появляющиеся «звездочки» пока я заполняю поля для установки паролей. А вот видео использования сервиса, наверное, будет интересно читателям. Если будет интерес у сообщества, и получится по времени у меня, то постараюсь сделать. Может быть в интернете уже есть? Поделитесь ссылками, если кто знает.
У них есть пароль для авторизации на сайте. Он изменяется. Достаточно его изменить и получить доступ на сайт станет невозможным. Но, получив почтовый пароль, злоумышленник сможет расшифровать сообщения, доступ к которым у него будет в силу каких-либо причин.
Если осуществить Man-in-the-middle аттаку, то достаточно пользователю показать приглашение для ввода его почтового пароля и получить ответ. Ну или встроить в JavaScript код, который этот пароль отправит.
Такой атаке подвержен любой веб-сервис, так как надежность авторизации держится на том, что у злоумышленника не может быть доступа к паролю в открытом виде. Если даже пароль не передается в открытом виде или вообще, как в случае с ProtonMail, не покидает пределы компьютера, то имея возможность вклиниться в поток данных, можно изменить JavaScript и получить заветный пароль.
Именно поэтому реализация криптографии на стороне браузера является плохим решением с точки зрения безопасности. Надо, чтобы у злоумышленника не было способа изменить исполняемый код, как минимум. А это значит, что реализация криптографии должна быть вынесена или в отдельное ПО, или хотя бы в плагин к браузеру. Но от социальной инженерии с просьбой ввести почтовый пароль на сайте, а не в ПО это не поможет.
Есть несколько решений данной задачи. Основное и самое простое — это построить индекс исходного текста, но значения индекса не должны выдавать исходные ключевые слова. На первый взгляд захочется использовать обычную hash-функцию типа MD5/SHA, но это позволит атакующему подобрать ключевые слова, посчитав значения hash-функций для всех слов в словаре. Данное решение не подходит. Но! Есть MAC (http://ru.wikipedia.org/wiki/Имитовставка). Если очень упростить объяснение, то MAC работает как hash-функция, но требуется еще и пароль для ее работы.
Соответственно, индексируем письмо на стороне клиента и на сервер отправляем посчитанный индекс для поиска, который пропущен через MAC с почтовым паролем. Когда надо найти что-то, то клиент считать MAC от введенной строки для поиска и отправляет серверу. Сервер не может догадаться, что ищет клиент по этому значению, и выдает список документов из индекса, в которых встречалось введенное ключевое слово.
Получаем, что:
1. Сервер не знает, что в индексе
2. Сервер не знает, что просят искать
3. Нельзя восстановить содержимое индекса путем расчета значения hash-функции для всех слов по словарю
4. У всех пользователей одно и то же слово даст разный hash. Имея значения для одного пользователя нельзя получить доступ к данным другого пользователя.
Да, кстати, во многих случаях решение, размещающееся на собственных серверах, и при этом правильно организованное, будет иметь несомненно массу преимуществ для компаний. Хотя бы дать полный контроль над тем, как работает сервис и что на нем когда изменяется и зачем. Во многих случаях это будет уже больше напоминать паранойю, но надо отталкиваться от задачи (от кого защищаются).
Именно поэтому сервис может считаться «безопасным» только в случае, если даже изъятие серверов не нарушит безопасность пользователей. То есть не должно быть никакой потенциальной возможности получить доступ к данным пользователей. А в подобной реализации достаточно добавить одну строку кода на JavaScript, чтобы отправить почтовый пароль пользователя куда-то за пределы его компьютера.
В противном случае это напоминает игру в кошки-мышки. Сегодня они в Швейцарии, так как туда «не доберутся» по их словам, завтра — на околоземной орбите спутник :)
Несомненно, такое криптографическое решение имеет право на существование, но не думаю, что стоит его описывать столь громкими заявлениями, как это делается ими в пресс-релизах. Надо отметить, что PR-команда у них работает на «отлично».
В статье приводил ссылку http://matasano.com/articles/javascript-cryptography/ , где очень хорошо последовательно даются ответы на все потенциальные вопросы, объясняя, что все подобные решение на стороне браузера, где код скрипта отдается сервисом, имеют массу недостатков.
Нативные приложения (почтовые клиенты, встроенные в ОС, и отдельные приложения) и, естественно, open-source решения. Если мы говорим только про атаки со стороны хакеров, а не государственных служб, то потенциальные «закладки» в закрытом ПО можно не рассматривать. Подобные закладки имеют практическое применение только у тех, кто про них знает, а это очень узкий круг людей. Хотя, как показывает практика, и до open-source тоже добрались. Из последних примеров — реализация проверки сертификата в openssl. Хотя может быть и обычной ошибкой ;) Это тема для отдельной дискуссии.
Совершенно верно! У всех подобных сервисов слишком много потенциальных проблем. Их надо стараться минимизировать. Но такие сервисы востребованы и будут существовать, так как пользователи хотят «простых» решений. Найти грань очень тяжело — уж очень она тонкая в этих вопросах. Все зависит от задачи.
Настройка — одноразовое действие, если не происходит смена устройства, переустановка операционной системы (что очень любят делать многи компании по технической поддержке в любом удобном случае), потенциально может что-то измениться в программном комплексе, что потребуется от пользователя какой-то реакции. А первый вопрос вызовет в большинстве случаев нажатие первой попавшейся кнопки или ступор.
Все это становится в разы сложнее, когда устройств много в компании. И чем сложнее обслуживание, тем больше вероятность нарушение регламента работы с ПО. Еще есть «хотелки» в стиле том, что кто-то привык использовать XYZ для чтения почты, и ZYX ему вообще не нравится. К сожалению, в компаниях с подобными трудностями приходится сталкиваться постоянно.
И довольно тяжело произвести такую настройку удаленно. Да, есть удаленный рабочий стол и т.п. Но объяснить недоверчивому и технически плохо представляющему пользователю, как это все работает (который слышал про безопасные веб-сервисы), зачем ему это все делают, является очень сложной задачей.
Решения для криптографии уже давно существуют. Проблема, как вы совершенно справедливо заметили, именно в том, что очень тяжело научить среднестатистического пользователя их использовать.
Домохозяйкам шифровать рецепты пирогов, наверное, не требуется. Если нет паранойни у них ;) А то всякое бывает…
А вот во многих компаниях большая часть документаоборота осуществляется по email без шифрования. Далее воображение может очень далеко зайти в том, какие беды и несчастья могут причинить те, кто завладеют конфиденциальной информацией.
Еще существенный момент во всей истории — установить подлинность отправителя письма. Именно поэтому так важно сделать грамотно и механизм авторизации, чтобы нельзя было злоумышленнику создать и отправить письмо от имени скомпрометированного почтового ящика. Например, одна компания ждет реквизиты для оплаты, а злоумышленник отправляет свое письмо со своими реквизитами, так как ранее получил доступ к паролю почтового ящика отправителя.
Очень неудобно — проверено неоднократно. Во-первых, остается вопрос, как передать этот пароль адресату. Во-вторых, секретарши в этой ситуации входят в ступор.
Да, проблема передачи пароля ставит данное решение в один ряд с загрузкой архива с паролем на любой общедоступный сервис (или пересылку его по email). Но уверен, что с точки зрения маркетинга это является хорошим ходом, так как легко использовать в качестве invite'ов — своеобразного завлечения на сервис новых пользователей.
А это как раз очень удобно и я часто этим пользуюсь. Пользуюсь этим для пересылки финансовой и другой важной информации: если компьютер у секретарши/бухгалтера/Васи Пупкина взломают, то к этой информации доступа не будет. Но насколько ю понимаю, в этом случае получатель должен на что-то кликнуть в теле письма, чтобы получить текст письма (ведь текст хранится на сервере). И тут секретарши опять входят в ступор.
Здесь может быть две ситуации:
1. Письмо самоудаляющееся было отправлено на сторонней сервис. Пришла ссылка на сайт ProtonMail. По истечению срока жизни письма сервис удаляет его у себя. По ссылке получить доступ к письму становится более невозможным. Данный сценарий полностью аналогичен отправлению зашифрованных паролем писем на сторонний сервис, когда получателю приходит ссылка на сайт ProtonMail.
2. Письмо отправляется от одного пользователя ProtonMail другому. В этом случае после истечения времени оно будет удалено на сервисе. Работа с таким письмом никак не отличается от работы с письмом без даты уничтожения для пользователей ProtonMail. Никаких лишних кликов.
Является решением на базе Roundcube и плагина к нему OpenPGP. Данный плагин хранит ключи в Local storage браузера. Отличие от Session storage, которое использует ProtonMail в том, что данные в Local Storage сохраняются между сессиями. Это требуется для постоянно хранения ключей там.
Но доступ к данному хранилищу (Local и Session storage) есть из любого JavaScript и, безусловно, malware на компьютере пользователя. Единственное ограничение доступа same-origin-policy. То есть, чтобы получить доступ к данным в local или session storage бразуера, скрипт должен быть получен с того же домена и протокола (http / https), но путь к скрипту при этом может быть другой.
Соответственно, браузер никаких вопросов не задаст пользователю, если получит кусок кода для извлечения данных оттуда с этого же домена. Браузер не сможет отличить вредоносный код от реального кода сервиса. Это же применимо и к XSS-атакам. Если удастся воткнуть зловредный JavaScript в страницу каким-либо способом, то на этом вся безопасность заканчивается.
Слишком уж много уязвимостей, которые легко использовать, у подобных решений.
1. Если пароль и сертификат скомпрометированы, то всё — ничего сделать нельзя. Что в этом случае — менять почтовый адрес?
В данном решение от ProtonMail на текущем этапе получается именно так. Причем, о том, что пароль нельзя сменить они пишут еще при регистрации, чтобы, видимо, не ставили временных тестовых паролей в надежде поменять позднее.
2. Злоумышленник, имеющий доступ к серверу (и приватному ключу) может модифицировать javascript и перехватить пароль. И тут моя паранойя выходит на новый уровень.
Совершенно согласен. Об этом я как раз в статье и писал, что проблема всех подобных решений в том, что достаточно встроить перехват пароля (и/или приватного ключа) из сессионного хранилища веб-браузера (одна строка кода) либо на стороне сервера, либо через XSS, либо через malware.
Про openmailbox.org отвечу отдельным комментарием. Пойду посмотрю сейчас.
Но до тех пор пока сама система, выполняющая шифрование, пересекается «пространством» со сторонним кодом, эта является самый большой дырой в безопасности. Именно поэтому решения с плагинами или отдельным специальным ПО являются единственным правильным путем, так как криптографическое ПО работает по принципу черного ящика для содержимого страницы.
По вашему опыту Kibana хорошо подойдет для задачи сбора информационных и сообщений об ошибках из логов для их визуального представления с различными фильтрами по ключевым словам и отображению на графиках кол-ва ошибок? И связать это со сторонним сервисом для оповещений, когда какой-то порог превышен. Или что-то требуется найти в логах. Например, все, что относится к такому-то пользователю (если в логе указывается имя пользователя, конечно).
Я думаю, здесь зависит от того, кто к чему больше привык. Это тоже самое, как есть фанаты iOS и Android с вечными «войнами» в плане интерфейса. ;)
Все очень гибко настраивается визуально на сайте. Есть интеграция со многими стандартными сервисами, есть API. Помимо стандартных вещей типа мониторинга нагрузки на сервере очень легко написать свои небольшие модули для передачи в DataDog любых данных типа количества регистраций или входов в личный кабинет.
Можно настроить alert'ы на случаи, когда какие-то показатели выходят за пределы нормы (например, место на диске заканчивается). Alert'ы идеально интегрируются с сервисом PagerDuty, который умеет отправлять SMS/звонить на телефон с учетом расписания работы технического персонала (задается, чья смена и в каком порядке кого необходимо уведомить).
Да, это не бесплатно. Хотя, можно попробовать и на бесплатном тарифе. Возможно, подойдет для определенных задач. Но ничего лучше в роли dashboard, с чем легко и приятно работать, я не встречал.
Такой атаке подвержен любой веб-сервис, так как надежность авторизации держится на том, что у злоумышленника не может быть доступа к паролю в открытом виде. Если даже пароль не передается в открытом виде или вообще, как в случае с ProtonMail, не покидает пределы компьютера, то имея возможность вклиниться в поток данных, можно изменить JavaScript и получить заветный пароль.
Именно поэтому реализация криптографии на стороне браузера является плохим решением с точки зрения безопасности. Надо, чтобы у злоумышленника не было способа изменить исполняемый код, как минимум. А это значит, что реализация криптографии должна быть вынесена или в отдельное ПО, или хотя бы в плагин к браузеру. Но от социальной инженерии с просьбой ввести почтовый пароль на сайте, а не в ПО это не поможет.
Соответственно, индексируем письмо на стороне клиента и на сервер отправляем посчитанный индекс для поиска, который пропущен через MAC с почтовым паролем. Когда надо найти что-то, то клиент считать MAC от введенной строки для поиска и отправляет серверу. Сервер не может догадаться, что ищет клиент по этому значению, и выдает список документов из индекса, в которых встречалось введенное ключевое слово.
Получаем, что:
1. Сервер не знает, что в индексе
2. Сервер не знает, что просят искать
3. Нельзя восстановить содержимое индекса путем расчета значения hash-функции для всех слов по словарю
4. У всех пользователей одно и то же слово даст разный hash. Имея значения для одного пользователя нельзя получить доступ к данным другого пользователя.
Упрощенный пример реализации на SQL (демонстрация идеи):
http://blogs.msdn.com/b/raulga/archive/2006/03/11/549754.aspx
В противном случае это напоминает игру в кошки-мышки. Сегодня они в Швейцарии, так как туда «не доберутся» по их словам, завтра — на околоземной орбите спутник :)
Несомненно, такое криптографическое решение имеет право на существование, но не думаю, что стоит его описывать столь громкими заявлениями, как это делается ими в пресс-релизах. Надо отметить, что PR-команда у них работает на «отлично».
В статье приводил ссылку http://matasano.com/articles/javascript-cryptography/ , где очень хорошо последовательно даются ответы на все потенциальные вопросы, объясняя, что все подобные решение на стороне браузера, где код скрипта отдается сервисом, имеют массу недостатков.
Нативные приложения (почтовые клиенты, встроенные в ОС, и отдельные приложения) и, естественно, open-source решения. Если мы говорим только про атаки со стороны хакеров, а не государственных служб, то потенциальные «закладки» в закрытом ПО можно не рассматривать. Подобные закладки имеют практическое применение только у тех, кто про них знает, а это очень узкий круг людей. Хотя, как показывает практика, и до open-source тоже добрались. Из последних примеров — реализация проверки сертификата в openssl. Хотя может быть и обычной ошибкой ;) Это тема для отдельной дискуссии.
Все это становится в разы сложнее, когда устройств много в компании. И чем сложнее обслуживание, тем больше вероятность нарушение регламента работы с ПО. Еще есть «хотелки» в стиле том, что кто-то привык использовать XYZ для чтения почты, и ZYX ему вообще не нравится. К сожалению, в компаниях с подобными трудностями приходится сталкиваться постоянно.
И довольно тяжело произвести такую настройку удаленно. Да, есть удаленный рабочий стол и т.п. Но объяснить недоверчивому и технически плохо представляющему пользователю, как это все работает (который слышал про безопасные веб-сервисы), зачем ему это все делают, является очень сложной задачей.
Домохозяйкам шифровать рецепты пирогов, наверное, не требуется. Если нет паранойни у них ;) А то всякое бывает…
А вот во многих компаниях большая часть документаоборота осуществляется по email без шифрования. Далее воображение может очень далеко зайти в том, какие беды и несчастья могут причинить те, кто завладеют конфиденциальной информацией.
Еще существенный момент во всей истории — установить подлинность отправителя письма. Именно поэтому так важно сделать грамотно и механизм авторизации, чтобы нельзя было злоумышленнику создать и отправить письмо от имени скомпрометированного почтового ящика. Например, одна компания ждет реквизиты для оплаты, а злоумышленник отправляет свое письмо со своими реквизитами, так как ранее получил доступ к паролю почтового ящика отправителя.
Да, проблема передачи пароля ставит данное решение в один ряд с загрузкой архива с паролем на любой общедоступный сервис (или пересылку его по email). Но уверен, что с точки зрения маркетинга это является хорошим ходом, так как легко использовать в качестве invite'ов — своеобразного завлечения на сервис новых пользователей.
Здесь может быть две ситуации:
1. Письмо самоудаляющееся было отправлено на сторонней сервис. Пришла ссылка на сайт ProtonMail. По истечению срока жизни письма сервис удаляет его у себя. По ссылке получить доступ к письму становится более невозможным. Данный сценарий полностью аналогичен отправлению зашифрованных паролем писем на сторонний сервис, когда получателю приходит ссылка на сайт ProtonMail.
2. Письмо отправляется от одного пользователя ProtonMail другому. В этом случае после истечения времени оно будет удалено на сервисе. Работа с таким письмом никак не отличается от работы с письмом без даты уничтожения для пользователей ProtonMail. Никаких лишних кликов.
Является решением на базе Roundcube и плагина к нему OpenPGP. Данный плагин хранит ключи в Local storage браузера. Отличие от Session storage, которое использует ProtonMail в том, что данные в Local Storage сохраняются между сессиями. Это требуется для постоянно хранения ключей там.
Но доступ к данному хранилищу (Local и Session storage) есть из любого JavaScript и, безусловно, malware на компьютере пользователя. Единственное ограничение доступа same-origin-policy. То есть, чтобы получить доступ к данным в local или session storage бразуера, скрипт должен быть получен с того же домена и протокола (http / https), но путь к скрипту при этом может быть другой.
Соответственно, браузер никаких вопросов не задаст пользователю, если получит кусок кода для извлечения данных оттуда с этого же домена. Браузер не сможет отличить вредоносный код от реального кода сервиса. Это же применимо и к XSS-атакам. Если удастся воткнуть зловредный JavaScript в страницу каким-либо способом, то на этом вся безопасность заканчивается.
Слишком уж много уязвимостей, которые легко использовать, у подобных решений.
Ссылки по теме:
1. https://www.owasp.org/index.php/HTML5_Security_Cheat_Sheet#Local_Storage
2. http://www.drdobbs.com/web-development/the-localstorage-api/240000682
В данном решение от ProtonMail на текущем этапе получается именно так. Причем, о том, что пароль нельзя сменить они пишут еще при регистрации, чтобы, видимо, не ставили временных тестовых паролей в надежде поменять позднее.
Совершенно согласен. Об этом я как раз в статье и писал, что проблема всех подобных решений в том, что достаточно встроить перехват пароля (и/или приватного ключа) из сессионного хранилища веб-браузера (одна строка кода) либо на стороне сервера, либо через XSS, либо через malware.
Про openmailbox.org отвечу отдельным комментарием. Пойду посмотрю сейчас.
Но до тех пор пока сама система, выполняющая шифрование, пересекается «пространством» со сторонним кодом, эта является самый большой дырой в безопасности. Именно поэтому решения с плагинами или отдельным специальным ПО являются единственным правильным путем, так как криптографическое ПО работает по принципу черного ящика для содержимого страницы.