Дело как раз в этом.
Как говорил один человек, «знает один — это тайна, знают двое — это секрет, знают трое — публичное достояние».
Дак вот, идентификационные данные — это секрет, который должен быть известен только пользователю и идентифицирующему сервису. Строго говоря, идентифицирующему сервису он тоже не должен быть известен, но он должен иметь возможность математически удостовериться в корректности идентификационных данных (на практическом языке — хранить хэш).
В данном случае нарушен базовый принцип безопасности: после ввода секрета идентификационный сервис оперирует данными в открытом виде, то что он вывел их на заключительном этапе говорит, что он их где-то подсохранил. В памяти, в файлах или базе — это несущественно.
Это называется вырезать гланды через анальное отверстие. Надо не приложения портировать, а делать сборку андроида для PlayBook. Гугл подсказывает, что более менее успешные попытки уже есть.
Речь о том, что переход с Oracle на EnterpriseDB будет невозможен, либо очень дорог из-за того, что многие годами работающие вещи придется переписывать на коленке на стороне приложения, либо делать middleware, а это еще одна точка отказа, которая в свою очередь потребует резервирования и цепочка потянулась.
Основная проблема состоит в непонимании ситуации. Под простые задачи, которые в состоянии выполнять
опенсорсные субд никто и не будет использовать Oracle, потому что это просто _очень_ дорого. А задачи, под которые объективно был выбран Оракл, требуют возможностей, которые предоставляет Оракл. И спрыгивать на что-то другое, пока это другое до дотянется до требуемой функциональности просто идиотизм.
Нет повести печальнее на свете, чем маркетолог в интернете.
Полез проверить есть ли что-то реализующее масштабируемость по принципу N-masters кластера. Т.е. прямой аналог Oracle RAC/GRID.
Вообще говоря, юзабили сайта (www.enterprisedb.com, я туда попал, правильно?) ужасное, потыкавшись на разные разделы я так и не попал куда-нибудь, где бы мне адекватно, по главам, представили документацию хотя бы в плане отличий от Postgresql.
Отчаявшись я ввел в гугл свой вопрос и все таки получил ответ на него.
2.4.5 Synchronous Multi-Master Replication
…
Postgres Plus Advanced Server does not offer this type of replication, though Postgres Plus Advanced Server two-phase commit (PREPARE TRANSACTION and COMMIT PREPARED) can be used to implement this in application code or middleware.
Это ваши слова, «Судите сами — компания EnterpriseDB предлагает аналогичную СУБД.»
Что вы в самом деле, фигню втираете. Да ладно бы где, здесь то зачем. Стыдно должно быть.
Я считаю что вопрос управления ключами, в том числе цикл жизни ключей имеет
непосредственное отношение к ЭЦП.
Много — да. Скомкано — нет. Все указанные технологии образуют картину целиком,
вы выкусили самую верхушку айсберга и расказываете о ней как об ЭЦП.
Подпись изначально создавалась для «удостоверения» (от достоверность) некоторым лицом.
Т.е. обязательно должен присутствовать фактор доверия. Главным фактором доверия в мире ЭЦП служит
корневой сертификат ключа подписи CA. Компрометация этого ключа мгновенно разрушает смысл
всей иерархии. Далее аналогичное условие спускается по всему дереву до конечного пользователя.
А вы говорите управление ключами не причем. Эх…
Как говорят в некоторых кругах, тема @$ли не раскрыта.
Что ожидал увидеть, но не увидел.
1. В описании pkcs7 не упомянута такая интересная вещь как co-signature (встречная подпись, дословно — подпись на подпись), фактически упрощенная функция нотариата.
2. Сама служба нотариата во всей своей мощи описана в rfc3029. Тоже не помянули.
3. Не затронули тему управления ключами, время жизни ключей, вопрос компрометации ключей, выпуск и распространение CRL, время его жизни.
4. Ничего не сказали о службе онлайновой (мгновенной) проверки статуса сертификата, она же служба OCSP, rfc4806.
5. Не рассказали о проблемах сертификации криптографического ПО в России. Хотя тут на ваше усмотрение, может быть вы не имеете к этому процессу отношения.
на raid0, raid1, raid10 оверхед не ощущается. что-то расходуется, но очень мало.
на raid5, raid6 нагрузка в разумных пределах. на нынешних процессорах опять же практически не ощущается, хотя на топе уже заметна.
про sas диски я не понял к чему было сказано, вещи не связанные.
> По-моему, люди, уверенно заявляющие о ненужности аппаратных рейдов ничего сложнее RAID1
> (в крайнем случае RAID10) из маленькой кучки SATA-дисков не видели.
зависит от потребностей. если у вас единичные сервера, то выбор небольшой, да и смысла выбирать особенно нет.
если речь о хотя бы стойке, то тут уже есть пространство для маневра и по типу размещения и по цене и по прочим условиям.
Лично я давно пришел к выводу, что если речь идет о линуксе, то никаких аппаратных рейдов не надо, даже если они под рукой. mdadm работает очевиднее, быстрее и надежнее. После сбоя его можно без проблем собрать, если собрать возможно в принципе, все понятно и предсказуемо.
Минус только в отсутствии флешпамяти с батарейкой, но во первых в аппаратных это тоже не везде есть, во-вторых для 95% задач обеспечение целостности кэша не критично. UPS в данном случае решает большую часть нештатных ситуаций.
Что касается Hetzner, у меня только один вопрос, почему вы все еще там?
> А вот все ваши пароли от сайтов/почты/аськи можно поснифать очень и очень легко.
Во-первых не все, а те которые передаются в виде, уязвимом для атаки MiM. Еcли вы еще не используете ssl/tls, то это ваше дело.
Во-вторых публичная сеть не более опасна чем любая недоверенная среда передачи данных.
В-третьих, данная схема все таки обеспечивает защиту в виде прикрытия внутреннего периметра, просто человек похоже не знает как это принято называть.
Решение жизнеспособное, как функция обнаружения критериев, но практически ненужная.
Отфильтровывать бота по единичным запросам гораздо проще обычным grep по известным критериям, их немного. Строить для этого НС нецелесообразно. У НС есть еще один минус, боты могут получить команду на изменение типа атаки. Поправить скрипты фильтрации просто, переобучить НС в общем случае сложно (дорого по времени и вычислительным ресурсам).
НС имела бы смысл, если бы вы реализовали обнаружение бота по истории его запросов, т.е. поведенческий анализ, но это уже значительно сложнее и MLP тут не выручит.
Резюмируя, подход рабочий, необычный, но практически невостребованый. Данную задачу при конкретных указанных условиях grep выполняет быстрее, проще и гибче.
Кроме аккумуляторов изнашивается и сам инструмент. при интенсивном использовании, к тому моменту, когда начинают проявляться проблемы с аккумуляторами, обычно начинают проявляться проблемы с щетками, курком, патроном. Все это меняется и ремонтируется, только стоимость такого ремонта в совокупности с заменой АКБ или банок в АКБ (не важно) оказывается больше стоимости нового шуруповерта.
С практической точки зрения такой ремонт не оправдан, разумнее купить новый инструмент, который проходит еще пару лет и на который будет гарантия, если что.
Замена дешевых банок на что-то более хорошее, хотя бы на NiMh удорожает инструмент, цена для рядового
человека будет неконкурентноспособной. Инструмент как правило выпускают не для гиков, а для обычных таких мужиков, для которых основное занятие руками работать. Им до химических процессов все равно.
Вопрос к людям, которые голосуют за «Я сам, собираю из обычного железа».
Как вы решаете задачу удаленного управления, какие аналоги iLO, IPMI используете?
Ссылки на описание конкретных железок пожалуйста.
Ок, размышляем дальше.
1. Я не утверждал, что она одна, это ваши необоснованные выдумки. Я говорю, что потерять нить/процесс
на 2 секунды в слипе, даже пула отдачи контента (не процессингового пула) только потому, что надо
задержать ответ — это очень расточительно.
2. Каков бы не был размер пула отдачи контента, он конечен. Любой конечный быстроисчерпаемый ресурс будет первой целью при ddos атаке. Вывести из работы нитку на 2 секунды — это просто находка для атакующего.
3. Рискну предположить, что вы не сталкивались с реальной ddos атакой, иначе бы поняли, что ваши очереди — это лишняя нагрузка на процессор, тем более на яве. Система под ddos это не та система, на которую вы смотрите попивая свой кофе и придумывая «чего бы еще такое интересное и академичное выдумать ». Это система у которой загрузка ядер в 100%, процессы начинает выбирать от нехватки памяти, заход по ssh занимает с полминуты и в лучшем случае удается перекрыть сетевой поток, чтобы начать обработку логов и формирование черных списков ботов.
> Добавление пары секунд задержки на ответ при превышении порога запросов с диапазона
> ip сводит на нет усилия юных хакеров.
Вы не правы. Это означает что процесс/нить обработчика запроса на эти две секунды больше будет
несвободна для других клиентов. Одна из задач платежного шлюза обеспечить максимальную
скорострельность, а вы предлагаете убить две секунды только на задержку с ответом.
Как говорил один человек, «знает один — это тайна, знают двое — это секрет, знают трое — публичное достояние».
Дак вот, идентификационные данные — это секрет, который должен быть известен только пользователю и идентифицирующему сервису. Строго говоря, идентифицирующему сервису он тоже не должен быть известен, но он должен иметь возможность математически удостовериться в корректности идентификационных данных (на практическом языке — хранить хэш).
В данном случае нарушен базовый принцип безопасности: после ввода секрета идентификационный сервис оперирует данными в открытом виде, то что он вывел их на заключительном этапе говорит, что он их где-то подсохранил. В памяти, в файлах или базе — это несущественно.
Основная проблема состоит в непонимании ситуации. Под простые задачи, которые в состоянии выполнять
опенсорсные субд никто и не будет использовать Oracle, потому что это просто _очень_ дорого. А задачи, под которые объективно был выбран Оракл, требуют возможностей, которые предоставляет Оракл. И спрыгивать на что-то другое, пока это другое до дотянется до требуемой функциональности просто идиотизм.
Полез проверить есть ли что-то реализующее масштабируемость по принципу N-masters кластера. Т.е. прямой аналог Oracle RAC/GRID.
Вообще говоря, юзабили сайта (www.enterprisedb.com, я туда попал, правильно?) ужасное, потыкавшись на разные разделы я так и не попал куда-нибудь, где бы мне адекватно, по главам, представили документацию хотя бы в плане отличий от Postgresql.
Отчаявшись я ввел в гугл свой вопрос и все таки получил ответ на него.
2.4.5 Synchronous Multi-Master Replication
…
Postgres Plus Advanced Server does not offer this type of replication, though Postgres Plus Advanced Server two-phase commit (PREPARE TRANSACTION and COMMIT PREPARED) can be used to implement this in application code or middleware.
Это ваши слова, «Судите сами — компания EnterpriseDB предлагает аналогичную СУБД.»
Что вы в самом деле, фигню втираете. Да ладно бы где, здесь то зачем. Стыдно должно быть.
непосредственное отношение к ЭЦП.
Много — да. Скомкано — нет. Все указанные технологии образуют картину целиком,
вы выкусили самую верхушку айсберга и расказываете о ней как об ЭЦП.
Подпись изначально создавалась для «удостоверения» (от достоверность) некоторым лицом.
Т.е. обязательно должен присутствовать фактор доверия. Главным фактором доверия в мире ЭЦП служит
корневой сертификат ключа подписи CA. Компрометация этого ключа мгновенно разрушает смысл
всей иерархии. Далее аналогичное условие спускается по всему дереву до конечного пользователя.
А вы говорите управление ключами не причем. Эх…
Что ожидал увидеть, но не увидел.
1. В описании pkcs7 не упомянута такая интересная вещь как co-signature (встречная подпись, дословно — подпись на подпись), фактически упрощенная функция нотариата.
2. Сама служба нотариата во всей своей мощи описана в rfc3029. Тоже не помянули.
3. Не затронули тему управления ключами, время жизни ключей, вопрос компрометации ключей, выпуск и распространение CRL, время его жизни.
4. Ничего не сказали о службе онлайновой (мгновенной) проверки статуса сертификата, она же служба OCSP, rfc4806.
5. Не рассказали о проблемах сертификации криптографического ПО в России. Хотя тут на ваше усмотрение, может быть вы не имеете к этому процессу отношения.
на raid0, raid1, raid10 оверхед не ощущается. что-то расходуется, но очень мало.
на raid5, raid6 нагрузка в разумных пределах. на нынешних процессорах опять же практически не ощущается, хотя на топе уже заметна.
про sas диски я не понял к чему было сказано, вещи не связанные.
> По-моему, люди, уверенно заявляющие о ненужности аппаратных рейдов ничего сложнее RAID1
> (в крайнем случае RAID10) из маленькой кучки SATA-дисков не видели.
Это завышенное ЧСВ говорит, не более того.
если речь о хотя бы стойке, то тут уже есть пространство для маневра и по типу размещения и по цене и по прочим условиям.
Минус только в отсутствии флешпамяти с батарейкой, но во первых в аппаратных это тоже не везде есть, во-вторых для 95% задач обеспечение целостности кэша не критично. UPS в данном случае решает большую часть нештатных ситуаций.
Что касается Hetzner, у меня только один вопрос, почему вы все еще там?
Во-первых не все, а те которые передаются в виде, уязвимом для атаки MiM. Еcли вы еще не используете ssl/tls, то это ваше дело.
Во-вторых публичная сеть не более опасна чем любая недоверенная среда передачи данных.
В-третьих, данная схема все таки обеспечивает защиту в виде прикрытия внутреннего периметра, просто человек похоже не знает как это принято называть.
Отфильтровывать бота по единичным запросам гораздо проще обычным grep по известным критериям, их немного. Строить для этого НС нецелесообразно. У НС есть еще один минус, боты могут получить команду на изменение типа атаки. Поправить скрипты фильтрации просто, переобучить НС в общем случае сложно (дорого по времени и вычислительным ресурсам).
НС имела бы смысл, если бы вы реализовали обнаружение бота по истории его запросов, т.е. поведенческий анализ, но это уже значительно сложнее и MLP тут не выручит.
Резюмируя, подход рабочий, необычный, но практически невостребованый. Данную задачу при конкретных указанных условиях grep выполняет быстрее, проще и гибче.
С практической точки зрения такой ремонт не оправдан, разумнее купить новый инструмент, который проходит еще пару лет и на который будет гарантия, если что.
Замена дешевых банок на что-то более хорошее, хотя бы на NiMh удорожает инструмент, цена для рядового
человека будет неконкурентноспособной. Инструмент как правило выпускают не для гиков, а для обычных таких мужиков, для которых основное занятие руками работать. Им до химических процессов все равно.
www.sapido.com.tw/EN/data/service/rb1632_35g.ht
поправьте
Как вы решаете задачу удаленного управления, какие аналоги iLO, IPMI используете?
Ссылки на описание конкретных железок пожалуйста.
Ок, размышляем дальше.
1. Я не утверждал, что она одна, это ваши необоснованные выдумки. Я говорю, что потерять нить/процесс
на 2 секунды в слипе, даже пула отдачи контента (не процессингового пула) только потому, что надо
задержать ответ — это очень расточительно.
2. Каков бы не был размер пула отдачи контента, он конечен. Любой конечный быстроисчерпаемый ресурс будет первой целью при ddos атаке. Вывести из работы нитку на 2 секунды — это просто находка для атакующего.
3. Рискну предположить, что вы не сталкивались с реальной ddos атакой, иначе бы поняли, что ваши очереди — это лишняя нагрузка на процессор, тем более на яве. Система под ddos это не та система, на которую вы смотрите попивая свой кофе и придумывая «чего бы еще такое интересное и академичное выдумать ». Это система у которой загрузка ядер в 100%, процессы начинает выбирать от нехватки памяти, заход по ssh занимает с полминуты и в лучшем случае удается перекрыть сетевой поток, чтобы начать обработку логов и формирование черных списков ботов.
> ip сводит на нет усилия юных хакеров.
Вы не правы. Это означает что процесс/нить обработчика запроса на эти две секунды больше будет
несвободна для других клиентов. Одна из задач платежного шлюза обеспечить максимальную
скорострельность, а вы предлагаете убить две секунды только на задержку с ответом.