PlusMagi's Blog By Pitt Phunsanit Cloud Computing,Cybersecurity เปลี่ยนพอร์ต SSH เริ่มต้น และเปิดใช้งาน การยืนยันตัวตนด้วย SSH Key เท่านั้น

เปลี่ยนพอร์ต SSH เริ่มต้น และเปิดใช้งาน การยืนยันตัวตนด้วย SSH Key เท่านั้น

ในโลกของการบริหารจัดการโครงสร้างพื้นฐานระบบคลาวด์ (Cloud Infrastructure) ความมั่นคงปลอดภัยทางไซเบอร์ถือเป็นรากฐานที่สำคัญที่สุด การเปิดเผยบริการเครือข่ายด้วยค่าเริ่มต้น (Default Configuration) ไม่ว่าจะเป็นพอร์ตมาตรฐานหรือการใช้รหัสผ่านในการเข้าถึง ล้วนเป็นช่องโหว่ที่ผู้ไม่ประสงค์ดีสามารถใช้ประโยชน์ได้ง่าย การยกระดับมาตรฐานความปลอดภัยจึงไม่ใช่แค่การแก้ไขปัญหา แต่คือการสร้างเกราะป้องกันเชิงรุกให้กับสินทรัพย์ดิจิทัลของเรา

หลักการเสริมความแข็งแกร่งของ SSH: 2 มาตรการสำคัญ

การเข้าถึงระบบผ่าน SSH เป็นช่องทางหลักที่ผู้ดูแลระบบใช้ แต่การปล่อยให้ใช้ค่าเริ่มต้น (Default Port 22) และรหัสผ่าน (Password Authentication) นั้นมีความเสี่ยงสูงอย่างยิ่ง เราจึงต้องดำเนินการสองมาตรการหลักเพื่อลดความเสี่ยงจากการโจมตี:

1. การเปลี่ยนพอร์ต SSH (Port Change)

การเปลี่ยนพอร์ต SSH ออกจากค่ามาตรฐาน (Port 22) เป็นมาตรการที่เรียกว่า Security by Obscurity ซึ่งไม่ได้หมายความว่าปลอดภัย 100% แต่มีประสิทธิภาพสูงในการลดปริมาณ Traffic จากเครื่องมือสแกนช่องโหว่แบบอัตโนมัติ (Automated Scanners) และบอทโจมตีทั่วไป ทำให้ผู้โจมตีต้องใช้เวลาและทรัพยากรในการค้นหาพอร์ตที่ถูกต้องมากขึ้น

2. การบังคับใช้ SSH Key Authentication

นี่คือมาตรการที่สำคัญที่สุด การใช้ SSH Key แทนการใช้รหัสผ่านเป็นการกำจัดความเสี่ยงจากการโจมตีแบบ Brute-Force โดยสิ้นเชิง เนื่องจาก Private Key จะถูกเก็บไว้ในเครื่องของผู้ใช้เท่านั้น และ Public Key จะถูกผูกไว้กับระบบปลายทาง การทำเช่นนี้ทำให้การเข้าถึงระบบมีความปลอดภัยสูงกว่าการใช้รหัสผ่านที่สามารถเดาได้

การผนวกความปลอดภัยเข้ากับ PostgreSQL

แม้ว่าการเปลี่ยนพอร์ต SSH และการใช้ SSH Key จะเป็นระดับระบบปฏิบัติการ (OS Level) แต่การรักษาความปลอดภัยของฐานข้อมูล PostgreSQL ก็ต้องเป็นไปในระดับที่เข้มงวดเช่นกัน เราควรใช้ PostgreSQL เพื่อจัดการสิทธิ์การเข้าถึงและจำกัดการดำเนินการของผู้ใช้แต่ละคน เพื่อให้แน่ใจว่าแม้ผู้โจมตีจะเข้าถึงระบบได้ ก็ไม่สามารถทำลายข้อมูลทั้งหมดได้

ในเชิงปฏิบัติ เราควรตรวจสอบและจำกัดสิทธิ์ของ Role ต่างๆ โดยไม่ให้มี Role ใดมีสิทธิ์เกินความจำเป็น (Principle of Least Privilege) ตัวอย่างการจำกัดสิทธิ์ผู้ใช้งานใน PostgreSQL เพื่อเพิ่มความปลอดภัย:

SQL

-- ตัวอย่าง: การจำกัดสิทธิ์ผู้ใช้ที่เข้าถึงฐานข้อมูล (Role)</code>

-- 1. สร้าง Role ใหม่สำหรับแอปพลิเคชันที่จำกัดสิทธิ์
CREATE ROLE app_user LOGIN PASSWORD 'secure_password';

-- 2. กำหนดให้ Role นี้มีสิทธิ์เพียงแค่ SELECT และ INSERT ในตารางที่จำเป็นเท่านั้น
GRANT SELECT, INSERT ON public.data_table TO app_user;

-- 3. ป้องกันไม่ให้ Role นี้สามารถแก้ไขโครงสร้างตารางได้ (DROP/ALTER)
REVOKE ALL ON ALL TABLES IN SCHEMA public FROM app_user;

บทสรุป: การป้องกันเชิงรุกที่สมบูรณ์

การรวมมาตรการเหล่านี้เข้าด้วยกัน—ตั้งแต่การเปลี่ยนพอร์ต SSH, การบังคับใช้ SSH Key, ไปจนถึงการจำกัดสิทธิ์อย่างเข้มงวดในระดับ PostgreSQL—คือการสร้างเกราะป้องกันเชิงรุกที่สมบูรณ์แบบ (Defense in Depth) การดำเนินการเหล่านี้ไม่เพียงแต่เพิ่มความยากลำบากในการโจมตี แต่ยังเป็นการยกระดับมาตรฐานความปลอดภัยขององค์กรให้เป็นไปตามแนวปฏิบัติที่ดีที่สุด (Best Practices) ในระดับสถาปัตยกรรมระบบ (Architectural Level) เสมอ

Exit mobile version