Cách dễ nhất để gửi email được mã hóa?


17

Để tuân thủ luật bảo vệ thông tin cá nhân mới của Massachusetts, công ty của tôi cần (trong số những thứ khác) đảm bảo rằng bất cứ khi nào thông tin cá nhân được gửi qua email, nó được mã hóa. cách dễ nhất để làm điều này là gì? Về cơ bản, tôi đang tìm kiếm thứ gì đó sẽ đòi hỏi ít nỗ lực nhất từ ​​phía người nhận. Nếu có thể, tôi thực sự muốn tránh việc họ phải tải xuống một chương trình hoặc trải qua bất kỳ bước nào để tạo một cặp khóa, v.v. Vì vậy, công cụ loại GPG dòng lệnh không phải là một tùy chọn. Chúng tôi sử dụng Exchange Server và Outlook 2007 làm hệ thống email của chúng tôi.

Có chương trình nào chúng ta có thể sử dụng để dễ dàng mã hóa email và sau đó fax hoặc gọi cho người nhận bằng một phím không? (Hoặc có thể email của chúng tôi có thể bao gồm một liên kết đến trang web của chúng tôi chứa khóa công khai của chúng tôi, rằng người nhận có thể tải xuống để giải mã thư không?) Chúng tôi sẽ không phải gửi nhiều email được mã hóa này, nhưng những người sẽ gửi chúng sẽ không phải là đặc biệt kỹ thuật, vì vậy tôi muốn nó dễ dàng nhất có thể. Bất kỳ recs cho các chương trình tốt sẽ là tuyệt vời. Cảm ơn.


1
Lợn-Latin. Không cần cài đặt bất cứ thứ gì cho điều đó ;-)
Bart Silverstrim

Khóa công khai thuộc về người nhận và người gửi sử dụng nó để mã hóa tin nhắn. Người nhận sử dụng khóa riêng của họ để giải mã nó. Nếu nó hoạt động theo cách khác như bạn mô tả, thì bất cứ ai cũng có thể tải xuống khóa và giải mã bất kỳ tin nhắn nào. Nếu bạn định gọi điện hoặc fax, tại sao không "truyền" dữ liệu theo cách đó?
Tạm dừng cho đến khi có thông báo mới.

Vâng, tôi đã chuyển công khai / riêng tư của tôi lên; gõ quá nhanh. Tôi đang cố gắng tìm ra một giải pháp sẽ phù hợp với quy trình công việc hiện có trong công ty, trong đó nhân sự thường xuyên gửi email qua lại cho nhân viên mới, công ty bảo hiểm, v.v. Ý tưởng fax / cuộc gọi có lẽ cũng không phải là một lựa chọn tốt đường.
johnnyb10

Câu trả lời:


12

Chúng tôi đã phải trải qua một cái gì đó tương tự với các khách hàng của chúng tôi cho PCI. Cách tốt nhất là sử dụng một số phiên bản PGP / GPG.

Bây giờ được nói, nó thực sự không đau đớn như bạn nghĩ. Chúng tôi đã làm điều này với hàng trăm người dùng không có kỹ thuật. Những gì chúng tôi đã làm là chọn hai sản phẩm - GPG miễn phí (mà các bang Kronick có giao diện người dùng GUI) cũng như trả tiền cho phần mềm PGP. Chúng tôi đã viết ra một số tài liệu thực sự tốt có thể được gửi cho khách hàng của mình để hướng dẫn họ cách sử dụng phần mềm mà họ đã chọn cũng như đào tạo Quản lý tài khoản của chúng tôi về cách khắc phục sự cố cơ bản và cách sử dụng phần mềm.

Điều đó đã giữ 95% các vấn đề mà khách hàng gặp phải trong hàng đợi CNTT. Đối với 5% khác, chúng tôi đã cung cấp tài nguyên CNTT để trả lời các câu hỏi, cũng như trong trường hợp xấu nhất nhận được cuộc gọi để giúp khách hàng giải quyết.


Để thay thế, chúng tôi cũng đã mua một số giấy phép của winzip để có thể sử dụng mã hóa AES tích hợp với cụm từ thông qua. Phần mềm PGP thương mại có khả năng tạo một tệp được mã hóa chỉ được mở bằng cụm mật khẩu. Mặc dù thành thật sử dụng PGP đã hoạt động rất tốt nhưng tôi nghĩ rằng tôi chỉ tạo ra các loại tệp này 2 hoặc 3 lần một năm.


Cảm ơn, đây là thông tin tuyệt vời - sản phẩm để kiểm tra cũng như một số thông tin về trải nghiệm của bạn. Tôi đang tải xuống GPG4win và tôi sẽ kiểm tra trước.
johnnyb10

Sử dụng bất kỳ loại tùy chọn người dùng cuối nào sẽ mở ra cho bạn trách nhiệm pháp lý, không giống như PCI, luật pháp yêu cầu bạn phải xử lý mọi vấn đề hợp lý (như người dùng joe không sử dụng công nghệ)
Jim B

@Jim B: sử dụng pgp nếu người dùng không cung cấp cho bạn khóa, bạn không gửi cho họ. Về cơ bản, họ buộc phải sử dụng nó - trong trường hợp sử dụng này - nếu không họ A) Không nhận được dữ liệu hoặc B) không thể đọc dữ liệu.
Zypher

@ zypher- làm thế nào bạn có thể đảm bảo rằng mọi người dùng gửi dữ liệu sẽ mã hóa mọi email? Giống như một giải pháp SMIME bạn phải chọn để mã hóa email của mình, nó không thể bị ép buộc - hay tôi đang thiếu thứ gì đó?
Jim B

@Jim B: Nó khá đơn giản, nếu bạn gửi một email chứa thông tin cần được mã hóa mà không cần mã hóa, bạn sẽ bị đuổi việc (theo ý muốn, điều này có nghĩa là không có thất nghiệp). Không phải tất cả mọi thứ cần phải là một giải pháp kỹ thuật. Từ câu hỏi này sẽ không được thực hiện quá thường xuyên nên một giải pháp liên quan hơn có lẽ không đáng giá / chi phí. Nếu họ cần làm điều này cả ngày mỗi ngày, tôi sẽ ủng hộ việc không sử dụng email, và chuyển sang các biểu mẫu trực tuyến qua SSL.
Zypher

5

Sẽ không dễ dàng hơn nếu họ kiểm tra một trang web với dữ liệu được mã hóa thông qua SSL, bằng một nút để in dữ liệu trên đầu của họ? Bằng cách đó, bạn không truyền tải bất cứ điều gì và bạn có thể kiểm soát việc phổ biến dữ liệu.

Bất cứ điều gì với email có thể sẽ quá khó khăn cho người dùng của bạn; họ sẽ liên quan đến việc tạo khóa hoặc tải xuống một khóa hoặc những thứ khác mà người dùng sẽ thấy là rắc rối hoặc khó hiểu. Chi phí hỗ trợ của bạn sẽ tăng vọt, trừ khi người dùng bỏ cuộc trong sự thất vọng.


Cảm ơn, đó có vẻ là một giải pháp tốt lâu dài; công ty chúng tôi đang dần thử nghiệm và dần dần triển khai SharePoint như một công cụ để liên lạc với khách hàng và nhà cung cấp của chúng tôi; cuối cùng, việc mọi người tải xuống nội dung thông qua một trang SharePoint an toàn có thể sẽ là một phần quan trọng trong đó. Hiện tại, tôi cần tìm ra cách khắc phục ngay lập tức hơn cho những người làm nhân sự, những người gửi email qua lại có chứa thông tin cá nhân như SSN.
johnnyb10

Tôi không biết các yêu cầu thực tế của bạn theo luật đó là gì, nhưng nếu chỉ là hình thức, việc sử dụng ZIP sẽ biến nó thành tệp EXE tự giải nén (với mật khẩu được đặt trên EXE)? Tôi biết một số bộ lọc chặn chúng, nhưng trình trích xuất tự sử dụng rất đơn giản và không yêu cầu trình cài đặt. Thậm chí sau đó, bạn có thể lưu trữ chúng trên một trang web nội bộ và liên kết email qua email để người dùng tải xuống (và cung cấp cho họ mật khẩu / cụm mật khẩu thông qua các kênh đáng tin cậy).
Bart Silverstrim

Một số điều này phụ thuộc vào các kênh bạn đang sử dụng để truyền / lưu trữ dữ liệu. Nếu đây là nội bộ, sử dụng các khóa được bảo vệ bằng mật khẩu có thể sẽ ổn, nhưng nếu bạn đang làm điều này với truy cập công cộng, điều đó sẽ làm phức tạp mọi thứ vì có các công cụ phá mật khẩu zip ngoài kia.
Bart Silverstrim

Bây giờ tôi đang nghĩ rằng các khóa được mã hóa có thể là con đường để đi. Tôi vừa tải xuống PGP4win và xem qua hướng dẫn PGP4win cho Novices và nó đòi hỏi quá nhiều công việc cho người nhận (theo ý kiến ​​của tôi). Tôi muốn người nhận có thể nhập mật khẩu và được thực hiện với nó.
johnnyb10

3

Có phải nó chỉ cần được mã hóa trong quá trình (SMTP / TLS), hoặc trong bộ lưu trữ / tại các điểm cuối quá (PGP, v.v.) không?

Làm việc với các cơ quan lập pháp tương tự, tôi thường thiết lập PKI / SMTP / TLS giữa hai hoặc nhiều tổ chức thường xuyên gửi / nhận thông tin cá nhân / được bảo vệ; Tôi chỉ thiết lập một smarthost tại mỗi tổ chức phù hợp với các tên miền được đề cập để định tuyến thư qua đường hầm VPN giữa các trang khi áp dụng hoặc sử dụng SMTP / TLS để mã hóa thư trong quá trình chuyển đổi với Exchange.


Theo luật MA, đó chỉ là việc truyền tải cần được mã hóa. Nó chỉ định "mã hóa tất cả các bản ghi và tệp được truyền có chứa thông tin cá nhân sẽ truyền qua các mạng công cộng và mã hóa tất cả dữ liệu chứa thông tin cá nhân được truyền không dây."
johnnyb10

Sau đó, như tôi đã đề xuất, tùy thuộc vào mối quan hệ giữa các tổ chức, tôi đã thiết lập các đường hầm VPN giữa các trang web (với các quy tắc đường hầm hạn chế theo yêu cầu; họ cũng đã hợp tác để đường hầm là lựa chọn tốt nhất) hoặc thiết lập TLS trong Exchange với các chứng chỉ để mã hóa thư trong quá cảnh. Có một bài viết hay về cách làm này trong Exchange 2000/2003 từ Blog của Nhóm trao đổi MS ( msexchangeteam.com/archive/2006/10/04/429090.aspx )
gravyface

+1 vì cho phép mã hóa ở cấp máy chủ sẽ đáng tin cậy hơn nhiều so với việc dựa vào người dùng cuối để nhớ mã hóa nội dung khi cần thiết. Chính sách của bạn có thể sa thải những người dùng cuối không mã hóa dữ liệu cần thiết nhưng nếu họ tiết lộ thông tin họ không nên có, việc sa thải họ sẽ không xoa dịu các vị thần quy định - công ty của bạn vẫn đang gặp khó khăn.
icky3000

2

Bạn nên xem Tin nhắn an toàn với S / MIME và OWA trên Exchange Server 2007 SP1 Nếu bạn muốn mã hóa tin nhắn. Giải pháp này cũng yêu cầu thêm một bước vì người dùng phải chọn nút mã hóa (có lẽ cũng không hợp pháp vì bạn phải bằng cách nào đó cho rằng tất cả người dùng của bạn sẽ không bao giờ mắc lỗi và không mã hóa email mà họ nên có.) bạn cần làm là đảm bảo rằng các điểm đến mà bạn muốn gửi Massachusetts PII đang sử dụng TLS (bạn bắt buộc phải có thông tin đó vì bạn phải kiểm tra mọi người mà bạn có thể gửi Mass.PII theo CMR 17.04). Bạn cũng có thể nên viết một quy tắc vận chuyển sử dụng biểu thức chính quy để tìm kiếm Mass PII. Massachusetts PII được định nghĩa là sự kết hợp giữa tên và họ của một cư dân được kết nối với một trong những điều sau đây: Số bằng lái xe, số thẻ tín dụng hoặc số An sinh Xã hội.

Không có chủ đề nhưng mầm ...

Lưu ý cho những người đọc điều này và nghĩ rằng bạn thật may mắn khi không sống ở MA, Supawn! Nếu bạn lưu trữ thông tin cá nhân của một cư dân Massachusetts, bất kể bạn có sự hiện diện kinh doanh ở Massachusetts hay không, bạn phải chịu các hình phạt được quy định trong 201 CMR 17.00. có thể mất 100 đô la kỷ lục, với tối đa 50 nghìn đô la cho mỗi "sự cố". MA General Law 93H tuyên bố rằng sẽ có khoản tiền phạt 5.000 đô la cho mỗi lần "vi phạm". Nó chính xác nghĩa là gì? Tôi không nghĩ có ai biết và sẽ không cho đến khi ai đó bị nó tấn công.

Điều quan trọng cần lưu ý rằng đây không phải là một chủ đề dễ dàng - đây là ý kiến ​​của một cuộc thảo luận giữa tôi và Zypher về câu trả lời của anh ấy:

tôi: Sử dụng bất kỳ loại tùy chọn người dùng cuối nào sẽ mở ra cho bạn trách nhiệm pháp lý, không giống như PCI, luật pháp yêu cầu bạn phải nắm bắt mọi vấn đề hợp lý (như người dùng joe không sử dụng công nghệ)

Zypher: sử dụng pgp nếu người dùng không cung cấp cho bạn khóa, bạn không gửi cho họ. Về cơ bản, họ buộc phải sử dụng nó - trong trường hợp sử dụng này - nếu không thì họ A) Không nhận được dữ liệu hoặc B) không thể đọc dữ liệu.

tôi: làm thế nào bạn có thể đảm bảo rằng mọi người dùng gửi dữ liệu sẽ mã hóa mọi email? Giống như một giải pháp SMIME bạn phải chọn để mã hóa email của mình, nó không thể bị ép buộc - hoặc tôi đang thiếu thứ gì đó?

Zypher: Nó khá đơn giản, nếu bạn gửi một email chứa thông tin cần được mã hóa mà không mã hóa nó, bạn sẽ bị đuổi việc (theo ý muốn, điều này có nghĩa là không có thất nghiệp). Không phải tất cả mọi thứ cần phải là một giải pháp kỹ thuật. Từ câu hỏi này sẽ không được thực hiện quá thường xuyên nên một giải pháp liên quan hơn có lẽ không đáng giá / chi phí. Nếu họ cần làm điều này cả ngày mỗi ngày, tôi sẽ ủng hộ việc không sử dụng email, và chuyển sang các biểu mẫu trực tuyến qua SSL.

tôi: IANAL - nhưng tôi bế tắc lắng nghe họ, luật pháp nói rõ rằng đó phải là một giải pháp công nghệ - "nhưng tôi đã có một chính sách" là bằng chứng thực tế cho thấy một trong những vấn đề "có thể thấy trước được" mà bạn phải giảm thiểu không được giảm nhẹ. Kỷ luật người vi phạm cũng là một phần của pháp luật. Hãy xem thông tin thảo luận nàyweek.com/blog/main/archives/2009/02/

Zypher: Trên thực tế nếu bạn đọc 17.03.2.b (ở đây: mass.gov/Eoca/docs/idtheft/201CMR1700reg.pdf ) Tôi có một chính sách và đào tạo người của mình về nó, cũng như có các biện pháp kỷ luật thực sự hoàn toàn có thể phòng thủ được. Trong thực tế, đề cập duy nhất về một giải pháp kỹ thuật là để ngăn chặn nhân viên bị chấm dứt truy cập hồ sơ. IAANAL (Tôi cũng không phải là luật sư).

tôi: - 1,2,3 chỉ đơn giản là những thứ được dự kiến ​​sẽ không bao gồm các giải pháp dứt khoát, 2b là từ ngữ cụ thể được áp dụng (tôi đã lừa dối và hỏi luật sư). Nếu bạn phải nói "Tôi có thể bảo vệ điều đó" thì tòa án có thể sẽ nghiền nát bạn. Với các vấn đề tuân thủ, bạn phải chứng minh rằng bạn đang theo dõi regs. Các reg đặc biệt nói "có thể thấy trước". Nếu bạn đứng trước tòa và nói "tốt nếu ai đó vi phạm chính sách mà họ sẽ bị sa thải" thì việc truy tố chỉ đơn giản là nói "Vì vậy, bạn thừa nhận rằng bạn đã thấy trước một cách để chính sách này bị vi phạm và không có biện pháp hợp lý nào để loại bỏ vấn đề?"

Zypher: Chết tiệt bạn vì gian lận. Bây giờ chúng tôi phải xác định hợp lý là tốt, hợp lý cho công ty của tôi (nhân viên đa quốc gia lớn với 100 nghìn nhân viên) không giống như đối với một cửa hàng mẹ và cửa hàng pop. Nhưng trên cùng một mã thông báo đó, tôi nghĩ rằng chúng ta đang đi quá xa so với nhiệm vụ Hỏi và Đáp của trang web ... thật không may vì cuộc thảo luận này đã cung cấp một số hiểu biết tốt.

tôi: đó là "hợp lý có thể thấy trước" không "an toàn hợp lý" hoặc thậm chí hợp lý để thực hiện. Hãy nhớ rằng về mặt pháp lý, sử dụng rot13 trên tên người và không có gì khác tuân theo becuase tiêu chuẩn là một hình thức mã hóa. Cuộc thảo luận này rất hữu ích vì vậy tôi sẽ chỉnh sửa câu trả lời của mình để đưa nó vào để nó không bị mất.


1

GPG có các tiện ích cho windows và plugin cho ứng dụng email (chủ yếu là triển vọng và eudora): http://openpgp.vie-privee.org/gnupg-win.htmlm Nó sẽ đáp ứng nhu cầu của bạn Tôi hy vọng bạn chỉ cần nhấp chuột phải và "mã hóa", không yêu cầu CLI :)


bạn cũng có thể thử cái này www3.gdata.de/gpg/doad.html
Razique

gpg4win.org - Giao diện cửa sổ GNUPG chính thức. Có một plugin triển vọng như là một phần của gói.
Zypher

1

Bạn có thể thử cổng mã hóa email Djigzo (từ chối trách nhiệm: Tôi là tác giả của Djigzo). Cổng mã hóa email Djigzo là một máy chủ email được quản lý tập trung (MTA) mã nguồn mở dựa trên các tiêu chuẩn nguồn mở mã hóa và giải mã email đến và đi của bạn ở cấp độ cổng. Cổng mã hóa email Djigzo hiện hỗ trợ hai tiêu chuẩn mã hóa: email được mã hóa S / MIME và PDF. S / MIME cung cấp xác thực, tính toàn vẹn của tin nhắn và không thoái thác (sử dụng chứng chỉ X.509) và bảo vệ chống lại việc chặn tin nhắn. S / MIME sử dụng mã hóa khóa công khai (PKI) để mã hóa và ký. Mã hóa PDF có thể được sử dụng như một giải pháp thay thế nhẹ cho mã hóa S / MIME. PDF cho phép bạn giải mã và đọc các tài liệu PDF được mã hóa. Tài liệu PDF thậm chí có thể chứa tệp đính kèm được nhúng trong tệp PDF được mã hóa.

Cổng mã hóa email Djigzo có CA tích hợp mà bạn có thể sử dụng để cấp chứng chỉ X.509 cho người dùng nội bộ và bên ngoài. Người dùng bên ngoài có thể sử dụng chứng chỉ với bất kỳ ứng dụng email khách có khả năng S / MIME nào như Outlook, Outlook express, Lotus Notes, Thunderbird, Gmail, v.v.

Bởi vì Cổng mã hóa email Djigzo hoạt động như một máy chủ email SMTP chung, nó tương thích với các cơ sở hạ tầng email hiện có như Microsoft Exchange và Lotus Notes. Djigzo có thể được cài đặt bằng một trong các gói được cung cấp cho Ubuntu Linux, Debian, Red Hat và CentOS. Sẵn sàng để chạy "Thiết bị ảo" cho VMware ESX và Workstation.

Bởi vì nó là nguồn mở, nó có thể được sử dụng tự do. Nguồn và gói nhị phân có thể được tải xuống từ trang web của chúng tôi (www.djigzo.com).


Tôi vừa mới thiết lập Djigzo ngày hôm qua. Với Ubuntu 12.04, nó thực sự dễ dàng (có vấn đề với 12.10). Nó được dự định để sử dụng như một cổng mã hóa và nó hoạt động rất tốt. Nhưng việc tích hợp nó với một máy chủ Postfix hiện tại khá đơn giản, do đó không cần một máy chủ riêng để lưu trữ cổng mã hóa nếu bạn đang sử dụng Postfix.
David

1

Trên thực tế, luật nói để mã hóa dữ liệu senstive, không nhất thiết phải là tin nhắn. Nếu dữ liệu là một tệp (và thực tế là như vậy), thì phương pháp dễ nhất là chỉ mã hóa tệp.

Giả sử mục tiêu của bạn là một giải pháp cực kỳ dễ sử dụng và triển khai sẽ hoạt động trên cơ sở khách hàng đa dạng của bạn ....

Thuật sĩ mã hóa của Phòng thí nghiệm nghiên cứu không quân Hoa Kỳ ( http://spi.dod.mil/ewizard.htm ) là miễn phí, được mã hóa tập tin đơn giản, được công nhận bởi DoD. Nó xử lý mật khẩu, thẻ thông minh chứng chỉ. Xóa an toàn của nó có thể xóa tập tin senstive từ một máy tính công cộng.

Ngoài việc có Java, không có gì để cài đặt hoặc cấu hình trên cả hai máy tính - chỉ cần chạy tệp .jar. Thuật sĩ mã hóa chạy trên Mac, Windows, Linux, Sun và các hệ điều hành khác chạy Oracle Java.

Với EW, từ số 0, bạn có thể mã hóa và gửi tệp w / trong một phút và người nhận có thể giải mã trong cùng một khoảng thời gian (giả sử bạn sử dụng chứng chỉ hoặc gọi cho người đó bằng mật khẩu.)

Có những giải pháp lớn, nội bộ doanh nghiệp tốt hơn nhưng chúng tôi không tìm thấy gì tốt hơn có thể làm việc cho hầu hết mọi người mọi lúc mọi nơi.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.