31 декември 2012

Проблеми със сигурността на Microinvest Warehouse Open

Във Microinvest Warehouse Open има проблем със сигурността, който на няколко пъти съм повдигал. За мое съжаление, хората от Microinvest го неглижират. С настоящия си постинг бих искал да дам публичност на проблема, така че от една страна хората, които ползват продукта да преценят до колко той отговаря на техните разбирания за сигурност, а от друга да стимулирам хората от Microinvest да го отстранят.

Microinvest Warehouse Open, както и повечето складово счетоводни програми, принадлежат към класа програми, предоставящи интерфейс върху някаква база данни. С други думи казано съхранението, манипулирането и управлението на данните се извършва от някаква СУБД (в случая на Warehouse Open това е MySQL), а приложният софтуер ни предоставя по-удобен начин да се случва това (не ни се налага да пишем директно сложни SQL команди). Когато се налага да  се реализират някакви правила за достъп и промяна на данните сме изправени пред следната дилема – дали да ползваме функционалностите предоставени от СУБД или да направим нещо върху нея (ако е възможно), което да е реализирано в приложния софтуер.

Всяка себе уважаваща се СУБД предлага доста гъвкавост при управление на достъпа до данните. В повечето случаи не е трудно да се ограничи достъпа на потребителя до конкретна база данни, таблица, колони или редове в таблица, както и операциите, които може да прави върху дадени данни (да ги изтрива, променя по специфичен начин и т.н.). Имайки това в предвид, някак си съвсем естествено идва потребителите на приложния софтуер, да са потребители на СУБД. Разбира се, това може да наложи да се направят множество специфични изгледи на таблици или използването на stored procedures. Съответно, това усложнява структурата на базата данни и може би коства повече усилия да се реализира.

Другата възможност е сигурността да е реализирано в самия приложен софтуер. Най-често това става, като се съхранява таблица с потребители, информация за правата им за достъп и хешове на паролите им. Съответно, когато някой потребител се идентифицира в приложението, то проверява предоставената информация от съответната таблица. Ако всичко е успешно, то променя интерфейса си, съгласно зададените права за достъп. Предимството на този подход е че не се налага да се прави по сложна структура на базата данни и съответно времето за програмиране на приложението би било по-малко. Разбира се, това става на цената на редица недостатъци. За да може приложението да се закачи да СУБД, то трябва да използва потребител от СУБД. Този потребител, в термините на СУБД, трябва да има достъп за четене/промяна (поне) до данните, които управлява приложението. В частност и до таблицата с потребители на приложението. Основните рисковете, които крие тази реализация, са три:

  • Данните за идентифициране пред СУБД трябва да се пазят в тайна. Разбиването на паролата на този единствен потребител, компрометира най-малко данните на използваното приложение. В същото време тази информация трябва да съхранява някъде, така че когато някой потребител иска да влезе в приложението, то да може да се закачи до СУБД.
  • Ефективно всеки потребител на приложението има повече права, от колкото биха му били нужни за да си върши работата. Това от своя страна означава, че много по-лесно може да се използват грешки на самото приложение (sql injections, грешки в модела/интерфейса направата за достъп и т.н.).
  • При злонамерени опити за прихващане на комуникациите между приложението и СУБД, чисто статистически най-вероятно е да има успех при потребителите, които най-често ползват приложението. Обикновено тези потребители (от бизнес гледна точка) не би трябвало да имат значителни права за работа върху данните. Така че компрометирането на техните account-и, не би трябвало да нанесе сериозни щети, ако управлението на сигурността на данните на приложението се извършва от СУБД. Когато самото приложение има грижата да управлява правата за достъп, то рискът от компрометиране на системата е значително по-висок.
Подходът за реализиране на системата за сигурност в приложния софтуер се ползва най-често в web базираните приложения. Като цяло крайният потребител има достъп единствено до интерфейса на приложението, така че възможностите му да прочете файла, в който приложението съхранява информацията за достъп до СУБД или да предприеме атаки върху комуникацията между СУБД и приложението са значително ограничени. Съответно негативните ефекти от реализирането на този подход са силно смекчени.

За съжаление това не е така при stand-alone приложенията. Ако чрез инструментите на операционната система би могло да се ограничат възможностите за атака (от компютъра на който работи приложението) на комуникацията между приложния софтуер и СУБД, то не е толкова лесно да се ограничи достъпа до файла, който съхранява информацията за достъп до СУБД. Като цяло затвореният софтуер разчита на security through obscurity подхода. Информацията се пази криптирана и се разчита, че само приложението знае алгоритъма и ключа който се използва за декриптирането и. Разбира се, този подход не работи при приложенията с отворен код, тъй като всеки би могъл до види използвания алгоритъм и ключ. За мое най-голямо учудване Microinvest Warehouse Open използва именно този подход.

Лесно може да видите информацията касаеща връзката до СУБД чрез:
cat ~/.config/Microinvest/Warehouse\ Open/WarehouseOpen.exe.config |grep Db

Криптираната парола за достъп до MySQL се съхранява във value полето на DbPassword реда. Бърз поглед върху изходния код на Warehouse Open ни дава информация за използвания алгоритъм и ключ. Имайки тази информация, лесно може да видим паролата чрез тази команда:
cat  ~/.config/Microinvest/Warehouse\ Open/WarehouseOpen.exe.config |grep DbPassword | cut -f4 -d'"' | openssl enc -des-cbc -a -d -K 4d6963726f696e76 -iv 1234567890abcdef; echo

Мисля, че не е необходимо да обяснявам какви биха могли да бъдат последствията, ако паролата за достъп стане известна на злонамерен човек. Ако при инсталирането на Warehouse Open е използван административен потребител на MySQL, то рискът се пренася и върху другите приложения, които използват същия MySQL сървър.

Като цяло докато този проблем не бъде разрешен, не може да се разчита на правата за достъп на Warehouse Open. Съвсем тривиално е всеки да се сдобие с каквито права за достъп иска. Разбира се, това не добавя кой знае какъв допълнителен риск, ако всичко (приложен софтуер и СУБД) се върти на една машина, до която злонамерения потребител има физически достъп. В такава ситуация, макар и една идея по-трудно, могат да се случат доста неприятни неща. За съжаление, този проблем компрометира ситуации, в които машината, на която е разположена СУБД е добре физически и мрежово защитена.

15 коментара:

Vladimir Dimitrov каза...

Какво бихте променили в Warehouse Open за да го няма този проблем и въпреки това да не се пише паролата за достъп до базата данни всеки път при вход в системата?

Dimitar Vasilev каза...

Аз бих прехвърлил цялата оторизация на mysql. Така няма да се съхранявт локално пароли, всеки потребител ще си има собствен account за базата данни и той ще е с достъпа, който е необходим и нищо повече.

Други опции са свързани с изграждане на междинен слой в комуникацията между mysql и warehouse open. Това може да бъде както класически midleware, така и използване на mysql proxy.

За съжаление първите два варианта искат доста усилия, за да се реализират. С mysql proxy нещата би трябвало да станат по-лесно, но софтуера седи на alpha/beta версия.

Vladimir Dimitrov каза...

А какво би станало ако има поддръжка на други бази данни като наптимер SQLite (която вече е добавена като поддръжка), която пък няма почти никакви механизми за работа с потребители?

Освен това MySQL (както и повечето други бази) има много слабо застъпена йерархия на потребителите. Реално всеки потребител, трябва да може да пише и чете почти всичко в базата за да може да работи нормално (да записва операции, да добавя стоки, патньори, потребители с по-нисък достъп). Това от своя страна означава, че всеки добавен потребител, дори и оператор веднага има директен логин за базата (неговата си парола) и веднага може да промени каквото си пожелае в нея, като например нивото си на достъп...

Това, което се опитвам да обясня, е че ако човек иска да пробие система с отворен код, която е изцяло на негови я компютър почти няма шанс да се опази информацията на 100%. И MySQL да е локално инсталиран и той може да бъде пробит.

Dimitar Vasilev каза...

Ако Warehouse Open, може да работи с няколко СУБД, част от които не предлагат никакви механизми за защита на данните, то вече е отговорност на самия потребител какво решение ще избере. Не смятам, че е редно да се смъква нивото на сигурност, което може да се постигне с mysql, за да се угоди на sqlite. Нещо повече, когато приложението работи с sqlite, е най-добре да се стартира без екран за идентификация, отколкото да създава някаква псевдосигурност.

По отношение на mysql, не е нужно да се дава достъп за четене/писане до всичко. Може самите операции да се дефинират в mysql и да се даде достъп до тях. Съответно потребителите на програмата ще могат да изпълняват само операциите, до които имат достъп и нищо повече.

Съгласен съм, че всеки може да прави каквото си иска със собствените си компютри. В един магазин те обикновено са собственост на собственика, а на служителя зад касата. Съответно едва ли се очаква служителят да може да прави всичко. Ако той няма физчески достъп до него (което се реализира лесно с терминално решение) опазването на информацията на 100% е доста лесно постижимо.

Анонимен каза...

Като чета това:
По отношение на mysql, не е нужно да се дава достъп за четене/писане до всичко. Може самите операции да се дефинират в mysql и да се даде достъп до тях. Съответно потребителите на програмата ще могат да изпълняват само операциите, до които имат достъп и нищо повече.

Бих желал да оцените сложността на създаване на операция в самия MySQL. Ако може, направете груба оценка за колко време бихте пресъздали цялата операция "продажби" (заедно с всичките и спомагателни функции, например плащане, опресняване на количествата и парота с партиди) чрез средствата на MySQL.

Смятам, че всеки специалист, който предлага нещо е в състояние сам да го изпълни. Затова направете примерно приближение на тази операция в MySQL и ще продължим разговора за развитие на продукта.

Спомням си времето, когато един приятел каза: "Ами то не е никак сложно да се изпрати човек в космоса, затваряш го херметично и го засилваш с 7.9 км/сек."

Затова аз лично ще следя темата и очаквам реална демонстрация на най-стандартната операция "Продажби" по посочената от Вас технология. Все пак тя се отнася само до 5-10 таблици в базата...

Dimitar Vasilev каза...

@Анонимен. Предполагам си от Микроинвест. Не виждам какво дискусия има да се продължава. Във Warehouse Open има проблем със сигурността, който ако искате ще отстраните, ако не искате, няма (предполагам не ви пречи на embedded решенията).

В решението, което предлагам няма никакъв "rocket science" (така че намирам примера за неуместен). Вместо приложението да праща insert/update команда, извиква stored procedure, която има същите параметри и върши работата, която се очаква да свърши insert/update командата. Ако не може да си го представите, може да погледнете изходния код на RD Suite. Моделът му на сигурност е реализиран в SQL сървъра и нещата работят доста добре, с много по-засукани неща от една продажба.

По отношение на времето за реализация, мога да кажа, че ако трябваше отново да правите warehouse open, то моето предложение нямаше да ви коства повече усилия от тези, които сте вложили.

Най-неприятното на споменатия проблем, е че той не се дължи на грешка в кода, а на грешка в проектирането на приложението. Съответно усилията да се оправи ще са значителни.

Виктор Павлов каза...

Да, работя в Microinvest, казвам се Виктор Павлов и сега ще Ви посоча местата, където Вие не сте прав (отдавам го на липсата Ви на опит в такива системи):
1. Продуктът Microinvest Warehouse Open е много голям като обем. Наистина много голям. И ако приемем, че 50% се пада на интерфейса, то 50% се пада на функциите. А там основното са операциите и справките. Вие смятате ли, че скриптовата система на MySQL ще издържи на такова голяма натоварване? Аз съм сигурен, че няма, все пак MySQL е SQL сървър, а не език за програмиране с вграден компилатор/интерпретатор. Дори и при прости операции, търсенето и работата в базата е постоянно;
2. При голямо натоварване SQL сървърът ще се „задръсти“, все пак при работа в супермаркет всички стандартни операции се правят на локалното работно място, към сървърът се изпращат само SQL за промяна на съдържанието на базата. Ако самият SQL сървър изпълнява и операциите (както Вие сте предложили), той със сигурност ще умре при натоварване на няколко касови работни места едновременно;
3. По втората предложена технология, чрез изпълнение на вградени процедури защитата е почти на същото ниво както при нас. Който има достъп до таблиците, той ще има достъп и до процедурите. И вместо да променя данни в таблиците, той ще изпълнява процедурите. Като резултат е същото, да, малко по-сложно е, но е аналогично като принцип. И нищо не можете да защитите повече от стандартното, защото на потребителите им трябват основните операции – добавяне, промяна, изтриване. Без тях самият софтуер не функционира. Дори и да ги ограничите по потребители, функциите ги има и те достъпват данните;
4. Параноичната защита на данните не е предимство на нито една система. Практически данни могат да се получат от всяка система, въпрос на време е. И тук следва основния въпрос – заслужава ли си? Не, за нашия таргет не си заслужава. Никой няма да хвърля огромни усилия за да „счупи“ базата на един магазин/кафе/ресторант. Защото е по-лесно да свали продавачката и да си получи всички справки у дома, в леглото…
5. Сега да видим как можем да извлечем данните на предложената от Вас архитектура. Спираме процеса на сървъра, копираме файловете на базата и имаме 2 пътя – закачваме ги към наш сървър или ги даваме на един студент, който ги извлича с HEX редактор;

Тук искам да сигнализирам за един чисто български парадокс – много лесно е да се критикува, даваме акъл на всеки, но реална работа няма.
Вие посочихте RD Suite, може ли да посочите къде продукта работи, искам да отида и да си купя едно кафе от магазин/заведение или да ми направят счетоводна справка с него. Посочете ми такъв клиент!
А през същото време Microinvest Warehouse Open можете да видите в магазините iYabalka, дискотеките в Априлци, в Русия, Украйна, Армения и Грузия. Вижте и този сайта www.microinside.ru

Аз много уважавам блогерите, възхищавам се на устрема им. Но едновременно с това бих желал всеки да може да изразява професионално и точно мнение, което съответства на неговите способности, да не се простира в мечтите и фантазиите.
Това, което сте предложили е добро за определен клас системи, но в приложния софтуер за магазини не става. Не е професионално, няма скалируемост, има много ограничения и никаква гъвкавост.
PS: Задачка-закачка: При предложената от Вас схема, когато операцията се изпълнява вътре в SQL сървърът, как процедурата би разбрала за индивидуалната настройка на работното място (например забрана за отрицателни количества на ниво интерфейс или работа по среднопретеглена цена, FIFO, LIFO). Как сървърът би уведомил клиентския интерфейс за евентуална промяна на количеството? Отговор: Никак!
PS2: Често ме обвиняват за невъздържан тон. Това сигурно е така, но аз не толерирам изявления, които въобще не са премислени и са се родили от нищото, без щателен анализ. Все пак ние можем да се гордеем, че продаваме в 22 страни на света, при това един и същи продукт.

Dimitar Vasilev каза...

@Виктор Павлов: По вашите точки.
по т.1 - Личи си че не познавате MySQL. Не че е учудващо, все пак сте мениджър. Най-простия пример е, ако една операция изисква попълване на данни в 2-3 таблици, защо изпращането на 2-3 команди към sql сървъра ще отнеме по-малко време, от изпращането на една команда? Особено като се има предвид, че при едната команда се товари много по-малко комуникацията между сървъра и клиента, както и че анализирането на самите SQL операции вече е направено.
по т.2. Имам опит с големи бази данни на MySQL (~100GB) е вярвайте, не се задръства лесно. Отделен е въпроса, че при добре измислена база, нещата лесно се скалират.
по т.3. Личи си, че нямата идея как работи системата за сигурност на MySQL. Може да имате достъп до процедура, която променя няколко таблици, създава нови и т.н., и в същото време да не можете да изпълните никаква директна sql команда върху която и да е таблица в базата.
по т.4. В момента усилията да се счупи софтуера Ви са близки до нула. Направете ги огромни и ще Ви разбера.
По т.5. Извинявай но за да се случи това, което е написано, трябват и една права. Сдобиването с тях никак не е тривиална задача дори и за професионалисти. В противен случай, сървърите в интернет щяха да падат един по един.

В моя постинг не съм критикувал никой, коментирал съм факт (който никой от коментиращите не е отрекъл) и съм се постарал да обясня добре откъде идва проблема. Нямам намерение на никой да давам акъл, но вашият колега си го поиска. За вас знам, че си знаете всичко, и акъл не ви трябва. Факт е, че ако бяхте прочели внимателно и помислили върху това, което съм написал нямаше да ми пишете такива коментари.

Мога да ви кажа 2 фирми, в които RD Suite се ползва за счетоводство, но това няма никакъв принос към дискусията. Самият факт, че не сте отделили време да видите за какво става въпрос (съответно да разберете че RD Suite е счетоводен, а не е складов софтуер), не ме мотивира да ви вода наляво надясно или да ви правя демонстрация от вашия офис през VPN връзка до базата данни.

В заключение мога да кажа, че никак не съм учуден от отношението ви. То просто потвърждава началото на постинга ми. Аз не бих ви обвинил в невъздържан тон, но най-добронамерено мога да кажа, че самонадеяността ви някой ден ще ви изиграе лоша шега. Най-малкото, преди да коментирате какво може и какво не с дадена технология (PS1), е хубаво да се запознаете с нея.

Vladimir Dimitrov каза...

Да допълня и аз нещо към разгорещената дискусия :).

Гледайки примера ви за промяна на базата ми става ясно, че вие явно сте фен на базите данни като цяло, но с програмирането не сте толкова навътре (може и да греша). Подхода, който предлагате е да се замени бизнес логиката, която сега е написана на C# със такава написана на T-SQL. Двата езика нямат база за сравнение от към функционалност, и съответно време за разработка на продукт на него. Елементарни неща, като цикли, работа с изключения, обекти и т.н. са много трудни или направо невъзможни под T-SQL. Освен това съхранените процедури описани с T-SQL въобще не са преносим код, който да може после да се пренесе на други бази данни. Всяка база си има своя версия, която уж е по стандарта, но всички знаем, че не е точно така. SQLite дори няма поддръжка по подразбиране на UTF8.

Всичко това е за да ви обясня, не че не е възможно да стане така, както вие казвате а че ще е безумно усилие и загуба на време за да се спечели защита от евентуален пробив, за който вие сте първия от горе долу 6 години живот на проекта, който се сети че го има.

От опит ви казвам, че 90% от потребителите на тази система нямат достатъчните познания дори да изпълнят стъпките от поста ви, така че усилията, които предлагате не са оправдании в никой случай по моя преценка.

Ако имате други предложения, давайте. Софтуера винаги може, и ще се подобрява, но само ако усилията са оправдани.

Dimitar Vasilev каза...

@Vladimir Dimitrov: Работя извън IT индустрията, което не пречи да имам опит и знания над средните за бранша.

Дали ще замените бизнес логиката от C# с такава в SQL е въпрос на ваш избор и възможности. Няма никакъв проблем цялата бизнес логика да остане в C# и пак да ползвате подхода, който предлагам.

Ако бизнес логиката изисква добавяне на един ред в дадена таблица, вместо да давате права на потребителя да може да добавя всичко в таблицата, то може да се направи процедура, която добавя конкретния вид информация и да се даде достъп само до нея.

Според мен обаче е добре логиката, която проверява консистентността на данните да е сложена на SQL сървъра. Част от тези неща вървят директно с SQL езика (например foreign keys), на за други може да се наложат допълнителни усилия.
Например, ако потребителят трябва да може да променя редове, които той е въвел, е много по-добре валидацията да се случва на сървъра. От една страна се разтоварва комуникацията клиент сървър (т.е. не трябва да пускате заявка за проверка на потребителя въвел записа и чак след това да изпълнявате самата промяна, а просто директно да извикате процедурата за промяна), а от друга си гарантирате, че потребителя може да прави само това, което се очаква от него (т.е. има достъп да променя само своите записи, вместо всички налични в таблицата).

Съгласен съм, че SQL процедурите не са преносим код, но то това е в сила и за останалите SQL команди. Тоест поддържането на допълнителен SQL сървър изисква усилия. Обаче ако нещата са добре планирани, тези усилия не касаят C# кода. SQL нещата се мигрират лесно и бързо, ако цялата концепция е добре измислена.

По отношение на пробива, само да до уточня че с Виктор съм го коментирал още преди 5 години. И доста пъти след това. Този постинг се каня да го пиша от две години на сам, но просто все не ми достига време.

Дали си заслужава да оправяте проблема е въпрос на ваш избор. Може да разчитате на неграмотността на потребителите, но в поста ми няма стъпки, а една команда, която се copy-paste-ва. По същия начин, може да се появи команда, която затрива цялата база, и някой ядосан служител може да я изпълни в последния си работен ден или пък команда, чрез която някой да си повиши правата в софтуера, така че да върти далавери зад гърба на шефа си. С ваше разрешение може да пусна две такава тема във форума на Microinvest, за да се видят реакциите на потребителите.

Виктор Павлов каза...

1. Ще се радвам да пуснете тема в нашия форум, тъй като ние не сме имали нито един такъв проблем от 2002 година, въпреки, че работим в Русия, и;
2. Когато имате достъп до процедура за промяна на базата, нищо не пречи чрез нея да внесете вредни изменения по същия начин, както и чрез директен достъп до базата;
3. Това за RD Suite ми е много странно, последната версия според Wiki е 2010-08-29 Версия 0.3.1, през 2012 година има промяна на кодировката на ДДС файловете. А аз много добре съм разгледал профула на продукта, затова освен "складов" съм запитал и за "счетоводна" справка;
4. По това твърдение "пък команда, чрез която някой да си повиши правата в софтуера" мога да Ви оборя. Такъв човек няма да работи в магазин, в момента той би работил като IT специалист, там заплащането е по-добро;
5. За скалируемостта на сървъра не съм съгласен. Ние имаме бази по 3-5 GB, които едва-едва вървят и SUB-SELECT се изпълнява отвратително бавно, часове отнема...

На мен дискусията ми е интересна, но бих желал да превключим в реалната сфера, тоест да анализираме точни данни, примери и резултати.

Dimitar Vasilev каза...

@Виктор Павлов:
по т.1. Ще го направя като ми остане малко свободно време.
по т.2. Интересно ми е да вида пример за това. Според мен не е възможно, освен ако няма бъг в самия SQL сървър, който да го позволява. Но пък това не е проблем на приложния софтуер.
по т.3. Ще се съгласите, че кодировката на ДДС файловете няма отношение към счетоводството само по себе си. RD Suite е типичен некомерсиален GPL софтуер. Никога не съм имал амбиции да правя пари от него. Направил съм нещо за конкретна фирма и съм го споделил с останалите в случай, че е полезно на някой друг. Не се е налагало да правя модул за файлове по ДДС към НАП, съответно не се е налагало да се правят промени.
по т.4. Мисля, че има доста примери как интернет свързва знаещите хора, с тези които имат физическата възможност да направят нещо. Не е нужно потребителят на софтуера да разбира детайлите на атаката. Достатъчно е някой да му каже какво да направи и той да го направи. Все пак става въпрос за една shell команда, която се копира лесно.
по т.5. Няма универсални рецепти за оптимизиране на бази данни. Може да имате проблеми в структурирането на базата, в самата SQL заявка или в нещо трето. Мога да ви препоръчам погледнете следната книга -
High Performance MySQL. Надявам се да ви даде идея какво не е наред във вашия случай.

Виктор Павлов каза...

Мина доста време и нещата замряха, ще остане ли малко време за да проверим на практика това, което сте написали? Аз продължавам да не вярвам на тази технология, иначе всичко остава само пожелания.

Веселин Колев каза...

Служителите на никоя себеуважаваща се компания - разработчик на софтуер не се държат като селски бекове по форуми. Но каквито са те такъв е и бизнеса им. Четох им днес и невероятните технически излияния по техния фирме форум. За да оправдаят мързела си и да сложат указване на порт за комуникация с SQL сървъра, карат потребителите да пускат VPN. Аз за близо 15 години в мрежовата администрация съм виждал доста простотия, но да се обясняваш със самочувствие как пускаш VPN за да прекараш трафик от/до един порт по TCP показва, че липсата на знания в тази компания е издигната в почти религиозен култ. Хора с подобни разбирания обикновено не минават дори входен тест за интервю в сериозна фирма за комуниакция. Аз не знам какво безочие трябва да има някой, за да има самочувствието да пише и демонстрира непознаване на OSI модела и кой слой за какво е, що е то IP тунел и за какво се ползва и каква е разликата между VPN и SSL.

Същото се случва и тук. Обикновено давам URL от такива изяви на колеги в България, да погледат от кого не бива да купуват и кого не бива да търсят. Ако някой финансира подобна компания с подобен "капитал" от знания, определено не уважава нито парите си, нито бизнеса си.

Анонимен каза...

Здравейте мили колеги. Виждам,че сте се разгорещили в спора. Сългасен съм с едно. SQL базата на микровинвест след 3 години работа не става за нищо, не само, че е бавна, а и крашва, на моменти отказва достъп и тнт. Сигурността не е приоритет на микроинвест, защото програмата е разпространена сред малки фирми, които залагат на ексел и други софтуери за по-голяма сигурност... Едно е сигурно, най-простите операции след 3 години архив отнемат по 2-3 минути за генериране от 4-ярдрени процесори със сравнително нови конфигурации. Помислете над това, след това товарете излишно базите с процедури и какво ли още не!