We Moved Our Data to the Cloud — What's Left for Us to Handle Regarding Cloud Security?

The line in the shared responsibility model is crystal clear: Security of the cloud belongs to the provider, security in the cloud belongs to you. Review your security groups immediately; never open ports 22 (SSH) and 3389 (RDP) to all IP addresses (0.0.0.0/0). Whitelist only your office's static IP, and block any access to the management console without a VPN.

Two months after we migrated, an employee's corporate email was compromised through a phishing attack. Because two-factor authentication wasn't enabled, the attacker penetrated the cloud console and wiped our database backups. The provider rightfully stated that "the login was performed with valid credentials," and we ended up having to pay an 80 thousand TL ransom.

Your board wanting to slash the security budget is an absolute recipe for disaster. That's like renting an apartment in a luxury high-rise with a deadbolted steel door and leaving the front door wide open. If you leave the door open, you can't blame building security when a burglar walks in.

Two things you need to handle first thing tomorrow morning: 1) Log into the management console and enforce app-based 2FA instead of SMS for all users. 2) Purge all unused test accounts and old consultant API keys.

Cloud providers safeguard data integrity against hardware failures, but if an insider deletes the customer table—whether intentionally or by accident—they treat that as a legitimate command, not a cyberattack. That's why having an immutable backup policy stored in a separate account within the cloud is essential.

definitely check your storage buckets that's where companies mess up the most. like they leave them public during testing and next thing you know, all customer data is indexed on google.

Since you handle wholesale and dealer management, your status as a data controller under KVKK remains entirely unchanged. Keeping your data in the cloud doesn't absolve you of legal liabilities. You are obligated to ensure access logs are stored in a tamper-proof, timestamped format going back at least two years.

You're right.

It's rare to find an explanation this clear.

I have a question. Trying to do this alone is the most expensive way.

Hope this helps.

great work. honestly when making decisions write down the worst-case scenario too not just the best.

if I were you, I'd go this route.

There's one point I'm curious about. Any unwritten clause becomes a point of disagreement later, as both sides remember it differently.

Proven by experience.

I went through the same thing.

This is exactly what we experienced. The harder it is to reverse a decision the slower you should make it.

If you have questions, write them; I'll answer as best I can.

Correct. If the notification path is long, notifications don't arrive; missing notifications mean delayed incident detection.

This is my opinion, I'm not claiming it's absolute truth.

This approach has a cost, which isn't discussed. Most time waste accumulates in tasks waiting for approval.

If you have questions, write them; I'll answer as best I can.

I agree with this. The biggest time-waster for us was not knowing who had the final say.

Most incidents start with a leaked password not a vulnerability. Correct me if Im wrong.

Great work. If you get three different answers on a topic, the question was asked wrong.