回答編集履歴
1
校正・追記
test
CHANGED
|
@@ -38,7 +38,39 @@
|
|
|
38
38
|
|
|
39
39
|
|
|
40
40
|
|
|
41
|
+
既製品のどんなシステムも結局Webサーバのマシンがハッカーの手に落ちて抜かれたらアウトです。
|
|
42
|
+
|
|
43
|
+
|
|
44
|
+
|
|
45
|
+
個人開発のような人生オワタを避ける為に究極的には持たないというアプローチは有効です。
|
|
46
|
+
|
|
47
|
+
ログインせざるを得ないサービスを開発する場合でも、
|
|
48
|
+
|
|
49
|
+
GoogleのFirehoseやAWSのcognitoといったサービスに委託して極力持たなかったり、
|
|
50
|
+
|
|
51
|
+
OAuthのようなGoogleやTwitterのサービスのログイン情報を間借りする形がよく取られるアプローチです。
|
|
52
|
+
|
|
53
|
+
|
|
54
|
+
|
|
55
|
+
例えば企業ではリスクをとって個人情報を抱える決断を行い、
|
|
56
|
+
|
|
57
|
+
パスワードのような要らない情報は`SHA-1`のようなハッシュ化で潰してしまうといった対策になります。
|
|
58
|
+
|
|
59
|
+
これで万が一漏洩してもちょっとだけ安心。
|
|
60
|
+
|
|
61
|
+
|
|
62
|
+
|
|
63
|
+
Webサービスのセキュリティのアドバイスなんかを行ってくれる会社なんてのもありますから、
|
|
64
|
+
|
|
65
|
+
個人情報を抱える必要はあるが、漏洩するとヤバイケースでは利用することも視野に入れましょう。
|
|
66
|
+
|
|
67
|
+
|
|
68
|
+
|
|
69
|
+
---
|
|
70
|
+
|
|
71
|
+
|
|
72
|
+
|
|
41
|
-
問題は情報が勝手になくなったりしない
|
|
73
|
+
問題は**情報が勝手になくなったりしない**方で、
|
|
42
74
|
|
|
43
75
|
fsでの個人情報の管理は相当神経質に実装する必要があります。
|
|
44
76
|
|
|
@@ -64,17 +96,17 @@
|
|
|
64
96
|
|
|
65
97
|
- ファイルをロックしたプロセスが解除する前にエラーで落ちてロックしっぱなしになる
|
|
66
98
|
|
|
67
|
-
- A
|
|
99
|
+
- AとBの2ファイルをロックしたいプロセスが2個あり、それぞれのプロセス片方のファイルをロックしてしまいお見合いしたまま一生解除待ちになる(デッドロック)
|
|
68
100
|
|
|
69
101
|
- 上記を高度に解決しつつ高速なファイルの読み書き
|
|
70
102
|
|
|
71
103
|
|
|
72
104
|
|
|
73
|
-
その辺の問題に立ち向かった人類の汗と涙の
|
|
105
|
+
その辺の問題に立ち向かった人類の汗と涙の結晶がMySQL等の関係データベースです。
|
|
74
106
|
|
|
75
|
-
teratailにも沢山エンジニアが居ますが、MySQLに匹敵するようなファイルベースの読み書きロジックをほいと作れるような人間なんて居ないと言い切って良いでしょう。
|
|
107
|
+
teratailにも沢山プロのエンジニアが居ますが、MySQLに匹敵するようなファイルベースの読み書きロジックをほいと作れるような人間なんて居ないと言い切って良いでしょう。
|
|
76
108
|
|
|
77
|
-
まさに人生を
|
|
109
|
+
まさに人生を賭けた大プロジェクトになるわけですよ。
|
|
78
110
|
|
|
79
111
|
|
|
80
112
|
|
|
@@ -82,4 +114,4 @@
|
|
|
82
114
|
|
|
83
115
|
広く公開して不特定多数の人に使ってもらう事がゴールならば、
|
|
84
116
|
|
|
85
|
-
絶対にやめとけ、既製品使えとアドバイスします。
|
|
117
|
+
**絶対にやめとけ、既製品使え**とアドバイスします。
|