Я согласен, у меня вопрос довольно пространный, от "как обновить конфиг апача при установке докер контейнера" (то что шелл-скриптом можно решить) и до "как все переделать и переехать в облако".
Вообще, сложилось впечатление, что по стоимости ресурсов - 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 уже не пройдет и вызовет какой-то алерт. Операционистка сбера, даже зная уязвимость в приложении, не может слить всех клиентов.
Насколько я знаю (но может плохо знаю) у обычных СУБД нет механизмов для подобных ограничений.
Антон Р., хешировать только пароль можно. Даже ФИО пользователя уже не захешируешь, т.к. приложение должно с ними работать. Либо придется шифровать, но при этом ключ хранить рядом с замком, что не слишком-то помогает.
Это же, если правильно понимаю, прослойка между приложением (базой) и ядром, чтобы доступ к объектам ОС (файлам) контролировать? А в том случае, который я имею в виду, надо в пределах таблицы доступ ограничивать и по частоте обращений, и по строкам.
Хеши тоже довольно полезные. Да и ФИО, адреса - в общем, в базе довольно много того, что если удастся получить в большом количестве - то можно использовать.
Идея в том, что у API в принципе нет метода (по крайней мере доступного для фронтенда) чтобы сделать то, что фронтенду не нужно (напр, получить всех юзеров или дропнуть таблицу). Поэтому обращаться некуда.
Сделать доступ к записи пользователя только после его аутентификации - возможно? А лимитировать "дать не более 100 записей из табл. customers" за день ?
По производительности: у меня сейчас идея как раз в том, чтобы только маленькую часть данных (самую конфиденциальную) так надежно защищать, поэтому, даже если логин будет происходит не 0.01s а 10s - это все равно терпимо. А 90-99% данных могут быть по прежнему в базе, пусть даже утекают - их утечка мало что даст.
database firewalls прямо звучит как надо :-) Еще вопрос: а что-то опен-сорсное, бесплатное есть в этой сфере? По первому впечатлению, Imperva - это что-то для компаний типа боинга или кока-колы, за миллионы долларов.
Вообще, сложилось впечатление, что по стоимости ресурсов - AWS штука довольно дорогая, если сравнивать с недорогими VPS хостингами (ну и я замерял бенчмарки - не слишком-то быстрее, хотя ощутимо дороже). Полную отдачу можно получить если каждое приложение/сайт с самого начала под облако разрабатывать?
Правильно ли понимаю, что облачный хостинг особо хорошо работает для компаний-приложений вроде Netflix, когда есть ОДНО свое сложное приложение (под облако), ну или небольшой их набор, и сотни типовых виртуальных серверов. Но не очень хорошо подходит для обратной задачи - когда есть сотни-тысячи простеньких linux/apache/mysql/php сайтов и нужно их надежно хостить? (так как для каждого маленького сайта стоматологического кабинета и автомагазина нужно прорабатывать его облачную архитектуру)