thảo luận Xin nhận xét về SaaS app mà mình vừa hoàn thành

Lưu thông tin tài khoản bank, ông thớt nghĩ đơn giản nhưng làm không kĩ là vỡ mồm đấy. Nếu chơi được với bank thì điều kiện cần là phải theo chuẩn thế giới, điều kiện đủ là mang lại lợi ích TO LỚN cho bank. Nếu ông nghĩ có thể theo được business này và làm 1 cách hoàn chỉnh (kiếm VC support chẳng hạn...) thì hẵng tiếp tục, còn không thì nên nghỉ sớm cho đỡ mất time.

Khó vậy nên nhiều nơi chủ yếu chơi payment gateway. Nhiều thằng lớn như: Momo, Tiki, Zalopay...theo mình biết thì nó không lưu thông tin tài khoản bank hay CC, mà phải để ở bên thứ 3 với độ uy tín cực kì cao, ví dụ Cybersource của VISA. Ở bên trên ông thớt có nói microservice architecture + Encryption in transit, nghe có vẻ hợp lý, ok về mặt tech, mình tin là nhiều người dư sức design và implemnt, nhưng cái khó nhất ở đây là về business cơ.

Về ý kiến cá nhân thì mình không thấy lợi ích to lớn của app này mang lại, trong khi risk lại quá lớn. Nhiều khi phải xuất thông tin khi thanh toán mình đã khá quan ngại rồi chứ đừng nói tới dùng app để lấy thông tin từ thẻ hay tài khoản. Bài học về leak thông tin thẻ thì quá nhiều rồi, từ thằng bé -> cực kì lớn.
 
Last edited:
Serverless hết luôn hả fen, SQS đẩy vào Lambda xử lý à
Hiện tại mình mới chỉ dùng lambda ở crawler service thôi bác ạ.
vậy trường hợp xấu nhất là sau 30 phút mới biết được biến động số dư hả thớt, có quá chậm không

và cái lo ngại nhất là giao quyền truy cập tài khoản cho bên thứ 3
30 phút là tài khoản free ấy bác, tài khoản trả phí thì là 15 phút. Dĩ nhiên là có thể hạ thấp tần suất xuống nữa, vì thực tế tác vụ crawl chỉ tốn khoảng 5s thôi.
 
Lưu thông tin tài khoản bank, ông thớt nghĩ đơn giản nhưng làm không kĩ là vỡ mồm đấy. Nếu chơi được với bank thì điều kiện cần là phải theo chuẩn thế giới, điều kiện đủ là mang lại lợi ích TO LỚN cho bank. Nếu ông nghĩ có thể theo được business này và làm 1 cách hoàn chỉnh (kiếm VC support chẳng hạn...) thì hẵng tiếp tục, còn không thì nên nghỉ sớm cho đỡ mất time.

Khó vậy nên nhiều nơi chủ yếu chơi payment gateway. Nhiều thằng lớn như: Momo, Tiki, Zalopay...theo mình biết thì nó không lưu thông tin tài khoản bank hay CC, mà phải để ở bên thứ 3 với độ uy tín cực kì cao, ví dụ Cybersource của VISA. Ở bên trên ông thớt có nói microservice architecture + Encryption in transit, nghe có vẻ hợp lý, ok về mặt tech, mình tin là nhiều người dư sức design và implemnt, nhưng cái khó nhất ở đây là về business cơ.

Về ý kiến cá nhân thì mình không thấy lợi ích to lớn của app này mang lại, trong khi risk lại quá lớn. Nhiều khi phải xuất thông tin khi thanh toán mình đã khá quan ngại rồi chứ đừng nói tới dùng app để lấy thông tin từ thẻ hay tài khoản. Bài học về leak thông tin thẻ thì quá nhiều rồi, từ thằng bé -> cực kì lớn.
Cảm ơn những ý kiến hết sức thẳng thắn của bác, hiện tại thì mình rất cần những ý kiến thế này để hoàn thiện hơn cho sản phẩm của mình, và khi mà nó đủ độ "chín" thì chắc chắn mình đi tiếp đến bước tìm VC để được tư vấn và bảo trợ.

Về vấn đề mà các paygate họ lưu trữ thông tin tài khoản ở một bên thứ 3 là hoàn toàn chính xác và hợp lý, mình cũng công nhận như thế. Nhưng hiện tại thì mình thấy các ngân hàng đang dần tham gia vào hệ thống open banking, mà như vậy thì sẽ sớm thôi mình không cần lưu trữ thông tin tài khoản của khách hàng nữa, thay vào đó là API key của họ.
 
Th
Cảm ơn những ý kiến hết sức thẳng thắn của bác, hiện tại thì mình rất cần những ý kiến thế này để hoàn thiện hơn cho sản phẩm của mình, và khi mà nó đủ độ "chín" thì chắc chắn mình đi tiếp đến bước tìm VC để được tư vấn và bảo trợ.

Về vấn đề mà các paygate họ lưu trữ thông tin tài khoản ở một bên thứ 3 là hoàn toàn chính xác và hợp lý, mình cũng công nhận như thế. Nhưng hiện tại thì mình thấy các ngân hàng đang dần tham gia vào hệ thống open banking, mà như vậy thì sẽ sớm thôi mình không cần lưu trữ thông tin tài khoản của khách hàng nữa, thay vào đó là API key của họ.
Thực tế, cái bạn hướng tới là chờ họ public sdk đăng nhập kiểu FB hoặc google thì bạn mới có thể làm được . Còn API thì nó vẫn dựa trên tiền đề một Token xxx nào đó của mỗi doanh nghiệp mà ngân hàng cung cấp và cái token này full quyền. Bạn đừng chờ mong gì một hệ thống có chơi phân quyền như những hệ thống lớn khác vì mấy ông banking không chú trọng vào việc này . Cái họ hướng tới là một người một tài khoản chứ không phải một tài khoản nhiều người nên để họ áp vụ phân quyền này nọ là bất khả thi. Câu chuyện login bằng sdk thì có thể khả thì nhưng cũng phải chờ mùa quýt nào đó . Quay trở lại thì vẫn là bạn phải là cốp lớn trong đó thì may ra người khác họ tin họ giao cho bạn. Mấy hệ thống banking lớn trên thế giới thường do nhà nước quản hoặc tư nhân thì chỉ có Mẽo
 
Hi cả nhà, sau một ngày đăng đàn mình đã nhận được khá nhiều ý kiến đóng góp của mọi người, thật sự rất cảm ơn các bác đã bớt chút thời gian ghé thăm app của mình. Post này mình sẽ giải thích thêm về một số vấn đề mà các bác đã đặt câu hỏi như sau:

Vấn đề use case
Lấy ví dụ với số lượng giao dịch như trong ảnh mình đính kèm dưới đây, nó quá nhiều các bác ạ. Và với số lượng lớn như vậy sẽ đến lúc các bác cần nhân lực riêng chỉ để phục vụ cho việc đối chiếu giao dịch. Trong trường hợp của mình trước đây thì không chỉ 1, mà đến 3 người để làm việc này. Tuy nhiên sức người có hạn, nhân sự của các bác làm việc tối đa cũng chỉ 8-10 tiếng 1 ngày mà thôi, thêm nữa họ còn nghỉ cuối tuần, nghỉ lễ... còn khách hàng thì không, họ có thể thực hiện giao dịch bất cứ lúc nào họ cần, kể cả nửa đêm. Vậy trong trường hợp không có nhân lực đối chiếu giao dịch, khách hàng sẽ phải chờ đến giờ làm việc, cuối tuần hoặc nghỉ lễ thì phải chờ đến ngày làm việc tiếp theo => mất khách.
giao-dich-tech-18-1-2021.png

Thật sự mà nói thì mình làm app này không phải theo kiểu cọc đi tìm trâu, mà nhu cầu là hiện hữu, vì trong mô hình kinh doanh chính mà mình đang vận hành nó có những vấn đề phát sinh cần đến giải pháp này. Nghĩa là nhu cầu có rồi, mình chỉ là người cung cấp giải pháp mà thôi.

Vấn đề bảo mật
Mình sẽ giải thích thêm về việc bảo mật thông tin tài khoản của khách hàng bằng hình ảnh dưới đây.
transmoni-microservice.png
Chú giải như sau:
  • Web service: là service sẽ tương tác trực tiếp với người dùng, như đăng ký hay quản lý subscription. Sau khi người dùng liên kết tài khoản, service này sẽ ngay lập tức mã hóa toàn bộ thông tin bằng RSA public key (4096 bits), sau đó gửi lên SQS-A (sử dụng mã hóa AES-256 bits). Web service chỉ có quyền PUB lên SQS-A mà không có quyền SUB để gọi ngược thông tin trên SQS-A về.
  • Crawler service: là service tương tác với phía ngân hàng, nó có quyền SUB vào SQS-A để nhận thông tin tài khoản web service gửi lên, và sử dụng RSA private key để giải mã thông tin đó (web service không có private key này). Sau khi truy xuất thông tin giao dịch nó sẽ gửi thông tin theo SQS-B, nơi nó có quyền PUB nhưng quyền SUB lại chỉ có ở web service mà thôi.
Bên cạnh đó mỗi service đều có một database riêng đã thiết lập chỉ được cấp quyền truy cập từ chính service mà nó phụ thuộc. Các services này hoàn toàn không có bất kỳ liên hệ nào với nhau, hay nói cách khác là không dựa vào nhau để vận hành. Chính vì vậy kể cả trong trường hợp xấu nhất, web service của mình có bị tấn công, thì cũng không thể mò được ra crawler service của mình ở đâu cả.
 
Sau khi người dùng liên kết tài khoản, service này sẽ ngay lập tức mã hóa toàn bộ thông tin bằng RSA public key
Lấy gì đảm bảo điều này? Trừ khi open source.

Chính vì vậy kể cả trong trường hợp xấu nhất, web service của mình có bị tấn công, thì cũng không thể mò được ra crawler service của mình ở đâu cả.
Người ta có địa chỉ của SQS-B thì người ta cũng subscribe vào được thôi.

Mà 2 cái message bus 1 chiều khác gì 1 cái message bus 2 chiều nhỉ?
 
Ớ, mình thấy post này của bác có gì đó sai sai so với kinh nghiệm của post trước nhỉ? Để mình giải thích cho nhé:
Lấy gì đảm bảo điều này? Trừ khi open source.
Theo bác có bao nhiêu SaaS app open source chỉ để chứng minh sự trong sạch của mình? Thêm vào đó RSA encryption cực kỳ đơn giản, ngay cả những lập trình viên mới cũng dễ dàng hiểu và implement nó với vài dòng code cơ bản. Ngoài ra thì mình áp dụng encryption vừa để bảo vệ tài khoản của khách hàng và cũng là bảo vệ chính mình khỏi những rắc rối trong trường hợp xấu bác ạ!
Người ta có địa chỉ của SQS-B thì người ta cũng subscribe vào được thôi.
Chắc bác đang đùa hay sao ấy chứ, nếu chỉ cần có địa chỉ SQS endpoint là ai cũng có thể sub được vào thì có lẽ Amazon nó chả thể nào tồn tại được đến giờ này đâu.
 
Ớ, mình thấy post này của bác có gì đó sai sai so với kinh nghiệm của post trước nhỉ? Để mình giải thích cho nhé:

Theo bác có bao nhiêu SaaS app open source chỉ để chứng minh sự trong sạch của mình? Thêm vào đó RSA encryption cực kỳ đơn giản, ngay cả những lập trình viên mới cũng dễ dàng hiểu và implement nó với vài dòng code cơ bản. Ngoài ra thì mình áp dụng encryption vừa để bảo vệ tài khoản của khách hàng và cũng là bảo vệ chính mình khỏi những rắc rối trong trường hợp xấu bác ạ!

Chắc bác đang đùa hay sao ấy chứ, nếu chỉ cần có địa chỉ SQS endpoint là ai cũng có thể sub được vào thì có lẽ Amazon nó chả thể nào tồn tại được đến giờ này đâu.
1 là người ta có độ trust nên người ta không cần open source. anh nói rằng ngay sau khi nhận được form submit thì dùng PK để mã hóa. nhưng đó chỉ là điều anh nói, ai kiểm chứng được.

2 là
Chính vì vậy kể cả trong trường hợp xấu nhất, web service của mình có bị tấn công
thì người ta có thể mò ra được địa chỉ của SQS

Còn nếu anh khẳng định không thể tìm được địa chỉ của SQS, thì tội gì phải dùng 2 bus?
 
1 là người ta có độ trust nên người ta không cần open source.
Có thể những người có độ trust cao họ nhìn thấy tiềm năng của app này nó không bõ để bỏ công sức đầu tư, chứ mà lợi nhuận cao chắc chả đến lượt mình làm rồi.
Còn nếu anh khẳng định không thể tìm được địa chỉ của SQS, thì tội gì phải dùng 2 bus?
Việc mình chia nhỏ SQS thành 2 endpoint giải quyết được các vấn đề như sau:
  1. Để phân biệt rõ ràng endpoint nào thực hiện nhiệm vụ gì (kể cả mình có tạo bao nhiêu endpoint đi chăng nữa thì số tiền mình phải trả cũng chỉ tính trên tổng số message chứ không theo enpoint, nên chả tội gì mình phải gộp chung vào nhau cả).
  2. Để web service sau khi push thông tin tài khoản sẽ không truy xuất ngược về được nữa.
anh nói rằng ngay sau khi nhận được form submit thì dùng PK để mã hóa. nhưng đó chỉ là điều anh nói, ai kiểm chứng được.
Như mình đã giải thích là nó rất đơn giản để implement, nên chẳng có lý do gì mình lại không thể áp dụng cho app của mình cả, trong khi nó còn là để bảo vệ chính bản thân mình. Thêm vào đó các message gửi đi cũng tiếp tục được mã hóa với AES256 của aws cơ mà.
 
Như mình đã giải thích là nó rất đơn giản để implement, nên chẳng có lý do gì mình lại không thể áp dụng cho app của mình cả, trong khi nó còn là để bảo vệ chính bản thân mình. Thêm vào đó các message gửi đi cũng tiếp tục được mã hóa với AES256 của aws cơ mà.
Amazon nó mã hóa là để bảo mật cái đường truyền của nó, chả liên quan. Lý do mà anh không mã hóa thông tin tài khoản người dùng vì anh muốn lấy thông tin đó.

  1. Để web service sau khi push thông tin tài khoản sẽ không truy xuất ngược về được nữa.
Là sao? Từ webservice anh push data lên bus mà còn sợ bị truy xuất ngược về nữa.

Muốn tách bus thì dùng topic, việc gì phải tạo 2 bus đâu nhỉ.
Mà message bus từ trước đến nay tôi dùng là để loosing couple giữa các component, lần đầu tiên tôi thấy có người dùng để làm cơ chế bảo mật.

Mà có khi tôi không hiểu được vấn đề của anh, nên thảo luận có vẻ lệch pha.
 
Crawler service: là service tương tác với phía ngân hàng
bạn dùng cái gì để crawl vậy? Dùng mấy lib kiểu như selenium vs puppeteer à?
Với cả, trong trường hợp đăng nhập mà ngân hàng bắt nhập captcha, thì bạn đang dùng cách gì giải quyết vậy
 
Technical -> Ok

Microservice architecture + async message là chuẩn rồi, vì dự án startup phải tính đến mở rộng trong tương lai. Trong khi hầu hết cty trong lĩnh vực này đều đã, đang chuyển qua Microservice architecture


Bussiness -> Fatal Error

- Bác đã có cái nhìn toàn cục và sâu sắc trong cái lĩnh vực tài chính này chưa?

- Bác đã phân tích kỹ tập khách hàng chưa? Là 1 chủ doanh nghiệp thì đâu là quan trọng nhất với họ trong việc quản lý tài chính, ứng dụng của bác có đáp ứng được hay ko?

- Bác có từng nghiên cứu qua các dữ liệu báo cáo của các công ty liên quan đến lĩnh vực này chưa?

.....
 
nếu 1 ngày ngân hàng thấy 1 IP mà login vào quá nhiều account, thì nó có khóa tài khoản để bảo vệ không nhỉ?
Không đi đêm với ngân hàng, thì "gió lung lay quá"
 
Amazon nó mã hóa là để bảo mật cái đường truyền của nó, chả liên quan. Lý do mà anh không mã hóa thông tin tài khoản người dùng vì anh muốn lấy thông tin đó.
À ùi dồi, hóa ra bác đang đặt mình vào vị trí của kẻ xấu, bảo sao mình thấy có gì đó sai sai khi bác cố gắng bảo vệ quan điểm "chứng minh những gì mình nói là thật" một cách lỳ lợm đến vậy. Tuy nhiên nếu đã không tin tưởng nhau thì chắc chỉ có để thời gian chứng minh cho sự "chong xáng" của mình mà thôi bác ạ.

À quên nếu bác có suy nghĩ một cách tiêu cực như vậy thì lúc github hay gitlab mới ra đời chắc bác cũng không dám dùng đâu nhỉ? Vì nhỡ đâu nó mang source của mình đi bán thì sao?!

Là sao? Từ webservice anh push data lên bus mà còn sợ bị truy xuất ngược về nữa.

Muốn tách bus thì dùng topic, việc gì phải tạo 2 bus đâu nhỉ.
Ở đây mình tính đến trường hợp xấu nhất là hacker chiếm được quyền của web service, lúc đó họ hoàn toàn có thể sử dụng authorization credentials để thực hiện subscribe vào SQS-A của mình để gọi ngược thông tin mà mình đã push lên, đó là lý do vì sao mình cấm quyền sub của web service. Dĩ nhiên là nếu có thể xuất hiện một cái bug nào đó ở phía aws dẫn đến việc đó thành hiện thực, thì thông tin trong message cũng đã được mã hóa bằng RSA rồi, nên cũng khó có thể giải mã ra được nếu không có private key (thứ mà mình lưu trữ ở crawler service).

Mà message bus từ trước đến nay tôi dùng là để loosing couple giữa các component, lần đầu tiên tôi thấy có người dùng để làm cơ chế bảo mật.
Đâu có ai ép buộc mình dùng nó vào việc gì đâu bác? Một cái bánh xe (wheel) đối với hầu hết mọi người nó để cái xe chạy được, nhưng các cụ nhà ta còn có thể làm thành máy dệt tơ hay dụng cụ tập thể dục được cơ mà. Mình chỉ follow theo quan điểm "if it works it's not stupid" mà thôi.
 
đặt gạch đây tối về ném sau.
Gạch bác trước phát nhé hớ hớ.
bạn dùng cái gì để crawl vậy? Dùng mấy lib kiểu như selenium vs puppeteer à?
Với cả, trong trường hợp đăng nhập mà ngân hàng bắt nhập captcha, thì bạn đang dùng cách gì giải quyết vậy

Đúng rồi puppeteer.
Bọn ngân hàng nó không điên mà bắt người dùng nhập captcha

ẹc. hóa ra là có.

Nếu thế thì tôi biết 1 cách là dùng service giải captcha
Lúc đầu mình có dùng selenium, nhưng performance của nó thật sự rất kém, kể cả với headless nên mình sử dụng giải pháp riêng của mình rồi.
 
Back
Top