การยืนยันตัวตนและการอนุญาตสิทธิ์
กำหนดค่ารหัสผ่าน Redis, ACL และการจัดการผู้ใช้ เพื่อควบคุมการเข้าถึงอินสแตนซ์ Redis
การยืนยันตัวตนและการอนุญาตสิทธิ์ เป็นบทเรียน Redis Caching & Messaging (Pub/Sub, Streams) ฟรีบน CoddyKit นี่คือบทเรียนที่ 1 จากทั้งหมด 4 บทเรียน คุณสามารถอ่านบทเรียนทั้งหมดด้านล่างฟรี — จากนั้นลองปฏิบัติด้วยตัวคุณเองในเบราว์เซอร์พร้อมตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7 บทเรียนนี้เป็นส่วนหนึ่งของเส้นทางการเรียน Redis Caching & Messaging (Pub/Sub, Streams) และความก้าวหน้าของคุณจะซิงค์ข้ามเว็บและแอป CoddyKit คอร์ส Redis Caching & Messaging (Pub/Sub, Streams) มีบทเรียนทั้งหมด 4 บทเรียน
บางส่วนของบทเรียนนี้ยังไม่ได้รับการแปล และแสดงเป็นภาษาอังกฤษ
Why Secure Your Redis?
Redis is super fast and often holds sensitive data. Without proper security, your data could be exposed or modified by unauthorized users. Just like your house, your database needs locks!
This lesson will teach you how to set up basic authentication with passwords and advanced authorization using Access Control Lists (ACLs) to protect your Redis instances.
Basic Password Protection
The simplest way to secure Redis is using the requirepass directive in your redis.conf file. This sets a global password that clients must provide to execute *any* command.
It's like a single master key for everyone.
requirepass your_strong_password_hereLogging In with AUTH
Once requirepass is set, clients connecting to Redis must authenticate using the AUTH command. If the password is wrong, most commands will fail.
Here's how you'd connect via redis-cli and authenticate:
redis-cli
127.0.0.1:6379> AUTH your_strong_password_here
OK
127.0.0.1:6379> SET mykey "hello"
OK
127.0.0.1:6379> GET mykey
"hello"Global Password's Downside
While easy to set up, requirepass has a major limitation: it's a single password for everyone and everything. All authenticated clients have full access to all commands and data.
- No specific user accounts.
- No fine-grained permissions (e.g., read-only for some).
- Hard to manage in complex applications.
This is where Redis Access Control Lists (ACLs) come in handy!
Granular Access with ACLs
Redis ACLs (Access Control Lists) allow you to define multiple users, each with their own password and a specific set of permissions. This provides much finer control over who can do what.
You can control:
- Which commands a user can execute.
- Which keys a user can access.
It's like having different keys for different rooms in your house.
Creating & Setting Users
You manage ACLs directly through Redis commands, either in redis-cli or programmatically. The ACL SETUSER command is central to defining users and their properties.
Let's create a new user named app_user with a password. The > before the password indicates it's a password.
ACL SETUSER app_user ON >some_secret_password
ACL SETUSER another_user ON >another_secret_pass_123
ACL LIST
user default on #... (default user)
user app_user on #... (our new user)Controlling Commands
With ACLs, you can specify exactly which commands a user can run. Permissions are often given in categories (like @all, @read, @write) or specific command names.
+@read: Grants all read-only commands.-@admin: Revokes all administrative commands.+SET: Grants only the SET command.
Here's an example for our app_user, granting read/write but denying admin commands:
ACL SETUSER app_user +@read +@write -@admin
ACL SETUSER metrics_user ON >metrics_pass +INFO +MONITOR
ACL CAT @admin
# ... lists admin commandsKey-Level Access
Beyond commands, ACLs let you restrict access to specific keys or key patterns. This is incredibly powerful for multi-tenant applications or microservices.
~mykey: Access only to the key 'mykey'.~data:*: Access to any key starting with 'data:'.~*: Access to all keys (use with caution!).
Let's refine app_user to only access keys starting with user_data::
ACL SETUSER app_user ON >some_secret_password +@read +@write ~user_data:*
ACL SETUSER readonly_user ON >read_only_pass +@read ~cache:*Secure ACL Habits
To maximize security with ACLs, follow these best practices:
- Principle of Least Privilege: Grant only the necessary permissions. Avoid
+@allif not strictly needed. - Strong Passwords: Use unique, complex passwords for each user. Rotate them regularly.
- Disable Default User: If not used, disable the
defaultuser or give it a strong password and minimal permissions. - Audit Regularly: Periodically review your ACL configurations using
ACL LIST.
Test Your ACL Knowledge
Consider a Redis instance where you want a user named report_viewer to:
- Only read data.
- Only access keys starting with
reports:. - Have the password
ViewerPass!.
Which of the following commands would correctly configure this user?
Recap: Secure Your Redis!
Great job! You've learned how to secure your Redis instances:
requirepass: Provides simple, global password protection.AUTH: The command used by clients to authenticate.- ACLs: Offer advanced, granular control over users, commands, and specific keys.
ACL SETUSER: The primary command to create/modify users and set their permissions.- Best Practices: Always follow the principle of least privilege, use strong passwords, and audit your configurations.
Protecting your data is crucial, and Redis provides powerful tools to do just that!
คำถามที่พบบ่อย
บทเรียน “การยืนยันตัวตนและการอนุญาตสิทธิ์” ฟรีหรือไม่
ใช่ — ข้อความเต็มของ “การยืนยันตัวตนและการอนุญาตสิทธิ์” ฟรีให้อ่านที่นี่บนเว็บ เพื่อปฏิบัติแบบโต้ตอบ (ตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7) และปลดล็อคส่วนที่เหลือของคอร์ส Redis Caching & Messaging (Pub/Sub, Streams) ให้อัปเกรดเป็น CoddyKit PRO คอร์ส Redis Caching & Messaging (Pub/Sub, Streams) มีบทเรียนทั้งหมด 4 บทเรียน
คุณจะเรียนรู้อะไรในบทเรียน “การยืนยันตัวตนและการอนุญาตสิทธิ์”
กำหนดค่ารหัสผ่าน Redis, ACL และการจัดการผู้ใช้ เพื่อควบคุมการเข้าถึงอินสแตนซ์ Redis คุณปฏิบัติ Redis Caching & Messaging (Pub/Sub, Streams) ด้วยโค้ดที่ใช้งานได้จริงที่คุณเรียกใช้โดยตรงในเบราว์เซอร์ และติวเตอร์ AI ตลอด 24/7 ตอบคำถามของคุณขณะที่คุณไปผ่านบทเรียน
คุณต้องมีประสบการณ์ก่อนที่จะเริ่มเรียน Redis Caching & Messaging (Pub/Sub, Streams) หรือไม่
ไม่จำเป็นต้องมีประสบการณ์มาก่อน Redis Caching & Messaging (Pub/Sub, Streams) บน CoddyKit ออกแบบมาสำหรับผู้เริ่มต้นไปจนถึงผู้เรียนขั้นสูง คุณสามารถเริ่มต้นที่นี่หรือเริ่มจากตัวแรกและเรียนด้วยความเร็วของคุณเอง นี่คือบทเรียนที่ 1 จากทั้งหมด 4 บทเรียน
บทเรียน “การยืนยันตัวตนและการอนุญาตสิทธิ์” ใช้เวลานานแค่ไหน
บทเรียน CoddyKit ส่วนใหญ่ใช้เวลาประมาณ 5–10 นาที แต่ละบทเรียนจึงสั้นและเป็นแบบโต้ตอบ คุณสามารถก้าวหน้าอย่างต่อเนื่องและกลับมาเรียนต่อจากตรงที่เพิ่งหยุดบนเว็บและแอปได้เลย
ฉันเขียนและรันโค้ดในบทเรียน Redis Caching & Messaging (Pub/Sub, Streams) นี้ได้ไหม
ได้ บทเรียน Redis Caching & Messaging (Pub/Sub, Streams) ทุกบทมีตัวแก้ไขโค้ดในตัว คุณจึงเขียนและรันโค้ดจริงได้เลยในเบราว์เซอร์ และได้รับข้อเสนอแนะจาก AI ในทันที — ไม่ต้องติดตั้งในเครื่องของคุณ
บทเรียนทั้งหมดในหลักสูตรนี้
- การยืนยันตัวตนและการอนุญาตสิทธิ์
- ความปลอดภัยเครือข่ายสำหรับ Redis
- แนวทางปฏิบัติที่ดีที่สุดด้านการดำเนินงาน
- การเข้ารหัสระหว่างการส่งข้อมูลด้วย TLS