Kategori: Teknikbloggen

Här postas diskussioner och bloggar om teknik.

Schrems II i praktiken — vad sker när AWS Frankfurt får en CLOUD Act-begäran?

TL;DR: Schrems II-domen (CJEU C-311/18, juli 2020) ogiltigförklarade Privacy Shield och slog fast att data i USA inte har likvärdigt skydd som inom EU. Den centrala konsekvensen: en EU-baserad cloud-leverantör med amerikanskt moderbolag — AWS, Microsoft Azure, Google Cloud — kan tvingas lämna ut data till US-myndigheter via CLOUD Act eller FISA 702, även om hårdvaran står i Frankfurt eller Stockholm. SCC (Standard Contractual Clauses) löser inte problemet automatiskt. För svenska företag som hostar känslig data är moderbolagsjurisdiktion en separat faktor från fysisk dataplats.

Vad är Schrems II — kort

Max Schrems, österrikisk jurist och dataskyddsaktivist, drev sedan 2013 mål mot Facebooks dataöverföringar från EU till USA. Schrems I (2015) ogiltigförklarade Safe Harbor-avtalet. Schrems II (juli 2020) ogiltigförklarade dess efterföljare Privacy Shield. EU-domstolen slog fast att amerikansk lag — specifikt FISA Section 702 och Executive Order 12333 — ger US-myndigheter bred åtkomst till data hos amerikanska tjänsteleverantörer utan EU-likvärdig rättssäkerhet.

Konsekvensen: överföring av personuppgifter från EU till USA kräver ytterligare skyddsåtgärder utöver SCC, och i många fall är dessa praktiskt omöjliga att uppfylla.

CLOUD Act — den parallella historien

Clarifying Lawful Overseas Use of Data Act (USA, 2018) klarlägger att amerikanska brottsutredande myndigheter kan kräva data från amerikanska tjänsteleverantörer oavsett var data fysiskt lagras. AWS i Frankfurt, Microsoft Azure i Stockholm, Google Cloud i Belgien — alla omfattas av CLOUD Act eftersom moderbolagen är amerikanska.

Det här är skilt från Schrems II men förstärker problemet. Schrems II handlar om överföringar; CLOUD Act handlar om åtkomst till data som aldrig ”lämnar” EU.

Vad händer i praktiken vid en CLOUD Act-begäran?

Tre scenarier som faktiskt har inträffat eller är dokumenterade:

Scenario 1: Konkreta brottsutredningar

FBI eller DOJ kräver data från ett US-bolag som driver EU-datacenter. Bolaget kan välja att:

  • Lämna ut data direkt — i strid med GDPR men i enlighet med amerikansk lag
  • Bestrida via egen jurist (sällan framgångsrikt, dyrt)
  • Försöka få MLAT-process (mutual legal assistance treaty) — saktar ner men löser sällan principfrågan

Microsoft tappade sitt eget ”Microsoft Ireland”-fall (2018) som föranledde CLOUD Act från början. Sedan dess har juridiska invändningar mot CLOUD Act-begäran i praktiken slagits ner.

Scenario 2: Bulk-program enligt FISA 702

NSA:s PRISM-program ber stora US-cloudleverantörer regelbundet om data. Antalet begäran är hemligstämplat men Googles transparency report redovisar ~70 000 FISA-baserade begäran per halvår (2024-data). Begäran specificeras med ”selector” — vanligen e-postadress, telefonnummer eller IP.

Den drabbade individen får inte veta att begäran skett. Anställda hos cloud-leverantören som hanterat begäran får inte heller berätta (gag order).

Scenario 3: ”National Security Letter” (NSL)

FBI kan utfärda NSL utan domstolskontroll, med inbyggt sekretessförbud. Mottagaren — typiskt en ISP eller cloud-leverantör — får varken bekräfta eller förneka att de fått en NSL. Det här är vad många refererar till som ”warrant canary”-mekanismens motpol.

Räcker SCC eller egen kryptering?

EU-kommissionen publicerade uppdaterade SCC (Standard Contractual Clauses) 2021 som inkluderar Schrems II-aspekter. De fungerar — men endast om mottagarlandets lagstiftning faktiskt erbjuder likvärdigt skydd. För USA är det inte fallet enligt EU-domstolen. EDPB (European Data Protection Board) har därför rekommenderat ytterligare tekniska åtgärder:

  • Stark kryptering där nyckel hanteras i EU — bara om leverantören aldrig får tillgång till klartext
  • Pseudonymisering före överföring — där återidentifiering kräver information som lagras i EU
  • Splittrad lagring — där ingen single part har komplett dataset

Problemet: i många SaaS-tjänster (Office 365, Google Workspace, Salesforce) har leverantören tekniskt tillgång till klartext för att leverera funktioner som sök, ML, content-analys. Då fungerar inte E2E-kryptering som skyddsåtgärd.

Datainspektionen och Schrems II i Sverige

IMY (Integritetsskyddsmyndigheten, tidigare Datainspektionen) har varit relativt stillsam jämfört med franska CNIL och österrikiska DSB, men har:

  • 2021 — varnat svenska skolor för Google Workspace för Utbildning (efter klagomål från flera kommuner)
  • 2023 — granskat Microsoft Office 365-användning hos statliga myndigheter
  • 2024 — utfärdat tillsynsbeslut mot flera svenska företag för otillräcklig SCC-implementering

EU-domstolen har i flera nyare mål (Bindl v Commission 2025) bekräftat att ”ytterligare åtgärder” är ett krav, inte en rekommendation, vid överföringar till USA.

Vad innebär det här för svenska företag?

Beroende på datatyp och regulatoriskt sammanhang:

För personuppgifter i offentlig sektor

Skolor, sjukvård, statliga myndigheter: amerikanska SaaS-tjänster för känslig data är högrisk. Flera svenska kommuner har migrerat bort från Google Workspace och Microsoft Office 365 för specifika dataset. Egna datacenter eller EU-baserade leverantörer utan US-modernbolag (t.ex. tyska Hetzner, svenska Adminor, franska OVH) är säkrare alternativ.

För B2B-företag

Risken är lägre men inte noll. Om er affärsdata innehåller personuppgifter (HR, kunder, leads), så är CLOUD Act-exponering en relevant fråga. Det gäller särskilt om ni har avtal med statliga kunder eller annan reglerad sektor — de kommer fråga.

För känslig affärsdata utan personuppgifter

Källkod, finansiell data, kunddatabaser, drug discovery, R&D, patent-relaterad data: GDPR gäller inte direkt, men FCPA, säkerhetsskydd, och industri-specifik reglering kan göra US-exponering problematisk.

Vad gör man konkret?

Tre nivåer av åtgärder:

Nivå 1: Inventering

Lista alla SaaS/cloud-tjänster ni använder och deras moderbolagsland. AWS, GCP, Azure, Salesforce, Slack, GitHub, Atlassian (Confluence/Jira), Zoom = alla US-baserade. Datadog, MongoDB Atlas, Snowflake = US. Office 365 = US.

Nivå 2: Riskbedömning per system

Inte alla data är lika känslig. För varje system: vilken datatyp, vilken regulatorisk klassning, vilka skyddsåtgärder redan på plats. Det styr om migration är nödvändig eller om SCC + extra åtgärder räcker.

Nivå 3: Migration för kritiska system

För regulatoriskt känsliga system — finansiell journaling, hälsodata, statliga uppdrag — flytta till en EU-leverantör utan US-modernbolag. Helsvensk drift (Adminor, GleSYS, Bahnhof, Glesys, Resilans) eller EU-baserad utan US-exponering (Hetzner, OVH, Scaleway).

Vanliga frågor

Räcker det att hosta i AWS Frankfurt istället för us-east-1?
Nej. Fysisk dataplats inom EU eliminerar dataöverföringsproblematiken (Schrems II) men inte CLOUD Act-exponeringen. AWS-Frankfurt-data omfattas fortfarande av amerikansk jurisdiktion via moderbolaget.

Är ”EU-only” sovereign cloud från Microsoft eller AWS lösningen?
Microsoft ”EU Data Boundary” och AWS European Sovereign Cloud (annonserad 2024) försöker hantera detta genom strikt EU-personal och separata juridiska entiteter. Inget av initiativen har än så länge bedömts som tillräckligt av EDPB, eftersom moderbolagsrelationen kvarstår.

Är svenska AWS-kunder olagliga?
Nej, inte automatiskt. Det handlar om risknivå och tillämpliga skyddsåtgärder per datatyp. Men IMY kan i vissa fall förbjuda specifika överföringar om SCC + extra åtgärder inte räcker.

Vad är skillnaden mellan Schrems II och GDPR i sig?
GDPR är grundförordningen som styr databehandling inom EU. Schrems II är ett rättsfall som tolkat hur GDPR ska tillämpas vid överföringar till tredjeland (specifikt USA). Schrems II tillför inga nya regler — det förtydligar att existerande regler är striktare än många antagit.

Hur är det med UK efter Brexit?
EU-kommissionen har 2021 utfärdat adekvansbeslut för UK (motsvarande tidigare Privacy Shield), men det är skört. Flera dataskydds­organisationer driver mål för att få det ogiltigförklarat på samma sätt som Privacy Shield. Risk-medveten praxis: behandla UK som lågre-risk-tredjeland snarare än EU.

Sammanfattning

Schrems II och CLOUD Act tillsammans innebär att amerikanska cloud-leverantörers EU-datacenter inte ger samma dataskydd som EU-baserade leverantörer utan US-moderbolag. Det är inte en teknisk fråga — det är en juridisk. Stark kryptering hjälper för storage, men SaaS-tjänster med funktionsberoenden mot klartext är problematiska.

För svenska företag som driftar känslig data — personuppgifter i offentlig sektor, finansiell data, säkerhetsklassad data — är moderbolagsjurisdiktion en separat faktor från fysisk lagringsplats. Helsvenska eller EU-baserade leverantörer utan US-exponering minskar riskprofilen utan att kräva ändringar i den underliggande tekniska arkitekturen.

Adminor är ett helägt svenskt aktiebolag utan utländsk moderbolagsjurisdiktion. Era servrar hos oss — VPS, colocation eller dedikerade — lyder enbart under svensk och EU-lag. Inga CLOUD Act-begäran kan riktas mot oss, eftersom vi inte är amerikansk jurisdiktionssubjekt. Mer information på Adminor VPS och colocation.

Frågor om Schrems II, GDPR-compliance eller datasuveränitet för er specifika situation? Kontakta Adminor — vi har drivit svensk IT-infrastruktur sedan 1983 och hanterar dataskydds-känsliga kunder från offentlig sektor och regulerade branscher.

Hur fungerar RPKI — och varför ska svenska företag bry sig?

TL;DR: RPKI är en signaturmekanism för BGP — själva protokollet som styr hur Internet-trafik hittar vägen mellan operatörer. Utan RPKI kan vem som helst annonsera era IP-adresser som sina egna och stjäla trafik. Med RPKI är det kryptografiskt verifierbart vem som äger vilka prefix. För svenska företag som driftar egen infrastruktur, hostar känslig data eller är beroende av nätverksupptid är RPKI-täckning idag en hygienfråga — inte ett tillval.

Det grundläggande problemet: BGP litar på rykte

BGP (Border Gateway Protocol) är det språk som alla världens internetoperatörer pratar med varandra på. När er trafik till adminor.net ska hitta vägen från Comhem hem-router till en server i Stockholm, så är det BGP-tabeller hos varje operatör som styr nästa hopp.

Problemet: i grundkonfigurationen finns ingen autentisering. Om en operatör i Pakistan eller Ryssland råkar (eller avsiktligt) annonsera ”jag äger 192.51.100.0/24”, och deras grannar accepterar det, så börjar trafik dit gå dit. Det kallas BGP hijack.

Det är inte teoretiskt. Klassiska incidenter:

  • 2008 — Pakistan Telecom annonserade YouTubes IP-prefix för att blockera tjänsten inrikes. Annonsen läckte ut globalt → YouTube nere i två timmar världen över.
  • 2018 — Amazon Route 53 hijackad i 2 timmar för att stjäla kryptovaluta. ~$150k flöt iväg.
  • 2022 — Klayswap (sydkoreansk DEX) — BGP-hijack via KT Telekom, ~$1.9M i förluster.

Hijack-attacker kräver inget intrång hos er. Det räcker att någon på andra sidan jordklotet annonserar ert IP-utrymme — och era kunder hamnar hos dem.

RPKI: kryptografisk svar på frågan ”vem äger denna IP-adress?”

RPKI lägger ett signaturlager ovanpå BGP. Konceptuellt:

  1. Resource certificate utfärdas av regionala internet-registry (RIPE NCC för Europa). Bevis att ni äger ett visst IP-prefix.
  2. ROA — Route Origin Authorization — ni signerar ett uttalande: ”AS51701 får annonsera 192.51.100.0/24, ingen annan.”
  3. Validerande router — operatörers BGP-routers slår upp varje inkommande annons mot ROA-databasen. Om annonsen inte matchar → den droppas eller nedprioriteras.

Resultat: om någon i Pakistan annonserar ert prefix utan att ha er signatur, så ignoreras annonsen av alla operatörer som validerar RPKI. Hijack-försöket stoppas innan det når svenska Internet.

Vem validerar RPKI i Sverige idag?

Det här är den bit många missar. Att publicera ROAs är värdelöst om ingen operatör validerar dem.

Svenska operatörer som hade RPKI-validering aktiv per 2024 (källa: NLnet Labs Routinator + MANRS):

  • Telia (AS3301) — invalid-routes droppas
  • Bahnhof (AS8473) — invalid-routes droppas
  • GleSYS (AS42708) — validerar och droppar
  • Resilans (AS25406) — validerar
  • Netnod IX-route-servers — droppar invalid
  • STHIX route-server — droppar invalid

Det innebär att om ert prefix har en korrekt ROA, så ignoreras hijack-försök automatiskt av de operatörer som hanterar majoriteten av svensk konsumenttrafik.

Vad behöver ett svenskt företag göra?

Det beror på hur ni hanterar IP-adresser:

Om ni använder leverantörens IP-adresser

Ni har inget eget IP-utrymme — ni hostar hos AWS, Azure, GleSYS, Bahnhof eller liknande. Då är RPKI leverantörens ansvar, inte ert. Men ni bör fråga: ”har ni ROA-täckning på era IP-prefix?” Om svaret är nej eller ”vad är det?” — det är en signal om driftmognad i övrigt.

Kontrollera er leverantör på RIPEstat → sök på prefix → fliken ”Routing” → ”RPKI Validity”.

Om ni har egna PI-prefix (Provider Independent)

Ni har eget IP-utrymme i RIPE-databasen, oftast med ett eget AS-nummer. Då är ROA ert ansvar och måste hanteras genom er Sponsoring LIR — den RIPE-medlem som administrerar ert PI-prefix.

Adminor är RIPE LIR och fungerar som Sponsoring LIR för flera svenska företag — vi hanterar ROA-publicering, LOA-utfärdanden och uppdateringar i RIPE Database när ni byter operatör. Vi signerar typiskt ROA inom 1 arbetsdag efter prefix-allokering.

Om ni har eget AS-nummer

Ni driver eget autonomt system. Då måste ni:

  1. Publicera ROA för alla prefix ni annonserar
  2. Köra en RPKI-validerande router (Routinator, FORT, rpki-prover)
  3. Konfigurera BGP-policyn att droppa invalid

Det här är arbete för en nätverksingenjör, inte en webbutvecklare. Om ni inte har den kompetensen in-house — be er IP-leverantör om hjälp.

Vanliga frågor

Kostar RPKI något?
Nej, inte direkt. RIPE NCC tar inte separat avgift för ROA-publicering — det ingår i LIR-medlemskapet (~1 700 EUR/år). Som slutkund med PI-prefix kan ni ha en mindre årlig sponsorshipavgift.

Hur lång tid tar det innan ROA syns?
Ny ROA propagerar typiskt inom 30 minuter via RPKI-repository. Validering hos operatörer som hämtar var 10:e minut → max ~40 min innan skyddet är aktivt.

Vad händer vid felkonfigurerad ROA?
Det här är största risken. Om ni publicerar ROA som inte matchar er faktiska annonsering, så droppas er trafik av validerande operatörer. Ni ”RPKI-hijackar” er själva. Dubbelkolla MaxLength-värden och AS-nummer innan publicering.

RPKI vs BGPsec — är det samma sak?
Nej. RPKI signerar origin (vem som får annonsera). BGPsec signerar hela path (vilka mellanled trafik gick via). BGPsec finns men har minimal utbredning. RPKI är dagens standard.

Sammanfattning

RPKI är ett gratis, väletablerat skyddslager mot en specifik attack-klass — BGP hijack — som annars är osynlig för era egna säkerhetssystem. Det är inte ett kraftfullt verktyg, utan en hygienåtgärd som svenska operatörer (Telia, Bahnhof, GleSYS, STHIX-deltagarna) redan validerar mot. Om ni har eget IP-utrymme och inte har publicerat ROA, så är ni i 2026 i minoritet — och anledning till oro vid säkerhetsgranskningar.

Adminor publicerar ROA för alla kundprefix vi hanterar och fungerar som Sponsoring LIR för svenska företag som vill driva eget IP-utrymme utan att själva bli RIPE-medlemmar. Mer information på Adminor IP Registry.

Frågor om RPKI eller eget IP-utrymme? Kontakta Adminor — vi är RIPE LIR med AS51701 och hanterar IP-registry-frågor för flera svenska företag.

Solarwinds Observability tips&tricks

Solarwinds is known for their tool Appoptics. Sadly it has been deprecated and considered legacy.

They have released a new tool called Observability which performs the same tasks, but with improvements and changes.
Although the price has not improved, infact they hiked it up by double .

Either way, it’s still a good alternative to other APMs (application performance monitor) such as New Relic.

One thing I noticed is their documentation is lacking.

Their install instructions for Linux and PHP for example looks like this:

curl -sSO https://agent-binaries.cloud.solarwinds.com/apm/php/latest/solarwinds-apm-php.sh

sh solarwinds-apm-php.sh –service-key=yourservicekey:tag –collector=apm.collector.eu-01.cloud.solarwinds.com

systemctl restart <php.service>
systemctl restart <web_server.service>

The installed doesn’t mention it, and they have hid the so files behind non public directory service service key.
By default it installs the so-library for the current active php-cli is installed, which means you only get one PHP version library installed.

To install Observability for other PHP versions you simply change your consoles default PHP version, and it’ll pull the right version when you run the solarwinds-apm-php.sh script.

In Debian it’s update-alternatives –config php
select the version you want and re-run the script.

Dont forget to restart your PHP services (fpm) and webserver!

Se även

VMWare slutar tillhandahålla fria utvärderingslicenser

VMWare som sålts till Broadcom slutar nu tillhandahålla fria licenser för utvärdering och labb. Läs mer på https://kb.vmware.com/s/article/96168?lang=en_US

Adminor kan hjälpa till att migrera last från VMware till andra moln, t.ex. Proxmox eller Hyper-V. Kontakta oss så hjälper vi gärna till.

Vill man själv migrera virtuella VMware maskiner till PRoxmox kan man göra detta genom att följa stegen på denna blogg. https://nicolas.busseneau.fr/en/blog/2021/07/esxi-to-proxmox-migration

Se även

Azure and Azure files MMAP broken

We found out (or rather re-discovered) that Azure Files CIFS implementation does not correctly support mmap function that is used in some softwares.

It has been previously reported on https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900821 but we thought it might be worth clarifying this for people spending a lot of time googling why their apache2 fails to deliver files larger than 1MB.

The default setting in apache2 does not mmap files smaller than 1MB hence why the issue is not noticed on small files or files not hosted on the CIFS volume. Large files from the affected volume will however cause a ”Read error at byte X/ X (Bad address). Retrying.” error if you try to wget or download the files via apache2 on a web app using Azure Files mounted CIFS storage (path mapping).

Some searches might lead you to investigate apache2 file limitations preventing files larger than 1MB from beint transmitted.
LimitRequestBody is not a fix for this issue.

Scenario:
Azure web app or VM with Apache2 or other mmap using software fails to read files properly from Azure Files mounted ”path mapping” volumes which uses CIFS.

Workaround:
EnableMMAP off

This configuration line can be done per affected Directory, global apache2 config or in the vhost.

Important security notification: Linux remote crash vulnerability

We’ve been notified that there is a new remote crash vulnerability many Linux systems .

The CVE has yet to be publicly released, it has just been reserved so far: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-11477
The register has published more details: https://www.theregister.co.uk/2019/06/17/linux_tcp_sack_kernel_crash/
Other cloud hosting vendors have published steps on how to mitigate this flaw and so is Adminor AB.

A patch to linux kernel will be issued by different vendors, meanwhile a mitigation of these attacks is to disable tcp_sack (tcp selective acknowledgement) .
It’s possible that the recent reboot of systems already have mitigation for this exploit but we have not been notified of such by upstream vendor as the exploit is still not entirely released.

We recommend that you disable tcp_sack as a pre-caution.
TCP sack is used to speed up TCP transfer by allowing computers to tell the server how much data is left to be sent. This should have minimal impact on normal operations but we still recommend monitoring for any negative performance impacts

Command to run which should not require a system reboot:
echo 0 > /proc/sys/net/ipv4/tcp_sack


To make the change persistent across reboots a command such as the following can be run:echo ’net.ipv4.tcp_sack = 0’ >> /etc/sysctl.conf

We recommend enabling tcp_sack when a kernel patch has been issued and system rebooted.
Please let us know if you need assistance .

The GDPR letter from hell

This GDPR letter is a worst case scenario of someone making a GDPR info request under the new regulations.

We recommend studying it, and discussing within your organization to practice and be ready for a worst-case letter like this.

Some examples where GDPR can be used as a ”weapon” against companies is in social media outreach campaigns, a lot of users would be encouraged to send such request in order to tie up an organizations resources.

Let us know if we can be of help to prepare you for this.

”Dear Sir/Madam:

I am writing to you in your capacity as data protection officer for your company. I am a customer of yours, and in light of recent events, I am making this request for access to personal data pursuant to Article 15 of the General Data Protection Regulation. I am concerned that your company’s information practices may be putting my personal information at undue risk of exposure or in fact has breached its obligation to safeguard my personal information pursuant to <latest nasty cybersecurity event or thing in the news>.

I am including a copy of documentation necessary to verify my identity. If you require further information, please contact me at my address above.

I would like you to be aware at the outset, that I anticipate reply to my request within one month as required under Article 12, failing which I will be forwarding my inquiry with a letter of complaint to the <appropriate data protection authority>.

Please advise as to the following:

1.   Please confirm to me whether or not my personal data is being processed. If it is, please provide me with the categories of personal data you have about me in your files and databases.

a.   In particular, please tell me what you know about me in your information systems, whether or not contained in databases, and including e-mail, documents on your networks, or voice or other media that you may store.

b.   Additionally, please advise me in which countries my personal data is stored, or accessible from. In case you make use of cloud services to store or process my data, please include the countries in which the servers are located where my data are or were (in the past 12 months) stored.

c.   Please provide me with a copy of, or access to, my personal data that you have or are processing.

2.   Please provide me with a detailed accounting of the specific uses that you have made, are making, or will be making of my personal data.

3.   Please provide a list of all third parties with whom you have (or may have) shared my personal data.

a.   If you cannot identify with certainty the specific third parties to whom you have disclosed my personal data, please provide a list of third parties to whom you may have disclosed my personal data.

b.   Please also identify which jurisdictions that you have identified in 1(b) above that these third parties with whom you have or may have shared my personal data, from which these third parties have stored or can access my personal data. Please also provide insight in the legal grounds for transferring my personal data to these jurisdictions. Where you have done so, or are doing so, on the basis of appropriate safeguards, please provide a copy.

c.   Additionally, I would like to know what safeguards have been put in place in relation to these third parties that you have identified in relation to the transfer of my personal data.

4.   Please advise how long you store my personal data, and if retention is based upon the category of personal data, please identify how long each category is retained.

5.   If you are additionally collecting personal data about me from any source other than me, please provide me with all information about their source, as referred to in Article 14 of the GDPR.

6.   If you are making automated decisions about me, including profiling, whether or not on the basis of Article 22 of the GDPR, please provide me with information concerning the basis for the logic in making such automated decisions, and the significance and consequences of such processing.

7.   I would like to know whether or not my personal data has been disclosed inadvertently by your company in the past, or as a result of a security or privacy breach.

a.   If so, please advise as to the following details of each and any such breach:

                   i.    a general description of what occurred;

                   ii.    the date and time of the breach (or the best possible estimate);

                   iii.    the date and time the breach was discovered;

                   iv.    the source of the breach (either your own organization, or a third party to whom you have transferred my personal data);

                    v.    details of my personal data that was disclosed;

                    vi.    your company’s assessment of the risk of harm to myself, as a result of the breach;

                    vii.    a description of the measures taken or that will be taken to prevent further unauthorized access to my personal data;

                    viii.    contact information so that I can obtain more information and assistance in relation to such a breach, and

                     ix.    information and advice on what I can do to protect myself against any harms, including identity theft and fraud.

b.   If you are not able to state with any certainty whether such an exposure has taken place, through the use of appropriate technologies, please advise what mitigating steps you have taken, such as

                      i.    Encryption of my personal data;

                      ii.    Data minimization strategies; or,

                      iii.    Anonymization or pseudonymization;

                      iv.    Any other means

8.   I would like to know your information policies and standards that you follow in relation to the safeguarding of my personal data, such as whether you adhere to ISO27001 for information security, and more particularly, your practices in relation to the following:

a.   Please inform me whether you have backed up my personal data to tape, disk or other media, and where it is stored and how it is secured, including what steps you have taken to protect my personal data from loss or theft, and whether this includes encryption.

b.   Please also advise whether you have in place any technology which allows you with reasonable certainty to know whether or not my personal data has been disclosed, including but not limited to the following:

                     i.    Intrusion detection systems;

                     ii.    Firewall technologies;

                     iii.    Access and identity management technologies;

                     iv.    Database audit and/or security tools; or,

                     v.    Behavioural analysis tools, log analysis tools, or audit tools;

9.   In regards to employees and contractors, please advise as to the following:

a.   What technologies or business procedures do you have to ensure that individuals within your organization will be monitored to ensure that they do not deliberately or inadvertently disclose personal data outside your company, through e-mail, web-mail or instant messaging, or otherwise.

b.   Have you had had any circumstances in which employees or contractors have been dismissed, and/or been charged under criminal laws for accessing my personal data inappropriately, or if you are unable to determine this, of any customers, in the past twelve months.

c.   Please advise as to what training and awareness measures you have taken in order to ensure that employees and contractors are accessing and processing my personal data in conformity with the General Data Protection Regulation.

Yours Sincerely,

I. Rate”

Source: https://www.linkedin.com/pulse/nightmare-letter-subject-access-request-under-gdpr-karbaliotis

Ubiquiti trådlöst spridningsnät i glesbygd

I September var jag uppe i Norrland och installerade bynät.
Valet föll på Ubiquiti airmax länkar p.g.a. svåra markförhållanden (ägarfrågor, avstånd & kostnadsbild).
Kostnaden för mast-installationen är ungefär samma som vad ett hushålls fiberdragning hade kostat om man anlitar en professionell fiberinstallatör.
Byn förses ändå med radiolänk från kommunen så fiberdragningen hade ändå bara varit lokal.
 
Med 5G nätverk runt hörnen så är det en fråga hur mycket krut man ska lägga ned, något man får ta ställning till då när Telia räknar med att glesbyggden ska få tillgång till det (2025) och då kanske airmax också ska uppgraderas. 5G nätverk är tänkt att ge vanliga konsumenter upp till 100Mbit/s bredband via telefonen fast man säger samtidigt att fiber och alternativa anslutningar är bra alternativ. Så jag antar att de själva ser 5G som ett komplement.
Tills dess finns det ju ändå inget som stoppar individuella hushåll att gräva ned fiber till byns internetknytpunkt om möjligheten finns.
Kapaciteten i nätet är byggt så att hushåll ska kunna garanteras minst 100Mbit/s i båda riktningar vid normala radioförhållanden även när andra nyttjar bandbredd, men om behovet finns kan man få upp till 330Mbit/s upp eller ned, eller 165Mbit/s i båda riktningar.
4 sektor antenner sprider 90 grader i var sin riktning (dvs 360).
Resultatet hittills är 6 hushåll uppkopplade via airmax trådlösa länkar. 2st företag samt att minst 3 hushåll till ska kopplas upp. Byns internetuppfart mot kommunen skrämdes dessutom upp i dubbla hastigheten.
Våra egna mätningar visade att den gamla länken presterar som mest 25Mbit/s (totalt) medan den kommunlänken vi satte upp i mast klarar upp till 100Mbit/s. Det är något som man kan öka till 450Mbit/s om kommunen använder den nya generationens utrustning.
I  takt med att fler får upp ögonen för bredbandet så vill fler ansluta och då kommer behovet att finnas. Ska bli spännande att se hur det utvecklar sig.
Väder och vind är ett problem som kan ställa till det. Hård kyla och massor med snö/is på vinter, åska och regn på sommar. Heta soliga dagar med mera.
Men Ubiquiti har god renommé  samt har byggt sina grejer för att klara detta.
Kanske ökar behovet av bredband så att man sätter press på kommunen att uppgradera radiolänkarna som förser byn med uppfarten. De är trots allt 2 generationer äldre än det vi installerade för byns hushåll.

DKIM och SPF record

Adminor erbjuder SPF record.
För vår server Smallfoot gäller följande SPF record:

”v=spf1 mx ip4:46.253.202.12/32 ip4:46.253.202.13/32 ip4:46.253.205.58/32 -all”

För DKIM kontakta oss så kan vi slå igång det.

DKIM och SPF används för att identifiera att avsändarserver har rätt att skicka mail. På så vis minskar man risken för att klassa mail felaktigt som SPAM. Korrekt uppsatta SPF/DKM record är därför viktigt för att undvika problem med utskick av mail.