Eiropas mākoņdatošanas jautājums nav par to, kur atrodas serveris
A location can be true and still leave the question open
There is a familiar moment in a cloud discussion. Somebody asks where the data will be stored. Somebody else answers with the name of a European city. The room relaxes a little. The answer may be perfectly accurate, and it may matter a great deal. Geography affects latency, physical security, electricity, resilience planning, employment, public accountability and the legal arrangements around a service. A public authority that needs particular records to remain within a stated territory has a proper reason to ask. The trouble starts when the city name is asked to settle every other question in the arrangement.
A server sits somewhere. A service does not. A service is a relationship among legal entities, people with administrator rights, software components, hardware suppliers, contracts, support teams, networks, encryption arrangements, subcontractors and the customer who depends on the result. The building is one material part of that relationship. It does not reveal who can issue a privileged instruction from elsewhere, which corporate group controls the operating company, which jurisdiction may reach a provider, whether a subprocessor has changed, or what the customer can carry away when the contract ends.
This is not an argument against European data centres or European providers. It is an argument against letting a useful answer do work that it cannot do. The European cloud question is not whether a server can be placed on European soil. It is whether the organisation using the service can understand and exercise enough control over the whole arrangement for the work at stake. Location belongs in that answer. It cannot be the whole answer, any more than a company address tells us who holds the keys to its accounts.
The distinction matters most where the cloud is doing ordinary, consequential work. A local government may hold correspondence, case records and public information in a hosted environment. A manufacturer may hold designs and operational data. A research group may hold a data set that cannot casually be moved. A hospital may use services that touch personal information. None of these examples requires a dramatic outage or a spy novel to become serious. The daily question is simpler: who has practical authority over a system that has become part of the organisation's ability to work?
European law and guidance increasingly treat this as a question of evidence, roles and switching rather than a question of reassuring vocabulary. The Data Act gives customers rights and providers duties around switching, exportable data and interfaces for data processing services. The EDPS has long said that European institutions using cloud services remain responsible for their data-protection obligations. ENISA's cloud risk work names lock-in and legal risk as matters to assess. These are not identical instruments, and they do not create a single cloud doctrine. Together, they point in a useful direction: control has to be described, not implied.
The map pin and the control plane
Cloud language often makes the distinction harder to see. The word cloud suggests a weather system: large, distant and perhaps unavoidable. In practice, a cloud service has a control plane and a working plane. The working plane is where a workload runs, data are stored, requests are processed and results are returned. The control plane is the set of mechanisms through which identities are managed, policies are changed, software is updated, capacity is assigned, support is provided, records are retrieved and systems are stopped or restored. Both planes may be technically distributed. Both can cross organisational boundaries.
A location statement usually speaks first about the working plane. It may say where a particular data store, virtual machine or region is located. That information should be specific enough to be useful. It should say what it covers, which data categories it concerns, how changes are notified, and whether backups, logs, support information and derived data follow the same rule. A claim that merely says Europe, without a boundary, is a starting point for a question rather than an answer. Europe is a large place, and service architecture is fond of exceptions.
The control plane asks a different series of questions. Who can create or remove an administrator? Who approves an emergency intervention? Who operates the identity service? Who can see diagnostic information? Which company maintains the software that makes the platform work? Which legal entity receives a request from an authority? Which subcontractor is allowed to handle support? Which party can change a service description or discontinue a feature? A customer may be able to log in every day and still have no independent route to answer any of them.
This does not mean that customers should expect to operate every physical device. They usually cannot, and most do not need to. The point is to make delegation visible. Delegated operation can be responsible and efficient when the delegated powers are defined, monitored and reversible. It becomes a sovereignty problem when the customer has only a contractual label for control while the provider retains the people, interfaces, records and technical knowledge needed to exercise it. A contract that cannot be used in practice is a decorative object with good typography.
For a buyer, the practical consequence is straightforward. Keep the location question. Add the control question beside it. Ask where the workload sits, then ask who can change its conditions. Ask where the data are processed, then ask who can reach the administrative route. Ask where the backup is held, then ask who can restore it and under which authority. The answers may be satisfactory. They may expose a dependency that has to be accepted deliberately. Either outcome is better than discovering that a pin on a map was doing the work of an operating model.
Ownership is not an administrative detail
Ownership is sometimes treated as a separate debate about flags, stock exchanges and national pride. It is more concrete than that. Ownership can determine who appoints the board, who approves a sale, who directs investment, who owns intellectual property, which group policies apply, and which entity ultimately decides whether a service remains a line of business. A customer does not need a simplistic rule that only one ownership structure is acceptable. It does need to know the structure before calling the arrangement independent.
Corporate organisation also affects what a cloud promise means. A brand can be local while the service is run by a different entity. A European subsidiary can contract with a European customer while a group elsewhere provides essential software, security operations, support, billing, data analytics or executive authority. A local partner may genuinely contribute valuable implementation work while depending on a platform that it cannot alter. None of these arrangements is automatically improper. They are different control arrangements, and they should not be made to look identical by a shared logo and a local telephone number.
The relevant question is not whether a buyer can find a foreign connection somewhere in a long supply chain. Modern technology is interconnected, and purity tests are not a procurement method. The question is where a dependency becomes decisive. Which entity can change the contract? Which entity controls the service's intellectual property? Which entity can make a support commitment? Which entity has the credentials or knowledge needed to recover the function? Which entity can be bought, sanctioned, reorganised or instructed in a way that changes the customer's position? Those are questions about actual leverage.
Ownership also changes. An acquisition, a funding round, a restructuring or an internal transfer can alter the control picture without moving a single server. A location clause written at signature may remain factually correct while the organisational facts around it have changed. That is why a serious cloud file needs a change process. The customer should know which change has to be disclosed, who will assess its effect, what evidence must be updated and which authority can pause a new data flow while the assessment is made. It is not glamorous work. Neither is checking the oil in a car, which is perhaps why people remember it after the engine complains.
In its 2018 cloud guidelines, the EDPS emphasised that EU institutions remain responsible for their data-protection obligations when they use cloud computing services and should secure an equivalent level of protection to other infrastructure models. That is not a demand that every institution own everything. It is a reminder that outsourcing a function does not outsource the duty to understand the arrangement. The duty makes ownership relevant because responsibility cannot be exercised through a diagram that omits the party with the practical power.
Legal reach is not erased by a European address
Jurisdiction is often the most uncomfortable layer because it resists the simple answer. A contract may select a governing law and a court. Those choices matter. They do not make other legal powers disappear. Legal reach may follow an entity, an establishment, a service provider, a corporate group, a person with access, a hardware vendor or the location and nature of particular data. The exact analysis depends on facts and law. A blog post cannot settle it for a real organisation, and a procurement template cannot replace proper advice where the risk is material.
The useful discipline is to separate a legal question from a geographic statement. A data centre in the European Union tells us where equipment is situated. It does not by itself tell us which entities can be compelled, which authorities might make a request, what notification is possible, or whether a provider has obligations under another legal order. Treating the two as equivalent can produce a false sense of closure. The buyer may have satisfied a residency requirement while leaving the legal analysis entirely unperformed.
The EDPB's final guidelines on the interplay between Article 3 GDPR and Chapter V international transfers are helpful precisely because they resist shortcuts. They distinguish the territorial scope of the GDPR from the question whether a processing operation is an international transfer. That distinction does not provide an all-purpose conclusion about every cloud arrangement. It does show why phrases such as EU-based or GDPR-covered cannot carry every legal inference a buyer may want to make. The data-protection analysis follows the actual processing and actors.
Datu akts ienes saistītu jautājumu mākoņpakalpojumu dokumentācijā. Tā VII nodaļa attiecas uz nelikumīgu starptautisku valdību piekļuvi un tādu ar personu nesaistītu datu pārsūtīšanu, kas glabājas Savienībā. Regula pieprasa datu apstrādes pakalpojumu sniedzējiem veikt atbilstošus tehniskus, organizatoriskus un juridiskus pasākumus, tostarp līgumiskus pasākumus, 32. panta aprakstītajos apstākļos. Tā nesola, ka pakalpojumu sniedzējs var panākt, ka katrs ārējs pieprasījums pazūd. Tā pieprasa disciplinētu reakciju uz konfliktu, kuru nevar novērst ar mārketinga terminu.
Klientiem tūlītējais darbs ir pierādījumu karte. Nosakiet līgumslēdzēju juridisko personu, pakalpojumu sniedzēja juridiskās personas, kas pārvalda būtiskas pakalpojuma daļas, vietas, kur notiek datu un administrācijas darbības, norādītās jurisdikcijas, pieprasījumu saņemšanas un apstrīdēšanas ceļu, paziņošanas nosacījumus un konkrētajai darba slodzei nepieciešamos juridiskos padomus. Atzīmējiet, kas ir zināms, ko norādījis piegādātājs, kas ir līgumiski apņemts un kas vēl jāizpēta. Karte ar datumu un nepilnību ir noderīgāka par mūžīgi aktuālu apliecinājuma rindkopu.
Operatīvā kontrole ir vieta, kur solījums kļūst īsts
Operatīvā kontrole ir spēja likt sistēmai kaut ko darīt vai pārtraukt to darīt, izmantojot noteiktu pilnvaru un mehānismu. Tā ietver ikdienišķas lietas: konta izveidi, tīkla politikas maiņu, atslēgas rotāciju, dublējuma atjaunošanu, laidiena apstiprināšanu, nomnieka izolēšanu, administratora atsaukšanu, žurnāla pārbaudi un ieraksta eksportēšanu. Neviena no šīm darbībām nav suverenitātes sertifikāts. Kopā tās parāda, vai klientam un pakalpojumu sniedzējam ir saprotama atbildības sadale.
Mākoņpakalpojumu vienošanās ir vāja, ja katra būtiska darbība beidzas ar e-pastu uz vispārīgu atbalsta adresi. Atbalsts ir svarīgs, un ekspertu atbalsts var būt viens no labiem iemesliem izmantot pārvaldītu pakalpojumu. Taču kritiskai organizācijai būtu jānošķir atbalsta ceļš un pilnvaru ceļš. Atbalsta ceļš ir tas, kā pakalpojumu sniedzējs palīdz. Pilnvaru ceļš ir tas, kā klients var ierosināt, apstiprināt, novērot un reģistrēt darbību, par kuru tas joprojām ir atbildīgs. Abi var satikties biļetē. Tos nedrīkst sajaukt.
Aplūkosim skaidri hipotētisku gadījumu. Eiropas pētniecības konsorcijs izmanto mitinātu analītisko vidi sensitīvam, bet likumīgam projektam. Tam ir līgums par Eiropas reģionu un dokumentēta datu atrašanās vieta. Iekšējās pārskatīšanas laikā konsorcijs vēlas apturēt konkrētu datu apstrādes cauruļvadu, saglabāt saistītos ierakstus un nepieļaut jauna datu avota pievienošanu, līdz pārskatīšana beidzas. Noderīgie jautājumi nav par to, vai iedomāts operators rīkojas varonīgi. Tie ir par to, vai konsorcijam ir noteikta loma, kas var dot rīkojumu par izmaiņām, vai platforma piedāvā kontrolētu mehānismu, vai darbība tiek reģistrēta un vai atkarīgās plūsmas ir redzamas pirms slēdža izmantošanas.
Hipotētiskais gadījums ir apzināti kluss, jo parastā pilnvara ir būtība. Pakalpojumam nav jākļūst nefunkcionējošam, lai klientam būtu nepieciešama kontrole. Privātuma pārskatīšana, mērķa maiņa, iepirkuma lēmums, līguma strīds, drošības bažas vai darbinieka aiziešana var prasīt ierobežotu darbību. Ja neviens nezina, kurš to drīkst veikt, vai ja klients nevar pārbaudīt, ko darbība izdarīja, problēma nav tā, ka mākonis ir noslēpumains. Problēma ir tā, ka darbības modelis nekad netika pabeigts.
Laba darbības kontrole ne vienmēr nozīmē centralizāciju. Liela iestāde pienākumus var sadalīt starp pakalpojuma īpašnieku, drošības lomu, datu aizsardzības funkciju, ekspluatācijas komandu un piegādātāju. Sadalījums var samazināt risku, ka viens cilvēks viens pats pieņem kaitīgu lēmumu. Svarīgi, lai pilnvaru robeža būtu skaidri redzama. Katrai lomai jāzina, ko tā drīkst uzsākt, ko tā drīkst apstiprināt, kas tai jāreģistrē, kad tai jāvēršas augstākā instancē un kā organizācija rīkojas, ja ierastais cilvēks nav pieejams. Mākonis nav atbrīvots no pārvaldības tikai tāpēc, ka tā informācijas panelis ir glīts.
Apakšuzņēmēju līnija ir daļa no pakalpojuma
Lielāko daļu mākoņpakalpojumu nesniedz viens uzņēmums, kas izmanto vienu ēku un vienu programmatūras kopu. Tajos var būt iesaistīti infrastruktūras nodrošinātāji, tīkla operatori, pārvaldīti drošības pakalpojumi, atbalsta partneri, maksājumu apstrādātāji, programmatūras uzturētāji, identitātes pakalpojumi, aparatūras ražotāji un specializēti apakšuzņēmēji. Sarežģīta ķēde nav pierādījums neveiksmei. Tā ir iemesls aprakstīt ķēdi. Klientam jāzina, kur sākas būtiskās atkarības, ko tās drīkst darīt un kā tiks paziņots par izmaiņām.
Datu aizsardzības vārdkopa par pārzini un apstrādātāju šeit ir noderīga, taču tā nedrīkst kļūt par izpratnes aizstājēju. Apstrādātāju saraksts var identificēt organizācijas, kas personas datus apstrādā piegādātāja vārdā. Tas var neatbildēt uz visiem ekspluatācijas jautājumiem par programmatūras piegādi, aparatūras atbalstu, attālo administrēšanu, telemetriju, incidentu reaģēšanu vai korporatīvo pilnvarojumu. Savukārt inženiertehniskais inventārs var identificēt komponentes, bet neparādīt, kam ir līgumisks pienākums pret klientu. Abi skatījumi jālasa kopā, nevis jāuztver kā konkurējoši dokumenti.
EDPS mākoņdatošanas vadlīnijas iesaka skaidri sadalīt pienākumus un pievērst uzmanību mākoņpakalpojumos iesaistīto pušu lomām. Šī praktiskā rūpe joprojām ir aktuāla, jo sarežģīti piegādes modeļi var radīt iespaidu, ka atbildība ir iztvaikojusi arhitektūrā. Tā nav. Kāds joprojām izlemj par apstrādes darbības mērķi. Kāds joprojām nosaka tehniskos nosacījumus. Kāds joprojām pieņem apakšuzņēmēju. Kādam joprojām ir jāpaskaidro, kas noticis, kad sistēma mainās. Sarežģītība var izskaidrot, kāpēc atbilde prasa laiku. Tā nepadara jautājumu par nepamatotu.
Ir noderīgs materiālitātes tests. Ja piegādātājs rīt pazustu no vienošanās, vai pakalpojums zaudētu funkciju, kas klientam nepieciešama, zaudētu drošības īpašību, zaudētu piekļuvi ierakstam vai zaudētu spēju pārvietoties? Ja atbilde ir jā, šis piegādātājs pieder kontroles kartē. Kartei nav jāatklāj katrs rezistors vai jāpadara publiskas visas komerciālās attiecības. Tai ir jāparāda atkarības, kas maina klienta spēju pārvaldīt darbu. Slēpta atkarība nav gudra abstrakcija. Tā ir nākotnes tikšanās ar nedaudz citādu toni.
Apakšuzņēmēju kontrole ir atkarīga arī no laika. Pircējam būtu jāzina, kā tiek ieviesti jauni apstrādātāji un būtiski ekspluatācijas piegādātāji, kāds paziņojums tiek sniegts, kāda iebildumu vai novērtēšanas procedūra tiek piemērota un kā izmaiņas tiek reģistrētas. Statisks saraksts ir labāks nekā nekāda saraksta. Aktuāls, pārskatāms saraksts ir labāks, jo tas atzīst, ka pakalpojums nav iesaldēts parakstīšanas brīdī. Organizācija nevar pārvaldīt atkarības, par kuru ienākšanu tai nav paziņots.
Aparatūrai ir sava politika un ekspluatācijas sekas
Analīzi ir vilinoši pārtraukt pie programmatūras saskarnes. Pakalpojums darbojas, informācijas panelis ir pareizajā valodā, līgumā minēts Eiropas reģions, un infrastruktūra zem tā šķiet pārāk attāla, lai būtu noderīga. Tomēr aparatūra un tās atbalsta ķēde var būt izšķiroša, ja svarīga ir pieejamība, konfidencialitāte, uzturēšana, remonts, jauda vai nepārtrauktība. Jautājums nav par to, vai klientam būtu jārevidē katra mikroshēma. Jautājums ir par to, vai klients zina, no kurām atkarībām ir atkarīgs izvēlētais pakalpojums un kas notiek, ja kāda no tām mainās.
Šeit ir vērts nošķirt suverenitātes centienus no pašpietiekamības. Eiropa piedalās globālajās piegādes ķēdēs. Neviena nopietna organizācija nevar saražot katru pusvadītāju, kabeli, serveri, programmaparatūras komponenti, operētājsistēmu un rīku vienas iepirkuma robežas ietvaros. Tas nebūtu arī saprātīgs slieksnis katrai darba slodzei. Praktiska suverenitāte ir spēja atpazīt atkarību, noteikt ap to nosacījumus, saglabāt alternatīvas tur, kur tās ir vajadzīgas, un neizlikties, ka neaizstājama ārēja komponente nav neaizstājama.
Aparatūras atkarības var ietekmēt mākoņa pārvaldību caur jaudas sadali, uzturēšanas piekļuvi, programmatūras atjauninājumiem, nomaiņas ceļiem un uzticamām komponentēm. Tās var ietekmēt arī migrācijas iespējamību. Darba slodze, kas veidota ap konkrētu pārvaldītu funkciju, īpašu paātrinātāja vidi vai nedokumentētu integrāciju, var būt tehniski pārnesama tikai tādā pašā nozīmē, kādā klavieres ir pārnesamas, ja kāds piedāvā tās nest augšā pa sešiem kāpņu laidumiem. Lietvārds ir pareizs. Plāns ir nepilnīgs.
ENISA mākoņa riska novērtējums tagad ir vecāka publikācija, bet tās brīdinājums par piesaisti, juridisko risku un kontroles zaudēšanu nav kļuvis novecojis. Tehniskā vārdnīca kopš tā parādīšanās ir mainījusies vairākas reizes. Pamatjautājums nav mainījies: ko klients zaudē, ja pakalpojums mainās, attiecības beidzas vai atkarība neuzvedas kā gaidīts? Riska novērtējums neprasa pircējam noraidīt katru pārvaldīto pakalpojumu. Tas prasa pircējam piesaistīt sekas atkarībām, pirms atkarība kļūst par ārkārtas situāciju.
Aparatūru apzinošs mākoņa dokuments var palikt samērīgs. Ierakstiet arhitektūru līmenī, kas ir svarīgs darba slodzei. Identificējiet vienīgās atkarības un vienīgos operacionālās zināšanu punktus. Norādiet līguma nosacījumus, kas ietekmē nepārtrauktību un migrāciju. Jautājiet, kurš atbalsta ceļš ir nepieciešams drošības atjauninājumiem vai atkopšanai. Pārbaudiet, vai nomaiņas videi ir vajadzīgas tās pašas patentētās komponentes. Mērķis nav muzeja katalogs. Tas ir prātīgs priekšstats par lietām, kurām jāpaliek pieejamām, lai organizācija varētu turpināt savu darbu.
Iziešana ir spēja, nevis lejupielādes poga
Visatklājošākais mākoņa jautājums bieži ir tas, kas notiek, kad klients vēlas aiziet. Aiziešana var nozīmēt pāriešanu pie cita pakalpojumu sniedzēja, funkcijas atgriešanu lokālā vidē, arhitektūras maiņu, pakalpojuma samazināšanu vai tā pārtraukšanu. Klients dažkārt var eksportēt datubāzi un joprojām nespēt atsākt pakalpojumu. Funkcija var būt atkarīga arī no konfigurācijas, identitātēm, atslēgām, žurnāliem, atļaujām, automatizācijas, modeļiem, novērtēšanas materiāliem, datu izcelsmes, integrācijas noteikumiem un operacionālajām zināšanām, kas liek daļām darboties kopā.
Datu akts šajā jautājumā ir neparasti konkrēts. Tā maiņas noteikumi prasa, lai līgumi noteiktu tiesības un pienākumus attiecībā uz maiņu un eksportējamo datu un digitālo aktīvu pārnesamību. Tas nosaka parasto maksimālo pārejas periodu 30 kalendārās dienas pēc attiecīgā paziņošanas perioda, vienlaikus atļaujot alternatīvu periodu noteiktos tehniskas neiespējamības gadījumos, ievērojot nosacījumus. Tas attiecas arī uz atvērtām saskarnēm un sadarbspēju. Regula dod pircējiem kaut ko vērtīgu: juridisku iemeslu jautāt par ceļu, pirms tas ir vajadzīgs.
The limits are just as important. The Data Act does not make every digital asset transferable, does not require a provider to disclose protected intellectual property or trade secrets, and does not guarantee functional equivalence at a destination. A provider can meet legal duties while a migration remains difficult. A buyer can have an export right while lacking the people, budget or destination needed to use it. This is why exit should be treated as a capability shared between contract, architecture and organisation, rather than a promise made by one line in an order form.
A credible exit file records the target service type, the data and assets that are exportable, their formats, the procedure for obtaining them, the expected continuity conditions, the retrieval period, the destination assumptions and the parts of the function that cannot simply move. It identifies who will validate that the exported material is usable. It records what logs and evidence must survive. It names the authority that can accept the switch or decide that it is not yet safe to complete. This is less exciting than a migration announcement. It is much more likely to make the announcement true.
Testing matters. A small, bounded exercise can reveal whether a format is merely available or actually usable, whether an identity can be recreated without altering permissions, whether a key can be transferred under the right authority, whether records retain their meaning, and whether a reduced service can continue while the full service moves. This is not a claim that every organisation must rehearse a complete cloud exit every month. The scope should reflect the consequence of interruption. It is a claim that an untested exit is an intention, not yet an option.
What a European cloud assessment should contain
A useful assessment begins by naming the function, not the supplier. What work is the service expected to support? What data, records, rights, continuity needs and public consequences are involved? A low-consequence collaboration tool and a system holding sensitive operational records do not need identical controls. Starting with the workload prevents an organisation from applying a large sovereignty label to a small and specific decision, or from treating a critical service as if it were another office subscription.
Then make a location statement with a boundary. State where the relevant working plane is expected to operate, what data categories it covers, which copies and diagnostics are included, which transfers are allowed, how the position is evidenced and how changes are notified. If the supplier can only make a broad regional statement, record that limitation. A buyer is allowed to distinguish between a precise commitment and a general commercial description. The distinction is not hostile. It is what contracts are for.
Next make an entity and authority map. Record the contracting entity, group entities with a material role, named processors or subprocessors where relevant, the roles that can administer the service, the escalation path, the identity and key arrangements, and the customer authority that remains after outsourcing. Include the legal and technical evidence that supports each entry. Do not write provider or customer where a particular entity, role or mechanism is known. General nouns are very good at concealing specific absences.
Pievienojiet atkarību karti. Tajā jāiekļauj būtiskā programmatūra, aparatūra, tīkls, atbalsts un integrācijas atkarības, katras izmaiņu ceļš un zaudējuma vai izmaiņu sekas. Tai nav jāprognozē nākotne. Tai ir jāpadara pašreizējais dizains apstrīdams. Ja atkarība ir pieņemama, pierakstiet, kāpēc. Ja tā nav pieņemama, norādiet atteikuma nosacījumu. Ja tā nav zināma, neatrisiniet neērtību, nosaucot to par zemu risku. Nezināms ir reāls statuss, un tas bieži vien nosaka nākamo darba posmu.
Visbeidzot pievienojiet iziešanas un pārskatīšanas ierakstu. Ietveriet piemērojamos līguma noteikumus, eksporta procedūras, veiktos testus, atrastās nepilnības, korektīvās darbības, pārskatīšanas datumu un notikumus, kas izraisa atkārtotu izvērtēšanu. Mērķis nav radīt perfektu mapi. Mērķis ir izveidot dzīvu kontroles uzskaiti, kas izdzīvo personāla maiņu, pakalpojuma atjauninājumu, līguma pagarināšanu un dienu, kad kādam ātri jāpieņem neērts lēmums. Pārskats, ko nevar atjaunināt, kļūst par vēsturi ar pievienotu rēķinu.
Ko publiskais iepirkums var prasīt, neizliekoties, ka atrisina visu
Publiskajiem pircējiem ir īpašs iemesls uzstāt uz šiem pierādījumiem, jo viņiem bieži ir pienākumi, kas nebeidzas, kad līgums ir parakstīts. Viņi var būt atbildīgi pilsoņu priekšā, pakļauti publisko ierakstu noteikumiem, atbildīgi par būtiskām funkcijām vai arī viņiem ir jāpaskaidro, kāpēc lēmums bija pamatots. Tas nenozīmē, ka publiskais iepirkums var novērst visas ārvalstu atkarības vai ka nacionālā izvēle ir tehniska novērtējuma aizstājējs. Tas nozīmē, ka iepirkums var uzdot jautājumus, kas padara vienošanos redzamu, pirms tā kļūst iesakņojusies.
Samērīgs iepirkums var prasīt norādīt subjektus, kas nodrošinās būtiskas pakalpojuma daļas, deklarētās ģeogrāfiskās un juridiskās robežas, lomu un pilnvaru modeli, apakšuzņēmēju maiņas procesu, atbalsta un incidentu maršrutu, klientam saglabātos pierādījumus, eksporta un pārslēgšanas procedūru, kā arī nosacījumus, saskaņā ar kuriem klients var apturēt, ierobežot vai pārtraukt lietošanu. Tas var vērtēt atbilžu kvalitāti, nevis apbalvot īpašības vārdu. Piegādātājs, kas pārzina savu darbības modeli, spēj to izskaidrot bez miglas mašīnas.
Pastāv kompromisi. Vairāk pierādījumu var pagarināt iepirkumu. Dažas prasības var samazināt piedāvājumu skaitu. Mazam pakalpojumu sniedzējam var būt mazāk iespēju sagatavot plašu dokumentāciju, pat ja tā kontroles modelis ir spēcīgs. Esošajam piegādātājam var būt lielisks tehniskais pakalpojums, bet iziešanas ceļš, kas jāsaskaņo. Tie nav argumenti, lai izlaistu jautājumus. Tie ir fakti, kas pircējam nepieciešami, lai izlemtu, kuras izmaksas ir pieņemamas: pierādījumu un alternatīvu izmaksas tagad vai atkarības izmaksas vēlāk.
Eiropas Komisijas darbs mākoņdatošanas suverenitātes jomā ir padarījis šo virzienu redzamu iepirkuma izteiksmē, bet pircējiem nav jāgaida universāla zīme. Viņi var noteikt savu riska robežu un pieprasīt pierādījumus, kas tai atbilst. Publiskā bibliotēka, pētniecības aģentūra, pilsētas departaments un kritiskās infrastruktūras operators neizmantos vienu un to pašu slieksni. Viņiem nevajadzētu. Pārbaude ir tāda, vai prasības atbilst funkcijai, ir godīgi publicētas, var tikt konsekventi novērtētas un saglabā klienta spēju izskaidrot savu izvēli.
Tas ir klusāks Eiropas mākoņpolitikas solījums. Tā var pārcelt sarunu prom no nacionālās piederības teātra un uz attiecību pārvaldību. Eiropas atbildei nav jābūt noslēgtai tehnoloģiskai salai. Tas var būt nobriedušāks tirgus, kurā apgalvojumi par atrašanās vietu, kontroli, tiesībām un iziešanu ir atsevišķi apgalvojumi, ko pamato atsevišķi pierādījumi. Savstarpējā atkarība nepazūd, kad to nosauc. Tā kļūst par kaut ko tādu, par ko var izlemt, kur tā ir pieļaujama.
Kontroles neatbild viena otrai
Ir vērts pretoties vēl vienam pēdējam īsceļam. Spēcīga šifrēšana neatbild uz īpašumtiesību jautājumu. Klienta rīcībā esošās atslēgas var samazināt konkrētus piekļuves riskus un var būt svarīga kontrole, taču tās pašas par sevi nenosaka, kas pārvalda pakalpojumu, kam ir kontrole pār platformu, kāda informācija paliek redzama metadatos vai vai klients var pārvietot funkciju. Laba iziešanas klauzula neatbild uz jurisdikcijas jautājumu. Eiropas mātesuzņēmums neatbild uz aparatūras atbalsta jautājumu. Katrai kontrolei ir savs uzdevums. Katra jāvērtē pēc tā, ko tā faktiski dara.
Tieši tāpēc lēmumam par mākoņpakalpojumiem vajadzētu spēt pateikt "nepietiek", nekļūstot teatrālam. Pircējs var secināt, ka apņemšanās par atrašanās vietu ir pietiekama, bet izmaiņu paziņošanas termiņš ir pārāk neskaidrs. Tas var pieņemt apakšapstrādātāju, bet prasīt skaidrāku pilnvaru ceļu. Tas var pieņemt ārvalstu aparatūras atkarību, vienlaikus uzstājot uz dokumentētu nomaiņas plānu. Tas var nolemt, ka konkrēts pakalpojums nav piemērots noteiktai datu kategorijai, bet joprojām ir piemērots citai. Nianses nav nespēja pieņemt lēmumu. Tās ir nosacījums, lai lēmumu pieņemtu, balstoties uz pierādījumiem, nevis zīmola atpazīstamību.
Darbs kļūst vieglāks, ja pierādījumi tiek turēti tuvu lēmumam. Nelieciet datu atrašanās vietas paziņojumu vienā sistēmā, līgumu citā, piekļuves pārskatu e-pasta pastkastē un iziešanas plānu kāda cilvēka atmiņā. Saistiet tos ar pakalpojuma ierakstu un piešķiriet ierakstam īpašnieku. Kad prasība mainās, organizācijai jāspēj atrast pierādījumus, noteikt skarto robežu un izlemt, vai pakalpojumu var turpināt. Tā ir pārvaldība tās nekrāšņākajā un visnoderīgākajā veidolā.
Īsa piezīme no mums
Mūsu ziņojumā The Sovereignty Illusion tiek izmantotas piecas praktiskas lēcas līdzīgam jautājumam: īpašumtiesības, tehnoloģija, kapitāls, infrastruktūra un juridiskā iedarbība. Tas ir mūsu pētniecības ietvars, nevis juridiska klasifikācija un nevis pierādījums, ka konkrēts pakalpojums atbilst klienta vajadzībām. Tā noderīgais ieguldījums ir uzmanības ieradums. Kad mākoņpakalpojumu apgalvojums izklausās pilnīgs, jautājiet, kuras no šīm lēcām tas patiesībā ir aptvēris un kuras paliek ārpus rāmja.
Šis ieradums veido arī to, kā mēs aprakstām savu darbu. Suverenitātes apgalvojums jāierobežo ar izvietošanu, līgumu un darbības atbildību, nevis jāuzpūš par solījumu, ko produkta lapa nevar izpildīt. Klients, darba slodze un saskaņotais kontroles modelis joprojām nosaka, ko var godīgi apgalvot. Jomā, kas pilna ar lieliem lietvārdiem, atturība nav mārketinga traucēklis. Tā ir daļa no pierādījumiem.
Jautājums pēc pilsētas nosaukuma
Eiropas atrašanās vieta joprojām ir vērts jautājums. Tā var būt juridiska prasība, darbības prasība, noturības izvēle, fiziskās drošības izvēle vai sabiedriskās atbildības izpausme. Pircējam nevajadzētu kaunēties jautāt, kur sistēma darbojas. Tam vienkārši jāuzdod jautājums kopā ar citiem. Kam pieder vienība, kurai ir nozīme? Kam ir darbības pilnvaras? Kuras tiesību sistēmas var sasniegt šo vienošanos? Kuri apakšuzņēmēji un komponenti ir būtiski? Ko klients var pārbaudīt, apturēt, pārvietot un saglabāt?
Šie jautājumi nepadara mākoņdatošanu mazāk noderīgu. Tie padara mākoņdatošanas izmantošanu apdomīgāku. Tie aizstāj pārliecības gaisotni ar failu, ko var pārskatīt. Tie sniedz piegādātājiem godīgu iespēju parādīt izveidotās kontroles un pircējiem godīgu veidu, kā atšķirt noderīgu ierobežojumu no tukša apgalvojuma. Pats svarīgākais, tie saglabā iespēju mainīt kursu, pirms atkarība pārvēršas apsūdzībā.
Eiropas mākoņdatošanas jautājums tātad nav par to, kur atrodas serveris. Tas ir par to, kur atrodas kontrole, kad sistēmai ir jāmainās. Datu centrs var būt daļa no atbildes. Eiropas līgums var būt daļa no atbildes. Eiropas pakalpojumu sniedzējs var būt daļa no atbildes. Atbilde kļūst ticama tikai tad, ja organizācija var izsekot ceļu no vietas līdz īpašumtiesībām, no īpašumtiesībām līdz juridiskajai darbības jomai, no juridiskās darbības jomas līdz darbības pilnvarām un no pilnvarām līdz pārbaudītam izejas ceļam. Šis ceļš nav tik viegli iegaumējams kā karogs pie ēkas. Tieši šeit arī sākas darbs.
Avoti
- Cloud Computing, Eiropas Datu aizsardzības uzraudzītājs. Izmantots EDPS mākoņdatošanas vadlīniju nostājai, ka ES iestādes joprojām ir atbildīgas par savām datu aizsardzības saistībām un tām jānodrošina līdzvērtīga aizsardzība.
- EDPB publishes three guidelines following public consultation, Eiropas Datu aizsardzības kolēģija, 2023. gada 24. februāris. Izmantots galīgo vadlīniju par VDAR 3. pantu un V nodaļas starptautiskajiem datu nosūtījumiem tvērumam un mērķim.
- Regulation (EU) 2023/2854 (Data Act), EUR-Lex. Izmantots datu apstrādes pakalpojumu maiņas, eksporta, nepārtrauktības, sadarbspējas un starptautiskās valdības piekļuves noteikumiem.
- Cloud Computing Risk Assessment, Eiropas Savienības Kiberdrošības aģentūra. Izmantots riska novērtējuma ietvaram attiecībā uz piesaisti, juridisko risku un kontroles zaudēšanu.
- The Sovereignty Illusion, Dweve. Izmantots tikai atklātajam Dweve piecu lēcu pētniecības ietvaram.