All posts by Bozho

Няколко административни мита

Post Syndicated from Bozho original https://blog.bozho.net/blog/3200

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

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

  • Печати – печат не се изисква по закон почти за нищо. Един документ е валиден, когато е подписан от лице, което е законен представител на организацията от чието име се издава документа (по силата на нормативен акт, договор или заповед, напр.). Печатът някога може да е служил за допълнителна защита от фалшификации, но в момента можеш да направиш фалшив печат изключително лесно и евтино. Да, това би била допълнителна стъпка, която при евентуално документно престъпление би утежнила вината на извършителя, но изискване за печат няма за почти никой документ. Преди време правих анализ на законодателството с оглед на това къде се изискват печати. Има държавен печат, който е до голяма степен церемониален. Има печати на университетите, с които се подпечатват дипломи (също може да се каже, че е церемониален). Има професионални печати – напр. определени регулирани професии според специалните им закони трябва да имат печати – нотариуси, архитекти, ветеринари (пак остаряло изискване, но поне го има по закон). И има фирмени печати, чието използване е задължително общо взето само на годишните финансови отчети (голяма глупост, която пречи на подаването на машинно-четими финансови отчети). Това не е изчерпателен списък, разбира се – има поне 20-тина случаи в законодателството, където печат се изисква, но те не са общия случай. Т.е. ако някой ви каже, че документ не е валиден, защото няма печат – накарайте го да ви посочи законово основание за това.
  • Свидетелство за съдимост – някои фирми продължават да искат свидетелство за съдимост, за да ви регистрират трудовия договор. Това рядко е необходимонаредбата за необходимите документи при постъпване на работа казва, че свидетелство за съдимост се изисква само „когато със закон или нормативен акт се изисква удостоверяването на съдебно минало“. Т.е. само в регулирани професии и индустрии може да има такова изискване. Чл. 10 от GDPR затвърждава това, като казва, че данни за съдебно минало могат да се обработват само от държавни органи или в случаи, когато закон го изисква. В допълнение на темата, с изменение на една наредба от тази година вече свидетелство за съдимост не може да ви се иска от държавни органи – трябва да си го съберат по служебен път, в духа на Закона за електронното управление. Та, когато някой ви поиска свидетелство за съдимост – питайте го кой закон го изисква (или ако е администрация – да си го вземе сам, защото ще подадете сигнал за нарушение).
  • „Медицинско“ при започване на работа – това по мое наблюдение е по-масово от искането за свидетелството за съдимост. Същата наредба като по-горе обаче казва изрично в кои случаи се иска „медицинско“ – „документ за медицински преглед при първоначално постъпване на работа и след преустановяване на трудовата дейност по трудово правоотношение за срок над 3 месеца“. Т.е. само на първата ви работа, или ако сте бил без трудов договор над 3 месеца. Това не е единствената наредба, която урежда въпроса – другата казва същото. Общо взето „медицинско свидетелство“ го няма като термин в Кодекса на труда и свързаните с него (и със ЗБУТ) наредби. Има го обаче в една наредба от 91-ва (Наредба № 14), която явно не е осъвременена заедно с трудовото законодателство. И в този случай, ако ви поискат медицинско, питайте защо, вместо да се разкарвате до личния лекар (при който е добре да се ходи за профилактика, а не за бележки)
  • Съгласие за обработване на лични данни при трудов договор – това се случваше и преди, а с влизането в сила на GDPR се засили. А всъщност е напълно ненужно, тъй като личните данни за трудовото правоотношение се обработват по силата на закон (Кодекс на труда). Съгласие би имало нужда да се дава, ако данните се ползват от работодателя за нещо извън изискванията на Кодекса на труда. Например искате да ползвате данните на служителите за маркетингови цели. Само че ако съгласието е обвързано с подписването на трудовия договор, то не е свободно дадено и пак не е валидно. Така че ако някой ви поиска съгласие при подписване на трудов договор – няма нужда.
  • Материално отговорно лице – наскоро правихме електронни фактури и разровихме изискванията на законодателството. Някои от реквизитите, които са възприети кат стандартни, всъщност не се изискват. Т.нар. „МОЛ“ е един от тях. Приложимото законодателство е Закон за счетоводството (чл. 7), Закон за ДДС и Правилник за прилагане на ЗДДС. Настрана факта, че трябва от три места да се събират изисквани към един документ, но изискване за МОЛ просто няма. (Между другото, няма изискване и за „съставил“). МОЛ като цяло отсъства като термин в нормативната уредба (с изключение на 3-4 специфични наредби). Общо взето важното лице е законният представител, който може да бъде проверен в реално време в Търговския регистър на база на ЕИК (или съответно в регистър Булстат).
  • Електронният подпис – според много хора електронният подпис не е същият като саморъчният, по-известно като „това не може с електронен подпис“ или „елате да го подпишете на място“. Регламент 910/2014 на ЕС обаче казва, че „квалифицираният електронен подпис [..] има същата правна сила като саморъчния подпис.“. Това е проблем не само на нашата администрация и нашия бизнес. „С електронен подпис не може“ съм получавал като отговор и в Холандия и при отношения на немска и с люксембургска компании. Макар Директивата за електронния подпис да е била приета преди близо 20 години, а Регламентът преди 4, все още разбирането не е на високо ниво, както в администрацията, така и в бизнеса – който съвсем спокойно може да си спести куриерски услуги, но не го прави. Описал съм проблемите с разбирането за електронните подписи тук, след което комуникирах проблем с Европейската комисия, като отговорът от там беше доста незадоволителен – държавите членки в крайна сметка правят каквото си искат. Но рано или късно и администрацията, и съдът, и бизнесът ще разберат какво значи електронен документ и електронен подпис.

В обобщение, може да се види, че поне част от бюрокрацията, на която сме подложени, не е законна. И никой не я изисква или не би трябвало да я изисква. Обаче „хората така са свикнали“. Служителят в „човешки ресурси“ от 20 години иска едни и същи документи, счетоводителят от 20 години издава едни и същи фактури. А „подписът и печатът на хартия“ дават усещане за някаква сигурност.

Бизнесът (в т.ч. в ролята му на работодател) може да си улесни живота. Аз подписвам всички договори с електронен подпис (освен ако отсрещната страна ама много не се запъне) и не искам от служителите си излишни документи. За съжаление имам печат, заради неадекватния Закон за счетоводството (едва ли някой ще върне отчета, ако няма печат, но с бюрокрацията не бива да се рискува).

Законодателят и нормотворците на подзаконови актове пък трябва да имат две неща предвид. Първото е, че законодателството трябва да се синхронизира и да бъде по-четимо. Неприемливо е за най-базови неща да отваряш три нормативни акта и да си задаваш въпроса „кой закон се явява специален в случая“ и „тази наредба е по-стара, сигурно са забравили да я променят“. Второто е, че законодателството трябва да е устойчиво. Като правиш промени по три пъти в годината е нормално хората да пропускат неща.

Често правим неща по инерция и защото „винаги така сме ги правили“. От време на време трябва да се замисляме дали има нужда да ги правим и дали това е начинът, по който да ги правим. И това важи по принцип, не само за документи и бюрокрация.

Scaling Horizontally on AWS [talk]

Post Syndicated from Bozho original https://techblog.bozho.net/scaling-horizontally-on-aws-talk/

On a recent conference (HackConf) I gave a talk where I tried to summarize how to do deployment and horizontal scaling on AWS. It is an overview of AWS resources (instance, load balancers, auto-scaling groups, security groups) as well as how to use CloudFormation to script your stack.

It briefly mentions the application layer and how it should look like (because another talk on the same conference was focused on that part). My point here is summarized as: ““You cannot scale an unscalable application”. But the talk continues to discuss AWS specific things, although many of them have their nearly identical counterparts in other IaaS providers (e.g. Google Cloud, Azure).

The video of the talk can be seen here:

And the slides are here:

As someone summarized on twitter: “That talk is approximately a year worth of learning experience with AWS in 40 minutes”. This is a benefit and a drawback, as it might be too condensed and too shallow, but I think I’ve covered important bits with enough depth for a starting point.

One of my points was that for simpler setups you don’t need fancy tools and platforms (docker, kubernetes, etc.) – as you’ll have to use bash anyway, you can go with just bash + CloudFormation and have a perfectly good, highly-available, blue-green deployment setup.

The other main points where: “think about your infrastructure as code”, and “consider all your resources dispensable, as they will surely die at some point”. Overall, I hope the talk is useful for everyone using or planning to use AWS, or any other IaaS provider.

The post Scaling Horizontally on AWS [talk] appeared first on Bozho's tech blog.

Models for Electronic Identification

Post Syndicated from Bozho original https://techblog.bozho.net/models-for-electronic-identification/

Electronic identity is an important concept as it lies on the crossroads of the digital, the physical and the legal worlds. How do you prove your identity without being physically present? I’ve previously given an overview talk on electronic identification, tackled the high-level and philosophical aspects, and criticized biometric-only identification as insecure. Now I want to list a few practical ways in which eID can be implemented.

First, it’s important to mention the eIDAS regulation which makes electronic identity a legal reality. It says what an electronic identification scheme is and what are its legal effects (proving that you are who you claim to be). And it defines multiple “levels of assurance”, i.e. the levels of security of a method of authentication. But it is a broad framework that doesn’t tell you how to do things in the technical world.

And while electronic identification is mostly cited in the context of government and municipal services, it applies to private companies as well. Currently in the US, for example, the SSN is used for electronic identification. This is a very poor approach, as leaking the SSN allows for identity theft. In the EU there are many different approaches to do that, from the Estonian PKI-based approach, to UK’s verify initiative, which relies on the databases of private companies.

You can see electronic identity as a more legally-meaningful login. You still perform a login, in many cases using username and password as one of the factors, but it carries additional information – who is the actual person behind that login. In some cases it doesn’t have to even give information on who the person is – it can just confirm that such a person exists, and some attributes of that person – age (e.g. if you want to purchase alcohol online), city of registration (e.g. if you want to use municipal services), conviction status (e.g. if applying for a driver in an Uber-like service). It is also very useful when doing anti money laundering checks (e.g. if you are a payment provider, an online currency or crypto-currency exchange, etc.)

Electronic identification schemes can be public and private. Public are operated by governments (federal or state in the case of the US), a particular institution (e.g. the one the issues driver’s licenses). Private ones can be operated by any company that has had the ability to verify your physical identity – e.g. by you going and signing a contract with them. A bank, a telecom, a utility company.

I will use “authentication” and “identification” interchangeably, and for practical purposes this is sort-of true. They differ, of course, as authentication is proving you are who you are, and identification is uniquely identifying you among others (and they have slightly different meanings when it comes to cryptography, but let’s not get carried away in terminology).

Enrollment is the process of signing you up in the electronic identification scheme’s database. It can include a typical online registration step, but it has to do proper identity verification. This can be done in three ways:

  • In-person – you physically go to a counter to have your identity verified. This is easy in the EU where ID cards exists, and a bit harder in the US, where you are not required to actually have an identity document (though you may have one of several). In that case you’d have to bring a birth certificate, utility bills or whatever the local legislation requires
  • Online – any combination of the following may be deemed acceptable, depending on the level of assurance needed: a videoconferencing call; selfie with an identity document; separate picture of an identity document; camera-based liveness detection; matching of selfie with government-registered photo. Basically, a way to say that 1. I have this document 2. I am the person on the document. This could be automated or manual. But does not require physical presence.
  • By proxy – by relying on another eID provider that can confirm your identity. This is an odd option, but you can cascade eID schemes.

And then there’s the technical aspects – what do you add to “username and password” to make identity theft less likely or nearly impossible:

  • OTP (one-time passwords). This can be a hardware OTP token (e.g. RSA SecureID) or a software-based TOTP (like Google Authenticator). The principal of both is the same – the client and the server share a secret, and based on the current time, generate a 6-digit password. Note that storing the secrets on the server side is not trivial – ideally that should be on an HSM (hardware security module) that can do native OTP, otherwise the secrets can leak and your users can be impersonated (The HSM is supposed to not let any secret key leave the hardware). There are less secure OTP approaches, like SMS or other type of messages – you generate one and send it to a registered phone, viber, telegram, email, etc. Banks often use that for their login, but it cannot be used across organizations, as it would require the secrets to be shared. Because the approach is centralized, you can easily revoke an OTP, e.g. declare a phone or OTP device as stolen and then go get a new one / register a new phone.
  • PKI-based authentication – when you verify the person’s identity, have them generate a private key, and issue a X.509 certificate for the corresponding public key. That way the user can use the private key to authenticate (the most straightforward way – TLS mutual authentication, where the user signs a challenge with the private key to confirm they are the “owners” of the certificate). The certificate would normally hold some identifier which can then be used to fetch data from databases. Alternatively, the data can be on the certificate itself, but that has some privacy implications and is rarely a good option. This option can be use across institutions, as you can prove you are the person that owns a private key without the other side needing to share a secret with you. They only need the certificate, and it is public anyway. Another benefit of PKI-based authentication is revokability – in case the user’s private key is somehow compromised, you can easily revoke a certificate (publish it in a CRL, for example).
  • Biometrics – when you are enrolled, you scan a fingerprint, a palm, an iris, a retina or whatever the current cool biometric tech is. I often argue that this cannot be your main factor of authentication. It can and sometimes should be used as an additional safeguard, but it has a big problem – it cannot be revoked. Once a biometric identifier is leaked, it is impossible to stop people from using it. And while they may not be able to fool scanners (although for fingerprints that has been proven easy in the past), the scanners communicate with a server which perform authentication. An attacker may simply spoof a scanner and make it seem to the server that the biometric data was properly obtained. If that has to be avoided, scanners have to themselves be identified by signing a challenge with a private key in a secure hardware module, which make the whole process too complicated to be meaningful. But then again – the biometric factor is useful and important, as we’ll see below.

The typical “factors” in an authentication process are: something you know (passwords), something you have (OTP token, smartcard, phone) and something you are (biometrics). The “something you have” part is what generates multiple variations to the PKI approach mentioned above:

  • Use an unprotected storage on a computer to store the private key – obviously not secure enough, as the private key can be easily extracted and your identity can thus be stolen. But it has to be mentioned, as it can be useful in lower-risk scenarios
  • Use a smartcard – a hardware device that can handle PKI operations (signing, encryption) and does not let private keys leave the hardware. Smartcards are tricky, as they require a reader (usually plugged via USB) and vendor-specific drivers and “magic” to have browser support. Depending on the circumstances, it could be a good approach, as it is the most secure – there is no way for someone to impersonate you, apart from stealing your smartcard and knowing both your smartcard PIN and your password. The problem with plugging the smartcard can be alleviated by utilzing NFC with a smartphone (so just place the card on the back of the smartphone in order to authenticate) but that leads to a lot more other problems, e.g. how to protect the communication from eavesdropping and MITM attacks (as far as I know, there is no established standard for that, except for NFC-SEC, which I think is not universally supported). The smartcard can be put on a national ID card, a separate card, or even the ones in existing bank cards can be reused (though issuers are reluctant to share the chip with functionality (applets) other than the EMV).
  • Use a smartphone – smartphones these days have secure storage capabilities (e.g. Android’s Trusted execution environment or iPhone’s Secure Enclave). A few years ago when I was doing a more thorough, these secure modules were not perfect and there were known attacks, but they have certainly improved. You can in many cases rely on a smartphone to protect the private key. Then, in order to authenticate, you’d need a PIN or biometrics to unlock the phone. Here’s when biometrics come really handy – when they don’t leave the phone, so even if leaked, they cannot be used to impersonate you. They can only be used to potentially make a fake fingerprint to unlock the phone (which should also be stolen). And of course, there’s still the password (“something you know”).
  • Remote HSM – the private keys can be stored remotely, on a hardware security module, so that they cannot physically leave the hardware. However, the hardware is not under your physical control and unlocking it requires just a PIN, which turns this scheme into just “something you know” (times 2, if you add the password). Remote identification and remote signing schemes are becoming popular and in order for them to be secure, you also have to somehow associate the device with the particular user and their private key on the HSM. This can be done in a combination of ways, including the IMEI of the phone (which is spoofable, though) and utilizing some of the aforementioned options – the protected storage of the phone and OTPs handled behind the scene. (Note: the keys on the HSM should be in the protected storage. Having them in an external database encrypted by the master key is not good enough, as they can still leak). If you are going to rely on the smartphone secure storage anyway, what’s the benefit of the remote HSM? It’s twofold – first – loosing the phone doesn’t mean you cannot use the same key again, and second – it reduces the risk of leaking the key, as the HSM is theoretically more secure than the smartphone storage
  • Hybrid / split key – the last two approaches – the smartphone secure storage and the remote HSM can be combined for additional security. You can have the key split in two – part in the smartphone, part on the HSM. That way you are reducing the risk of the key leaking. Losing the phone, however, would mean the key should be regenerated and new certificates should be issued, but that may be okay depending on the usecase.

As you can see, the smartphone secure storage is becoming animportant aspect for electronic identification that is both secure and usable. It allows easily adding a biometric factor without the need to be able to revoke it. And it doesn’t rely on a clunky smartcard that you can’t easily plug.

This is not everything that can be said about secure electronic identification, but I think it’s enough details to get a good picture. It’s not trivial and getting it wrong may lead to real-world damages. It is viewed as primarily government-related, but the eID market in Europe is likely going to grow (partly thanks to unifying the legislation by eIDAS) and many private providers will take part in that. In the US the problem of identity theft and the horrible practice of using the SSN for authentication is being recognized and it’s likely that legislative efforts will follow to put electronic identification on track and in turn foster a market for eID solutions (which is currently a patchwork of scanning and manual verification of documents).

The ultimate goal is to be both secure and usable. And that’s always hard. But thanks to the almost ubiquitous smartphone, it is now possible (though backup options should exist for people that don’t have smartphones). Electronic identification is a key enabler for the so called “digital transformation”, and getting it right is crucial for the digital economy. Apologies for the generic high-level sentence, but I do think we should have technical discussions at the same time as policy discussions, otherwise the two diverge and policy monsters are born.

The post Models for Electronic Identification appeared first on Bozho's tech blog.

Typical Workarounds For Compliant Logs

Post Syndicated from Bozho original https://techblog.bozho.net/typical-workarounds-for-compliant-logs/

You may think you have logs. Chances are, you can rely on them only for tracing exceptions and debugging. But you can’t rely on them for compliance, forensics, or any legal matter. And that may be none of your concern as an engineer, but it is one of those important non-functional requirements that, if not met, are ultimately our fault.

Because of my audit trail startup, I’m obviously both biased and qualified to discuss logs (I’ve previously described what audit trail / audit logs are and how they can be maintained). And while they are a only a part of the security aspects, and certainly not very exciting, they are important, especially from a legal standpoint. That’s why many standards and laws – including ISO 27001, PCI-DSS, HIPAA, SOC 2, PSD2, GDPR – require audit trail functionality. And most of them have very specific security requirements.

PCI-DSS has a bunch of sections with audit trail related requirements:

10.2.3
“Malicious users often attempt to alter audit logs to hide their actions, and a record of access allows an organization to trace any inconsistencies or potential tampering of the logs to an individual account. [..]”

10.5 Secure audit trails so they cannot be altered. Often a malicious individual who has entered the network will attempt to edit the audit logs in order to hide their activity. Without adequate protection of audit logs, their completeness, accuracy, and integrity cannot be guaranteed, and the audit logs can be rendered useless as an investigation tool after a compromise.

10.5.5
Use file-integrity monitoring or change-detection software on logs to ensure that existing log data cannot be changed without generating alerts (although new data being added should not cause an alert).

ISO 27001 Annex A also speaks about protecting the audit trail against tampering

A.12.4.2 Protection of log information
Logging facilities and log information shall be protected against tampering and unauthorized access

From my experience, sadly, logs are rarely fully compliant. However, auditors are mostly fine with that and certification is given, even though logs can be tampered with. I decided to collect and list the typical workarounds the the secure, tamper-evident/tamper-protected audit logs.

  • We don’t need them secured – you almost certainly do. If you need to be compliant – you do. If you don’t need to be compliant, but you have a high-value / high-impact system, you do. If it doesn’t have to be compliant and it’s low-value or low-impact, than yes. You don’t need much security for that anyway (but be careful to not underestimate the needed security)
  • We store it in multiple places with different access – this is based on the assumption that multiple administrators won’t conspire to tamper with the logs. And you can’t guarantee that, of course. But even if you are sure they won’t, you can’t prove that to external parties. Imagine someone sues you and you provide logs as evidence. If the logs are not tamper-evident, the other side can easily claim you have fabricated logs and make them inadmissible evidence.
  • Our system is so complicated, nobody knows how to modify data without breaking our integrity checks – this is the “security through obscurity” approach and it will probably work well … until it doesn’t.
  • We store it with external provider – external log providers usually claim they provide compliance. And they do provide many aspects of compliance, mainly operational security around the log collection systems. Besides, in that case you (or your admins) can’t easily modify the externally stored records. Some providers may give you the option to delete records, which isn’t great for audit trail. The problem with such services is that they keep the logs operational for relatively short periods of time and then export them in a form that can be tampered with. Furthermore, you can’t really be sure that the logs are not tampered with. Yes, the provider is unlikely to care about your logs, but having that as the main guarantee doesn’t sound perfect.
  • We are using trusted timestamping – and that’s great, it covers many aspects of the logs integrity. AWS is timestamping their CloudTrail log files and it’s certainly a good practice. However, it comes short in just one scenario – someone deleting an entire timestamped file. And because it’s a whole file, rather than record-by-record, you won’t know which record exactly was targeted. There’s another caveat – if the TSA is under your control, you can backdate timestamps and therefore can’t prove that you didn’t fabricate logs.

These approaches are valid and are somewhere on a non-zero point on the compliance spectrum. Is having four copies of the data accessible to different admins better than having just one? Yup. Is timestamping with a local TSA better than not timestamping? Sure. Is using an external service more secure than using a local one? Yes. Are they sufficient to get certified? Apparently yes. Is this the best that can be done? No. Do you need the best? Sometimes yes.

Most of these measures are organizational rather than technical, and organizational measures can be reversed or circumvented much more easily than technical ones. And I may be too paranoid, but when I was a government advisor, I had to be paranoid when it comes to security.

And what do I consider a non-workaround? There is a lot of research around tamper-evident logging, tamper-evident data structures, merkle trees, hash chains. Here’s just one example. It should have been mainstream by now, but it isn’t. We’ve apparently settled on suboptimal procedures (even when it comes to cost), and we’ve interpreted the standards loosely, looking for a low-hanging fruit. And that’s fine for some organizations. I guess.

It takes time for a certain good practice to become mainstream, and it has to be obvious. Tamper-evident logging isn’t obvious. We had gradually become more aware about properly storing passwords, using TLS, multi-factor authentication. But security is rarely a business priority, as seen in reports about what drives security investments (it’s predominantly “compliance”).

As a practical conclusion – if you are going to settle for a workaround, at least choose a better one. Not having audit trail or not making any effort to protect it from tampering should be out of the question.

The post Typical Workarounds For Compliant Logs appeared first on Bozho's tech blog.

Митът за недемократичния Европейски съюз

Post Syndicated from Bozho original https://blog.bozho.net/blog/3193

Има един мит, който се повтаря все по-често – че Европейският съюз е недемократичен, а решенията се вземат от неизбрани от никого бюрократи.

Сямо че…ЕС има няколко основни институции и всички те са доста демократични (както отбелязва и The Economist).

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

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

Малко известна на широката публика доскоро институция на ЕС е Съветът. Много от решенията се вземат на практика именно там (а не в парламента или Комисията), а той е съвсем демократичен – министрите от изпълнителната власт на всяка държава имат равен глас. Да, министрите на Борисов и Орбан имат равен глас с тези на Меркел и Макрон. И макар да не са избирани пряко, а чрез парламент, това са представители на демократично избраните правителства на съответните държави. Именно този съвет председателствахме през първата половина на тази година. Да, и те правят глупости, да, решенията там се вземат бавно и с трудни компромиси между интересите на всички държави-членки. Но именно това е демократичното.

Европейската комисия и често критикувания Юнкер са изпълнителната власт на ЕС. Те се избират от парламента, който пък е демократично избран. Както всъщност почти всяка изпълнителна власт в Европа. Критиците обичат да казват „никой не е избирал еврокомисарите“. Но никой не е избирал и нашите министри, и все пак те са легитимното правителство (колкото и наедекватно да е то). Всъщност, „никой“ не е вярно – демократично избраният парламент ги е избрал. И да, Комисията има право да съставя обвързващи нормативни актове, които не са минали през парламент и съвет (решения и част от регламентите), и може би техният обхват може да се прецизира, но всяка изпълнителна власт има такова право (нашата, например, приема правилници, наредби, решения и постановления)

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

Така че Европейският съюз си е възможно най-демократичен, че даже понякога вповече, което води до блокиране на преговорите по някои теми.

„Неизбраните от никого бюрократи“ не са тези, които вземат решенията – решенията се вземат от избрани от народите на ЕС представители, така че предлагам да спрем с тази теза.

ЕС има други кусури, които трябва да работим, за да поправим, но демократичността не е един от тях.

Обобщение относно Търговския регистър

Post Syndicated from Bozho original https://blog.bozho.net/blog/3188

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

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

Разбира се, нещата не са толкова прости. Да, ИТ експертите знаят как да конфигурират и поддържат системите, но коренът на проблема не е технически, а управленски. Много ми се иска всички проблеми да имат технически решения, но както виждаме нещата понякога са иначе – много проблеми водят след себе си технически проблеми.

Затова участвах (с експерти от Демократична България) в изготвянето на детайлен план за управление на информационните ресурси. Това е донякъде политически документ, но много повече – управленски. И то не само в смисъл на „държавно управление“, а на управление по принцип – всяка една голяма корпорация, чиято инфраструктура е в състоянието, в което е държавната, би следвало да има такъв план.

За да решим проблема с Търговския регистър трябва да дадем „zoom out“, и да видим защо изобщо се стига до некачествена поддръжка на некачествено надграждан остарял софтуер, при това в засекретена поръчка. И тук дори отговорът не обичайният – корупция. Или поне не със стандартните финансови подбуди. Поддръжката на Търговския регистър струва 90 хиляди годишно. Това са твърде малко пари за адекватна поддръжка.

Проблемът не е в липсата на изисквания и стандарти – докато бях съветник в МС, прокарахме всички необходими изисквания и стандарти. Само че самото им наличие не е достатъчно за спазването им. Дори наличието на контролен орган не е достатъчно. Нужно е това, което много консултанти биха нарекли „организационна зрялост“. А такава в държавата липсва.

В интервю по темата за Медиапул казах, че на първо време липсват хора, които да „превеждат“ евентуална политическа воля в технологична и организационна реалност. Днес присъствах на лекция, която дефинира ролите на продуктовия мениджър в софтуерните компании, а именно – да служи като медиатор между бизнес изискванията, потребителските изисквания и технологичната реалност. Може да се каже, че ни трябва екип от хора с умения на продуктови мениджъри за редица системи и институции. А, да – не можем да си ги позволим, защото заплатите в администрацията са ниски, а пък Държавно предприятие „Единен системен оператор“ все още няма. Така че ще разчитаме на добра подредба на звездите.

Говорейки за мерки, все пак правителството предприе няколко от описаните в документа с препоръки – активизира се по създаването на „аварийно-възстановителен център“, както и на държавно предприятие. Не би трябвало да се сещаме какво ни трябва чак след като кризата удари, но пък иначе за какво са кризите?

В заключение, немарливостта при поддръжката на Търговския регистър е системен проблем, който няма да се реши с успешното възстановяване на един дисковия масив. Решаването на този проблем не е лесно – дори когато знаеш как, случването му на практика е пълно с препятствия от всякакво естество. Но се надявам, че от ситуация на „умерен разпад“ можем да преминем поне към „умерен прогрес“. Защо се надявам? Ами защото ако не се, значи да се отчаям, а от това няма смисъл.

До Приднестровието и назад

Post Syndicated from Bozho original https://blog.bozho.net/blog/3173

Преди няколко месеца един приятел каза „айде да ходим в Транснистрия“. Не се чудих твърде много – кога пак ще имам възможност да се организирам да отида в непризната от никой република. Това ще бъде нещо като пътепис за обиколката ни (четирима души) до Транснистрия (или Приднестровска молдовска република) и обратно, придружено със снимки. Пътят ни мина през Русе, Букурещ, Яш, Бълци, Кишинев, Тираспол, Бендери, Паркани и Одеса.

Та на 29-ти август вечерта потеглихме… с влак. Към Русе. Защо? Защо не… в 3 без нещо бяхме на гарата в Русе, направихме една разходка и стигнахме до ресторант „Дива орхидея“ – известно денонощно заведение в Русе. Имахме време за една кола преди да дойде таксито, което поръчано от предния ден, което да ни закара до летището в Букурещ.

От Букурещ взехме полета за Яш – по различни данни между 2-ри и 5-ти по големина град в Румъния. Летището в Яш е малко, като селска автогара, но пък има три терминала. Яш е приятен, има ботаническа градина, много църкви и интересни градски гледки. Бивша столица на Молдова е (1564-1862) и макар да е било отдавна, „столичното“ се усеща. Усеща се и соцът, разбира се.

От Яш хванахме автобус към Бълци, вторият по големина град в Молдова (ако не броим Тираспол, който според приднестровците не е в Молдова). Автобусът мина по умопомрачителен път (за съжаление – главният). Дупки нямаше, явно е бил направен качествено. Но според мен това е било някъде през 80-те. Беше толкова нагънат и крив, че всеки камък в бъбреците би излязъл. Все пак бяха решили да го ремонтират, но тъй като много от местните не спазваха светофарите в еднопосочните участъци, ставаха задръствания и разминаване на камиони, автобуси и коли, каращи през тревата. Нашите пътища и нашите шофьори са си направи „първи свят“.

В Бълци е мизерно, лъха на соц, сградите плачат за саниране, а както ще забележим после в цяла Молдова и Украйна – тръби минават навсякъде. На центъра има танк, както и няколко различни пазара – едни съвсем открит, един съвсем закрит, и един полуоткрит. Впечатление прави как местните (поне по-възрастните) се кръстят не просто когато влизат и излизат от църква, а дори когато минават покрай църква в тролей. Спахме в лятната къща на местно семейство (което я беше пуснало в Booking), и след кратка сутрешна разходка на другия ден, отидохме на автогарата. Там виковете „Кишинеу, Кишинеу“ са през 10 секунди – с цел да напълнят поредната маршрутка и на нейно място да дойде следващата.

Пътят до Кишинев беше значително по-добър, та даже успях да спя. За да ни остави по-близо до квартирата (апартамент пуснат в Booking, който явно яде от пазара на AirBNB), маршрутката ни остави „в нищото“ (в центъра, все пак, де). След дълъг (сервитьорите в Молдова не бързат, или поне нашите не бързаха) обяд (с кюфтенца от мамалига) последва цял ден разходка из Кишинев.

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

Кишинев е приятен. Има го соц усещането, но има и доста красиви места. Гарата е чудесна. Парковете са приятни. Има места, които са направени за картички. Има интересно градско изкуство. Новото строителство е … голямо, и се чудиш дали е ново или са санирани панелки.

Бяхме в Кишинев в деня на молдовския празник Лимба ноастръ (нашият език). Централният булевард беше затворен и имаше народни песни и тълпа от хора. Това е денят, на който молдовският език е станал официален в Молдовската ССР през 89-та, като е прието, че е иденетичен с румънския и се пише с латиница. Това е сериозна стъпка, тъй като съветската власт е настоявала, че молдовският е различен език, пишел се е с кирилица, като по този начин е бил предпоставка за твърдението, че има отделна молдовска нация и съответно – държава. Много молдовци не са на това мнение, и виждат този ден като важна стъпка към обединение с Румъния (опростявам, разбира се – има много за четене по темата). Този празник е важен и за отделянето на Транснистрия, както ще видим след малко.

Политическата обстановка в Молдова също е интересна. Имат проевропейска власт (както може да се види от флаговете по улицата), но пък проруски президент и все още вкоренени в институциите проруски настроения. В дните преди и след празника е имало многохилядни протести в Кишинев заради касирани избори за кмет (спечелил е проевропейският кандидат). Изглежда в Молдова борбата за влияние е доста активна.

На следващия ден станахме в 6ч, за да хванем влака за Тираспол (има един влак дневно). Опашката на гарата беше до входа – правиха проверка на билетите преди излизане на перона. Влакът беше пълен, тъй като крайната му дестинация е Одеса. Интересното при влизането с влак в Транснистрия е, че няма гранична гара. Влизаш си с влака в републиката (пресичайки мост над Днестър) и на гарата в Тираспол трябва да минеш през имиграционната служба. Там попълваш една бланка (с доста грешки в английската ѝ част), вземат ти горната половина, а долната половина си я пазиш до напускане. Имаш право на 10-тина часа, като ако нощуваш някъде, трябва собственикът на апартамента или хотела да ти удължи престоя, като отиде в районното. Ние бяхме планирали да останем само до следобед, така че тази стъпка не ни се наложи.

Граничният полицай много учтиво ни обясни всичко, каза кога ни е последната маршрутка за Одеса (не беше прав, беше по-късна), каза ни и за селото с бесарабски българи близо до Тираспол и как да стигнем дотам. Обменихме и пари – там се плаща с приднестровски рубли, които можеш да си купиш само от там. От гарата тръгнахме към тролейбусна спирка, откъдето да отидем до близкия град – Бендери. Да, има тролей между двата града. Първо обаче дойде маршрутка (с гениален начин за затваряне на вратата), та се отправихме към Бендери.

Бендери е ключов град в историята на Транснистрия. Той от другата страна на Днестър и е в демилитаризираната зона, макар че е под контрола на Транснистрия. Поради това, за да стигнеш до него, се минава през военния пункт на моста. Никой не те проверява, но прави впечатление. Усещането в Бендери е като в малък български град в средата на деведесетте (но с по-нови коли). Бяхме там на 1-ви септември, което е първият учебен ден и всички ученици с униформи бяха по улиците. Впечатление на направи, че повечето бяха момичета, но може би е било случайно. В единия край на града има крепост, за която нямахме време. Вместо това влязохме в музея на „Бендерската трагедия“.

Това е ключовият момент от приднестровската война, в който Молдовската армия нахлува в града, стреляйки по цивилни къщи и автомобили. Нещата, разбира се, са по-сложни. След приемането на молдовския (т.е. румънски) за официален език, малцинствата в Молдова – руското и гагаузкото – се притесняват от дискриминация и дори геноцид и обявяват независимост. Разбира се, езикът не е бил единственият фактор, цялостните настроения, в комбинация с разпада на съветския съюз, са довели до този акт. След референдума за напускане на СССР, Молдова все още няма опитна армия, с която да защити територията си, а 14-та руска армия подпомага приднестровците. В продължение на две години има епизоди на насилие, които кулминират в трагедията в Бендери – молдовската полиция арестува руски майор, но приднестровската „съпротива“ обстрелва полицейското управление. В отговор, молдовската армия влиза в града, за да установи контрол. Само че, твърди се, че правейки го, извършва доста нарушения. Което провокира Русия да застане официално на страната на Транснистрия. Последват кратки военни действия, след което примирие, което продължава и до днес. Общо взето Транснистрия съшествува благодарение на руската армия.

Проблемът обаче е назрявал много преди 90-та година. Транснистрия всъщност не е била част от Молдова, а от украинската ССР. След присъединяването на Молдова към СССР през 40-та година (в резултат от пакта Молотов-Рибентроп), Сталин „начертава границата“ на Молдовската ССР не до Днестър, а отвъд – включвайки и Транснистрия, в която тогава има 41% молдовско население. Бендери е „Против румънизацията“, а притесненията им може би са били отчасти основателни. Споменах Гагаузия – друга област, където се говори гагаузки език (който е тюркски). Тя през 94-та получава статут на автономна област, в която гагаузкият език е признат. Такова решение е най-логично, но за съжаление не е постигнато за Транснистрия.

Обратно в настоящето – хванахме такси от Бендери до Паркани (селото между Бендери и Тираспол). На въпрос „колко ще струва“, таксиджията каза „по апарат“. След което сложи смартфона си на таблото и отчиташе с него. Излезе колкото очаквахме. А в Паркани има бесарабски българи. Но в почивен ден в жегата не можеш точно да намериш българи по улицата. Само че решихме да потърсим споменатия от граничния полицай музей. Не било музей, оказа се, а културен център. На площада пред културния център има две неща. Паметник на Ленин и бюст на Васил Левски. Ленин и Левски – идилия.

А вътре в културния център ни посрещна жена, която, като разбра, че сме от България пита „на руски ли да говорим или да не си кършим езиците и да говорим на български. Той нашият е по-различен, де“. Показа ни експозицията на българската култура – трябваше да я подреди малко, защото я готвели за утрешния национален празник на Транснистрия. Щели да ходят с ансамбъла да представят българската култура в Тираспол. Показа ни и многото награди от български фолклорни фестивали – често идвали до България. Бесарабският български звучи много интересно – прилича на родопски, но със западни нотки.

След това излязохме на главния път и хванахме тролея за Тираспол – столицата на републиката. Видяхме паметника на Суворов (основател на Тираспол), както и явната близост на Транснистрия с Русия. Освен, че руският и приднестровският флаг винаги са един до друг, руската Сбербанк има силно присъствие.

Видяхме и сградата на парламента, пихме квас (супер е в жегата), видяхме посолсвата на Южна Осетия и Абхазия – две от трите държави, които признават Транснистрия (третата е Нагорни Карабах). Тираспол е вторият по-големина град на територията на Молдова. Усеща се като среден български областен град в началото на века – преди да дойдат европарите за ремонти.

Приднестровието е бедно. Произвеждат коняк (Квинт), чиито магазини са едно от малкото по-лъскави неща, заедно със Сбербанк. За да изнасят стоки за ЕС, те трябва да са „произведени в Молдова“, а след подписването на договора за асоцииране между Молдова и ЕС през 2014-та, приднестровската икономика бързо се преориентира към ЕС, като износът за Русия спада. Вносът от ЕС пък е с високо качество, както можем да видим от тази снимка. По десетки стълбове, както и в маршрутките, има обяви за курсове с гарантирана работа в Европа, работа в Полша и дори румънско гражданство. Руските знамена са благодарност за военната помощ от руската армия, но икономиката вече е ясно насочена към Европа. Любопитна нотка е и логото на Приста Ойл на гарата в Тираспол, вероятно от едни минали времена.

От Тираспол тръгнахме с маршрутка за Одеса. Границата е интересна, защото е тройна. Напускаш Транснистрия, съответно има техен граничен пункт. Влизаш в Украйна, съответно има техен пункт. Но интересното е, че в същото време напускаш и Молдова. И ако няма молдовски граничен пункт, няма да има кой да ти сложи печат, че си напуснал Молдова. Този проблем е решен със споразумение между Молдова и Украйна, така че на украинският пункт получаваш печата за изход от Молдова. А украинският граничен полицай ни пита „Нещо изнасяте ли? Наркотици, трева, съветски медали?“. Вероятно заради ценните метали, но все пак беше забавен въпрос.

В Одеса спахме в антиутопичен жилищен комплекс, а на следващия ден цял ден се разхождахме. Одеса, особено в центъра, е доста приятен град. Красива гара, красиви стари сгради, още красиви сгради, (макар и понякога с големи свински опашки), музей на контрабандата, до чието посещаване на стигнахме, пристанище, и разбира се – плаж.

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

Няколко дни след като станах на 31, посетих 31-вата си държава. Но не броя Транснистрия – с нея биха били 32. А тя е пример за това колко много история и много историческа глупост може да има на едно малко парче земя. И как тази историческа глупост води до това едни хора да живеят бедно, да бъдат облъчвани с пропаганда и да нямат възможностите за развитие, които имаме ние.

Молдова никога не е искала да бъде част от Съветския съюз. Но е станала след споразумение между двата силни режима в средата на века – хитлеристка Германия и СССР на Сталин. В резултат на това, в момента Молдова е бедна, макар че могат да се видят проблясъците и възможностите, които са пред нея.

Приднестровската република пък е отчасти жертва на „чертаенето“ на граници с молив върху карта от неадекватни лидери. Можеше, разбира се, про-румънските настроения в Молдова да не бъдат за сметка на руското и гагаузкото малцинство и на тях да бъдат дадени уверения, че няма да бъдат дискриминирани. В резултат, днес 475 хиляди души живеят „в нищото“. Живеят спокойно, бавно, но бедно и без особени перспективи. Освен ако не пробват да скъсат някое листче за „работа в Полша“ или „Румънско гражданство“.

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

Трябва да сме много внимателни да не попадаме в такива ситуации, защото излизането от тях е трудно. Последният път ни отне 62 години (1944-2007). Дано да няма следващ такъв малшанс, подпомаган от местни опортюнисти и полезни идиоти.

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

Общински електронни услуги и защо никой не ги ползва

Post Syndicated from Bozho original https://blog.bozho.net/blog/3167

Когато говорим за електронно управление, почти винаги си представяме електронизация на централната власт. Само че немалка част от административните услуги са общински. Или по-точно – предоставени от общините.

Някои общини имат електронни услуги, като те са се случили по един от следните начини:

  • По някой проект по ОПАК (Оперативна програма „Административен капацитет“), като индивидуално усилие на съответната община. Често тези проекти нямат устойчивост
  • Чрез публичен модул на деловодната система (най-често Акстър)
  • Чрез интеграция на системата за местни данъци и такси с НАП
  • По проект за общински електронни услуги на МТИТС, който имаше две итерации – първата внедри услугите в Столична община, а втората – с Радомир, Бургас и Габрово

Проектите по ОПАК често остават без поддръжка и електронните услуги вече дори не са достъпни. Преди доста години работех в една фирма, с която направихме електронни услуги в две общини – проверих, и в двата случая вече не работят. Даже едната община явно е имала нови електронни услуги, които да заменят старите, но и те в момента не работят. Не е новина, че ОПАК беше едно неадекватно разхищение на европари, но това е друга тема – надявам Оперативна програма „Добро управление“ (наследник на ОПАК) да бъде по-успешна, макар че в момента там има друг проблем – много малко проекти реално са стартирали, вероятно отчасти заради високите изисквания за качество и невъзможността за „пари на калпак“.

Публичните модули на деловодните системи са полезни, като плюсът е, че няма нужда от специална интеграция с това, което така или иначе администрацията ползва всеки ден – деловодната система. Много от проектите за електронни услуги създаваха де факто паралелна деловодна система (в някои случаи прехвърлянето в реалната става с copy-paste), което не е добре от процесна гледна точка.

Местните данъци и такси, с малки изключения, работят прилично – влизаш на сайта на НАП, проверяваш колко дължиш и плащаш – с банкова карта онлайн. Като истинско (само трябва да имаш ПИК или КЕП, тъй като още сме доникъде с електронната идентификация).

Проектите на МТИТС за електронни услуги дават възможност една и съща инсталация да се използва в няколко общини, с леки модификации. Т.нар. multi-tenant софтуер, залегнал и в чл. 26, ал. 2 от наредбата към Закона за е-управление.

Всичко чудесно, но какво всъщност са общинските услуги? Най-често заявяваните такива се оказва, че на практика не са „общински“. Да, заявяват се в общината, но реално са услуги на ГД „ГРАО“, т.нар. „гражданска регистрация“. Промяна на адрес (постоянен, настоящ), удостоверения за куп неща – адреси, семейно положение, наследници, идентичност на имена, акт за раждане, разни дубликати. За всичко това общината е фронт-офис на ГРАО – ползва информационната система на ГРАО.

Т.е. подходът всеки да си прави отделни услуги за гражданска регистрация е дълбоко погрешен, но така или иначе вече има такива, реших да видя как се използват. По-конкретно – в Столична община. Аз успях да си сменя постоянния адрес чрез тях, а преди три години си извадих така удостоверение за семейно положение. Макар и след тежка битка и в двата случая. Попитах Столична община по Закона за достъп до обществена информация колко пъти са предоставяни електроните услуги. И резултатът не беше изненадващ. Пълната справка можете да свалите тук.

Но ето извадка за категорията „Гражданска регистрация“ (където има най-много заявления, като изключим една вътрешно-административна услуга категория „Местни данъци и такси“).

наименование на електронна услуга/справка брой постъпили заявления за 2016 г. брой постъпили заявления за 2017 г. брой постъпили заявления за 2018 г.
Удостоверение за наследници 4 14 14
Удостоверение за настоящ адрес при вече регистриран настоящ адрес 3 13 1
Удостоверение за настоящ адрес след подаване адресна карта за заявяване или за промяна на настоящ адрес 2 5 4
Удостоверение за постоянен адрес при вече регистриран постоянен адрес 6 8 4
Удостоверение за постоянен адрес след подаване на заявление за заявяване или за промяна на постоянен адрес 2 6 3
Удостоверение за промени на постоянен адрес регистриран след 2000 година 1 2 3
Удостоверение за промeни на настоящ адрес регистриран след 2000 година 0 0 7
Удостоверение за раждане – дубликат 5 5 0
Удостоверение за родените от майката деца 1 1 0
Удостоверение за семейно положение 7 27 30
Удостоверение за семейно положение, съпруг/а и деца 26 65 54
Удостоверение за сключен граждански брак – дубликат 0 4 1
Удостоверение за съпруг/а и родствени връзки 0 1 1
Удостоверение за идентичност на лице с различни имена 0 3 2
Препис-извлечение от акт за смърт, за втори и следващ път 3 5 2
Заверен препис или копие от личeн регистрационeн картон или страница от семейния регистър на населението 1 0 0
Удостоверение за вписване в регистрите на населението 2 0 0

Та, на практика никой не ползва тези услуги. Защо?

  • Столична община не ги промотира – почти никой не знае за съществуването им.
  • Трудни са за използване – когато аз подавах заявление имаше бъг с подписването на големи документи, а подкарването на коректната версия на Java в коректния браузър беше трудно дори за Java програмист. Трудно и да измислиш коя точно услуга ти трябва – много от тях не трябва да бъдат различни услуги, а една, с разлика от едно поле.
  • Нужен е и квалифициран електронен подпис. Малко хора имат.

Защо това е така – мога да обяснявам цял ден, но обединяващата причина е, че неразбирането на концепцията за е-управление и липсата на електронна идентификация. Ако всеки имаше средство, с което удобно да може да ползва тези услуги, със сигурност щяха да са използвани много повече. Също така, поне половината от тези услуги щяха да са излишни – те не са услуги, а издаване на удостоверения, които да послужат пред друг орган…който вместо това трябва (и вече може) да си ги вземе служебно.

Накратко и много опростено – електронното управление не е трупане на електронни услуги без осигурена поддръжка. То е две неща:

  • намаляване на услугите чрез елиминиране на удостоверителните (и превръщането им във вътрешно-административни)
  • масова и удобна електронна идентификация, с която гражданите да могат да ползват останалите услуги

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

А дотогава – аз и още 40-тина ентусиасти ще ползват общински електронни услуги на Столична община, общината ще е отчела, че „има електронни услуги, ето“. И всичко ще си върви както винаги – на хартия и по гишета.

 

A Caveat With AWS Shared Resources

Post Syndicated from Bozho original https://techblog.bozho.net/a-caveat-with-aws-shared-resources/

Recently I’ve been releasing a new build, as usual utilizing a blue-green deployment by switching the DNS record to point to the load balancer of the previously “spare” group. But before I switched the DNS, I checked the logs of the newly launched version and noticed something strange – continuous HTTP errors from our web frameworks (Spring MVC) that a certain endpoint does not support the HTTP method.

The odd thing was – I didn’t have such an endpoint at all. I enabled further logging and it turned out that the request URL was not about my domain at all. The spare group, not yet having traffic directed at it, was receiving requests pointed at a completely different domain, which I didn’t own.

I messaged the domain owner, as well as AWS, to inform them of the issue. The domain owner said they have no idea what that is and that they don’t have any unused or forgotten AWS resources. AWS, however, responded as follows:

The ELB service scales dynamically as traffic demand changes, therefore when scaling occurs, the ELB service will take IP addresses from the AWS unused public IP address pool and assign them to the ELB nodes that are provisioned for you. The foreign domain name you see here in your case, likely belongs to another AWS customer who’s AWS resource is no longer using one of the IP addresses that your ELB node now has as it was released to the AWS unused IP pool at some stage, their web clients are very likely excessively caching DNS for these DNS names (not respecting DNS TTL), or their own DNS servers are configured with static entries and are therefore communicating with an IP address that now belongs to your ELB. The ELB adding and removing IPs from Route53 is briefly described in [Link 1] and the TTL attached to the DNS name is 60 seconds. Provided that clients respect the TTL, there should be no such issues.

I can simply ignore the traffic, but what happens if I’m in this role – after a burst my IP gets released, but some client (or some intermediate DNS resolver) has cached the information for longer than instructed. Then requests to my service, including passwords, API keys, etc. will be forwarded to someone else.

Using HTTPS might help in case of browsers, as the the certificate of the new load balancer will not match my domain, but in case of other tools that don’t perform this validation or have it cached, HTTPS won’t help, unless there’s certificate pinning implemented.

AWS say they can’t fix that at the load balancer, but they actually can, by keeping a mapping between IPs, owners and Host headers. It won’t be trivial, but it’s worth exploring in case my experience is not an exceptional scenario. Whether it’s worth fixing if HTTPS solves it – probably not.

So this is yet another reason to always use HTTPS and to force HTTPS if connection is made over HTTP. But also a reminder to not do clever client-side IP caching (let the DNS resolvers handle that) and to always verify the server certificate.

The post A Caveat With AWS Shared Resources appeared first on Bozho's tech blog.

Writing Big JSON Files With Jackson

Post Syndicated from Bozho original https://techblog.bozho.net/writing-big-json-files-with-jackson/

Sometimes you need to export a lot of data to JSON to a file. Maybe it’s “export all data to JSON”, or the GDPR “Right to portability”, where you effectively need to do the same.

And as with any big dataset, you can’t just fit it all in memory and write it to a file. It takes a while, it reads a lot of entries from the database and you need to be careful not to make such exports overload the entire system, or run out of memory.

Luckily, it’s fairly straightforward to do that, with a the help Jackson’s SequenceWriter and optionally of piped streams. Here’s how it would look like:

    private ObjectMapper jsonMapper = new ObjectMapper();
    private ExecutorService executorService = Executors.newFixedThreadPool(5);

    @Async
    public ListenableFuture<Boolean> export(UUID customerId) {
        try (PipedInputStream in = new PipedInputStream();
                PipedOutputStream pipedOut = new PipedOutputStream(in);
                GZIPOutputStream out = new GZIPOutputStream(pipedOut)) {
        
            Stopwatch stopwatch = Stopwatch.createStarted();

            ObjectWriter writer = jsonMapper.writer().withDefaultPrettyPrinter();

            try(SequenceWriter sequenceWriter = writer.writeValues(out)) {
                sequenceWriter.init(true);
            
                Future<?> storageFuture = executorService.submit(() ->
                       storageProvider.storeFile(getFilePath(customerId), in));

                int batchCounter = 0;
                while (true) {
                    List<Record> batch = readDatabaseBatch(batchCounter++);
                    for (Record record : batch) {
                        sequenceWriter.write(entry);
                    }
                }

                // wait for storing to complete
                storageFuture.get();
            }  

            logger.info("Exporting took {} seconds", stopwatch.stop().elapsed(TimeUnit.SECONDS));

            return AsyncResult.forValue(true);
        } catch (Exception ex) {
            logger.error("Failed to export data", ex);
            return AsyncResult.forValue(false);
        }
    }

The code does a few things:

  • Uses a SequenceWriter to continuously write records. It is initialized with an OutputStream, to which everything is written. This could be a simple FileOutputStream, or a piped stream as discussed below. Note that the naming here is a bit misleading – writeValues(out) sounds like you are instructing the writer to write something now; instead it configures it to use the particular stream later.
  • The SequenceWriter is initialized with true, which means “wrap in array”. You are writing many identical records, so they should represent an array in the final JSON.
  • Uses PipedOutputStream and PipedInputStream to link the SequenceWriter to a an InputStream which is then passed to a storage service. If we were explicitly working with files, there would be no need for that – simply passing a FileOutputStream would do. However, you may want to store the file differently, e.g. in Amazon S3, and there the putObject call requires an InputStream from which to read data and store it in S3. So, in effect, you are writing to an OutputStream which is directly written to an InputStream, which, when attampted to be read from, gets everything written to another OutputStream
  • Storing the file is invoked in a separate thread, so that writing to the file does not block the current thread, whose purpose is to read from the database. Again, this would not be needed if simple FileOutputStream was used.
  • The whole method is marked as @Async (spring) so that it doesn’t block execution – it gets invoked and finishes when ready (using an internal Spring executor service with a limited thread pool)
  • The database batch reading code is not shown here, as it varies depending on the database. The point is, you should fetch your data in batches, rather than SELECT * FROM X.
  • The OutputStream is wrapped in a GZIPOutputStream, as text files like JSON with repetitive elements benefit significantly from compression

The main work is done by Jackson’s SequenceWriter, and the (kind of obvious) point to take home is – don’t assume your data will fit in memory. It almost never does, so do everything in batches and incremental writes.

The post Writing Big JSON Files With Jackson appeared first on Bozho's tech blog.

Няма консервативна вълна?

Post Syndicated from Bozho original https://blog.bozho.net/blog/3156

В своя статия тези дни, д-р Петър Николов (зам.министър на образованието и кандидат за народен представител на патриотите) направи опит да затвърди разпространената теза, че има консервативна вълна в света. Аз, обаче, не съм съгласен.

И да, не съм политолог, историк, социолог, културолог, анализатор или „говореща глава“, затова мнението ми вероятно е по-неподготвено, но целта ми е да дам един алтернативен поглед – пък бил той и не напълно коректен.

Първо трябва да знаем за какво говорим – какво е „консерватизъм“ (и „либерализъм“). Понятия, които носят конкретен смисъл в достатъчно академични среди, но са натоварени с всевъзможни значения извън тях. В публичния дебат общо взето няма значение какво значи консерватизъм – той значи това, което хората смятат, че значи. И можем да го обобщим като „придържане към традиционни ценности, обичаи и уповаване на миналото и силен скептицизъм спрямо нови или променящи се обществени норми“. Не твърдя, че това е пълна или коректна дефиниция, но рядко работим с конкретни дефиниции в често повърхностните дебати, с които разполагаме.

И макар да обичам „закачки“ с консерватизма, като например: „Логиката на консерватизма: всичко ще стане по-добре, ако остане както си е било винаги.“, истината е, че консерватизмът има своите ползи за обществото – идеята, че ако нещата останат както са, няма да станат по-зле (което е риск при промяната); хората имат нужда от идентичност и общност, към която да се придържат, и традициите определено са нещо, което помага в това отношение.

Искам също да отбележа, че за разлика от д-р Николов, не мога да кажа, че „харесвам“ или „не харесвам“ консерватори или либерали. Не си изграждам мнение за хората на база на някакъв етикет, който някой (или те самите) са си поставили. Имам приятели – консерватори, с които водим много продуктивни и интересни дискусии. Хора, които следват традициите (Християнските, родовите, националните). Няма как да кажа, че не ги харесвам – живеят по начин, който те смятат за правилен, това ги прави щастливи и им дава спокойствие. Нямам нито един аргумент срещу тях.

Имам аргумент обаче срещу тези, които изхождайки от своите виждания казват как трябва да живеят всички останали. Или как да НЕ живеят. Аз не съм традиционалист, но докато някой не ми каже, че като по-либерален „съсипвам всичко ценно в нашия свят и разрушавам всичко красиво“, нямам спор с традиционалистите.

Съвсем естествен е сблъсъкът на консервативните и либералните тези в контекста на това „кое е по-добро за дългосрочното развитие на обществото“ и отговорът най-вероятно е „по малко и от двете“. Твърде бързата промяна носи рискове, твърде бавната промяна носи изоставане. Но какво общо има това с консервативната вълна, каквато аз твърдя, че няма?

Консерватизмът в Европа се възприема чрез изборните победи на консервативни партии в Австрия, Полша, Унгария, Италия, както и Брекзит и високия резултат на националистите във Франция и Германия. Местните специфики настрана, какво е общото между изредените? Антимигрантската реторика. Всяка от консервативтните партии, спечелили или засилили влиянието си през последните години разчита именно на това – да капитализира неспряването с мигрантската криза. Пикът на тази криза беше 2015-та и оттогава намалява, но не намалява усещането за нея, отчасти благодарение на използването ѝ като политическо послание.

Мигрантската криза пък е обвързана с терористичните атентати и заплахи. Атентатите във Франция и Белгия създадоха страх и обвинени, разбира се, бяха мигрантите. По-скоро несправедливо, но така или иначе ислямският тероризъм е факт. Не можем да кажем, че го няма. Паленето на свещи и съпричастността не могат да разсеят този страх. Етикетирани като консервативни партии, обаче, могат да се възползват от него.

А провалът на европейските правоохранителни органи и служби е виден. И той не е заради „твърде либерална политика“ – колкото и либерална да е една политика, заподозрените в тероризъм най-много да бъдат прибрани в по-лъскав затвор. Само че службите и полицията не можаха да се справят с тези заплахи и това не е идеологически проблем. Това е технически и организационен проблем. Може би ще прозвучи странно, но нашето МВР е по-подготвено от гледна точна на информационните технологии отколкото доста западноевропейски партньори.

Преди няколко години Microsoft представиха в МВР свое решение за консолидиране на източниците на информация с цел разкриване и превенция на престъпления, в т.ч. атентати. Това, което отбелязаха в презентацията си е, че след анализ през 2001-ва година е станало ясно, че правоохранителните органи в САЩ са имали цялата необходима информация за предотвратяване на атентата от 11-ти септември. Просто информацията е била пръсната между федерални, щатски и общински служби и органи, които не са я обменяли помежду си. Атентатът подейства отрезвително и администрацията на Буш реформира тази система, така че да е по-ефективна и по-информирана. Да, в щатите това носи със себе си „орязване“ на някои граждански свободи, но според мен и според експерти постиганият резултат е възможен и без масовото следене.

Ако службите работеха по-добре и използваха новите технологии по-адекватно, може би атентати нямаше да има? Знам, че това е просто хипотеза, но понякога в историята на пръв поглед малки грешки водят след себе си големи промени и проблеми.

Свързано със страха от мигранти и тероризъм е и друг обединяващ фактор – протекционизмът. И в САЩ и в Европа, етикетираните като консервативни партии и лидери говорят за затваряне на граници, за защита на „местното“. Силна „опорна точка“ и в кампанията на Тръмп, Орбан, Курц, и в тази за Брекзит, бяха границите. Стената. „Да си върнем контрола на границите“.

Всички тези неща – антиимигрантската реторика, протекционизмът, са основните фактори за успеха на консерваторите в Европа. Да, те имат и други, реални консервативни тези. Но според мен те не бяха и няма да бъдат определящи. Да, най-естествено е да закачиш национализма и популизма за консервативните партии, но не мисля, че вълната е консервативна.

Вълната е резултат не несправянето на традиционните парии и лидери с кризите и като цяло липсата на лидерство и визионерство в Европа в момента.

Франция избра либерал за президент; Ирландия, силно религиозна, католическа страна, гласува за гей браковете и абортите; в Германия най-голямо увеличение в гласовете получиха националистите, но веднага след тях е либералната партия; в Чехия пиратската партия е трета в парламента с 8% ръст; на последните местни избори в Холандия най-голям ръст имат Зелените и либералната партия (част от ALDE в Европейския парламент). Португалия продължава вече почти 20 години с успешната си политика за декриминализиране на наркотиците и няма изгледи това да се промени. Дали има консервативна вълна в европейските общества е много спорно.

Не е спорно обаче, че има опортюнистична вълна. Или както е казал Бай Ганьо:

„А бе, бай Иречек, я ми кажи твоя милост леберал ли си, консерватор ли си? Май-май, че си консерва, както виждам. И аз, ако питаш, не мога да ги разбера нито едните, нито другите, ама хайде, да не им остане хатъра… Знайш, алъш-вериш е то, не е шега… Па и мене нали ми се иска – я депутат да ме изберат, я кмет. Келепир има в тия работи. Хората пара натрупаха, ти знаеш ли… Тъй е! Аз съм врял и кипял в тия работи, че ги разбирам…“

В западна Европа, където държавите имат демократични традиции, този политически опортюнизъм може да има позитивни резултати – В Астрия Курц изглежда доста подготвен и грамотен и може да направи необходимите реформи. Не така обаче стоят нещата в бившия социалистически блок. В Полша и в Унгария управляващите отдалечават страните си от идеалите на либералната демокрация. Няма да е преувеличение ако кажем, че създават условия за диктатура – и в Унгария и в Полша върви подмяна на кадри по всички структури на властта и особено в съдебната власт.

У нас нещата са по-спокойни, а за яхване на тази уж консервативна вълна се борят почти всички – и БСП, и патриотите, и все още безформени извънпарламентарни „групички“. И тук ще се съглася с Петър Николов – хората не са глупави. И ще видят байганьовщината, колкото и усилена да е консервативната медийна кампания, умело използваща неща като Истанбулската конвенция, за създаване на разделения.

Хората не са глупави, но при толкова опити да бъдат манипулирани и етикетирани, плашени и екстремизирани, могат да бъдат подведени към друга крилата фраза на Бай Ганьо – „всички са маскари“. Но краткосрочните политически „интрижки“ не са големият проблем. Големият проблем е, че малка група опортюнисти искат да набутат хората в кутийки, да им сложат етикетчета, и да си ги „приберат“ електорално. Да ги плашат с бежанци и „джендъри“, да ги разделят.

Хората имат да управляват своя живот, своята работа, своя бизнес. И рядко са крайни в позициите си. Да, имат различен начин на живот, различна степен на традиционализъм и различно ежедневие, но когато седнат „на маса“ да си говорят, могат да се разберат. Опитът на политическите опортюнисти е това да не е така – да издърпат нормалните, умерени хора в крайностите. И да има кажат „другите са врагът, другите са виновни, другите разрушават всичко красиво“.

Това не е консервативно или либерално, това е просто безотговорно.

Proving Digital Events (Without Blockchain)

Post Syndicated from Bozho original https://techblog.bozho.net/proving-digital-events-without-blockchain/

Recently technical and non-technical people alike started to believe that the best (and only) way to prove that something has happened in an information system is to use a blockchain. But there are other ways to achieve that that are arguably better and cheaper. Of course, blockchain can be used to do that, and it will do it well, but it is far from the only solution to this problem.

The way blockchain proves that some event has occurred by putting it into a tamper-evident data structure (a hash chain of the roots of merkle trees of transactions) and distributing that data structure across multiple independent actors so that “tamper-evident” becomes “tamper-proof” (sort-of). So if an event is stored on a blockchain, and the chain is intact (and others have confirmed it’s intact), this is a technical guarantee that it had indeed happened and was neither back-dated, nor modified.

An important note here – I’m stressing on “digital” events, because no physical event can be truly guaranteed electronically. The fact that someone has to enter the physical event into a digital system makes this process error-prone and the question becomes “was the event correctly recorded” rather than “was it modified once it was recorded”. And yes, you can have “certified” / “approved” recording devices that automate transferring physical events to the digital realm, e.g. certified speed cameras, but the certification process is a separate topic. So we’ll stay purely in the digital realm (and ignore all provenance use cases).

There are two aspects to proving digital events – technical and legal. Once you get in court, it’s unlikely to be able to easily convince a judge that “byzantine fault tolerance guarantees tamper-proof hash chains”. You need a legal framework to allow for treating digital proofs as legally binding.

Luckily, Europe has such a legal framework – Regulation (EU) 910/2014. It classifies trust services in three categories – basic, advanced and qualified. Qualified ones are always supplied by a qualified trust service provider. The benefit of qualified signatures and timestamps is that the burden of proof is on the one claiming that the event didn’t actually happen (or was modified). If a digital event is signed with a qualified electronic signature or timestamped with a qualified timestamp, and someone challenges that occurrence of the event, it is they that should prove that it didn’t happen.

Advanced and basic services still bear legal strength – you can bring a timestamped event to court and prove that you’ve kept your keys securely so that nobody could have backdated an event. And the court should acknowledge that, because it’s in the law.

Having said that, the blockchain, even if it’s technically more secure, is not the best option from a legal point of view. Timestamps on blocks are not put by qualified trust service providers, but by nodes on the system and therefore could be seen as non-qualified electronic time stamp. Signatures on transactions have a similar problem – they are signed by anonymous actors on the network, rather than individuals whose identity is linked to the signature, therefore making them legally weaker.

On the technical side, we have been able to prove events even before blockchain. With digital signatures and trusted timestamps. Once you do a, say, RSA signature (encrypt the hash of the content with your private key, so that anyone knowing your public key can decrypt it and match it to the hash of the content you claim to have signed, thus verifying that it is indeed you who signed it), you cannot deny having signed it (non-repudiation). The signature also protects the integrity of the data (it can’t be changed without breaking the signature). It is also known who signed it, owning the private key (authentication). Having these properties on an piece of data (“event”) you can use it to prove that this event has indeed occurred.

You can’t, however, prove when it occurred – for that you need trusted timestamping. Usually a third-party provider signing the data you send them, and having the current timestamp in the signed response. That way, using public key cryptography and a few centralized authorities (the CA and the TSA), we’ve been able to prove the existence of digital events.

And yes, relying on centralized infrastructure is not perfect. But apart from a few extreme cases, you don’t need 100% protection for 100% of your events. That is not to say that you should go entirely unprotected and hope that an event has occurred simply because it is in some log file.

Relying on plain log files for proving things happened is a “no-go”, as I’ve explained in a previous post about audit trail. You simply can’t prove you didn’t back-date or modify the event data.

But you can rely on good old PKI to prove digital events (of course, blockchain also relies on public key cryptography). And the blockchain approach will not necessarily be better in court.

In a private blockchain you can, of course, utilize centralized components, like a TSA (Time stamping authority) or a CA to get the best of both worlds. And adding hash chains and merkle trees to the mix is certainly great from a technical perspective (which is what I’ve been doing recently). But you don’t need a distributed consensus in order to prove something digital happened – we’ve had the tools for that even before proof-of-work distributed consensus existed.

The post Proving Digital Events (Without Blockchain) appeared first on Bozho's tech blog.

Гадната европейска бюрокрация

Post Syndicated from Bozho original https://blog.bozho.net/blog/3147

Гадните евро-бюрократи (еврократи) само измислят глупости и ги налагат на суверенните държави! Никой не е гласувал за тях, а определят каква форма да имат краставиците! Огромната брюкселска бюрокрация взема милиони и опитва да оправдае съществуването си!

Така звучат оплакванията на евроскептиците. Както британският сериал (от 81-ва) „Да, г-н министър“ иронизира ситуацията – „Брюкселски бюрократи, които летят с частни самолети и се хранят с шампанско и хайвер“.

Всичко това са до голяма степен митове и преувеличения. В Европейската комисия (която е изпълнителната власт на ЕС) работят 32 хиляди души, а в администрацията на Европейския парламент работят 7500 души. Общо 40 хиляди. Може и по-малко, но не бих го нарекъл „раздута администрация“. В България администрацията е около 110 хиляди, например.

Каква обаче е целта не европейските регулации? И кой ги „измисля“, кой ги приема?

Целта е до голяма степен хармонизиране на националните законодателства, така че единният пазар да функционира. Ако според френските закони даден продукт трябва да отговаря на едни условия, а според немския на други, то българска компания не може да изнася и за Германия, и за Франция. Затова трябва общи стандарти, на които всички страни да се съгласят, за да могат фирмите да търгуват без затруднения. Защото на теория единен пазар има, ама ако трябва да си пригаждаш продукта за всяка държава поотделно, би било доста непрактично.

Последната Европейска комисия се фокусира върху единния цифров пазар – как да се уеднаквят правилата „онлайн“. Това включваше, например, GDPR. GDPR почти не въвежда неща, които ги е нямало в едно или друго национално законодателство (или които не са се наложили след съдебна практика). Общо взето процесът е „вземаме настоящите закони и измисляме нов такъв, който да отразява спецификите на всички държави“. Защо да има общо законодателство за защитата на личните данни? За да не се налага дигиталните компании да имат различни политики за всяка държава поотделно, съответно да плащат на адвокати във всяка държава.

Регламент 910/2014 пък унифицира електронните подписи и електронната идентификация. Благодарение на това, електронен подпис, издаден в една държава, важи във всички останали. Така ако искаме да подпишем договор между българска и немска фирма, и да сме сигурни, че договорът да има стойност и в двете държави, няма нужда българската фирма да купува немски електронен подпис. Същият регламент, обаче, въвежда възможност за предоставяне на електронни услуги на граждани от други държави. Това е друг аспект на европейското законодателство – предоставяне на свързаност и интегриране на държавите членки.

В Европа, един камион може да пътува от България до Франция без да прави нищо специфично, в зависимост от държавите, през които минава. Съществува унифицирана система за тол-такси, с която се улеснява отчитането и плащането. Преди година имах разговор с американски предприемач, който разказваше как всеки щат има специфики и съответно има компании, които се занимават само с това – да уреждат документите на превозвачи, така че да могат да преминават през всички щати, които са им нужни.

Наскоро ЕС въведе изискване за шаблони за някои документи, така че да не се изисква апостил. Т.е. за определени удостоверения процедурата ще е много по-лесна (например ако искате брачно свидетелство от Дания да се признае в България).

Понякога, все пак, се предлагат и изцяло нови неща, които ги е нямало в ничие законодателство. Директивите за платежните услуги (PSD, PSD2), например, създават възможности за небанкови инстутиции да предлагат все повече платежни услуги. Предлагането на нови идеи невинаги е гладко – понякога Европейската комисия (и то на политическо ниво, не „бюрократите“) измисля някоя глупост, като автоматичното филтриране на съдържание, което го е нямало в ничие законодателство преди това. Или недообмисля някой детайл, като закривеността на краставици и банани (което е частично мит, но общо взето е базирано на международна класификация на плодовете и зеленчуците).

И затова е важен процесът. И е абсолютен мит, че нещата се приемат от бюрократи, които никой не е избирал. Дали един регламент или директива (двата основни вида законодателство на Европейския съюз) ще бъде приет или не, и в какъв вид ще бъде приет, зависи от Европейския парламент, където всеки представител е избран на избори, както и от Съвета на ЕС, в който всяка държава е представляване от своите министри, т.е. от легитимно избраното си правителство. Парламентът и Съветът обсъждат и приемат свои версии на предложените от Комисията закони, след което сядат и ги обединяват във финална версия, която приемат.

Процесът е дълъг и сложен, данни, които извлякох от EUR-LEX):

Първата представя Регламентите и Директивите приети по процеса, описан по-горе – както от Парламента, така и от Съвета. Те намаляват от 2014-та година насам, което е добър тренд.

На втората са Регламентите и Директивите, приети само от съвета. Те видимо намаляват през годините.

На третата са актовете на Комисията. Те също значително намаляват.

(Съществуват още няколко вида актове на институциите на ЕС, но можем да ги определим като по-маловажни и да не се спираме на тях)

В обобщение, европейското законодателство прави следните неща: хармонизира съществуващи закони; въвежда стандарти, които да улеснят обмена на стоки и услуги; създава възможности за повече свързаност между държавите и бизнесите, които оперират в тях; осъвременява законодателството спрямо новите технологии и реалности. Европейското законодателство намалява с годините, т.е. Брюксел „твори“ с по-бавни темпове.

Не вярвам митовете за лошите еврократи и задушаващият, недемократичен Европейски съюз да изчезнат, особено предвид излизващите от време на време недомислени текстове. Също така ЕС не е само „законодателство“, има и доста изпълнителни функции. Има и други структури, като Европейска централна банка, съд на ЕС, и е нормално човек да се обърка във всичките тези неща. Те обаче се следствие на богатата история на държавите в Европа и на историческите им взаимодействия.

Гадната европейска бюрокрация е толкова гадна, колкото са държавите-членки. Има какво да се желае от Брюксел, но 40-те хиляди еврократи не са виновни за кризата на доверието, която назрява в ЕС.

Вината е в липсата на лидерство и в тесния национален интерес, който някои държави преследват. Да, държавите в ЕС са суверенни (и са доста по-суверенни от американските щати), но уеднаквяването на правилата не значи отказ от суверенитет.

Европейският съюз трябва да се реформира и да еволюира, но не защото е „твърде бюрократичен“ или „твърде централизиран“ или „твърде недемократичен“ – данните и реалността казват обратното. Трябва да се реформира, за да бъде по-гъвкав при вземането на решения, особено в кризисни ситуации.

Ще има ли електронно гласуване?

Post Syndicated from Bozho original https://blog.bozho.net/blog/3144

Пак сме на темата електронно гласуване – този път, защото Държавна агенция „Електронно управление“ пусна за обществено обсъждане техническата спецификация за бъдещата система.

Няма за пореден път да влизам в детайли защо и как може да работи и да е сигурно. Да приемем, че може и да видим какви са стъпките (досега и оттук нататък):

  • Референдум – гласувахме „за“
  • Решение на Народното събрание дали да признае референдума – призна го
  • Законодателни промени – в работна група в НС работихме по измененията в Изборния кодекс, той беше приет и предвижда 2019-та да се гласува електронно на европейските избори
  • Вкарване на проекта като приоритетен в стратегически документ (пътна карта) и осигуряване на финансиране – това го направихме 2016-та, няколко месеца след приемането на измененията в Изборния кодекс. Финансиранетоп е по оперативна програма „Добро управление“
  • Разписване на проекта, одобряването му управляващия орган на оперативната програма и пускане на първа обществена поръчка – случи се в първата половина на 2017-та
  • Извършване на анализ на добрите практики по света – стана във втората половина на 2017-та и завърши с представяне на резултатите в началото на декември
  • Пускане на поръчка и избор на изпълнител за написване на техническото задание на база на анализа – беше завършено в края на 2017-та или началото на 2018-та
  • Изготвяне на техническо задание и приемането му от ЦИК и ДАЕУ – това отне 6-7 месеца, като доколкото ми е известно самото задание е било готово доста бързо
  • Обществено обсъждане на заданието – юли-август 2018-та
  • Обявяване на обществена поръчка и избор на изпълнител – надявам се до края на годината
  • Разработка (или доработка на съществуващо решение) и внедряване – поне 6 месеца
  • Експериментални гласувания – трябва да са поне 3
  • Действително гласуване

Виждаме, че натрупаното изоставане е доста – то е най-вече в периода 2017-2018, в който липсва ясна политическа визия и воля, че това трябва да се случи.

Вчера обсъждахме с двама членове на ЦИК в Bulgaria on Air именно това – дали за евроизборите ще има някаква готовност. От ЦИК са на мнение, че без национална схема за електронна идентификация електронно гласуване не може да има. Както неведнъж съм казвал – това не е точно така, в най-добрия случай е спорно. На една конференция и аз (като съавтор на текстовете) и Петър Славов (вносител и съавтор) уточнихме, че текстовете са написани както са именно за да не ограничават средствата за идентификация. Квалифицираният електронен подпис е напълно валидно средство.

В средносрочен и дългосрочен план, разбира се, националната схема за електронна идентификация (по известно като „чип в личните карти“, макар всъщност да е повече от това) е задължителна за постигане на масовост и достъпност, особено за българи в чужбина. Но за целите на експертиментите, а дори и на първите гласувания, квалифицираният електронен подпис е съвсем подходящо средство. Да, струва пари, но електронното гласуване е само още един канал за гласуване – ако няматате електронен подпис и не искате да си купувате само заради гласуването (60-тина лева е за три години), хартията винаги ще бъде там. Т.е. нма дискриминационен фактор.

Електронната идентифиакция пък се бави, защото изглежда в МВР личните карти са „горещ картоф“ и вземането на решение да се обяви поръчка не е лесно. През април това щеше да стане „всеки момент“. Но хубавите неща отнемат време (и бързата работа – срам за майстора).

Също така е вярно, че за да има електронно гласуване, трябва парламентът да измени изборният кодекс (след отчитане на проведените експертименти), за да направи електронното гласуване обвързващо. Но е важно да отбележим, че за да се изгради системата за електронно гласуване няма нужда да се чака електронната идентификация. Системата може да се свърже с един модул (еАвт) в Държавна агенция „Електронно управление“, който оперира по същите стандартни протоколи, по които е предвидено да оперира както нашата електронна идентификация, така и трансграничната такава, така че граждани на ЕС да могат да позлват наши електронни услуги с техния местен електронен идентификатор.

Това би позволило, при желание, на евроизборите да се гласува експериментално с електронни подписи. (И не, няма да гласуваме с банкова карта, както бяха писали някои медии – банковата карта, макар да има подходящ за целта чип, не е предвидена за нищо друго, освен за потвърждаване на идентификацията, т.е. за т.нар. „втори фактор“).

А за да отговоря на въпроса в заглавието в духа на „Улицата“ – „ще има, ама друг път“. За евроизборите няма да могат да бъдат спазени сроковете. За местните – само при много силно политическо желание за това. А не трябва да забравяме, че технологията трябва да се тества. Защото опитът на други държави (като напр. Норвегия) показва, че малки и тривиални грешки обръщат каруцата и рушат доверието.

През 2019-та политическата класа ще опита да си измие ръцете с ЦИК. Но реалността е, че ЦИК е само изпълнител. А за последните две години никой в законодателната власт и политическия „елит“ не е направил стъпка към това да има електронно гласуване. Мълчанието по темата и оставянето ѝ по течението на административните процедури е това, което ще доведе до забавянето. Защото ако имаше политическо желание, нямаше да се чака по 6-7 (или в случая с електронната идентификация – 12-13) месеца в чудене „да напишем ли тоя проект“ и „да пуснем ли тая поръчка“.

Все пак, да завършва с оптимизъм – електронно гласуване ще има. Системата, която се изгради, ще може да се използва при първото проявления на митичната политическа воля. И без възможност за оправдания „ама то е много дълъг процес“.

Implementing White-Labelling

Post Syndicated from Bozho original https://techblog.bozho.net/implementing-white-labelling/

Sometimes (very often in my experience) you need to support white-labelling of your application. You may normally run it in a SaaS fashion, but some important or high profile clients may want either a dedicated deployment, or an on-premise deployment, or simply “their corner” on your cloud deployment.

White-labelling normally includes different CSS, different logos and other images, and different header and footer texts. The rest of the product stays the same. So how do we support white-labelling in the least invasive way possible? (I will use Spring MVC in my examples, but it’s pretty straightforward to port the logic to other frameworks)

First, let’s outline the three different ways white-labelling can be supported. You can (and probably should) implement all of them, as they are useful in different scenarios, and have much overlap.

  • White-labelled installation – change the styles of the whole deployment. Useful for on-premise or managed installations.
  • White-labelled subdomain – allow different styling of the service is accessed through a particular subdomain
  • White-labelled client(s) – allow specific customers, after logging in, to see the customized styles

To implement a full white-labelled installation, we have to configure a path on the filesystem where the customized css files and images will be placed, as well as the customized texts. Here’s an example from a .properties file passed to the application on startup:

styling.dir=/var/config/whitelabel
styling.footer=&copy;2018 Your Company
styling.logo=/images/logsentinel-logo.png
styling.css=/css/custom.css
styling.title=Your Company

In spring / spring boot, you can server files from the file system if a certain URL pattern is matched. For example:

@Component
@Configuration
public class WebMvcCustomization implements WebMvcConfigurer {
  @Value("${styling.dir}")
  private String whiteLabelDir;

  @Override
  public void addResourceHandlers(ResourceHandlerRegistry registry) {
    registry.addResourceHandler("/whitelabel/**").addResourceLocations(whiteLabelDir);
  }
}

And finally, you need to customize your HTML templates, but we’ll get to that at the end, when all the other options are implemented as well.

Next, are white-labelled subdomain. For me this is the best option, as it allows you to have a single installation with multiple customers with specific styles. The style depends solely on the domain/subdomain the service is accessed through.

For that, we’d need to introduce an entity, WhitelabelStyling and a corresponding database table. We can make some admin UI to configure that, or configure it directly in the database. The entity may look something like this:

@Table("whitelabel_styling")
public class WhitelabelStyling {
    @PrimaryKey
    private String key;
    @Column
    private String title;
    @Column
    private String css;
    @Column
    @CassandraType(type = DataType.Name.BLOB)
    private byte[] logo;
    @Column
    private String footer;
    @Column
    private String domain;

   // getters and setters
}

The key is an arbitrary string you choose. It may be the same as the (sub)domain or some other business-meaningful string. The rest is mostly obvious. After we have this, we need to be able to serve the resources. For that we need a controller, which you can see here. The controller picks up a white-label key and tries to load the corresponding entry from the database, and then serves the result. The controller endpoints are in this case /whitelabel-resources/logo.png and /whitelabel-resources/style.css.

In order to set the proper key for the particular subdomain, you need a per-request model attribute (i.e. a value that is set in the model of all pages being rendered). Something like this (which refreshes the white-label cache once a day; the cache is mandatory if you don’t want to hit the database on every request):

@ModelAttribute("domainWhitelabel")
public WhitelabelStyling perDomainStyling(HttpServletRequest request) {
    String serverName = request.getServerName();
    if (perDomainStylings.containsKey(serverName)) {
        return perDomainStylings.get(serverName);
    }
    return null;
}

@Scheduled(fixedRate = DateTimeConstants.MILLIS_PER_DAY)
public void refreshAllowedWhitelabelDomains() {
     perDomainStylings = whitelabelService.getWhitelabelStyles()
            .stream()
            .collect(Collectors.toMap(WhitelabelStyling::getDomain, Function.identity()));
}

And finally, per-customer white-labeling is achieved the same way as above, using the same controller, only the current key is not fetched based on request.getServerName() but on a property of the currently authenticated user. An admin (through a UI or directly in the database) can assign a whitelabel key to each user, and then, after login, that user sees the customized styling.

We’ve seen how the Java part of the solution looks, but we need to modify the HTML templates in order to pick the customisations. A simple approach would look like this (using pebble templating):

{% if domainWhitelabel != null %}
  <link href="/whitelabel-resources/style.css?key={{ domainWhitelabel.key }}" rel="stylesheet">
{% elseif user.whitelabelStyling != null and user.whitelabelStyling.css != '' %}
  <link href="/whitelabel-resources/style.css" rel="stylesheet">
{% elseif beans.environment.getProperty('styling.dir') != '' and beans.environment.getProperty('styling.css.enabled') == true %}
  <link href="{{'/whitelabel/'+  beans.environment.getProperty('styling.css')}}" rel="stylesheet">
{% else %}
  <link href="{{ beans.environment.getProperty('styling.css')}}" rel="stylesheet">
{% endif %}

It’s pretty straightforward – if there’s a domain-level white-labelling configured, use that; if not, check if the current user has specific white-label assigned; if not, check if global installation white-labelling is configured; if not, use the default. This snippet makes use of the WhitelabelController above (in the former two cases) and of the custom resource handler in the penultimate case.

Overall, this is a flexible and easy solution that shouldn’t take more than a few days to implement and test even on existing systems. I’ll once again voice my preference for the domain-based styles, as they allow having the same multi-tenant installation used with many different styles and logos. Of course, your web server/load balancer/domain should be configured properly to allow subdomains and let you easily manage them, but that’s offtopic.

I think white-labelling is a good approach for many products. Obviously, don’t implement it until the business needs it, but have in mind that it might come down the line and that’s relatively easy to implement.

The post Implementing White-Labelling appeared first on Bozho's tech blog.

5 Features Eclipse Should Copy From IntelliJ IDEA

Post Syndicated from Bozho original https://techblog.bozho.net/5-features-eclipse-should-copy-from-intellij-idea/

Eclipse Photon has been released a few days ago, and I decided to do yet another comparison with IntelliJ IDEA. Last time I explained why I still prefer Eclipse, but because my current project had problems with Java 9 in Eclipse initially, I’ve been using IntelliJ IDEA in the past half a year. (Still using Eclipse for everything else; partly because of the lack of “multiple projects in one workspace” in IDEA).

This time, though, the comparison will be the other way around – what IDEA features I’d really like to have in Eclipse; features that make work much easier and way more efficient. (Btw, what’s the proper short version to use – IntelliJ? IDEA?)

Isn’t that a departure from my stance “Eclipse is better”? No – I don’t believe there’s a perfect IDE (or perfect anything, for that matter), so any product can try to get the best aspects of the competition. Here I’ll focus on five features of IDEA where Eclipse lags behind.

First, the “Find in path” dialog. The interactivity of the dialog, the fact that you see all the results while typing and being able to navigate the results with the arrows is huge. Compare that to Eclipse’s clunky Search dialog, which (while pretty powerful), has a million tabs (rarely focused on the one you need) and then you actually click “Search” to get a list of results in a search panel, where you double-click in order to see the context…it’s just bad compared to IDEA.

Second is suggesting static imports. Static imports are not used too often, except in tests. Mockito, Hamcrest, test utility methods – in every class you need dozens of static imports. And Eclipse feels miserable with those – you manually go and import the methods you need, then organize imports and suddenly you need another one, and the .* you naively added has been changed to particular imports, so once again, you have to go and manually import. In contrast, IDEA just suggest the most relevant static import in the autocomplete pop-up and handles that for you.

Third is autocomplete. IDEA autocomplete triggers automatically when you start typing; in Eclipse it only triggers after a dot – otherwise you have to CTRL+space. And yes, I know there’s auto-activation setting where you can configure symbols that trigger the auto-complete, but as I’ve previously complained about IDEA’s defaults, it’s Eclipse’s turn. And it’s not even a checkbox – you have to actively type the entire alphabet, lower and upper case, in order to get it working – that’s just bad design. In what scenario would I need autocomplete on a,b,c but not on d,e,f??

Fourth is lambda simplification. You sometimes end up with pretty long chain of calls on a stream and they may not be the best way to express what you want. IDEA can suggest improvements so that it is more readable and easier to understand while achieving the same result. As a bonus, you eventually start doing this simplifications yourself.

Fifth – parameter labels. When you call a method foo.bar("Some string", 0, true) it’s not exactly obvious what the parameters are. And while you can rightly argue that this is a bad method signature, primitive (+String) parameters where you just pass a value happen every now and then, and it’s useful to see the name of the parameter at the point of method invocation. IDEA nicely shows that.

There are certainly more things that each of the IDEs can copy from the other one. Hopefully this competition will continue and result in improving both.

The post 5 Features Eclipse Should Copy From IntelliJ IDEA appeared first on Bozho's tech blog.

Авторско право и свободен интернет

Post Syndicated from Bozho original https://blog.bozho.net/blog/3139

Отдавна защитата на авторското право е в привиден конфликт със свободния интернет. Законодатели неведнъж са опитвали да помогнат на правоносителите чрез налагане на технологични ограничения в интернет. Преди години това беше ACTA, която извади на протест хиляди хора в Европа.

В последната година Европейският парламент и Съветет на ЕС обсъждат нова такава мярка, като дебатите кулминираха миналата седмица в решение на правна комисия да подкрепи текстовете, които налагат изискване за филтриране на съдържание при неговото качване онлайн.

Преди време бях писал за проблемите с това и за някои практически предложения за компромис. Опити за компромис имаше от много страни, но такъв не изглежда да е постигнат. В приетото решение на правната комисия, макар и доста витиевато и трудно разбираемо, се казва именно това – доставчиците на услуги по предоставяне на съдържание (като YouTube, но дефиницията може да бъде тълкуване и доста по-широко) са длъжни да филтрират съдържанието при неговото качване като го сравняват с налична база данни от защитени от авторско право творби.

Какъв е проблемът с това? Всичко, което качваме онлайн – собствени творби, домашни изпълнения на известни творби, пародии, видеа от събития, но също така и политически коментари и видеа, изразяващи мнение по даден въпрос, ще минават през филтъра, и ако правоносителят не е посочил друго, няма изобщо да бъдат допускани за публикуване. „Алгоритмична цензура“ може би е малко пресилено, но ще има немалко случаи на именно това.

Да, в момента YouTube разполага с такава технология и тя е далеч от перфектна. Примери за свалени поради уж нарушения на авторски права има много – от комичното сваляне на записа на правителствената конференция „Данни канят“, защото за няколко секунди заместник министър пуска сцена от филма „Дами канят“, до по-сериозни проблеми, като сваляне на видеа на опозиционни партии и активисти (в Русия, в Украйна и за съжаление – у нас).

Проблемът със свободата на изразяване а е най-големият, но не единственият. За платформи, различни от гигантите (като YouTube и Spotify, напр.), цената за реализиране на такава технология ще бъде твърде висока. Европейската комисия твърди, че е направила проучване… и е намерила едно комерсиално достъпно решение, чийто лиценз обаче не е ясно колко струва. Друг голям проблем за по-малките и съответно за свободния пазар е това, че правоносителските организации отказват да предоставят съдържанието си, така че да може да бъде извършено сравнение. Т.е. доставчикът на услугата има задължение да взема мерки за сваляне, но няма възможност да го направи.

А като така или иначе в момента такива алгоритми има, какъв е проблемът на новата директива? Проблемът е, че обръща режимът на отговорност. До момента, съгласно директивата за електронна търговия, доставчиците на услуги нямаха отговорност да правят нищо със защитено от авторско право съдържание до момента, в който не получат искане от правоносителя. С новата директива задължението е априори – ако не филтрираш съдържание, не спазваш закона. Това, разбира се, ще доведе до по-консервативни алгоритми, по-агресивно филтриране, „за всеки случай“.

Давам пример с YouTube, но това ще важи за текст, снимки, и др. А там проблемите ще са най-разнообразни. Например има риск т.нар. memes няма да могат да бъдат качвани изобщо, тъй като нарушават нечие авторско право. Наскоро четох статия как Фолксваген е поискал сваляне на рисунки на бръмбари, защото нарушавали правата на „Volkswagen Beetle“ (тук не става въпрос точно за авторско право, но все пак е в полето на интелектуалната собственост и примерът е доста показателен). Несъвършени алгоритми, невнимателни юридически отдели, злонамерен конкуренти или репресивни държавни органи – причините за неправомерно сваляне на съдържание са много. И понякога жертви са именно авторите – има редица примери на свалено авторско съдържание, защото алгоритъмът е решил, че то е нечие (напр. при използване на бийтове, за които можеш да си платиш и да включиш в твое произведение – първият, използвал даден бийт може да сваля произведенията на всички останали).

И всичко това тръгва от грешното допускане, че творците не искат създаденото от тях да се гледа/слуша. Защо някой би въвел такъв строг режим на автоматично сваляне, при положение че (по данни на YouTube) в 98% от случаите на засечено авторско съдържание, правоносителите са избирали опцията „монетизирай“, т.е. да вземат пари от показаната реклама при гледане а това съдържание. Фокусът на такова законодателство би следвало да бъде именно такъв – как съдържанието да се монетизира. В много редки случаи някой изобщо има интерес то да не бъде гледано (напр. ако изтече преди премиера/представяне). Ако вместо да мисли как да решава несъществуващи проблеми, законодателят (в случая – Европейската комисия) беше опитал да даде механизми за получаване на справедливо възнаграждение, нямаше да имаме спор. И да, текстът на директивата предвижда лицензионни споразумения, с които се уреждат отчисленията, но алтернативите не трябва да са „лицензионни споразумения или сваляне“. Има много други опции, от които биха спечелили и авторите, и интернет-потребителите.

Има и доста други технологични опции – придържане към сегашния режим на сваляне след известия от страна на правоносителя, но по по-автоматизиран начин и то такъв, който нито натоварва платформите и уебсайтовете, нито работи като „филтър“. Сегашните текстовете, за съжаление, ще циментират големите доставчици като Google (защото никой друг няма да може да поеме риска от дела затова, че не е сложил достатъчно агресивни филтри)

Член 13 не е единствената глупост в текста на директивата. Член 11, т.нар. „такса линк“ е друго гениално творение, с което уж да се защитят медиите, които произвеждат съдържание. Грубо казано, всеки, на чийто сайт се споделя линк и откъс от дадена новина, ще дължи такса на медията, към чийто сайт води. Би било нарушение ако споделя новина във Facebook и копирам два-три абзаца от нея. Съответно Facebook ще трябва да ми блокира публикацията.

И тук стигаме до фундаменталния проблем с тези предложения, а и с редица други (като напр. известието за ползване на бисквитки) – когато липсват технически грамотни хора във формулирането на политики, свързани с дигиталния свят, тези политики са лоши. В случая с директивата за авторското право лобистите на правоносителските организации (основно френски и немски) са превзели съзнанието на еврокомисарите и евродепутатите и там вече няма място за технологична адекватност. А ако имаше такава, можеше да се достигне до доста по-умни компромиси и в двата случая. Техническата грамотност на евродепутатите, подкрепили предложенията, мога да обобщя с туит на френския евродепутат Жан Мари Кавада, който нарече интернет „дигитална джунгла“.

Това не е краят на интернет, разбира се. Но такива необмислени и късогледи стъпки не помагат на никого. Гласуването в правната комисия не е и краят на дебатите. Следват много, много стъпки – комисията предлага парламентът да приеме мандат за преговори по директивата, така че да отиде на среща със Съвета и с Европейската комисия (триалог) и да се уточнят финалните текстове. Съветът, в същото време (който ще председателстваме още 5 дни), трябва да излезе със своя версия. За съжаление в нашето председателство не се случи кой знае какво по тази тема, така че Австрийското председателство ще води този процес. Европейската комисия също има роля, в лицето на Мария Габриел. Тя, за съжаление, следва оставеното от Йотингер, който често е бил в ролята на проводник на интересите на немски корпорации и организации.

В предстоящата неяснота можем да питаме нашите евродепутати как ще гласуват, да поискаме от нашия еврокомисар да подходи адекватно към бъдещ компромис, и да поискаме от нашите представители в Съвета на ЕС (в случая – министъра на културата) да не допускат интернет да бъде „счупен“ по такъв начин.

Моето лично мнение е, че тези текстове трябва да отпаднат изцяло и да бъдат започнати наново от следващата Европейска комисия, тъй като не изглежда да смислено решение на хоризонта – всички са се окопали в позициите и сме в хипотеза на „фалшива дилема“ – уж трябва да избираме между правата на творците и свободата на интернет. А това не е така – можем да имаме и двете, стига да има по-информирана дискусия и по-малко технически неграмотни лобисти.

Electronic Signatures Using The Browser

Post Syndicated from Bozho original https://techblog.bozho.net/electronic-signatures-using-the-browser/

Sometimes, especially in government or enterprise context, you need to sign a document in the browser using a smartcard (some may call it “crypto token”). It’s rare, but many people have asked me, in private messages and emails, how to do it. Maybe they’ve seen some of my articles from several years ago, but failed to make it work. And my articles show the evolution (or devolution) of in-browser electronic signing.

First it was possible with javascript, then I even created a library to make things easier. Then CAPICOM and window.crypto were deprecated, so the only option was to use a Java applet. Then Java applets were deprecated and we were out of options. We got the web crytpo API, but it explicitly didn’t support hardware tokens.

For that reason, I wrote a “plea” for smartcard support in browsers, but it hasn’t happened yet and probably won’t in the near future. So what can we do now, that all previous options are deprecated?

A good approach is to have a one-time installation of some custom software (it could be a Java Web Start application or a Java-independent application), which runs a local service that listens to a particular port, and then a javascript library that sends the data to be signed to http://localhost:1234/sign and gets the response. There are such solutions available, notably NexU (thanks to efforts put in the DSS package). There are other attempts, such as this one, using Java Web Start (it’s currently not in English).

You can try NexU’s demo here. It’s also included in the dss-demo-webapp project.

It has some tricky bits that have been recently resolved in browsers, namely, that in order to send an XMLHTTPRequest to the local service, it has to run on HTTPS, and therefor you have to package a private key in your applications (which goes against the requirements of many Certificate Authorities). Now, as far as I know, localhost is exempt from that requirement.

I hope I don’t have to write yet another article in two years explaining that this approach is superseded by yet another hacky approach.

The post Electronic Signatures Using The Browser appeared first on Bozho's tech blog.

Storing Encrypted Credentials In Git

Post Syndicated from Bozho original https://techblog.bozho.net/storing-encrypted-credentials-in-git/

We all know that we should not commit any passwords or keys to the repo with our code (no matter if public or private). Yet, thousands of production passwords can be found on GitHub (and probably thousands more in internal company repositories). Some have tried to fix that by removing the passwords (once they learned it’s not a good idea to store them publicly), but passwords have remained in the git history.

Knowing what not to do is the first and very important step. But how do we store production credentials. Database credentials, system secrets (e.g. for HMACs), access keys for 3rd party services like payment providers or social networks. There doesn’t seem to be an agreed upon solution.

I’ve previously argued with the 12-factor app recommendation to use environment variables – if you have a few that might be okay, but when the number of variables grow (as in any real application), it becomes impractical. And you can set environment variables via a bash script, but you’d have to store it somewhere. And in fact, even separate environment variables should be stored somewhere.

This somewhere could be a local directory (risky), a shared storage, e.g. FTP or S3 bucket with limited access, or a separate git repository. I think I prefer the git repository as it allows versioning (Note: S3 also does, but is provider-specific). So you can store all your environment-specific properties files with all their credentials and environment-specific configurations in a git repo with limited access (only Ops people). And that’s not bad, as long as it’s not the same repo as the source code.

Such a repo would look like this:

project
└─── production
|   |   application.properites
|   |   keystore.jks
└─── staging
|   |   application.properites
|   |   keystore.jks
└─── on-premise-client1
|   |   application.properites
|   |   keystore.jks
└─── on-premise-client2
|   |   application.properites
|   |   keystore.jks

Since many companies are using GitHub or BitBucket for their repositories, storing production credentials on a public provider may still be risky. That’s why it’s a good idea to encrypt the files in the repository. A good way to do it is via git-crypt. It is “transparent” encryption because it supports diff and encryption and decryption on the fly. Once you set it up, you continue working with the repo as if it’s not encrypted. There’s even a fork that works on Windows.

You simply run git-crypt init (after you’ve put the git-crypt binary on your OS Path), which generates a key. Then you specify your .gitattributes, e.g. like that:

secretfile filter=git-crypt diff=git-crypt
*.key filter=git-crypt diff=git-crypt
*.properties filter=git-crypt diff=git-crypt
*.jks filter=git-crypt diff=git-crypt

And you’re done. Well, almost. If this is a fresh repo, everything is good. If it is an existing repo, you’d have to clean up your history which contains the unencrypted files. Following these steps will get you there, with one addition – before calling git commit, you should call git-crypt status -f so that the existing files are actually encrypted.

You’re almost done. We should somehow share and backup the keys. For the sharing part, it’s not a big issue to have a team of 2-3 Ops people share the same key, but you could also use the GPG option of git-crypt (as documented in the README). What’s left is to backup your secret key (that’s generated in the .git/git-crypt directory). You can store it (password-protected) in some other storage, be it a company shared folder, Dropbox/Google Drive, or even your email. Just make sure your computer is not the only place where it’s present and that it’s protected. I don’t think key rotation is necessary, but you can devise some rotation procedure.

git-crypt authors claim to shine when it comes to encrypting just a few files in an otherwise public repo. And recommend looking at git-remote-gcrypt. But as often there are non-sensitive parts of environment-specific configurations, you may not want to encrypt everything. And I think it’s perfectly fine to use git-crypt even in a separate repo scenario. And even though encryption is an okay approach to protect credentials in your source code repo, it’s still not necessarily a good idea to have the environment configurations in the same repo. Especially given that different people/teams manage these credentials. Even in small companies, maybe not all members have production access.

The outstanding questions in this case is – how do you sync the properties with code changes. Sometimes the code adds new properties that should be reflected in the environment configurations. There are two scenarios here – first, properties that could vary across environments, but can have default values (e.g. scheduled job periods), and second, properties that require explicit configuration (e.g. database credentials). The former can have the default values bundled in the code repo and therefore in the release artifact, allowing external files to override them. The latter should be announced to the people who do the deployment so that they can set the proper values.

The whole process of having versioned environment-speific configurations is actually quite simple and logical, even with the encryption added to the picture. And I think it’s a good security practice we should try to follow.

The post Storing Encrypted Credentials In Git appeared first on Bozho's tech blog.

За едно дарение

Post Syndicated from Bozho original https://blog.bozho.net/blog/3132

През седмицата компанията, която стартирах преди шест месеца, дари лицензи на Държавна агенция „Електронно управление“ за използване (без ограничение във времето) на нашия софтуер, LogSentinel. В допълнение на прессъобщенията и фейсбук анонсите ми се иска да дам малко повече детайли.

Идеята за продукта и съответно компанията се роди няколко месеца след като вече не бях съветник за електронно управление. Шофирайки няколко часа и мислейки за приложение на наученото в последните две години (за блокчейн и за организационните, правните и техническите аспекти на големите институции) реших, че на пазара липсва решение за сигурна одитна следа – нещо, към което да пращаш всички събития, които са се случили в дадена система, и което да ги съхранява по начин, който или не позволява подмяна, или подмяната може да бъде идентифицирана изключително бързо. Попрочетох известно количество научни статии, написах прототип и след няколко месеца (които прекарах в Холандия) формализирахме създаването на компанията.

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

В един момент решихме (със съдружниците ми), че държавата би имала полза от такова решение. Така или иначе сигурната одитна следа е добра практика и в немалко европейски нормативни актове има изисквания за такава следа. Не че не може да бъде реализирана по други начини – може, но ако всеки изпълнител пише отделно такова решение, както се е случвало досега, това би било загуба на време, а и не би било с такова ниво на сигурност. Пилотният проект е за интеграция със системата за обмен на данни между системи и регистри (т.е. кой до какви данни е искал достъп, в контекста на GDPR), но предстои да бъдат интегрирани и други системи. За щастие интеграцията е лесна и не отнема много време (ако се чудите как ни излиза „сметката“).

Когато журналист от Дневник ме пита „Защо го дарявате“, отговорът ми беше „Защо не?“. Така или иначе сме отделили достатъчно време да помагаме на държавата за електронното управление, не само докато бяхме в Министерски съвет, но и преди и след това, така че беше съвсем логично да помогнем и не само с мнения и документи, а и с това, което разработваме. Нямам намерение да участвам в обществени поръчки, които и да спечеля честно, винаги ще оставят съмнения, че са били наредени – хората до голяма степен с право имат негативни очаквания, че „и тоя си постла да намаже от държавния пост“. Това не е случаят и не искахме да има никакви съмнения по въпроса. Основният ни пазар е частният сектор, не обществените поръчки.

Даряване на софтуер за електронно управление вече се е случвало. Например в Естония. Там основни софтуерни компоненти са били дарени. Е, след това фирмите са получавали поръчки за надграждане и поддръжка (ние нямаме такова намерение). Но благодарение на това взаимодействие между държава и частен сектор, в Естония нещата „потръгват“. Нашето решение не е ключов компонент, така че едно дарение няма да доведе значителни промени и да настигнем Естония, но със сигурност ще бъде от помощ.

Като цяло реакцията на дарението беше позитивна, което е чудесно. Имаше и някои разумни притеснения и критики – например защо не отворим кода, като сме прокарали законово изменение за отворения код. Както неведнъж съм подчертавал, изискването важи само за софтуер, чиято разработка държавата поръчва и съответно става собственик. Случаят не е такъв, става дума за лицензи на готово решение. Но все пак всички компоненти (библиотеки и др.) около продукта са с отворен код и могат да се ползват свободно за интеграция.

Не смятам, че сме направили геройство, а просто една позитивна стъпка. И е факт, че в следствие на тази стъпка продуктът ще получи малко повече популярност. Но идеята на председателя на ДАЕУ беше самото действие на даряване да получи повече популярност и съответно да вдъхнови други доставчици. И би било супер, ако компании с устойчиви бизнеси, дарят по нещо от своето портфолио. Да, работата с държавата е трудна и има доста непредвидени проблеми, а бизнесите работят за да печелят, не за да подаряват. Но допринасянето за по-добра среда е нещо, което бизнесите по света правят. Например в САЩ големи корпорации „даряват“ временно най-добрите си служители на USDS, станал известен като „стартъп в Белия дом“. При нас също има опция за такъв подход (заложена в Закона за електронно управление), но докато стигнем до нея, и даренията на лицензи не са лош подход.

Може би все още не личи отвън, но след промените в закона, които бяха приети 2016-та, електронното управление тръгна, макар и бавно, в правилна посока. Използване на централизирани компоненти, използване на едни и същи решения на няколко места (вместо всеки път всичко от нулата), централна координация на проектите. Нашето решение се вписва в този подход и се надявам да допринесе за по-високата сигурност на системите в администрацията.