Где это все сейчас? Где?!
вторник, 29 ноября 2011 г.
понедельник, 28 ноября 2011 г.
Ненависти псто
Вот казалось бы, что может быть проще - записаться на курсы... Ан нет, все не так просто.
Маленькая предыстория.
В связи с принятием гениального 152-го федерального закона "О персональных данных" в далеком 2006 году, жизнь операторов персональных данных стала прекрасной и удивительной. Во-первых, операторами персональных данных являются абсолютно все организации - ОАО, ЗАО, ИП, ПБОЮЛ, вообще все, у кого есть сотрудники, либо контрагенты - физические лица. Во-вторых, денег, для приведения информационной системы персональных данных, в соответствие этому чудесному закону, требуется чуть больше чем до хрена, а сложность администрирования получившиейся системы возрастает если не на порядки, то в разы уж точно. Ну, это небольшое отвлечение от темы. В общем, есть закон, который мы обязаны соблюдать.
По воле рока так случилось, что отвественным за исполнение этого закона был назначен я. Естественно, я не единолично решаю как будет защищаться предприятие - в этом принимает участие весь отдел. Но если придет проверка и вскроется, что мы не защищены, то штраф, по словам юристов, наложат на меня и, если я в какие-то сроки, не приму меры, мне даже могут запретить занимать должности связанные с защитой информации (и, видит Бог, я не буду переживать по этому поводу). Но я опять отвлекся.
В общем, поскольку нас хотят защищать аж 4 фирмы, но у каждой из этих фирм своя точка зрения на защиту ПДн, выбрать очень тяжело. Хотя бы потому, что я (и никто из отдела, в общем-то) вообще нихрена не понимаю как в итоге должна выглядеть защищенная система. И было принято волевое решение отправить меня на курсы.
Сказано-сделано. Нашли курсы в Омске. В ОмГТУ. Программа вроде нормальная, но по телефону не смогли сразу назвать фамилию того кто их ведет. Ладно, хрен с ним, по крайней мере хоть кому-то можно будет задать вопрос, может быть даже с кем-то пообщаться на тему - как это сделано у них и что они обо всем этом думают. Обменяться опытом, так сказать.
Итак, созваниваюсь и говорю, что хочу пройти курс "Защита персональных данных". "Отлично!", говорят мне. "Как раз 28-го ноября начинается такой курс. Народу правда мало, но он точно будет". В тот же день, мне высылают проект договора, мы подписываем его и мы договариваемся, что 28-го числа я приношу подписанный нами договор к началу занятий.
Договор я принес, но, блядь, когда начались занятия, оказалось, что это ДРУГОЙ курс.
Другой, блядь. Вот как это вообще возможно? Курс не по защите персональных данных, а по криптографической защите информационных систем.
Криптография мне не уперлась вообще никуда, курс по защите персональных данных есть, но он занятия там начались неделю назад. Договор заключался на прохождение мной курса по защите персональных данных. И ведет оба курса давний знакомый, бывший сотрудник одной из фирм-лицензиатов ФСТЭК. Мужик, конечно, умный, но точки зрения наши во многом не совпадали.
В общем, завтра буду звонить в полутех и ругаться-ругаться-ругаться.
Завтра же будет подтверждена, либо опровергнута бритва Хэнлона: "Не стоит искать злого умысла в том, что может быть объяснено человеческой глупостью". Может быть действительно, тетушка на телефоне не видит разницы между этими двумя курсами?! Не понимаю...
upd
Ну вот и завершение этой глупой истории.
Поскольку на курс по защите персональных данных записалось 3 человека и на курс по криптографической защите информационных систем записалось столько же человек - в чью-то, без сомнения гениальную, голову пришла идея эти курсы совместить.
Что интересно. Программа курса для всех будет одна, но корочки все получат разные. Трое, как и планировали - по защите ПДн, другие трое - по криптографической защите ИС.
Немного удивила позиция преподователя: "Если он такой умный, то зачем записался на курсы?", высказанная в личном разговоре между ним и моим начальником.
Я, блядь, не считаю себя "таким" умным, но хочу разобраться как и что надо делать, а не сидеть с вылупленными глазками и внимать бреду льющемуся из его рта.
Ни один, ни один человек не смог доказать мне, что
1) нашу ИСПДн надо аттестовывать;
2) при защите ИСПДн надо руководствоваться, в том числе, СТР-К.
В общем, я несколько растроен, был лучшего мнения об этом человеке и думал, что он так же хочет и может разобраться в хитросплетениях 152 ФЗ.
Маленькая предыстория.
В связи с принятием гениального 152-го федерального закона "О персональных данных" в далеком 2006 году, жизнь операторов персональных данных стала прекрасной и удивительной. Во-первых, операторами персональных данных являются абсолютно все организации - ОАО, ЗАО, ИП, ПБОЮЛ, вообще все, у кого есть сотрудники, либо контрагенты - физические лица. Во-вторых, денег, для приведения информационной системы персональных данных, в соответствие этому чудесному закону, требуется чуть больше чем до хрена, а сложность администрирования получившиейся системы возрастает если не на порядки, то в разы уж точно. Ну, это небольшое отвлечение от темы. В общем, есть закон, который мы обязаны соблюдать.
По воле рока так случилось, что отвественным за исполнение этого закона был назначен я. Естественно, я не единолично решаю как будет защищаться предприятие - в этом принимает участие весь отдел. Но если придет проверка и вскроется, что мы не защищены, то штраф, по словам юристов, наложат на меня и, если я в какие-то сроки, не приму меры, мне даже могут запретить занимать должности связанные с защитой информации (и, видит Бог, я не буду переживать по этому поводу). Но я опять отвлекся.
В общем, поскольку нас хотят защищать аж 4 фирмы, но у каждой из этих фирм своя точка зрения на защиту ПДн, выбрать очень тяжело. Хотя бы потому, что я (и никто из отдела, в общем-то) вообще нихрена не понимаю как в итоге должна выглядеть защищенная система. И было принято волевое решение отправить меня на курсы.
Сказано-сделано. Нашли курсы в Омске. В ОмГТУ. Программа вроде нормальная, но по телефону не смогли сразу назвать фамилию того кто их ведет. Ладно, хрен с ним, по крайней мере хоть кому-то можно будет задать вопрос, может быть даже с кем-то пообщаться на тему - как это сделано у них и что они обо всем этом думают. Обменяться опытом, так сказать.
Итак, созваниваюсь и говорю, что хочу пройти курс "Защита персональных данных". "Отлично!", говорят мне. "Как раз 28-го ноября начинается такой курс. Народу правда мало, но он точно будет". В тот же день, мне высылают проект договора, мы подписываем его и мы договариваемся, что 28-го числа я приношу подписанный нами договор к началу занятий.
Договор я принес, но, блядь, когда начались занятия, оказалось, что это ДРУГОЙ курс.
Другой, блядь. Вот как это вообще возможно? Курс не по защите персональных данных, а по криптографической защите информационных систем.
Криптография мне не уперлась вообще никуда, курс по защите персональных данных есть, но он занятия там начались неделю назад. Договор заключался на прохождение мной курса по защите персональных данных. И ведет оба курса давний знакомый, бывший сотрудник одной из фирм-лицензиатов ФСТЭК. Мужик, конечно, умный, но точки зрения наши во многом не совпадали.
В общем, завтра буду звонить в полутех и ругаться-ругаться-ругаться.
Завтра же будет подтверждена, либо опровергнута бритва Хэнлона: "Не стоит искать злого умысла в том, что может быть объяснено человеческой глупостью". Может быть действительно, тетушка на телефоне не видит разницы между этими двумя курсами?! Не понимаю...
upd
Ну вот и завершение этой глупой истории.
Поскольку на курс по защите персональных данных записалось 3 человека и на курс по криптографической защите информационных систем записалось столько же человек - в чью-то, без сомнения гениальную, голову пришла идея эти курсы совместить.
Что интересно. Программа курса для всех будет одна, но корочки все получат разные. Трое, как и планировали - по защите ПДн, другие трое - по криптографической защите ИС.
Немного удивила позиция преподователя: "Если он такой умный, то зачем записался на курсы?", высказанная в личном разговоре между ним и моим начальником.
Я, блядь, не считаю себя "таким" умным, но хочу разобраться как и что надо делать, а не сидеть с вылупленными глазками и внимать бреду льющемуся из его рта.
Ни один, ни один человек не смог доказать мне, что
1) нашу ИСПДн надо аттестовывать;
2) при защите ИСПДн надо руководствоваться, в том числе, СТР-К.
В общем, я несколько растроен, был лучшего мнения об этом человеке и думал, что он так же хочет и может разобраться в хитросплетениях 152 ФЗ.
пятница, 18 ноября 2011 г.
Чудеса с журналом регистрации в 1С 8.2.13.205
В конце мая пришлось столкнуться со следующей проблемой.
После того как все пользователи выйдут из одной из информационных баз 1С (по причине обновления, перезапуска службы, перезагрузки сервера, либо просто все закончили работу и отправились по домам), подключение к этой же базе 1С занимало неоправданно долгое время - 3-5 минут. Потом, спустя эти самые 3-5 минут, наконец появляось окно для ввода логина и пароля, и никаких проблем в дальнейшем пользователи не испытывали. До тех пор пока все снова не выйдут из 1С. После этого ситуация повторялась. При этом, проблема возникала только на одной, основной, информационной базе. Из других баз пользователи могли входить и выходить когда им удобно, "злополучное" окно появлялось моментально.
В качестве временной меры было выбрано такое решение - на моем компьютере, включенном постоянно, 1С не закрывалась никогда. Если мне тоже требовалось выйти из 1С, чтобы программисты могли обновиться - у нас была договоренность - до тех пор пока три человека не войдут в эту ИБ, они не закрывают конфигуратор. Естественно, это не избавляло нас от всех проблем. Во-первых, программисты могли забыть об этом и закрыть конфигуратор, во-вторых, сервер 1С "любит" перезагрузки. Увы, но это так, если не перезагружать его длительное время, начинаются непонятные тормоза в произвольные моменты времени у произвольных пользователей (к серверу СУБД это не имеет никакого отношения). Соответственно, время этих процедур увеличивалось на 5 минут, что было совершенно неприемлимо. С одной стороны, если бы это была какая-нибудь редкоиспользуемая ИБ, никто даже не обратил бы на это внимания, но именно для этой базы требовалось обеспечить максимальную скорость работы.
Тогда, в мае, я обратил внимание на следующее: на любой копии базы, на любом сервере (как тестовом, так и на рабочем) проблема не появляется. При этом, процесс rmngr.exe (Менеджер кластера сервера 1С) потреблял 25 процентов процессорного времени, т.е. фактически захватывал одно ядро, на все 5 минут, которые длилось ожидание. После того, как он переставал "жрать" процессор, работа возобновлялась в нормальном режиме.
Зная, что у 1С возможны проблемы с "локальным кэшем", я предположил, что серверный кэш так же может быть причиной проблемы. Однако, ни удаление всех "временных" папок, создаваемых 1С, ни удаление каталога snccntx, ни запуск сервера 1С под другим пользователем, ни даже полная переустановка платформы не приносили никакого результата. В результате, я удалил информационную базу с сервера 1С и создал ее под другим именем. И, о чудо, проблема решилась.
Прошло 4 месяца.
Возникла та же самая проблема. Программисты "выгнали" всех из 1С для проведения обновления, а когда работу можно было продолжить - оказалось, что войти в эту самую информационную базу, никто не может. Окно с предложением ввести логин и пароль появилось только через 5 минут...
В этот раз, я твердо знал, что "пересоздание" информационной базы на сервере 1С поможет железно, но решил, что это решение не отличается ни простотой, ни красотой и следует найти что-нибудь более удобное. В первую очередь задумался: в чем разница между новой информационной базой и старой, при условии, что сама база данных на сервере СУБД остается нетронутой. И единственное различие, которое я увидел - это журнал регистрации.
Да, журнал регистрации, в который могут записываться ошибки, предупреждения и просто все действия пользователей. У нас, это было известно точно, в журнал регистрации писалось все возможное и еще немного сверху. В то время когда мы принимали участие в проекте ЦКТП, программисты добавляли в журнал регистрации записи о времении выполнения самых важных для предприятия процедур. После завершения проекта было решено, продолжать записывать эти данные, поскольку по ним можно увидеть как себя ведет система с течением времени.
Заглянув в каталог журнала регистрации (по адресу C:\Program Files\1cv82\srvinfo\reg_1641\id_базы\ - чтобы узнать id_базы посмотрите содержимое файла 1CV8Reg.lst) я увидел два каталога: 1Cv8FTxt и 1Cv8Log. Первый из которых содержал кучу файлов (период разделения ЖР установлен в "день") с совершенно нечитаемым содержимым, а второй содержал вполне привычные файлы журнала регистрации с расширениями .lgf и .lgp.
Итак, поскольку, я решил, что проблема найдена, в Конфигураторе был выбран пункт меню Сервис->Настройки журнала регистрации и нажата кнопка "Сократить". Я сохранил сокращаемые записи ЖР в папку и решил, что проблема решена. Увы, это оказалось не так. Суммарный размер файлов журнала регистрации составлял 900 мегабайт до сокращения и 450 мегабайт после его сокращения. Казалось бы, минимум в два раза время ожидания должно сократиться. Но нет, время не уменьшилось, совсем.
Готовясь плюнуть на все и "пересоздать" ИБ на сервере 1С, я, для успокоения совести, решил скопировать папки с ЖР на тестовый сервер, в идентичную базу и посмотреть что из этого получится. Как только копирование завершилось, я решил войти в эту ИБ конфигуратором - и, вот здесь произошло второе чудо, не смог. Тестовый сервер жалобно пыхтел одним ядром, а я любовался на белый квадрат в середине экрана. Окна с предложением ввести логин и пароль, не было. Спустя 35 минут окно появилось, конфигуратор открылся, rmngr.exe снова потреблял не больше 1-2 процентов процессорного времени.
Таким образом, было очевидно - причина в журнале регистрации. Однако, уменьшение его в размере совершенно не помогало. Тут произошло третье чудо - я вспомнил про чудесную утилиту FileMon от Марка Руссиновича. Оказалось, что такого продукта больше не существует, а его место занял ProcMon, совмещающий в себе функционал как FileMon, так и RegMon. Скачать его можно здесь.
Первым делом, нужно настроить фильтр, поскольку на работающей операционке каждую секунду производятся десятки и сотни вызовов к реестру, файловой системе, сети и другим ресурсам. В первую очередь я создал правило, исключающее всю информацию о процессах, имя которых отличается от "rmngr.exe" и еще одно правило, отсекало все записи, в которых путь не содержал в себе "C:\Program Files (x86)\1Cv82\" (это каталог в который устанвливается 32-х разрядная серверная и клиентская части 1С на 64-битной ОС).
И вот что я увидел:
Процесс rmngr.exe медленно и грустно "пережевывал" файл 1Cv8.lgf в папке журнала регистрации. Самое удивительное для меня заключалось в том, что размер файла был очень и очень небольшим - 11 мегабайт.
Когда rmngr.exe закончил с этим файлом, я вошел в режиме Конфигуратора и снова сократил журнал регистрации. Каково же было мое удивление, когда я увидел, что из папки журнала регистрации удалились файлы .lgp до той даты которую я выбрал, а вот файл 1Cv8.lgf остался нетронутым!
И, естественно, при следующей попытке запуска конфигуратора, rmngr.exe снова "прочесывал" весь 1Сv8.lgf. Методом научного тыка было выяснено:
После того как все пользователи выйдут из одной из информационных баз 1С (по причине обновления, перезапуска службы, перезагрузки сервера, либо просто все закончили работу и отправились по домам), подключение к этой же базе 1С занимало неоправданно долгое время - 3-5 минут. Потом, спустя эти самые 3-5 минут, наконец появляось окно для ввода логина и пароля, и никаких проблем в дальнейшем пользователи не испытывали. До тех пор пока все снова не выйдут из 1С. После этого ситуация повторялась. При этом, проблема возникала только на одной, основной, информационной базе. Из других баз пользователи могли входить и выходить когда им удобно, "злополучное" окно появлялось моментально.
В качестве временной меры было выбрано такое решение - на моем компьютере, включенном постоянно, 1С не закрывалась никогда. Если мне тоже требовалось выйти из 1С, чтобы программисты могли обновиться - у нас была договоренность - до тех пор пока три человека не войдут в эту ИБ, они не закрывают конфигуратор. Естественно, это не избавляло нас от всех проблем. Во-первых, программисты могли забыть об этом и закрыть конфигуратор, во-вторых, сервер 1С "любит" перезагрузки. Увы, но это так, если не перезагружать его длительное время, начинаются непонятные тормоза в произвольные моменты времени у произвольных пользователей (к серверу СУБД это не имеет никакого отношения). Соответственно, время этих процедур увеличивалось на 5 минут, что было совершенно неприемлимо. С одной стороны, если бы это была какая-нибудь редкоиспользуемая ИБ, никто даже не обратил бы на это внимания, но именно для этой базы требовалось обеспечить максимальную скорость работы.
Тогда, в мае, я обратил внимание на следующее: на любой копии базы, на любом сервере (как тестовом, так и на рабочем) проблема не появляется. При этом, процесс rmngr.exe (Менеджер кластера сервера 1С) потреблял 25 процентов процессорного времени, т.е. фактически захватывал одно ядро, на все 5 минут, которые длилось ожидание. После того, как он переставал "жрать" процессор, работа возобновлялась в нормальном режиме.
Зная, что у 1С возможны проблемы с "локальным кэшем", я предположил, что серверный кэш так же может быть причиной проблемы. Однако, ни удаление всех "временных" папок, создаваемых 1С, ни удаление каталога snccntx, ни запуск сервера 1С под другим пользователем, ни даже полная переустановка платформы не приносили никакого результата. В результате, я удалил информационную базу с сервера 1С и создал ее под другим именем. И, о чудо, проблема решилась.
Прошло 4 месяца.
Возникла та же самая проблема. Программисты "выгнали" всех из 1С для проведения обновления, а когда работу можно было продолжить - оказалось, что войти в эту самую информационную базу, никто не может. Окно с предложением ввести логин и пароль появилось только через 5 минут...
В этот раз, я твердо знал, что "пересоздание" информационной базы на сервере 1С поможет железно, но решил, что это решение не отличается ни простотой, ни красотой и следует найти что-нибудь более удобное. В первую очередь задумался: в чем разница между новой информационной базой и старой, при условии, что сама база данных на сервере СУБД остается нетронутой. И единственное различие, которое я увидел - это журнал регистрации.
Да, журнал регистрации, в который могут записываться ошибки, предупреждения и просто все действия пользователей. У нас, это было известно точно, в журнал регистрации писалось все возможное и еще немного сверху. В то время когда мы принимали участие в проекте ЦКТП, программисты добавляли в журнал регистрации записи о времении выполнения самых важных для предприятия процедур. После завершения проекта было решено, продолжать записывать эти данные, поскольку по ним можно увидеть как себя ведет система с течением времени.
Заглянув в каталог журнала регистрации (по адресу C:\Program Files\1cv82\srvinfo\reg_1641\id_базы\ - чтобы узнать id_базы посмотрите содержимое файла 1CV8Reg.lst) я увидел два каталога: 1Cv8FTxt и 1Cv8Log. Первый из которых содержал кучу файлов (период разделения ЖР установлен в "день") с совершенно нечитаемым содержимым, а второй содержал вполне привычные файлы журнала регистрации с расширениями .lgf и .lgp.
Итак, поскольку, я решил, что проблема найдена, в Конфигураторе был выбран пункт меню Сервис->Настройки журнала регистрации и нажата кнопка "Сократить". Я сохранил сокращаемые записи ЖР в папку и решил, что проблема решена. Увы, это оказалось не так. Суммарный размер файлов журнала регистрации составлял 900 мегабайт до сокращения и 450 мегабайт после его сокращения. Казалось бы, минимум в два раза время ожидания должно сократиться. Но нет, время не уменьшилось, совсем.
Готовясь плюнуть на все и "пересоздать" ИБ на сервере 1С, я, для успокоения совести, решил скопировать папки с ЖР на тестовый сервер, в идентичную базу и посмотреть что из этого получится. Как только копирование завершилось, я решил войти в эту ИБ конфигуратором - и, вот здесь произошло второе чудо, не смог. Тестовый сервер жалобно пыхтел одним ядром, а я любовался на белый квадрат в середине экрана. Окна с предложением ввести логин и пароль, не было. Спустя 35 минут окно появилось, конфигуратор открылся, rmngr.exe снова потреблял не больше 1-2 процентов процессорного времени.
Таким образом, было очевидно - причина в журнале регистрации. Однако, уменьшение его в размере совершенно не помогало. Тут произошло третье чудо - я вспомнил про чудесную утилиту FileMon от Марка Руссиновича. Оказалось, что такого продукта больше не существует, а его место занял ProcMon, совмещающий в себе функционал как FileMon, так и RegMon. Скачать его можно здесь.
Первым делом, нужно настроить фильтр, поскольку на работающей операционке каждую секунду производятся десятки и сотни вызовов к реестру, файловой системе, сети и другим ресурсам. В первую очередь я создал правило, исключающее всю информацию о процессах, имя которых отличается от "rmngr.exe" и еще одно правило, отсекало все записи, в которых путь не содержал в себе "C:\Program Files (x86)\1Cv82\" (это каталог в который устанвливается 32-х разрядная серверная и клиентская части 1С на 64-битной ОС).
И вот что я увидел:
Когда rmngr.exe закончил с этим файлом, я вошел в режиме Конфигуратора и снова сократил журнал регистрации. Каково же было мое удивление, когда я увидел, что из папки журнала регистрации удалились файлы .lgp до той даты которую я выбрал, а вот файл 1Cv8.lgf остался нетронутым!
И, естественно, при следующей попытке запуска конфигуратора, rmngr.exe снова "прочесывал" весь 1Сv8.lgf. Методом научного тыка было выяснено:
- если сокращать журнал регистрации до определенного момента в прошлом, файл 1Cv8.lgf, проверяемый процессом rmngr.exe, не изменяется в размерах;
- если сокращать журнал регистрации на сегодняшний день, 1Cv8.lgf не изменяется;
- если выбрать дату завтрашнего дня - бинго! файл 1Cv8.lgf очищается.
Естественно, при выборе последнего (да и второго варианта) информационная база, фактически остается без журнала регистрации (т.е. встроенными средствами через Сервис->Журнал регистрации) его нельзя будет просмотреть, поэтому требуется, при сокращении, ЖР сохранять его в папку, доступ к которой должен быть у всех пользователей, работающих с журналом регистрации.
Подписаться на:
Сообщения (Atom)