Алексей Харченко, я прямо представляю IT-детектив, как какой-нибудь губернатор открывает kremlin.ru по http и читает новость, например, о своей отставке, и назначении нового врио губрнатора. На сайте fsb.ru читает, что он объявлен в федеральный розыск. И тут в кабинет входит сын лейтенанта Шмидта и делает ему интересное предложение... .
А если б мы раньше захотели заранее подготовиться - имея сертификат c fsb.ru (с публичным ключом, без приватного) - то могли бы иметь те данные, по которым можно проверить наличие сертификата в отозванных?
но он вообще не знает был ли у kremlin.ru и fsb.ru сертификат. Это вообще странная версия, получается. Неужели, никогда и не было? Или как-то можно проверить, что был?
Именно это я и делаю - воссоздаю ту же (то есть "странную") конфигурацию на новой виртуалке, где нет зоопарка (но я хочу его там построить, чтобы безопасно откатить назад, и все проблемы получить на тестовой системе, а не на боевой). Сейчас ситуация лабораторно-чистая - предельно чистый debian amd64 на который надо поставить php i386.
Прямо по multiarch гайду ставится произвольный пакет (links) - все красиво и сразу. А вот php-cli - не ставится.
То, что на 64битной чистой системе поставится 64битный PHP я и не сомневаюсь - но это не позволит мне создать ту же проблемную ситуацию, чтобы красиво ее решить.
Я согласен, у меня вопрос довольно пространный, от "как обновить конфиг апача при установке докер контейнера" (то что шелл-скриптом можно решить) и до "как все переделать и переехать в облако".
Вообще, сложилось впечатление, что по стоимости ресурсов - AWS штука довольно дорогая, если сравнивать с недорогими VPS хостингами (ну и я замерял бенчмарки - не слишком-то быстрее, хотя ощутимо дороже). Полную отдачу можно получить если каждое приложение/сайт с самого начала под облако разрабатывать?
Правильно ли понимаю, что облачный хостинг особо хорошо работает для компаний-приложений вроде Netflix, когда есть ОДНО свое сложное приложение (под облако), ну или небольшой их набор, и сотни типовых виртуальных серверов. Но не очень хорошо подходит для обратной задачи - когда есть сотни-тысячи простеньких linux/apache/mysql/php сайтов и нужно их надежно хостить? (так как для каждого маленького сайта стоматологического кабинета и автомагазина нужно прорабатывать его облачную архитектуру)
АртемЪ, ну эту-то проблему я решил :-) Даже на хабре писал. Сайт с котиками работает даже при обесточивании дата-центра. (Сервер не работает, а сайт работает). За каждый час "умирает" два сервера, а сайт не падает.
Если в одном браузере смотреть - то из-за кеширования DNS запросов могут быть задержки, но все равно видно переключение. А если, например, в браузере, и затем в смартфоне и через сотовый интернет - то видно, что реальное переключение занимает секунды.
Правда, там ситуация проще, никакой базы, контент не меняется, ничего синхронизировать не надо, ну и все три сайта заранее подготовлены.
Я согласен. Поэтому, наверное, для такого rescue shell нужно использовать busybox, чтобы все утилиты уже были включены. Хотя бы ls/cat/ps.
Для решения частной проблемы - так и надо поступать, как вы описали. Но меня заинтересовало общее решение. При разработке же не знаешь где соломку подстелить. Поэтому и подумалось, что, наверное, было б хорошо, чтобы ssh сразу имел такую возможность, чтобы хоть что-то сразу сделать в аварийной ситуации и быстрее понять ситуацию. Еще при установке сервера включить какую-нибудь опцию EnableRescueShell yes, и через три года она пригодится.
nApoBo3, кстати, не могли бы вы пояснить по моделям безопасности один вопрос? Они все сводятся к тому, что субъект либо имеет доступ к объекту (файлу, записи), либо не имеет, и это не меняется динамически.
Но есть ведь важная потребность ограничить количество. Операционистка в Сбербанке должна иметь доступ к записи любого из ста миллионов клиентов. Но при этом она явно не должна иметь возможности слить всю базу целиком, за смену должна иметь доступ к не более чем 20 клиентам, допустим. В какой модели безопасности это динамическое ограничение реализуется?
nApoBo3, Идея не в том, чтобы "давайте не будем фиксить SQL Injection'ы, а вместо этого вот так вот усложним архитектуру, чтоб от них не было больно", а в том, что гарантировать безопасность, увы, нельзя. И все методы создания безопасного кода при применении на выходе создают НЕбезопасный код. (просто иногда уязвимость не видно по многу лет). Есть ли проект, где не было уязвимостей вообще никогда?
Поэтому, могут быть разного рода уязвимости. Мы не можем исключать никакую. И в API, так же может быть уязвимость, согласен. Но в отличие от приложения с его кучей "декоративного" функционала и тоннами кода, отладить API более реально. Я бы скорее положился на "бездырочность" API с кодом из 500 строчек (и списком URLов из 10 строчек), чем на "бездырочность" всего приложения, с кодом на из 50 000 строк. Вероятность уязвимости ниже все таки.
Безопасность ведь в том и состоит, чтобы эшелонировать оборону, и следующий уровень защищал от фейлов на предыдущих. Зачем были бы нужны файрволы, если бы все сетевые демоны были без уязвимостей в коде и настройках?
Вы изобретаете велосипед
Именно про это и вопрос - какие уже готовые велосипеды есть, чтобы их купить (а лучше бесплатно взять)
Андрей, замечательное уточнение. Ну, дропать таблицу фронтенду, по правилам, наверное, не требуется, но удалять отдельную запись - может требоваться.
Но тут другой вопрос интересный есть: нет механизма "принуждения" вебморды к тому чтобы все было безопасно. Поэтому на этапе проектирования, естественно, все хотят все безопасно делать, а на этапе эксплуатации часто все становится не так хорошо в плане безопасности, как хотелось бы. (напр, когда-то может потребоваться полный доступ на базу для отладки, а потом забыли убрать). А вот работа через API позволяет четче это разделить и усложняет незаметное неправильное использование.
Да, я именно о прослойке и говорю.
Либо прослойка (API) вообще базу изолирует, либо же отдельная ценная таблица (customers) за ней, а всякие с публичными и техническими данными - можно и локально на вебсервере.
Так если оно не используется фронтендом - можно просто исключить доступ к этим полям, для надежности. То, что захешировано - можно ведь все равно подобрать (имен - фамилий не так уж много, по крайней мере популярных, телефонных номеров - диапазон короткий). Хеш - защищает, конечно, но не так как полное отсутствие/недоступность данных.
profesor08, вот в том что я предлагаю (вижу в своих мечтах), в пределах сессии, можно получить доступ только к той записи, с которой я прошел аутентификацию.
То есть, наше веб приложение дергает метод /api/login (передает логин и пароль). Получает некий sessid (если все успешно). Затем дергает /api/profile и получает данные о пользователе. Именно о том, который в /api/login был. (Там userid даже не передается). Чтобы получить профайл другого юзера, надо успешно залогиниться как другой юзер, то есть, знать его пароль.
Более сложная ситуация:
Если же у нас есть оператор (ну как оператор в сбербанке, к которому может прийти любой клиент сбера, даже из другой страны), то для оператора будет метод вроде /api/customer_profile/. Но при этом можно сделать счетчик обращений. Оператор в день обслуживает N клиентов в среднем, можно разрешить получить данные для 2*N, следующий (2*N+1) запрос к /api/customer_profile уже не пройдет и вызовет какой-то алерт. Операционистка сбера, даже зная уязвимость в приложении, не может слить всех клиентов.
Насколько я знаю (но может плохо знаю) у обычных СУБД нет механизмов для подобных ограничений.
Антон Р., хешировать только пароль можно. Даже ФИО пользователя уже не захешируешь, т.к. приложение должно с ними работать. Либо придется шифровать, но при этом ключ хранить рядом с замком, что не слишком-то помогает.
Это же, если правильно понимаю, прослойка между приложением (базой) и ядром, чтобы доступ к объектам ОС (файлам) контролировать? А в том случае, который я имею в виду, надо в пределах таблицы доступ ограничивать и по частоте обращений, и по строкам.
Хеши тоже довольно полезные. Да и ФИО, адреса - в общем, в базе довольно много того, что если удастся получить в большом количестве - то можно использовать.
