回答編集履歴
3
修正
test
CHANGED
|
@@ -10,6 +10,10 @@
|
|
|
10
10
|
|
|
11
11
|
逆に、自分しか触らない＆秘密鍵とパスフレーズが十分に安全なのでそういう対策は要らないと言うことも言えます。
|
|
12
12
|
|
|
13
|
+
（実際、割と規模が大きめでセキュリティ要件の厳しいところでも固定IPによる接続元制限＋鍵認証だけで踏み台サーバを用意しないケースもあったりします）
|
|
14
|
+
|
|
15
|
+
|
|
16
|
+
|
|
13
17
|
|
|
14
18
|
|
|
15
19
|
ですので、それぞれの施策によってどういう要件が満たされるのかという観点で考えてみて下さい。
|
|
@@ -20,31 +24,63 @@
|
|
|
20
24
|
|
|
21
25
|
---
|
|
22
26
|
|
|
23
|
-
1.
|
|
24
27
|
|
|
25
|
-
例えば100台のEC2があった場合、そもそも必要の無いインスタンスにはパブリックIPを付けない方が考える事が減り管理が楽になります。
|
|
26
28
|
|
|
29
|
+
> 1. 接続元のPCを踏み台サーバーに限定することで不特定多数の外部からのアクセスを制限できる。踏み台サーバーへの接続も特定のIPアドレスに制限する
|
|
30
|
+
|
|
31
|
+
>
|
|
32
|
+
|
|
27
|
-
|
|
33
|
+
> 1に関して、そもそも接続先のサーバーへのアクセスを自分のネットワークのIPに限定することで解決しませんか？
|
|
34
|
+
|
|
35
|
+
> 二度手間のように思えてしまいます
|
|
28
36
|
|
|
29
37
|
|
|
30
38
|
|
|
31
|
-
|
|
39
|
+
例えば100台のEC2があった場合、そもそも必要の無いインスタンスにはパブリックIPを付けない方が考える事が減り管理が楽になるなど、いくつもメリットがあります。
|
|
32
|
-
|
|
33
|
-
99台のプライベートIPしか持たないサーバ
|
|
34
|
-
|
|
35
|
-
という構成にした場合は踏み台サーバが必須になります。
|
|
36
40
|
|
|
37
41
|
|
|
38
42
|
|
|
43
|
+
具体的には
|
|
44
|
+
|
|
45
|
+
- 踏み台サーバが起動していないという事さえ確認出来れば、外からのアクセスを完全無効化出来る
|
|
46
|
+
|
|
47
|
+
- インターネットに出る時の経路を絞れるので内部→外部への不正アクセスも防ぎやすい
|
|
48
|
+
|
|
49
|
+
- 純粋に管理する項目が減るので、管理ドキュメントの更新運用のコストが下がる
|
|
50
|
+
|
|
39
|
-
|
|
51
|
+
- 踏み台のユーザーを削除すれば、そのユーザーは確実に内部のインスタンスにはログイン出来なくなるので、管理者の退職や鍵の漏洩の際の初手が迅速に打てる（内部インスタンスの認証をどう管理するかはまた別の観点ですが、少なくとも「ログインを禁止する」ような対応がすぐに取れる）
|
|
40
52
|
|
|
41
53
|
|
|
42
54
|
|
|
55
|
+
等です。
|
|
43
56
|
|
|
44
57
|
|
|
45
58
|
|
|
59
|
+
こういったメリットが優先順位の高い要件と合致した場合は
|
|
46
60
|
|
|
61
|
+
1台のパブリックIPを持つ踏み台サーバと99台のプライベートIPしか持たないサーバという構成にする
|
|
62
|
+
|
|
63
|
+
という選択肢の妥当性が向上します。
|
|
64
|
+
|
|
65
|
+
|
|
66
|
+
|
|
67
|
+
別の観点だと、
|
|
68
|
+
|
|
69
|
+
99台のうち、管理責任を分担する場合(一部のセキュリティ要件が緩いor厳しいサーバだけ管理を外部に任せるとか)は踏み台サーバを分ければ、責任分界点の設定が楽になったりもします。
|
|
70
|
+
|
|
71
|
+
|
|
72
|
+
|
|
47
|
-
|
|
73
|
+
---
|
|
74
|
+
|
|
75
|
+
|
|
76
|
+
|
|
77
|
+
> 2. 通常時は踏み台サーバーを停止させておくことでメンテナンス時以外は目的のサーバーに到達できないようにする
|
|
78
|
+
|
|
79
|
+
> 2に関して、ただ時間帯による制限を増やしただけで本質的にセキュリティの向上になっている気がしません
|
|
80
|
+
|
|
81
|
+
> また、踏み台サーバーを停止・起動させる作業が必要であるならば、そもそもAWSのコンソールからインターネットからのアクセスをON・OFFすれば良いように思えます
|
|
82
|
+
|
|
83
|
+
|
|
48
84
|
|
|
49
85
|
セキュリティに完璧はありませんが、別の層で防御することによる効果はあります。
|
|
50
86
|
|
|
@@ -52,22 +88,32 @@
|
|
|
52
88
|
|
|
53
89
|
例えば、
|
|
54
90
|
|
|
55
|
-
sshでログインする人はマネジメントコンソールにログイン出来ず、踏み台サーバ起動には別の人の許可が必要
|
|
91
|
+
- sshでログインする人はマネジメントコンソールにログイン出来ず、踏み台サーバ起動には別の人の許可が必要
|
|
56
92
|
|
|
93
|
+
|
|
94
|
+
|
|
57
|
-
という
|
|
95
|
+
という運用にすれば、SSHで管理する役割の人が酔っ払って秘密鍵とパスフレーズをセットで無くしても悪用される前に対処が可能になります。
|
|
58
96
|
|
|
59
97
|
(このインシデントは結構発生しているので、どこでも何らかの対応をしています)
|
|
60
98
|
|
|
61
99
|
|
|
62
100
|
|
|
63
|
-
同じ人がインスタンス起動とsshログインを出来る場合でも、
|
|
101
|
+
- （同じ人がインスタンス起動とsshログインを出来る場合であっても、）マネジメントコンソールへのログインにMFAを必須とする運用にすれば、秘密鍵とパスフレーズとマネジメントコンソールのIDとパスワードとMFAデバイスを全部セットで盗まれない限りは悪用されない
|
|
102
|
+
|
|
103
|
+
- 踏み台インスタンスが起動したらアラートを上げるようにして、事前申請が無い場合は問答無用で踏み台サーバを落とす
|
|
64
104
|
|
|
65
105
|
|
|
66
106
|
|
|
67
|
-
踏み台インスタンスが起動したらアラートを上げるようにして、事前申請が無い場合は問答無用で踏み台サーバを落とす
|
|
68
|
-
|
|
69
|
-
|
|
107
|
+
と言う様な運用を設計することが出来ます。
|
|
70
108
|
|
|
71
109
|
|
|
72
110
|
|
|
111
|
+
> 踏み台サーバーのメリットがいまいちわかりません
|
|
112
|
+
|
|
113
|
+
|
|
114
|
+
|
|
115
|
+
前述のとおりですが、強いて言うなら、
|
|
116
|
+
|
|
73
|
-
|
|
117
|
+
発生するコストに対して運用をセキュアに保つ効果が高い。運用設計に柔軟度が生まれる
|
|
118
|
+
|
|
119
|
+
と言うところでしょうか。
|
2
追記
test
CHANGED
|
@@ -36,6 +36,12 @@
|
|
|
36
36
|
|
|
37
37
|
|
|
38
38
|
|
|
39
|
+
99台のうち、管理責任を分担する場合(一部のセキュリティ要件が緩いor厳しいサーバだけ管理を外部に任せるとか)は踏み台サーバを分ければ、責任分界点の設定が楽になったりもしますね。
|
|
40
|
+
|
|
41
|
+
|
|
42
|
+
|
|
43
|
+
|
|
44
|
+
|
|
39
45
|
|
|
40
46
|
|
|
41
47
|
2
|
1
修正
test
CHANGED
|
@@ -6,9 +6,13 @@
|
|
|
6
6
|
|
|
7
7
|
。
|
|
8
8
|
|
|
9
|
-
要件なし極論を話し出すと関係者全員が脅迫されるところまで考える必要が出てきてしまいますし、
|
|
9
|
+
要件なしで極論を話し出すと関係者全員が脅迫されるところまで考える必要が出てきてしまいますし、
|
|
10
10
|
|
|
11
|
-
逆に自分しか触らない＆秘密鍵とパスフレーズが十分に安全なのでそういう対策は要らないと言うことも
|
|
11
|
+
逆に、自分しか触らない＆秘密鍵とパスフレーズが十分に安全なのでそういう対策は要らないと言うことも言えます。
|
|
12
|
+
|
|
13
|
+
|
|
14
|
+
|
|
15
|
+
ですので、それぞれの施策によってどういう要件が満たされるのかという観点で考えてみて下さい。
|
|
12
16
|
|
|
13
17
|
|
|
14
18
|
|
|
@@ -46,6 +50,18 @@
|
|
|
46
50
|
|
|
47
51
|
という感じにすれば、SSHで管理する役割の人が酔っ払って秘密鍵とパスフレーズをセットで無くしても悪用される前に対処可能です。
|
|
48
52
|
|
|
53
|
+
(このインシデントは結構発生しているので、どこでも何らかの対応をしています)
|
|
54
|
+
|
|
49
55
|
|
|
50
56
|
|
|
51
57
|
同じ人がインスタンス起動とsshログインを出来る場合でも、例えばマネジメントコンソールへのログインにMFAを必須とすれば、秘密鍵とパスフレーズとマネジメントコンソールのIDとパスワードとMFAデバイスを全部セットで盗まれない限りは悪用されないことになります。
|
|
58
|
+
|
|
59
|
+
|
|
60
|
+
|
|
61
|
+
踏み台インスタンスが起動したらアラートを上げるようにして、事前申請が無い場合は問答無用で踏み台サーバを落とす
|
|
62
|
+
|
|
63
|
+
みたいな事も割と簡単に出来ます。
|
|
64
|
+
|
|
65
|
+
|
|
66
|
+
|
|
67
|
+
という感じ、必要な時だけ踏み台サーバを起動すると便利な事が結構あるので、採用されやすい施策なんだと思っています。
|