C нуля — естественно не факт, но речь шла не об этом.
Мне вообще кажется, что для систем которые только создаются намного легче соответствовать 152 ФЗ. Если бы он появился лет 10 назад, когда инфраструктура нашего предприятия только создавалась, нам было бы намного легче. Например, мы могли бы засунуть в отдельное помещение отдел кадров и зарплатчиков, по другому планировать схемы БД и многое другое. А вот сейчас, перестраивать имеющуюся систему намного сложнее.
Я рад за вас что они уже есть. Мы про вас или про вообще?
Вообще-то, я про себя. И про тех, у кого уже используется лицензионное, но не сертифицированное ФСТЭК ПО.
Вы уверены что у вас все приобретенные Windows той версии? :)
Да, уверен. Им наплевать, на самом деле, на дистрибутив. Главное, чтоб на диске было написано Service Pack 2 или Service Pack 3.
Хорошо. Это произошло что дальше? Кем осуществляется поддержка, откуда берутся обновления и кем после обновления подтверждается что у вас все еще все сертифицировано? :)
О да. Это отдельный разговор. У них какое-то свое ПО для обновлений. Есть даже возможность централизованной установки этих обновлений. Что-то типа своего WSUS'a с преферансом и девицами.
Сами сертифицированные обновления входят во все пакеты (состав пакетов), а вот софтину надо покупать.
В случае с Windows все ровно тоже самое. Опять же Windows XP Pro сейчас купить сложно, а вот Windows 7 Корпоративная. А она стоит далеко не всем те две тысячи про которые вы говорите :)
Посмотрите на мой самый первый комментарий. У нас есть 100 машин с лицензионной Windows XP/Vista/7 — есть уже! Не надо мне покупать лицензии! А сертификаты надо! И сертификат этот стоит около 2-х тысяч на одно рабочее место.
Вы своим первым комментарием предложили мне переход на linux. В этом случае уже стоимость ПО для перехода будет больше чем стоимость сертификации имеющегося ПО. Не говоря уже о затратах связанных со сменой инфраструктуры.
Мне вот очень сильно интересно как в этом случае обеспечивается сертификация.
Они присылают мне дистрибутивы, якобы проверенные спец. лабораторией, с сертификатами. Я с этих дистрибутивов устанавливаю операционку и ввожу свои ключи. По крайней мере они говорят так.
Сертифицированной считается система, установленная с оригинального диска, имеющего уникальный номер, проставленный сертифицированной лабораторией, и действующий купон технической поддержки.
Т.е., без поддержки, версия не считается сертифицированной. Каждый год надо будет платить. Windows XP и Windows 7. Еще их продает «Альтекс софт» (или как-то так) — на сайт сейчас зайти не могу, лежит, но порядок цен такой же.
Там дело в том, что сертифицированный дистрибутив не содержит лицензии Microsoft — ее нужно покупать отдельно, но об этом я уже писал.
Согласно условиям применения, комплект считается сертифицированным только при наличии купона технической поддержки, соответствующего типу компьютера (Рабочая станция или Сервер) с уникальным номером, в количестве 1 купон на 1 компьютер.
Альт Линукс СПТ 6.0 Рабочая станция с технической поддержкой на 1 год — 7000 рублей
Сертифицированый Windows дешевле купить. Если лицензия не нужна (уже куплена), они за 2 тыр продаются (примерно).
Я о том и говорю, что сейчас закон позволяет хитроумным продавцам ПО делать деньги буквально из воздуха.
Тут дело не в стране, а в законе. Накой, спрашивается, я должен покупать 100 сертифицированных дистрибутивов windows xp на 100 машин, если я использую коропоративные лицензии и устанавливаю на все 100 машин один и тот же дистрибутив?
А продавцы сертифицированного ПО продают винду с сертификатами только на 1 машину. Microsoft говорит — нас это не волнует, разбирайтесь с ними сами.
Нормальных сертифицированных фаерволов нет. Продукты Eset и Agnitum'а сертифицированы только частично, ставить их нельзя. А поделки от SecurityCOde и прочих российских производителей и не хочется…
А вот интересно, если на Denali выполнить скрипт 2 (который для SQL 2005/2008) — будет отличие по CPU time или нет?
Т.е. не является ли уменьшение CPU time следствием улучшения оптимизатора запросов, а не того, что Offset как-то хитро на уровне ядра выполняется?
насколько я понимаю, должно иметься в виду что-то отличное от штатных механизмов move db, copy db — т.к. они предлагают «движение» и связанных объектов (логины, задания и тд). по крайней мере, если делать это через гуй.
Да, SQL Server позволяет переносить логины на другой сервер, с помощью SSIS-пакета (задачи Transfer Logins и Transfer jobs). Но для этого у вас должен быть доступ к обоим SQL Server'ам с нехилыми правами. Contained Databases — позволит разработчикам, например, создать БД, набить ее какими-то служебными данными, сразу добавить туда какие-то job'ы и предопределенных пользователей и распространять. Это, возможно, будет удобно. От покупателя требуется только наличие SQL Server'a и не требуется наличие администратора баз данных — все «регламенты» уже включены в БД.
Вот, кстати, сейчас подумалось, что 1С, с их подходом к БД, будут очень рады запихать туда как можно больше и постараться запретить администраторам «на местах» менять в их базе хоть что-то.
т.е. имеем 2+ «унаследованных» баз, базы раньше жили на отдельных серверах, везде был сделан вход через «sa», пароли sa разные.
сможет ли приложение прозрачно аутентифицироваться/авторизоваться под sa своей базы?
Вы, по-моему, немного запутались с логинами и пользователями. Логин — это сущность сервера, связанная с сущностью БД — пользователем. Т.е. одному логину могут соответствовать несколько пользователей в разных БД.
Когда вы создаете автономного пользователя в contained database, для него НЕ создается логин. И после конвертации обычного пользователя в автономного — ему больше не нужен логин (в примере его логин вообще становится запрещенным — disabled).
Ваше приложение сможет авторизоваться, если в строке соединения будет прописана ВАША же contained database.
если мы мигрируем БД с сервера на сервер, и на новом сервере в списке учеток сервера/автономных бд уже есть аккаунт с таким же именем — что будет?
Ничего не будет. Список логинов сервера проверяться не будет — пользователь в contained database «самодостаточен», ему логин не нужен, а общего списка пользователей автономных БД тоже не существует — они хранятся каждый в своей базе.
Вообще интересно, если у нас есть linked server, «привязанный» к какой-то БД, сможем ли мы к нему обратиться в контексте другой БД? и немножко позанудствую по переводу:
Мне кажется, что linked servers стоит переводить не как «соединенные сервера», а как связанные сервера" — такая же формулировка используется MS в переводах BOL.
«Агенты задач» \ «агенты заданий», имхо, лучше перевести как «задания агента SQL Server» — более длинный вариант, но сразу понятный.
не совсем верно выразился: индексы на users к увеличению производительности не приведут. Просто я его писал в контексте того комментария, на который давал ответ. А там было условие оставлять FULL SCAN на calls.
У вас такой запрос, что хоть заиндексируйся — прироста не будет. Из users вы дергаете примерно половину записей (предполагаю, что мужчин и женщин там поровну), а потом все это соединяете со своими 10 миллионами записей в calls.
Имхо, от такого исследования толку нет — в рабочей системе таким запросам явно не место. И начинающим программистам (для которых, как я понимаю, вы это все и делали) лучше дать совет использовать соединения там где они нужны, используя при этом правильные индексы и думать над тем, что реально выполняет их запрос.
Мне кажется, имело бы смысл, написать про возможные проблемы при использовании того или иного уровня изоляции транзакций: грязные чтения, неповторяющиеся чтения, etc.
Угу… Особыми… Они обратились в испытательную лабораторию, им проверили эти дистрибутивы, выдали на них сертификаты, а теперь альтэкс-софт делает деньги «из воздуха» (как и все фирмы, продающие «сертифицированное» ПО). Очень порадовал NOD — мы купили у них всего 1 дистрибутив и теперь можем ставить его на все машины. А альтэкс-софт хочет чтобы мы на каждую машину ставили отдельно купленный дистрибутив, при том что на большой части используется один и тот же дистр винды и корпоративные лицензии.
Если вы хотите свои 300 дистрибутивов не менять, можете обратиться в спец. испытательную лабораторию, их список есть на сайте ФСТЭКа (прямая ссылка на список: fstec.ru/_doc/labs/_labs.xls). Только встанет вопрос с обновлениями. При покупке в том самом альтекс-софте обновляться можно будет с их серверов, «сертифицированными» обновлениями.
Тут дело в том, что если вы не позционируете свою СУБД как средство защиты, то она не обязательно должна быть сертифицирована.
Т.е. на этапе составления угроз вы выбираете актуальные для вас угрозы и решаете какими средствами/методами вы будете их «закрывать». ФСТЭК говорит, что, в принципе, для небольшой компании обрабатывающей только ПДн сотрудников, можно «закрыться» исключительно организационными мерами (увы, не говорят как). Если вы пишете, что какую-то угрозу «закрываете» с помощью своей СУБД — то она должна быть сертифицирована ФСТЭК как средство СЗИ.
Мне вообще кажется, что для систем которые только создаются намного легче соответствовать 152 ФЗ. Если бы он появился лет 10 назад, когда инфраструктура нашего предприятия только создавалась, нам было бы намного легче. Например, мы могли бы засунуть в отдельное помещение отдел кадров и зарплатчиков, по другому планировать схемы БД и многое другое. А вот сейчас, перестраивать имеющуюся систему намного сложнее.
Вообще-то, я про себя. И про тех, у кого уже используется лицензионное, но не сертифицированное ФСТЭК ПО.
Да, уверен. Им наплевать, на самом деле, на дистрибутив. Главное, чтоб на диске было написано Service Pack 2 или Service Pack 3.
О да. Это отдельный разговор. У них какое-то свое ПО для обновлений. Есть даже возможность централизованной установки этих обновлений. Что-то типа своего WSUS'a с преферансом и девицами.
Сами сертифицированные обновления входят во все пакеты (состав пакетов), а вот софтину надо покупать.
Посмотрите на мой самый первый комментарий. У нас есть 100 машин с лицензионной Windows XP/Vista/7 — есть уже! Не надо мне покупать лицензии! А сертификаты надо! И сертификат этот стоит около 2-х тысяч на одно рабочее место.
Вы своим первым комментарием предложили мне переход на linux. В этом случае уже стоимость ПО для перехода будет больше чем стоимость сертификации имеющегося ПО. Не говоря уже о затратах связанных со сменой инфраструктуры.
Они присылают мне дистрибутивы, якобы проверенные спец. лабораторией, с сертификатами. Я с этих дистрибутивов устанавливаю операционку и ввожу свои ключи. По крайней мере они говорят так.
Т.е., без поддержки, версия не считается сертифицированной. Каждый год надо будет платить.
Windows XP и Windows 7. Еще их продает «Альтекс софт» (или как-то так) — на сайт сейчас зайти не могу, лежит, но порядок цен такой же.
Там дело в том, что сертифицированный дистрибутив не содержит лицензии Microsoft — ее нужно покупать отдельно, но об этом я уже писал.
Сертифицированый Windows дешевле купить. Если лицензия не нужна (уже куплена), они за 2 тыр продаются (примерно).
Я о том и говорю, что сейчас закон позволяет хитроумным продавцам ПО делать деньги буквально из воздуха.
А продавцы сертифицированного ПО продают винду с сертификатами только на 1 машину. Microsoft говорит — нас это не волнует, разбирайтесь с ними сами.
Нормальных сертифицированных фаерволов нет. Продукты Eset и Agnitum'а сертифицированы только частично, ставить их нельзя. А поделки от SecurityCOde и прочих российских производителей и не хочется…
Т.е. не является ли уменьшение CPU time следствием улучшения оптимизатора запросов, а не того, что Offset как-то хитро на уровне ядра выполняется?
Да, SQL Server позволяет переносить логины на другой сервер, с помощью SSIS-пакета (задачи Transfer Logins и Transfer jobs). Но для этого у вас должен быть доступ к обоим SQL Server'ам с нехилыми правами. Contained Databases — позволит разработчикам, например, создать БД, набить ее какими-то служебными данными, сразу добавить туда какие-то job'ы и предопределенных пользователей и распространять. Это, возможно, будет удобно. От покупателя требуется только наличие SQL Server'a и не требуется наличие администратора баз данных — все «регламенты» уже включены в БД.
Вот, кстати, сейчас подумалось, что 1С, с их подходом к БД, будут очень рады запихать туда как можно больше и постараться запретить администраторам «на местах» менять в их базе хоть что-то.
Вы, по-моему, немного запутались с логинами и пользователями. Логин — это сущность сервера, связанная с сущностью БД — пользователем. Т.е. одному логину могут соответствовать несколько пользователей в разных БД.
Когда вы создаете автономного пользователя в contained database, для него НЕ создается логин. И после конвертации обычного пользователя в автономного — ему больше не нужен логин (в примере его логин вообще становится запрещенным — disabled).
Ваше приложение сможет авторизоваться, если в строке соединения будет прописана ВАША же contained database.
Ничего не будет. Список логинов сервера проверяться не будет — пользователь в contained database «самодостаточен», ему логин не нужен, а общего списка пользователей автономных БД тоже не существует — они хранятся каждый в своей базе.
и немножко позанудствую по переводу:
Мне кажется, что linked servers стоит переводить не как «соединенные сервера», а как связанные сервера" — такая же формулировка используется MS в переводах BOL.
«Агенты задач» \ «агенты заданий», имхо, лучше перевести как «задания агента SQL Server» — более длинный вариант, но сразу понятный.
Спасибо.
Имхо, от такого исследования толку нет — в рабочей системе таким запросам явно не место. И начинающим программистам (для которых, как я понимаю, вы это все и делали) лучше дать совет использовать соединения там где они нужны, используя при этом правильные индексы и думать над тем, что реально выполняет их запрос.
Если вы хотите свои 300 дистрибутивов не менять, можете обратиться в спец. испытательную лабораторию, их список есть на сайте ФСТЭКа (прямая ссылка на список: fstec.ru/_doc/labs/_labs.xls). Только встанет вопрос с обновлениями. При покупке в том самом альтекс-софте обновляться можно будет с их серверов, «сертифицированными» обновлениями.
Т.е. на этапе составления угроз вы выбираете актуальные для вас угрозы и решаете какими средствами/методами вы будете их «закрывать». ФСТЭК говорит, что, в принципе, для небольшой компании обрабатывающей только ПДн сотрудников, можно «закрыться» исключительно организационными мерами (увы, не говорят как). Если вы пишете, что какую-то угрозу «закрываете» с помощью своей СУБД — то она должна быть сертифицирована ФСТЭК как средство СЗИ.